Which should a nonprofit or sales-led team choose, SuiteCRM or CiviCRM?
Choose SuiteCRM when the core work is pipeline, quotes, service cases and campaigns for a sales or service team that manages deals and accounts. Choose CiviCRM when the core work is donor records, contributions, memberships and events for a nonprofit, NGO or advocacy organization. The decision turns on four things: the primary workload, whether a content management system already runs the website, the team's PHP and database skills, and how each release track fits the upgrade capacity you actually have. Neither platform is the better choice in general. A fundraising organization with a separate sales desk may need both tools, and that split should be planned on purpose rather than discovered later.
Start with the workload and the website. CiviCRM covers contributions, memberships, events, CiviMail, case management and contact management, and its download supports standalone use as well as Backdrop, Drupal 10 and later, Joomla 5 and later and WordPress. If your website already runs on one of these, confirm the CiviCRM release for that platform before anything else. If a Drupal 7 site is still in use, plan that move first, because CiviCRM warns that the Drupal project has ended support for Drupal 7. SuiteCRM 8.10 is a PHP application on MySQL or MariaDB with Apache 2.4, supporting PHP 8.2, 8.3 and 8.4, and its requirements do not include a CMS. CiviCRM 6.16 and later need PHP 8.3, 8.4 or 8.5 and MySQL 5.7.5 or later or MariaDB 10.2 or later, and PostgreSQL is not compatible, so a PostgreSQL shop should settle that before it starts.
Release tracks set the upgrade workload. CiviCRM's standard version is released monthly and is free to use, while its Extended Security Release comes out every six months as a subscription priced by organization budget, from US$360 to US$1,440 a year, according to CiviCRM. SuiteCRM 8 minor releases arrive roughly every eight weeks, and its patch releases contain only security and bug fixes. SuiteCRM 7.15 receives security fixes until January 2028. If you already run SuiteCRM 7, moving to 8 is a migration with a new environment, a staging test, full backups and a customization review, so treat it as its own project. Before you commit, confirm which track your administrators can keep current, the ESR price band for your organization, and who will own the PHP, CMS and database upgrades. SuiteCRM LTS and release lifecycle
Which scenario points to SuiteCRM and which to CiviCRM?
This table maps common nonprofit and services scenarios to the platform whose modules fit them, so the answer depends on contributions, memberships, events and cases rather than on brand familiarity. Read each row by asking which data the team must hold first, because that data should anchor the system. Most teams with a pure fundraising or membership need will land on CiviCRM, while services firms and sales-led organizations fit SuiteCRM better.
| Scenario | Better fit | Why, in terms of modules |
|---|---|---|
| Membership body with annual renewals and dues | CiviCRM | Memberships, contributions and contact records sit in one constituent model, so renewals and payment history stay linked to each member. |
| Peer-to-peer fundraising campaign with donor pages | CiviCRM | CiviCRM lists contributions and peer-to-peer fundraising among its core features, which covers donor tracking directly. Confirm the exact peer-to-peer tooling in your chosen host and extensions. |
| Services firm tracking quotes, cases and accounts | SuiteCRM | SuiteCRM's sales and service modules cover pipelines, quoting paths and case handling, which are built for client-facing revenue work. |
| Advocacy group running events, email and case work | CiviCRM | Events, CiviMail email marketing and case management are part of CiviCRM's core feature set, so one database covers outreach and follow-up. |
| Sales team with pipeline reporting and an ERP-style customer record | SuiteCRM | SuiteCRM is built around sales opportunities and account records, so pipeline stages and customer history are the primary objects. |
| Nonprofit with a website already on Drupal, WordPress or Joomla | CiviCRM | CiviCRM runs on these CMSs, so the site and donor database can share a host. Check the CMS version support in CiviCRM's download page before committing. |
| Mixed case: a nonprofit that also sells training or consulting | Both, with a plan | Anchor donor and membership records in CiviCRM and sales pipelines in SuiteCRM, then sync contacts through a defined integration. Illustrative only: decide the master record for each contact before building the sync. |
| Team with PostgreSQL skills and no PHP experience on the CMS | Confirm first | CiviCRM does not support PostgreSQL, while SuiteCRM runs on MySQL or MariaDB. Neither option suits a PostgreSQL-only shop without extra hosting work, so confirm the database standard before shortlisting. |
How SuiteCRM and CiviCRM are built and what that means for operations
SuiteCRM is a standalone PHP application, while CiviCRM is a CRM engine that runs inside a host content management system. That single difference decides who patches what, which database you can use, and how many moving parts your team must keep current. The cards below set out each component and the operational question it raises.
Standalone application stack
SuiteCRM 8 runs as its own PHP application on a web server and a relational database. You deploy, patch and back up one application and its stack. Its supported stack for the 8.10 line is Apache 2.4 with MariaDB or MySQL, so the team that already runs LAMP-style hosting can take it on without a new platform. Confirm that your web server and database versions appear on the compatibility matrix before you build the host.
CiviCRM as a host-dependent extension
CiviCRM is delivered standalone or inside Backdrop, Drupal, Joomla or WordPress. Your CMS is part of the CRM's runtime, so a CMS upgrade can break CiviCRM and a CiviCRM upgrade can depend on a CMS version. Choose the host before the CRM, and agree in writing who owns CMS patching, the CiviCRM release track and the test window for each.
Database requirements and PostgreSQL
SuiteCRM 8.10 supports MySQL 8.0 and 8.4 and MariaDB 10.6, 10.11, 11.4 and 11.8. CiviCRM 6.16 and later need MySQL 5.7.5 or later or MariaDB 10.2 or later, and PostgreSQL is not compatible. If your organization has standardized on PostgreSQL, CiviCRM is ruled out before any other comparison starts. Ask your database team which engine and version they will support for the life of the CRM.
PHP version support
SuiteCRM 8.10 supports PHP 8.2, 8.3 and 8.4. CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5. The overlap is 8.3 and 8.4, so a shared PHP runtime is possible, but the CMS you pick for CiviCRM may pin a different version. Check the PHP requirement of the host CMS and each CRM together, and plan PHP upgrades as one change window rather than two.
Who patches the CRM and the host
With SuiteCRM, your team or your provider patches the application, PHP and database directly. With CiviCRM, patching splits across the CMS, the CiviCRM extension and the database, and each has its own release cadence. CiviCRM's standard release is monthly, while its Extended Security Release arrives every six months. Decide which track you follow and who signs off each update, because mismatched layers are the most common source of outages on CMS-hosted tools.
Customization inside a CMS or a suite
Customizations to SuiteCRM live in the application's own module and configuration layers, and the migration guide warns that a move may remove non-core files under the public/legacy folder. CiviCRM customizations and extensions depend on the CMS hooks and templates beneath them. Ask any implementation partner to list every custom file and hook, then test each one on a staging copy after every upgrade.
How do SuiteCRM and CiviCRM compare on the capabilities that matter?
This table sets SuiteCRM's sales and service modules against CiviCRM's constituent-management features, row by row. Read each row with its condition: the difference only matters if your organization's daily work looks like the one described. Where the supplied facts are silent, the cell tells you what to confirm before you choose.
| Capability | SuiteCRM | CiviCRM |
|---|---|---|
| License | AGPL-3.0 for the SuiteCRM 8 core, per the SuiteCRM-Core LICENSE file. Confirm the terms of any SuiteCRM Ltd paid service you add. | AGPL-3.0 for civicrm-core, per the civicrm-core repository. Confirm license terms for any extension you install. |
| Core domain focus | Sales and service: pipelines, accounts, quotes-oriented workflows, cases and campaigns. Matters most when revenue and support teams drive the CRM. | Constituent relationship management for nonprofits, NGOs and advocacy groups. Matters most when donors, members and volunteers drive the CRM. |
| Contributions and fundraising | Not a listed core feature. Confirm whether a donation workflow is available through modules or add-ons before you rely on it. | Listed feature: contributions, plus peer-to-peer fundraising. Matters when gift processing and donor records are central. |
| Memberships | Not a listed core feature. Confirm with SuiteCRM Ltd or the community before relying on membership terms and renewals. | Listed feature: memberships. Matters when you manage renewals, membership tiers and dues. |
| Events | Confirm event registration and ticketing support in the SuiteCRM 8 module set for your version. | Listed feature: events. Matters when conferences, workshops or fundraising events need registration and attendance tracking. |
| Email marketing | Campaign modules are part of the sales and marketing scope. Confirm the sending and deliverability approach in your environment. | Listed feature: email marketing with CiviMail. Matters when you send newsletters and appeals from the same database as donor records. |
| Case management | Service and case handling is a core strength of the broad module set. Matters when support tickets and customer issues sit beside sales. | Listed feature: case management. Matters when staff or volunteers track client or beneficiary cases. |
| Reporting | Confirm the report builder and dashboards in your SuiteCRM 8 version. Matters when sales pipeline reporting is the priority. | Listed feature: reporting. Matters when grant, donor and campaign reporting drive board and funder reviews. |
| PHP and database versions | SuiteCRM 8.10 supports PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4 on Linux, Unix or macOS. Matters for choosing a host image. | CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5, and need MySQL 5.7.5 or later or MariaDB 10.2 or later. PostgreSQL is not compatible. Matters if your database standard is PostgreSQL. |
| Host CMS options | Runs as a standalone application. No CMS host is required. Matters when you want one self-hosted app with no CMS dependency. | Runs standalone, on Backdrop, Drupal 10 and later, Drupal 7, Joomla 5 and later, or WordPress. Drupal 7 support has ended. Matters for the choice of CMS and its upgrade path. |
| Sign-in options | LDAP (AUTH_TYPE=ldap) and SAML (AUTH_TYPE=saml). SAML does not support IdP-initiated logout, so an identity provider logout does not end the SuiteCRM session. | Depends on the chosen CMS and its login modules. Confirm SSO and directory options for your specific CMS before you commit. |
What the AGPL-3.0 licenses and release tracks cost each organization
SuiteCRM's core is licensed under AGPL-3.0, so you can download, self-host and modify the software without a per-seat license fee. The recurring cost question is who runs it. SuiteCRM Ltd sells paid services around the free software, including the SuiteASSURED support package, SuiteCRM Hosted, implementation, training and migration. These are separate agreements from the license, and they recur when you choose ongoing support or hosting.
- Core license: AGPL-3.0 covers the SuiteCRM 8 core repository. Confirm the terms of any add-on or extension you buy, since those may carry their own conditions.
- Paid vendor services: SuiteASSURED support, SuiteCRM Hosted, implementation, training and migration are sold by SuiteCRM Ltd. Ask which items are one-time and which renew.
- SuiteCRM 7 support window: SuiteCRM 7.15 is an extended support release with security fixes until January 2028. Plan any move off 7 around that date.
- SuiteCRM 8 release cadence: Minor 8.x releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes, with no new features or database changes. Budget test cycles for that rhythm.
- No SuiteCRM 8 extended support yet: No SuiteCRM 8 extended support release had been nominated, and SuiteCRM expects to name one by Q3 2027. Ask for the current position in writing before you commit.
Before you sign, ask SuiteCRM Ltd or your partner which services each quote includes, who applies patches between 8.x minor releases, and how support continues after the 7.15 window closes.
CiviCRM core is licensed under AGPL-3.0, and its standard version is released monthly and is free to download and use. The paid option is the Extended Security Release, a slightly older, stability-focused version released every six months. It is sold as a subscription priced by organization budget, from US$360 to US$1,440 a year. The decision is between a free track that changes often and a paid track that changes less often.
- Standard monthly release: The license cost is zero, but your team carries the upgrade frequency, testing and rollback planning for each monthly release.
- ESR subscription band: Per the CiviCRM Extended Security Release page, the subscription ranges from US$360 to US$1,440 a year depending on organization budget. Confirm which band applies to you in writing.
- What the subscription covers: The fee buys the release track, not hosting, configuration, extensions or a partner's testing time. Those remain separate line items.
- Cost drivers: The budget band, how many instances you run, and how much testing your partner must do each cycle all move the total. Ask whether the subscription renews automatically.
- Track rules to confirm: Check with CiviCRM whether an installation can move between the standard and ESR tracks without a rebuild, and whether an active subscription is required to receive security fixes.
Before you compare costs with SuiteCRM, request the release track, budget band, renewal terms and the testing your team must run for each cycle, all in one written quote.
CiviCRM can run standalone or as a component on Backdrop, Drupal 10 and later, Drupal 7, Joomla 5 and later, or WordPress. Each host adds its own web application, release cycle, hosting needs and license. The CMS license is separate from CiviCRM's AGPL-3.0 and must be checked with the CMS project, not assumed from CiviCRM's terms.
- Host choice sets the stack: Each CMS adds its own upgrade path and modules on top of the CiviCRM install, which increases the number of components your team patches.
- Drupal 7 support ended: CiviCRM warns that the Drupal project has ended support for Drupal 7. Running CiviCRM on Drupal 7 leaves the CMS layer without upstream support.
- Separate CMS license: Confirm the CMS license terms with the CMS project and with your legal team before deployment, because CiviCRM's license does not cover them.
- Extra patch surface: The CMS and its modules receive their own security fixes, adding testing effort on top of each CiviCRM release.
- Database and PHP requirements: CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5 and need MySQL 5.7.5 or later or MariaDB 10.2 or later. PostgreSQL is not compatible, which may rule out a shared database platform.
Before choosing a host, ask your implementation partner which CMS and PHP versions they will support and get the CMS license terms in writing, then compare the CiviCRM download page against the versions you plan to run.
What drives the running cost of SuiteCRM and CiviCRM
The running cost of either platform is mostly staff time and hosting, and the two products load those differently. SuiteCRM is a PHP application on MySQL or MariaDB, so the bill is driven by hosting for the application and database, by the people who administer PHP, web server and database, and by any SuiteCRM partner or support contract you buy. CiviCRM adds a layer on top: it runs inside a host CMS (Backdrop, Drupal, Joomla or WordPress) and needs MySQL or MariaDB, so you pay for the CMS upkeep, its security patching and its own skills as well as CiviCRM itself. Ask any implementer to price the CMS layer as a separate line, not folded into a single platform figure. Separate what you pay once from what recurs. One-time costs are implementation, data mapping, migration of existing contacts and history, and integration with mail, identity and finance systems. Recurring costs are hosting, support, the upgrade and regression testing that each release needs, and, if you choose it, the CiviCRM Extended Security Release subscription, which the CiviCRM ESR page prices by organization budget from US$360 to US$1,440 a year. Confirm the current ESR price with CiviCRM before you budget, since the figures above are the published range. Also confirm which CiviCRM release track and CMS version your chosen host supports, because a CMS upgrade can force a CiviCRM upgrade on a fixed schedule.
Upgrade and testing effort is the cost most often missing from early estimates. For SuiteCRM 8, the migration guidance tells you to test on a staging instance, back up files and database, and review customizations, because a migration may remove non-core files under the public/legacy folder. If you are still on SuiteCRM 7, the 7-to-8 move is a migration with its own cost, separate from routine upgrades. For CiviCRM, plan staging tests against each monthly standard release or the ESR cycle, and test the CMS upgrade together with it. When you request a quote, ask for these items in writing: the hosting specification and who operates it; which parts are one-time and which recur, with the renewal basis; the expected staff skills and whether they come from your team or the vendor; what the upgrade and regression testing covers per release; the CMS layer and its patching responsibility; and the exact terms of any support or ESR subscription. A DeployOpen quote follows from a written scope, so state your modules (for example, contributions, memberships, events or sales pipelines), your integrations and your hosting constraints up front.
How to move data between SuiteCRM and CiviCRM without losing donor history
This sequence moves contacts, gift records and service history between the two systems with a documented mapping, a tested staging run and a rollback path, so donor relationships survive the change intact.
Inventory data, customizations and integrations
The fundraising or operations lead and the platform administrator list every record type in the source system, including contacts, households or organizations, gifts, memberships, events, activities and cases, plus custom fields, workflows, email templates, reports and any connected tools such as payment processors or mailing services. Each item gets an owner and a note on whether it is needed after cutover. The step is done when the inventory is signed off and every record type has a named business owner.
Map contacts, households and relationships
The data lead maps how each source concept lands in the target. SuiteCRM organizes people and companies around accounts and contacts, while CiviCRM uses contacts with relationship types and household groupings, so the mapping must state which SuiteCRM relationships become CiviCRM relationships and which need a manual decision. Duplicate rules are agreed before any import. The step closes with a written field-by-field mapping that donor and service teams have reviewed.
Map gifts, memberships, activities and cases
Here the team decides how transactional history is represented. CiviCRM stores contributions, memberships and events as first-class records, whereas SuiteCRM handles sales opportunities, quotes, cases and activities through its own modules, so a SuiteCRM opportunity is not automatically a CiviCRM contribution. Each mapping rule states the target object, the date and amount fields, and how historical status such as lapsed or renewed is preserved. The check is a sample reconciliation that matches totals per donor and per year between the two systems.
Rebuild what does not transfer cleanly
Some items are rebuilt rather than moved: custom modules, workflow logic, email layouts, dashboards and any automation that relies on a SuiteCRM-specific structure. The administrator recreates them in CiviCRM using its own extensions and settings, and the fundraising lead signs off each rebuilt item against the original requirement. Confirm with CiviCRM and with your hosting provider which extensions and CMS integration your release track supports. The step is done when every item on the inventory is marked moved, rebuilt or retired.
Test the full migration on staging
The team runs the complete mapping and import on a staging copy of both environments, with the target built on the same PHP and database versions planned for production. Staff then check sample donor records, gift histories, membership renewals, open cases and user permissions. Defects go back into the mapping and the run repeats until results match the reconciliation. The step is done when a full staging run passes every check and the owners accept it in writing.
Back up files and database before cutover
The administrator takes a full backup of the source database and file system, plus a copy of the target environment, and verifies that each backup can be restored on a separate host. The migration guidance for SuiteCRM recommends backing up files and the database and reviewing customizations before any move, because a migration can remove non-core files. The step is complete when a restore test has succeeded and the backup locations and retention are documented.
Cut over with a documented rollback plan
The team freezes data entry in the source system for an agreed window, runs the final import, reconciles totals and points users and integrations to the new system. The rollback plan states the trigger for reverting, the steps to restore the source backup and who makes that call. Keep the source system read-only but intact until the business owners accept the result. The step closes when reconciliation matches and the rollback owner confirms the source remains recoverable.
Plan the reverse move before relying on the new system
Reversing the direction costs about as much as the original move, because the mapping, rebuilt items and staging work must be repeated in the opposite direction, and data created in the new system after cutover must be mapped back. Before go-live, ask each vendor or service provider how they support exports, what their supported migration paths are and whether they document the reverse mapping. The output is a written note in the project file that states these answers and the cost of a reverse move.
Where SuiteCRM and CiviCRM implementation projects usually run long
A SuiteCRM 8 project usually runs long at environment setup and customization review, not at the first login. Setup covers a new SuiteCRM 8 environment on PHP, Apache and either MariaDB or MySQL, with the version pairing taken from the compatibility matrix for the release chosen. If the source is SuiteCRM 7, the work is a migration into a new environment, not an in-place upgrade, and the 7 instance must first be brought to the latest 7.14.x or later. Confirm the SuiteCRM 7 patch level, the list of custom modules, logic hooks and files under the public/legacy folder before estimating anything, because the migration docs warn that non-core files there may be removed. Ask the vendor or your implementer to inventory customizations in writing and to run the migration on a staging copy first.
A CiviCRM project runs long for different reasons. The first decision is the host CMS, and a legacy Drupal 7 site is the most common source of delay: the CiviCRM download page warns that Drupal has ended support for Drupal 7, so a move to a supported host often becomes a separate project before CiviCRM work can start. Extension configuration, payment processor setup and email sending (CiviMail) each depend on credentials and accounts that the client must provide, and each waits on the provider's approval steps. Data import is the other long pole. Donor and membership records with duplicate contacts, missing consent fields or inconsistent addresses take longer to clean than to load, so ask for a sample extract and a data quality review early.
Scope for either project should be agreed in writing before work starts. The client should supply named owners for finance, fundraising and IT, read and write access to the current systems, the list of payment and email providers, a clean data extract, and decisions on which customizations stay. Ask any implementer to state which items are assumed to be the client's responsibility and what happens if a dependency, such as a provider account or a Drupal upgrade, arrives late. Written scope with those dependencies named is the strongest protection against a project that overruns on the client side rather than the technical side.
What do buyers ask before choosing SuiteCRM or CiviCRM?
Is CiviCRM worth it if we only run pipelines and quotes?
Usually not. CiviCRM is built around constituent records, contributions, memberships, events and CiviMail, so a sales team that needs deal stages, quote generation and forecasting will spend effort building what SuiteCRM already includes. The reverse also holds: a fundraising office that tries to run donor stewardship and recurring gifts in SuiteCRM will need custom modules. Map your three most frequent daily tasks against each product before you compare prices, because that mapping decides most of the effort.
Does CiviCRM require a CMS to run?
CiviCRM runs standalone, but it also installs on Backdrop, Drupal 10 and later, Drupal 7, Joomla 5 and later, and WordPress. The CMS you choose sets the upgrade path, the security patch cadence and the people who can maintain the site. Drupal 7 is a risk to avoid for new work, since CiviCRM warns that the Drupal project has ended support for it. SuiteCRM has no CMS dependency, so the question does not arise there. Ask your CiviCRM integrator which host they recommend and who will patch it.
How long does a migration to SuiteCRM 8 take?
The duration depends on the size of your data, how many customizations you carry, and how many integrations must be rebuilt. SuiteCRM documents the move from 7 to 8 as a migration, not an in-version upgrade: you set up a new SuiteCRM 8 environment and move the SuiteCRM 7 data into it, after bringing the 7 instance to the latest 7.14.x or later. The migration docs advise testing on a staging instance and reviewing customizations, because the process may remove non-core files under the public/legacy folder. Ask any implementer for a written scope that lists each module, custom field and integration, and for a staging test plan before agreeing a timeline.
What does SuiteCRM 8 migration mean for a SuiteCRM 7 instance?
It means a new environment, a data move and a regression test, not a simple patch. SuiteCRM 7.15 is an extended support release with security fixes until January 2028, and SuiteCRM has not yet nominated an extended support release for the 8 line, with plans to name one by Q3 2027. Staying on 7 buys time, but your team should plan the move on a schedule it controls. The SuiteCRM 8 compatibility matrix lists PHP 8.2 to 8.4, MariaDB or MySQL, and Apache 2.4, so check your current host against those versions first.
Is the CiviCRM Extended Security Release worth paying for?
It depends on how much you value a stable, slower release track over a monthly one. The standard CiviCRM version is released monthly and is free to download and use. The Extended Security Release is a slightly older, stability-focused version released every six months, sold as a subscription priced by organization budget from US$360 to US$1,440 a year, according to CiviCRM's ESR page. Compare that fee with the staff time you spend testing monthly releases and with the risk of running a version your integrators have not validated. Ask the vendor which tier applies to your budget and what the subscription covers.
Can our own team run SuiteCRM or CiviCRM without outside help?
A team with PHP, web server and MySQL or MariaDB skills can run either product, but the ongoing work is what decides it. For SuiteCRM, that means patching the application through minor and security releases, maintaining staging copies, and handling the LDAP or SAML sign-in configuration. For CiviCRM, it adds the CMS layer and the extension set. Note that CiviCRM requires MySQL 5.7.5 or later or MariaDB 10.2 or later, and PostgreSQL is not compatible. Decide who owns each recurring task on paper before you commit.
What should we ask for in a written quote for either CRM?
Ask for a fixed scope that names each module, data source, integration, custom field and report, plus the environments to be built, such as staging and production. Request the cost of data migration, of training, and of the first year of patching and support, and separate those from one-time setup. For CiviCRM, ask which CMS and release track are assumed and whether an ESR subscription is included. For SuiteCRM, ask whether the quote covers the 7 to 8 migration and any SAML or LDAP work. DeployOpen plans, implements and supports open-source platforms in your own infrastructure and works from a written scope, so ask any provider to show exactly what is excluded.
How DeployOpen helps teams choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a SuiteCRM vs CiviCRM decision, we start by confirming which workload leads, whether that is pipelines and quotes or donors, memberships and events, before any build work begins.
How we scope
- Confirm whether sales pipelines, service cases or donor, membership and event records drive the decision
- Map the hosting stack, including whether a CMS such as Drupal, WordPress or Joomla is already in place
- Agree the scope, deliverables and timelines in writing before work starts, with a quote following from that scope
How we build
- Install and configure the chosen platform inside your cloud account, data center or air-gapped network
- Set up identity integration, roles and permissions, and integrations with email, payments or existing systems in scope
- Test customizations on a staging instance and document the build so upgrades can be planned against it
How we hand over
- Deliver the runbook, configuration documentation, backup and restore procedures and the list of customizations
- Walk your administrators through daily operation, user management and the upgrade process for the release line you chose
- Provide evidence and controls documentation that your own auditors or assessors can review, noting that DeployOpen does not issue audit reports
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Retainers can cover platform patching, backup verification and reviews when new releases or CMS versions arrive
- Confirm response expectations and what a retainer includes in the written agreement before go-live
