CiviCRM standalone vs WordPress vs Drupal: when each host fits
Choose Standalone when the CRM is the centre of the work and you do not want a content management layer in the middle. If your nonprofit or membership body already runs a website elsewhere, or you only need CiviCRM for contacts, contributions, events and CiviMail, Standalone keeps one application to patch, back up and monitor. Your public pages stay on whatever site you run today, and forms can be embedded or linked. WordPress fits when your team already runs a WordPress site and staff who can maintain it, since CiviCRM's WordPress build lets members and donors sign in with the accounts they already have. Drupal fits when you have Drupal skills in-house, or the site needs complex content structures, workflows or permissions that a CRM-first team would otherwise build by hand. Confirm which CiviCRM build your host supports in the CiviCRM download page, which lists Backdrop, Drupal, Joomla, WordPress and Standalone.
If you run Drupal 7 today, plan a migration, not an in-place update. Drupal.org documents that Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. They are migrated into a new site using the core Migrate modules or Drush, and themes must be rebuilt. Drupal 7 security support ended on January 5, 2025, so any interim hosting decision should account for an extended support provider, and CiviCRM warns Drupal 7 users about this. Ask your vendor or agency to estimate the rebuild of the theme and any custom modules before you commit to the host. On the WordPress side, WordPress.org states that only the latest version is officially supported, though its security team backports critical fixes to older versions, so confirm your update policy with the people who will run the site.
Run a short pilot on your own data before you choose. Install the candidate host on a non-production copy of your site, import a sample of contacts, create one contribution page and one event with a payment and a webform, then test a member login, a password reset and the backup restore. Record who maintains each layer: the CMS core, the CiviCRM extensions and the server. Ask for a written quote that lists the migration, theming, identity integration and upgrade effort separately, since those drive the cost of every option. The choice is usually settled by whether your staff can maintain the host you pick for the next several years.
How the three hosts compare on the factors that matter
This table sets CiviCRM Standalone against WordPress or Drupal on license, releases, PHP, database, sign-in and public pages, and support windows. Read each row as a check on your own hosting stack, since a single mismatch in PHP or database can rule out an option. The main takeaway is that Standalone keeps the stack narrow, while a CMS host adds its own upgrade track and plugin or module decisions.
| Factor | Option A: CiviCRM Standalone | Option B: WordPress or Drupal |
|---|---|---|
| License | CiviCRM core is AGPL-3.0. | WordPress is GPLv2 or later. Drupal is GPL-2.0-or-later, with no paid edition of Drupal itself. |
| Current releases | CiviCRM 6.19.1 is the current download, with a standard monthly release. | WordPress 7.1.3 is the latest 7.1 release cited. Drupal 11 is current, and Drupal 12 is scheduled for the week of December 7, 2026. |
| PHP requirements | CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5. | WordPress recommends PHP 8.3 or greater. Drupal 11 needs PHP 8.3 or later, and Drupal 12 needs PHP 8.5 or later. |
| Database support | MySQL 5.7.5 or later or MariaDB 10.2 or later. PostgreSQL is not compatible. | WordPress recommends MariaDB 10.11 or later or MySQL 8.0 or later. Drupal supports MariaDB, MySQL, PostgreSQL or SQLite. |
| Users and sign-in | Confirm the login and single sign-on options in the CiviCRM documentation for your version before you choose. | Drupal has contributed SAML (samlauth) and OpenID Connect modules. WordPress sign-in options depend on the plugins you add. |
| Public pages and forms | Confirm how public pages and forms are themed and placed on your own domain. | Public pages sit inside the CMS and use its theme system. Drupal CMS adds recipes and a visual page builder. |
| Support window | The standard release is monthly. The Extended Security Release is a six-monthly paid subscription. | WordPress maintains only its latest release line. Drupal 10 reaches end of life on December 9, 2026. |
How CiviCRM sits inside each host
Every CiviCRM deployment has the same core parts: the CiviCRM application, its database, a web server with a PHP runtime, and the pages visitors see. Hosting CiviCRM inside a CMS adds a second application layer with its own logins, updates and release calendar, which is where the two options diverge.
CiviCRM application and database
CiviCRM core is the same codebase whichever host you choose, and it stores contacts, contributions, memberships and events in its own database. CiviCRM 6.16 and later need MySQL 5.7.5 or later or MariaDB 10.2 or later, and PostgreSQL is not compatible. Check that your database engine and version match this requirement before you commit to any host, and confirm how your chosen host backs up that database.
Host CMS, theme and modules
On WordPress, Drupal, Joomla or Backdrop, CiviCRM runs as an extension of the CMS, so the CMS plugin or module set, theme and CiviCRM extensions must all be compatible with each other. Each CMS version has its own supported module list, so a CMS upgrade can break a form, theme or extension even when CiviCRM itself is current. Standalone avoids this layer but gives you no content management.
Web server and PHP runtime
WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, and Drupal 11 requires PHP 8.3 or later. CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5. Where the CMS and CiviCRM share one PHP runtime, the oldest PHP requirement sets the floor for the whole site, so confirm the PHP version your host allows before you plan any upgrade.
User logins and identity
A CMS brings its own user table, so staff and contacts can end up with separate accounts for the website and for CiviCRM. Drupal can federate logins through contributed modules such as the SAML Authentication module (samlauth) or OpenID Connect modules, which create accounts on first sign-in. Confirm which login source your staff will use, how CiviCRM permissions map to CMS roles, and who removes access when someone leaves.
Public pages and forms
Donation forms, event registration, membership sign-up and profile pages are the parts of CiviCRM that the public sees, and the host CMS usually controls their layout, caching and page templates. Test these pages after every CMS or theme change, including payment forms and any caching layer in front of the site. Standalone gives you direct control of these pages but requires you to build the surrounding website yourself.
Two release calendars running together
CiviCRM publishes a standard release monthly, and WordPress, Drupal and Joomla each run their own cycles and support windows. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Plan one joint upgrade window per quarter that covers CiviCRM, the CMS and every extension, and record which CiviCRM release each CMS version has been tested against.
Which host fits which team
If your organization has no public website to manage and wants CiviCRM as its only web application, Standalone is the natural deciding factor. Without a CMS, there is one application to patch, one set of users and one upgrade path to plan. CiviCRM itself is released under AGPL-3.0 and its standard release is free to download and use, so the main recurring work is operating the CRM rather than maintaining a content layer.
- Fewer moving parts: You avoid a second application stack for pages, themes and plugins that would need its own updates.
- Login model: Staff and contacts sign in to CiviCRM directly, so you design identity and access for one system.
- Main risk: Your team must handle PHP, MySQL or MariaDB hosting, backups and upgrades on its own, with no CMS community around the server.
- Release choice: The standard monthly release and the Extended Security Release are both options. Decide which track you will follow before go-live.
- Public forms: Any public donation or event pages must still be built and hosted, so confirm how you will serve them.
Confirm with your team that it can run CiviCRM 6.16 or later on PHP 8.3 to 8.5 with MySQL 5.7.5 or later or MariaDB 10.2 or later, since PostgreSQL is not compatible.
If your website already runs on WordPress and your staff knows how to maintain it, hosting CiviCRM inside WordPress is the deciding factor. The website, forms and CRM can share one hosting account, one administrator group and one set of update habits. CiviCRM ships a WordPress download, so this is a supported installation path rather than a workaround.
- Shared administration: Website editors and CRM administrators may be the same people, which lowers training cost.
- Update exposure: WordPress and its plugins are updated automatically in some cases, so plugin changes can touch the CRM. Test updates before they reach production.
- Hosting baseline: WordPress.org recommends PHP 8.3 or greater and MariaDB 10.11 or greater or MySQL 8.0 or greater, which must also satisfy CiviCRM's requirements.
- Security responsibility: WordPress only officially supports its latest version, so an old site falls outside the normal support path.
- Main risk: A plugin conflict or a bad WordPress update can take down both the website and the CRM at once.
Confirm your current WordPress version, your plugin list and whether a staging copy exists before you add CiviCRM to the same site.
If your team already maintains Drupal or still runs a Drupal 7 site, the deciding factor is what that site is today. Drupal 7 security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. They must be migrated into a new site, and themes must be rebuilt. CiviCRM warns users running it with Drupal 7 for this reason, so a legacy site is a planning problem before it is a hosting choice.
- Current Drupal: Drupal 11 is the current major version, and Drupal 10 reaches end of life on December 9, 2026, so a new build should target a supported line.
- Legacy extended support: Drupal's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Treat that as a bridge with its own cost and contract, not a plan.
- Login options: Contributed modules such as SAML Authentication and OpenID Connect can connect a Drupal site to external identity providers, but confirm module versions against your Drupal release.
- Main risk: Migration and theme rebuilds take work that scales with the site, and that work is easy to underestimate.
- Licensing: Drupal is GPL-2.0-or-later with no paid edition of Drupal itself.
Confirm your exact Drupal version, your PHP version and every contributed module on the site before choosing this host.
If your organization already runs Joomla or Backdrop, or prefers one of them, CiviCRM supports both, and the choice depends on your existing team and site rather than on CiviCRM features. The CiviCRM download page lists Backdrop and Joomla 5 and later as supported hosts. Because the CRM behaves the same underneath, the decision turns on how well your team can maintain that CMS and its extensions over time.
- Existing skills: A team fluent in Joomla or Backdrop can run the host without learning a new platform.
- Smaller ecosystem: Fewer people may be available to diagnose a CMS-specific problem, so plan for vendor or community help.
- Version alignment: Confirm that the CiviCRM release you want supports your Joomla or Backdrop version before you upgrade either one.
- Login and forms: Confirm how the host handles public pages, user accounts and any SSO you need, because these features vary by CMS and module.
- Main risk: A host-specific update can lag behind CiviCRM releases, leaving you choosing between an old CRM and an untested host update.
Confirm with the CiviCRM download page and your host's own documentation which versions pair, and test the full upgrade on a copy before committing.
Upgrades, backups and skills for each host
This table compares how upgrades, backups, monitoring and skills differ when CiviCRM runs on Standalone or inside a CMS. Read each row against the host you are considering, and treat the CMS column as the rule that applies to whichever CMS you choose.
| Factor | CiviCRM Standalone | CMS-hosted (WordPress, Drupal and similar) |
|---|---|---|
| Upgrade cadence | CiviCRM standard releases come monthly, so the team sets a regular test-and-deploy rhythm for CiviCRM itself. | CMS and CiviCRM each have their own cadence. Drupal ships bugfix releases on the first Wednesday of each month and security releases on the third Wednesday. |
| Support window | Only CiviCRM's own release line matters for this host, so the team tracks CiviCRM and the PHP and database versions it requires. | WordPress supports only its latest version, though it backports critical security fixes to older versions as a courtesy. Drupal 7 support has ended, so older sites need a migration or a paid extended support provider. |
| Automatic updates | No CMS auto-updates apply. Every CiviCRM update is a change the team schedules and tests. | Sites created since WordPress 5.6 get automatic major release updates by default. Plugin and theme updates apply automatically only in special cases chosen by WordPress.org. |
| Compatibility testing | Test CiviCRM against its supported PHP, MySQL or MariaDB versions and your extensions before each update. | Each CMS upgrade can affect CiviCRM compatibility, so test the CMS, CiviCRM and extensions together in staging before production. |
| Backups | Back up the database and the CiviCRM files and configuration on your own schedule, and test restores regularly. | Back up the CMS database, uploads, theme and plugin files, and CiviCRM data together so the pieces restore to a consistent state. Confirm whether your host provides this. |
| Monitoring | Monitor the web server, PHP, the database and CiviCRM scheduled jobs directly. | Monitor the same layers plus the CMS admin and plugin or module health, since a CMS update can break CiviCRM without changing its own version. |
| Skills needed | Linux server administration, PHP, the CiviCRM installer and database administration. | The same server skills plus working knowledge of the CMS, its update model and its plugin or module ecosystem. |
| Confirm with your host | Ask who applies OS, PHP and database patches and who restores backups. | Confirm the update behavior of your chosen hosting stack, including whether auto-updates run on CMS core, plugins and CiviCRM. |
What changes for users, logins and public forms
The host decides who holds a login and how public donation, event and membership pages are built, so settle this before choosing a platform. On Standalone, CiviCRM manages its own users and public forms, and the identity options must be confirmed against the current CiviCRM documentation for your version. On WordPress, Drupal, Joomla or Backdrop, the CMS owns the user account and CiviCRM adds a contact record on top, so the login experience follows the CMS. Confirm for each host which single sign-on options your team needs, because identity support is not guaranteed to be equivalent across hosts and should not be assumed.
On Drupal, the contributed *SAML Authentication* module (samlauth) lets the site act as a SAML service provider. Its latest stable release, 8.x-3.14, supports Drupal 10.3 and later and Drupal 11, so a Drupal 11 site on the current line is the realistic target. The contributed *OpenID Connect* module lets external providers authenticate Drupal users and creates accounts on first sign-in. Its built-in clients cover generic OAuth 2.0, GitHub, Google, LinkedIn, Facebook and Okta. First-sign-in account creation is convenient, but it means every person who can authenticate at the provider also gets a Drupal account, so decide who may sign in before enabling it and check how the account maps to a CiviCRM contact.
A CMS login and a CiviCRM contact record are separate objects that must be linked. The user account controls access to the site, while the contact record holds the donor, member or attendee history, and their identifiers can drift apart if an account is renamed, merged or deleted. Ask your implementation partner to document the matching rule, the fields used to match and what happens to contributions when an account is removed. Test a donor who signs in, donates, and later changes email address, and confirm the record stays one person. Treat the same questions as open for WordPress and Standalone until you have tested them in your own setup.
How to move a Drupal 7 site off end-of-life support
This sequence takes a CiviCRM installation running on Drupal 7 from unsupported core to a supported Drupal release, with a documented cutover and a verified rollback path. It covers the bridge option for sites that cannot move yet and the checks that confirm the new stack is ready.
Confirm the Drupal 7 exposure and the bridge options
Start by recording the facts that set the deadline for your site. Drupal 7 security support ended on January 5, 2025, so the site no longer receives core security releases from the Drupal project. Your platform owner should list every Drupal 7 site that runs CiviCRM, along with its contributed modules and custom code. If a migration cannot happen soon, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for that bridge period. Confirm terms, scope and coverage directly with the provider. The step is done when you hold a written inventory and a signed decision on whether you need a bridge.
Choose the target Drupal version and CiviCRM release
Pick the target Drupal core line before you build anything. Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later, so the target is a new site. Drupal 11 is the current major version, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 10 reaches end of life on December 9, 2026, so a Drupal 10 target leaves little runway. Check the CiviCRM download page for the Drupal versions the current CiviCRM release supports, because the CiviCRM version must match the new CMS. The step is done when the target Drupal and CiviCRM versions are written down and checked against each other.
Confirm PHP and database versions before cutover
Verify the runtime before you copy any data. Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5, and they need MySQL 5.7.5 or later or MariaDB 10.2 or later. PostgreSQL is not compatible with CiviCRM. Your team should confirm these versions on the new hosts and check the web server and database engine against the Drupal system requirements. Repeat the check on the staging host after any OS or PHP upgrade. The step is done when a written compatibility check passes on the exact stack you will run in production.
Build the new Drupal site and install CiviCRM
Create a fresh Drupal site on the target version and install CiviCRM through its supported Drupal integration. Do not copy the Drupal 7 database into the new site, because the Drupal documentation describes migration as a new site rather than an upgrade. Enable the core Migrate, Migrate Drupal and Migrate Drupal UI modules on the new site so content and configuration can be moved in later. Set up staging, file storage and cron on the new host, and configure outbound mail so CiviMail can send. The step is done when a staging site runs the chosen Drupal and CiviCRM versions with an empty CiviCRM database and a working login.
Migrate content, configuration and CiviCRM data
Run the Migrate Drupal workflow from the Drupal 7 source, through the Migrate Drupal UI or Drush, to move content, users, roles and configuration into the new site. Migrate contributed modules only where a current Drupal version exists and you have tested it. Handle CiviCRM data with the CiviCRM documentation for the version you run, and verify contact, contribution, membership and event records against the source. Compare record counts and sample entries for each entity type. The step is done when a reconciliation report shows matching counts and an agreed list of exceptions that you have accepted in writing.
Rebuild themes and rework custom code
Plan a theme rebuild, because Drupal 7 themes cannot be migrated to Drupal 10 or later. Your front-end developer should build the new theme on the target version and move public pages, CiviCRM forms and any online donation or event templates across. Review custom modules and any code that calls CiviCRM APIs, since those interfaces may have changed between versions. Test authenticated pages, public forms and email templates on staging. The step is done when a test script covering login, a donation or event form, a CiviMail send and a report run passes on the new theme.
Test identity, backups and rollback before cutover
Test how users sign in on the new site. If you use SAML or OpenID Connect, the contributed samlauth module (latest stable 8.x-3.14, supporting Drupal 10.3 and later and Drupal 11) and the OpenID Connect module are the usual options to evaluate, and each needs its own configuration and test. Take a full backup of the Drupal 7 site, the CiviCRM database and the files, and confirm you can restore them to a separate host. Schedule a rehearsal of the cutover on staging. The step is done when a sign-in test passes for each user group, a restore from backup succeeds, and the rollback steps are written and rehearsed.
Cut over and confirm supported status
Freeze changes on the Drupal 7 site, run a final incremental migration, point DNS or the load balancer to the new site, and turn off public access to the old site once you have verified the new one. Check that the Drupal security release schedule and the CiviCRM release track are set up for updates on the new site. Keep the old environment in read-only storage for the period your records policy requires. The step is done when the production site serves traffic on a supported Drupal version, the old site is offline or read-only, and the cutover record is signed by the business owner.
What buyers ask before choosing a CiviCRM host
Which host is cheapest to run CiviCRM on?
No host is cheapest in every case. The cost is driven by three things: the hosting bill, the staff hours spent on CMS and PHP updates, and the one-time migration work if you change hosts later. Standalone removes the CMS layer, so there are fewer components to patch, but you own the web server, PHP and database directly. WordPress and Joomla sites often have the lowest entry effort because many hosts offer them as managed services, though each plugin or extension adds update work. Drupal adds more upgrade planning per major version. Ask any provider for a written breakdown of who patches each layer, how often, and what an upgrade costs in staff time, then compare those figures against your own team's hours.
How long does it take to move CiviCRM to a different host?
The duration depends on scope, so it must come from a written quote. The main variables are the size of the contact and contribution data, how many CiviCRM extensions and custom fields you run, whether you are moving between CMS platforms or only changing servers, and how many public pages, forms and logins need to keep working during cutover. A move between two Standalone servers with a tested backup is usually narrower than a move from a CMS to Standalone, which needs user accounts, theme work and form redirects reviewed. Ask the provider to list each deliverable, the test steps and the cutover window in the scope before work begins.
Can a nonprofit team run CiviCRM without outside help?
A team can run it in-house if it has the skills to operate the stack. For Standalone, that means someone comfortable with Linux administration, a supported PHP version (CiviCRM 6.16 and later recommend PHP 8.3, 8.4 or 8.5), and MySQL or MariaDB, since PostgreSQL is not compatible. For a CMS host, the team also needs to handle WordPress, Drupal or Joomla core updates, plugin or module compatibility, and CiviCRM's own upgrade steps in the right order. Backups, restore tests and a staging copy are the controls that matter most. If those skills are thin, an outside partner can plan, implement and document the setup under a fixed-scope agreement, and you can keep a retainer for upgrades.
Is WordPress or Drupal required to run CiviCRM?
No. CiviCRM can run on Standalone, without a content management system. Its download page also lists options for Backdrop, Drupal 10 and later, Drupal 7, Joomla 5 and later, and WordPress. Choose a CMS when you need the CMS for its own purpose, such as a public website, member login pages or content editing that your staff already know. If your main need is the CRM database and staff screens, Standalone avoids a second application to keep current. Confirm the Standalone setup against the requirements page for the CiviCRM version you plan to install.
What happens to a CiviCRM site running on Drupal 7?
Drupal 7 security support ended on January 5, 2025, according to Drupal.org, and CiviCRM warns users running it with Drupal 7 about this. Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. Drupal.org documentation describes migrating them into a new site using the core Migrate modules or Drush, and themes must be rebuilt because they cannot be migrated. If you cannot migrate yet, the Drupal Association's Extended Security Support Provider Program lists certified vendors that offer extended security support. Treat this as a priority risk item, plan the migration with a written scope, and check your CiviCRM version against the Drupal version you target.
Can CiviCRM public forms run on Standalone?
The need is to publish contribution pages, event registration and profile forms to people outside your network, with spam controls, payment processing and secure data handling. Standalone can serve public pages, but the exact behavior depends on the CiviCRM version, the web server configuration, the payment processor and the extensions you install. Some teams rely on CMS page builders or theme features for layout, and those would need to be rebuilt on Standalone. Confirm in your own environment by testing each form end to end, including email confirmations, payment callbacks and accessibility, before you commit to a host.
What should a fixed-scope quote for a CiviCRM host include?
Ask for a written scope that names the target host, the CiviCRM release line, the PHP and database versions, and the extensions to be installed or rebuilt. The quote should list the one-time work (server build, data migration, user and login mapping, form rebuilds, testing and documentation) separately from recurring work (patching, backups, monitoring and CiviCRM upgrades). Look for the acceptance tests, the cutover and rollback plan, and what is excluded. Ask whether ongoing support is a separate retainer and how upgrades are scheduled. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so a quote should trace back to that document.
How do user logins differ between Standalone and a CMS host?
On a CMS host, CiviCRM users and CMS users may be linked, so one account can control both the website and the CRM. On Standalone, CiviCRM manages its own user accounts. The difference matters for member logins, staff access and single sign-on. Identity integration with a CMS typically uses that CMS's modules, such as SAML or OpenID Connect modules for Drupal, while Standalone depends on the integration options you configure for it. Confirm which single sign-on method your identity provider supports for the chosen host and test account provisioning and removal before go-live.
How DeployOpen plans and runs a CiviCRM deployment
DeployOpen plans CiviCRM deployments inside your own cloud accounts, data centers or air-gapped networks, starting from a written scope that settles the host platform before any build begins. The same method applies whether CiviCRM runs on Standalone, WordPress, Drupal or another supported host, so the decision stays with your team and the work follows it.
How we scope
- Confirm which host (Standalone, WordPress, Drupal, Joomla or Backdrop) your users, public forms and login model require
- Record the PHP, MySQL or MariaDB versions and hosting stack your environment already supports before selecting a CiviCRM release
- Agree the written scope, deliverables and timeline in advance, since most engagements are fixed-scope and quoted from that scope
How we build
- Install CiviCRM on the chosen host, configure the database and web server, and set up contacts, contributions and events for your workflows
- Integrate identity sources and public pages, then test logins, permissions and form submissions against the agreed scope
- Run security testing and harden the server, plugin or module set, and backups before anything goes live
How we hand over
- Document the architecture, host configuration, extension list and the upgrade path your team will follow
- Deliver runbooks for backups, restores and release updates, so your staff can operate the system without outside help
- Walk your administrators through the handover and record the open items, owners and dates in writing
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the written scope rather than a standard package
- Plan CiviCRM and host upgrades ahead of end-of-life dates, including any Drupal 7 migration, which requires a new site rather than an in-place update
- Ask your quote to separate one-time build work from recurring retainer work so the ongoing cost is visible
