Acquia or self-hosted Drupal: which fits your team
Acquia suits teams that want the hosting platform operated for them, while self-hosted Drupal suits teams that have the skills, or a support partner, to run it themselves. The Drupal code is identical in both cases. Drupal and its contributed projects are GPL-2.0-or-later, and there is no paid edition of Drupal itself, so you are not choosing between two versions of the software. You are choosing who carries the operational work and where the data sits. Before a renewal, list each duty Acquia performs for you today, including backups, environment provisioning, security patching, upgrades and Acquia-specific add-ons, and assign an owner to each one under the self-hosted option.
Start the review with data location, because it can settle the question before cost does. Ask Acquia in writing which regions and data centers host your production, staging and backup copies, and whether any third-party services in the delivery path process personal data. If your obligations require the data to stay in a specific jurisdiction or on infrastructure you control, self-hosting may be the only route. Next, count the Drupal-specific work that will move to your team: Drupal's monthly bugfix and security release windows, the Drupal 11 to Drupal 12 major upgrade (Drupal 12 is scheduled for the week of December 7, 2026, per the Drupal core release schedule), and the PHP version each release requires. Confirm which of your contributed modules, such as SAML or OpenID Connect integrations, are tied to Acquia's identity or environment setup.
Which option fits which situation
This table matches common Acquia situations to the better fit, the reason and the condition that would reverse the answer. Read each row against your own constraints, since the right choice depends on who runs the platform, where data must live and how many sites you operate.
| Situation | Better fit | Reason and what would change the answer |
|---|---|---|
| Regulated team that must keep data in its own cloud account | Self-hosted Drupal in your account | Drupal is GPL and runs on your own cloud or data center, so hosting, logs and backups stay where your controls already apply. Acquia may still fit if its hosting regions and contract terms satisfy your assessor, so confirm data location and access terms in writing. |
| Team with no platform engineers | Acquia, or self-hosted with a support partner | Managed hosting removes patching of the stack and environment management. Self-hosting without a retained operator usually leaves security updates on Drupal's monthly and security release windows unowned. The answer changes if you can fund a retainer that covers patching and backups. |
| Multi-site estate on one codebase | Acquia for shared tooling, or self-hosted with a multisite build | Acquia's platform tooling helps when many sites share environments and deployment pipelines. Self-hosting becomes competitive once you have a standard build and a pipeline your team already operates. Confirm how each site's modules and configuration are managed before you decide. |
| Existing Kubernetes platform team | Self-hosted Drupal on Kubernetes | Your team can apply the same cluster, backup and monitoring standards to Drupal that it applies to other services. The answer reverses if the platform team is already stretched or lacks PHP and database operations experience. |
| Mid-upgrade from Drupal 10 to Drupal 11 | Decide hosting after the upgrade plan is fixed | Drupal 11 requires PHP 8.3 or later, and moving hosts during the upgrade doubles the variables to test. Stay on Acquia through the upgrade if it is already scheduled. Move only if the target platform can run PHP 8.3 and passes your performance and security tests. |
| Site still on Drupal 7 or 6 | Plan a rebuild before any hosting decision | Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later, and themes must be rebuilt. Hosting choice matters less than the migration project, so scope the rebuild first. |
Where your data lives and who controls it
Moving Drupal from Acquia changes who operates the hosting, who holds the database and file backups, and who signs in to the site. Each of the cards below is a decision you make once and then have to evidence later. Confirm each answer in writing with Acquia and with any host or partner you consider before work starts.
Hosting model options
Acquia runs the Drupal environments on its Cloud Platform, so the hosting, patching of the platform layer and environment provisioning are part of the contract. Self-hosting moves those duties to you: a virtual machine set, a Kubernetes cluster or a host in another cloud, each with its own operating system patching, web server, PHP and database upkeep. Drupal runs on Apache, Nginx and other web servers with MariaDB, MySQL, PostgreSQL or SQLite, so the choice of stack is yours to document. Ask Acquia exactly which layers it operates today.
Data residency and location
With Acquia, you rely on the regions and data locations Acquia offers and on its contractual terms for where content, logs and backups are stored. Self-hosting lets you pin the database, uploaded files and backups to a country, a data center or an air-gapped network. Check where Acquia stores backups and support access, and whether any sub-processor sits outside the region your regulator requires. Write the answer into your data map before you choose a target.
Access to database and file backups
Acquia's backups are taken on its platform, and the Acquia CLI and interface give your team a way to download them. Uploaded files are not part of a database backup, so you must copy the file system separately. After you move, the backup schedule, retention, encryption keys and restore testing become your responsibility. Confirm how long Acquia keeps backups and whether you can export them in full, because that sets the recovery point you can promise.
Identity integration and admin access
Acquia manages platform access for your developers and administrators through its own accounts. On your own servers, you decide how operators sign in to hosts, databases and the Drupal back end. Drupal can act as a SAML service provider through the contributed SAML Authentication module (samlauth), and the OpenID Connect module can accept external providers, creates accounts on first sign-in and includes built-in clients for Okta and others. Map every admin role to your identity provider and remove shared accounts before cutover.
Audit logs and change evidence
Auditors will ask who changed production, when, and where the record lives. Acquia's audit trails for platform actions are a dependency you need to understand before you leave, and a self-hosted site needs its own logging of web access, administrative actions, deployments and database changes. Decide where those logs are stored, how long they are kept and who can alter them. DeployOpen prepares these controls and evidence for assessments, but it does not issue audit reports; independent auditors decide conformity.
Security response and patch ownership
Drupal security releases are published on a set schedule, so someone on your side must watch them and apply them. Under Acquia, part of that patching work is handled through the platform, while self-hosting makes your team or support partner accountable for the core, contributed modules, the server stack and PHP. Check the Drupal Security Team announcements and your monitoring against the release windows, and agree an owner and response time in writing. Assigning these duties before cutover avoids gaps after it.
What Acquia manages today and what moves to your team
The first decision is which operational duties your current Acquia contract actually covers, because that list defines what you must replace. On a managed platform, the provider typically absorbs hosting maintenance, environment provisioning, the platform tooling that builds and deploys code, and the backup jobs that run against each environment. Your team usually still owns the Drupal codebase, the contributed modules you chose, and the content and configuration that live in the database. Confirm the exact Acquia service boundaries in your current contract and order form, including which environments, backup retention periods and support hours are included, and which items are add-ons. Treat that document as the source of truth, not a summary from memory or from this page.
After a move, patching becomes a recurring internal task that you must schedule. Drupal core and contributed projects publish bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so someone must watch those dates, test updates in a staging copy and deploy them quickly enough to stay supported. PHP upgrades are a separate track: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so your server images and the Drupal version must move together. Monitoring, uptime alerting, log review and incident response also transfer to you or to a support partner, and each needs a named owner, an on-call route and a tested rollback. Ask any partner to show how these duties are written into a fixed-scope agreement or retainer before you cut over.
What each path costs, component by component
Acquia bundles hosting, tooling and support into one subscription, while self-hosting splits the same work into separate line items. Drupal core and contributed modules carry no license fee, so the comparison comes down to who is paid for infrastructure, operations, upgrades and expertise. Use the cards below to build a like-for-like quote before you decide.
Acquia subscription and add-ons
This is the recurring fee for hosting, environments, support and the platform tooling Acquia provides, plus any add-on modules you buy separately. Ask the vendor to itemize the base subscription, each environment, add-on services and any usage-based charges, and to state which items renew automatically. Confirm how price changes at renewal are handled, because this line is the one most likely to move when you negotiate or switch.
Infrastructure and compute
Self-hosting moves servers, containers or Kubernetes nodes, databases and web tiers onto your cloud account or data center. These costs recur monthly and scale with traffic, number of environments and redundancy targets. Drupal runs on Apache, Nginx and other web servers, with MariaDB, MySQL, PostgreSQL or SQLite as the database, so ask your architects which combination your existing platform already supports and which components you would need to add.
CDN, caching and edge delivery
Content delivery, edge caching and web application firewall capabilities may be bundled with Acquia or sold separately, so confirm which of these your current contract includes. Self-hosting usually means buying a CDN or edge service from a separate provider and configuring cache rules for Drupal. Estimate how much of your traffic is anonymous and cacheable, since that share drives the bandwidth and origin load you will pay for.
Backups, storage and retention
Backups are a recurring cost for database dumps, uploaded files and retained snapshots, and the storage needed grows with content volume and retention policy. Acquia handles backups as part of its platform, while on your own servers your team or partner must schedule, copy off-site and test restores. Ask what the current retention period is, whether file backups are included, and how restores are verified.
Monitoring and security tooling
Monitoring, log retention, vulnerability scanning and alerting are often bundled into a managed platform, but self-hosting requires you to license or run them yourself. Open-source options exist for most of these functions, and their running cost is mostly staff time. Check which logs and alerts Acquia currently provides, so that your replacements cover uptime checks, error tracking and audit logging at the same level.
Security updates and upgrade projects
Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so patching becomes a recurring operational task. Major upgrades are a larger one-time project, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Drupal 12 requires PHP 8.5 or later, so include runtime upgrades in any plan. Ask a partner to quote testing, module compatibility work and rollout as separate items.
Staff time and support partners
The largest recurring cost on the self-hosted side is often the people who run hosting, deploy code, respond to incidents and maintain contributed modules. You can hire, train or contract this work, and the mix changes the total. Compare the hours your team already spends on Acquia support tickets, environment management and deployments with the hours a new operating model would require. Ask any partner for a written scope and a separate quote for ongoing support.
How a move from Acquia to self-hosted Drupal is structured
The sequence turns an Acquia-hosted Drupal site into one that runs on infrastructure you control, with each phase closed by a check that the site behaves the same elsewhere. It moves the code, data and files together so cutover is a controlled event, not a hope.
Inventory Acquia-specific modules and settings
Your team, with the Drupal lead or partner, lists every Acquia-dependent item: Acquia-branded modules, Cloud-specific settings files, environment variables, cron and queue configuration, search connectors, and any Acquia add-on services such as the CDN, WAF or search. Each item gets a named replacement or a decision to drop it. The step is done when the list is signed off by the business owner and every item has an owner and a replacement or a decision to drop it.
Replicate environments and deployment pipelines
Build the target hosting for development, staging and production, sized from current traffic data, and recreate the build and deploy path from your Git repository. Confirm that the same Drupal core and contributed module versions, PHP version and database engine run in each environment, since Drupal supports several web servers and databases. The step closes when a code change deploys through the new pipeline to staging and the site builds without errors.
Migrate the database and files separately
Take a database export from Acquia and restore it to the target, then copy the public and private file directories on their own track, because Acquia database backups do not include uploaded files. Run database updates and clear caches on the restored copy, and compare content counts, users and configuration between source and target. The step is complete when a staging copy matches production content and every uploaded file opens from the new host.
Re-run integrations and authentication
Reconnect the systems that depended on Acquia-hosted endpoints, including single sign-on, email delivery, payment callbacks, search indexes and third-party APIs. If you use SAML or OpenID Connect, retest the identity provider settings against the new hostname. The step is done when each integration is tested end to end on staging and its test results are recorded.
Test performance and security on the new stack
Run load tests against staging with representative traffic, measure page response, cache hit rates and database behavior, and tune the web server, PHP and caching layers to meet the targets set in advance. Your security team or testing partner checks the new stack against your baseline, including TLS, headers, access controls and patching routines. The step closes when the results are documented and the business owner accepts the performance and security sign-off.
Cut DNS over with a rollback plan
Schedule the cutover window, lower DNS record time-to-live values in advance, take a final database and file sync, and switch the record to the new host. Keep the Acquia environment running and writable only as far as your rollback plan allows, and document the exact steps to point DNS back if a critical fault appears. The step is done when the public site serves from the new host, smoke tests pass, and the rollback procedure has been rehearsed.
Run a post-cutover support period
Monitor errors, performance, scheduled tasks and security alerts closely for an agreed period, with named people on call for the new platform. Confirm that backups run and that a restore has been tested, and that the first routine security update cycle goes through your pipeline. The step closes when the support period ends with a handover document, a confirmed backup restore and a decision to decommission the Acquia environment.
Questions buyers ask before moving off Acquia
How much does it cost to move Drupal off Acquia?
The cost depends on the components you take on, not on a single figure. Acquia's subscription covers hosting, environments, and platform tooling, and that spend stops at exit. Your new costs fall into four groups: infrastructure and CDN, backups and restore testing, the work to rebuild deployment and monitoring, and the people who run the site. Some costs are one-time, such as the migration project, environment replication and cutover testing. Others recur, such as servers, bandwidth, security updates and on-call time. Ask any implementation partner for a quote built from a written scope that lists each component separately, so you can compare it line by line with your current Acquia invoice and its add-ons.
How long does a move from Acquia take?
Duration is set by the amount of custom code, the number of environments, the size of the database and file store, how many Acquia-specific modules and settings must be replaced, and how much performance and security testing you require before cutover. A single brochure site with few integrations takes far less work than a multi-site platform with single sign-on, search and custom deployment pipelines. Any figure you are given should come from a written scope and a test plan, not a generic estimate. Ask the provider which phases they include, what inputs they need from you, and which milestones require your sign-off.
Can our internal team move a Drupal site off Acquia alone?
A team with solid Drupal experience can often do it alone, but it needs more than general web development skills. The team must be able to rebuild the hosting layer, manage database and file backups, replicate environments, and rework deployment and caching. Check three things before committing: whether someone has run Drupal in production with its own servers, whether the team can carry out a restore test end to end, and whether anyone will handle the monthly security release cycle. If one of these is missing, a support partner can cover that gap for a fixed scope while your team keeps ownership of the content and the code.
What access and skills does a self-hosted Drupal move require?
The work needs access to the Git repository, the database, the uploaded files, and the environment settings currently used on Acquia. You also need accounts with your new cloud provider, data center or Kubernetes cluster, plus DNS control for the cutover. On the skills side, expect to need people who can manage PHP and web server configuration, database operations, and Drupal updates through Composer. A written test plan should cover content checks, role and permission checks, search, forms, single sign-on and performance under load, with a rollback plan for the DNS change. Confirm each access item with your current Acquia administrator before the project starts.
Does Drupal 10 end of life affect a move off Acquia?
Yes, it changes the timing and the target version. According to the Drupal core release schedule, Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 11 is the current major version. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, according to the Drupal.org PHP requirements page. Plan the move so the new environment runs a supported version, and budget the Drupal 10 to 11 upgrade as a separate task that can run before or after the move. Confirm the exact upgrade path with your developers, since contributed modules may need updates first.
What happens to Acquia-specific add-ons after the move?
Each Acquia add-on needs a named owner and a replacement or a decision to drop it. Typical categories include the managed CDN and edge caching, search, monitoring and log tools, backup scheduling, and any platform-specific module or settings file. For each one, record what it does today, which open-source or self-hosted component covers that need, and who will operate it after cutover. Some functions, such as a managed CDN or 24/7 platform response, may not have a direct open-source equivalent and will need a paid service or an internal process. Ask Acquia for a list of platform features in use, and check licenses for any replacement you adopt.
Who keeps Drupal secure once we host it ourselves?
Your team, or a support partner you contract, takes over the security work that Acquia currently handles on the platform. Drupal's Security Team publishes advisories, and core security releases come out on the third Wednesday of each month, according to the Drupal core release schedule. Bugfix releases come out on the first Wednesday of each month. Someone must watch those releases, apply updates to core and contributed modules, test them, and deploy them. You also need to cover the web server, database, operating system, TLS certificates and firewall rules. Put this in writing as a responsibility matrix before cutover so nothing falls between teams.
Does DeployOpen handle the entire move from Acquia?
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Drupal move, that can include the migration plan, environment replication, deployment pipeline, backup and restore testing, security hardening and documentation. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not issue audit reports or certifications, so any compliance evidence it prepares still needs review by an independent auditor. Ask for a written scope that lists which parts of the move you keep in-house.
How DeployOpen helps evaluate and implement a Drupal move
DeployOpen is a Chainscore Labs company that plans, implements and supports self-hosted Drupal inside your own cloud accounts, data centers or air-gapped networks. We are not an Acquia partner and we are not a Drupal partner or certified provider, so the work is defined by your environment and your written scope rather than by a vendor program. For an Acquia exit, the first deliverable is usually an inventory: the Drupal core version, the contributed modules, the Acquia-specific settings and the environments that must be reproduced, including the Acquia Cloud Platform features you actually use. From that inventory we agree the scope, deliverables and timeline in writing before any work starts, and the quote follows from that written scope.
During implementation we build the hosting target, the deployment pipeline and the database and file backup routine, then harden the stack, including web server and database configuration, secrets handling and the update process tied to Drupal's monthly bugfix and security release windows. Authentication is a common decision point: if you rely on SSO today, we can evaluate the contributed SAML Authentication module (samlauth) or the OpenID Connect module against your identity provider, and confirm the module versions against your Drupal version before committing. Security testing of the application, its APIs and the infrastructure can run before cutover, and we document the configuration, runbooks and evidence so your team and your auditors can follow them. Ongoing upgrades, monitoring and continuous testing are available as retainers, which keeps the post-migration work from falling back on a single engineer.
