How to migrate from Acquia to self-hosted Drupal without losing content or uptime
If you are facing an Acquia renewal, a hosting cost increase, a data residency requirement or lock-in concerns, the short answer is this: the Drupal codebase is GPL and moves with you, while Acquia-specific tooling, environments and add-ons must be replaced by your own equivalents. Drupal itself has no paid edition, so the software is not the thing you buy back. What you rebuild is the platform around it: the database and file backups, the Git-based deployment pipeline, the non-production environments, the caching and CDN layer, the monitoring and the on-call process. Most teams do this work with an internal platform team supported by an implementation partner for the parts they have not run before, such as hardening, performance testing and cutover planning.
Effort and risk depend mostly on how much Acquia-specific configuration your site relies on. Start by inventorying what the platform provides to your site today: environment variables and settings, scheduled jobs, search, Varnish or CDN purge hooks, SSO integration and any Acquia-only modules. Confirm with your Acquia team and your own documentation which of these are used, because the list is often longer than the codebase suggests. Also confirm which PHP version, database engine and web server your current site targets, and check that they match a Drupal release still in its supported window on the Drupal core release schedule. Moving onto an out-of-support version creates a security problem that the hosting change does not solve. This page covers the migration sequence, from building the target environment through to DNS cutover and rollback. The sibling pages cover the platform comparison, the cost of ownership by component, and the export checklist for what to take out of Acquia before you leave. Read those first if you have not yet decided whether to move, because the answers shape how much of this sequence applies to your site. Plan the cutover with a rollback path you have actually rehearsed, and keep the Acquia environment running until the new one has carried production traffic for long enough to be trusted.
Which Acquia capabilities map to self-hosted Drupal, and which need rework
This table maps the Acquia Cloud Platform capabilities a Drupal team typically relies on to their self-hosted equivalents, and labels each as clean, needs rework or a gap. Check each row against your own subscription and codebase before you plan the work, because add-on features vary by contract. The main takeaway is that the Drupal code itself usually moves as is, while the hosting, pipeline and platform-specific settings carry most of the effort.
| Acquia capability | Self-hosted Drupal equivalent | Status and what to confirm |
|---|---|---|
| Codebase in Git and Drupal core and contributed modules | Your Git repository deployed to your own servers or cluster | Clean. Drupal core and GPL contributed modules run unchanged on any supported web server and database. |
| Database backups | Database dump taken with your own scheduled job and stored off-site | Needs rework. Export a full database backup with the Acquia CLI, then confirm a restore works on your own stack. |
| Uploaded files (public and private) | Files copied from your own storage volume or object store | Gap. Backups do not include uploaded files, so you need a separate copy job and a tested restore path. |
| Environments (dev, stage, prod) | Equivalent environments you provision and keep in sync | Needs rework. Replicate database and files into each environment and set up the refresh process yourself. |
| Deployment pipeline and code promotion | CI/CD pipeline that builds, tests and deploys the same artifact | Gap. Your team builds the pipeline, approval steps and rollback logic that the platform handled. |
| Acquia-specific settings and environment config | Settings files and environment variables managed in your repository | Needs rework. Review settings for Acquia-specific database, cache and file path values, and move secrets to your own store. |
| Acquia Search (Solr) | Self-hosted Apache Solr or another search backend with the Drupal search connector | Gap. Confirm which search service your subscription uses, then provision and index it yourself. |
| CDN and edge caching | CDN or reverse proxy you configure, such as a managed CDN in front of your servers | Gap. Choose the CDN, cache rules and purge process, and test cache invalidation after publishing. |
| Single sign-on for editors | SAML or OpenID Connect modules such as samlauth or the OpenID Connect module | Needs rework. Modules are GPL and maintained on Drupal.org, but identity provider configuration is yours to build and test. |
What data and integrations move, and through which documented paths
A Drupal move has four data paths that run separately: the codebase from Git, the database, uploaded files and exported configuration. Integrations such as SSO, search, CDN and cron sit outside those paths and are easy to miss, so each one needs an owner and a test before DNS changes.
Codebase from the Git repository
Your Acquia-hosted Git repository holds the Drupal core version, contributed modules, custom modules, themes and the composer files that pin them. Clone it to a new repository you control and confirm the lock file reproduces the exact versions running in production. Check for any Acquia-specific files or settings in the repository, such as environment-specific includes, and remove or replace them before the first build on your own infrastructure.
Database exported with the Acquia CLI
Take a full database backup from the Acquia interface or with the Acquia CLI, then restore it into a clean MariaDB, MySQL or PostgreSQL instance on your side. Drupal supports those databases, and the restore should be verified by logging in, running cron and checking content counts against production. Record the backup timestamp so the cutover data freeze is clear to editors.
Uploaded files copied separately
Database backups do not include uploaded files. Images, documents and other public and private files live in the Acquia file system and must be copied with a separate transfer, then verified against the file records in the database. Confirm the private file path and its permissions, because the new host must serve private files through Drupal rather than a public web path. Plan a final sync shortly before cutover so files uploaded after the snapshot are not lost.
Configuration exported with Drupal's configuration system
Site structure such as content types, views, fields and permissions is stored in configuration files that Drupal exports and imports. Export the active configuration from production, import it into the new environment and confirm that the config status shows no differences. Environment-specific values such as API keys, mail settings and trusted host patterns belong in environment settings files or secrets, not in the exported configuration.
SAML single sign-on rebuilt with samlauth
If editors or staff sign in through your identity provider, rebuild that login with the contributed SAML Authentication module, which lets Drupal act as a SAML service provider. The latest stable release supports Drupal 10.3 and later and Drupal 11, so confirm your target core version matches before you install it. Re-register the new site's entity ID and assertion consumer URL with the identity provider and test the full login and logout flow.
OpenID Connect and Acquia-hosted dependencies
The contributed OpenID Connect module handles external OIDC providers and creates accounts on first sign-in, so check whether any existing accounts depend on that flow. Separately, list every Acquia-hosted dependency, such as search, CDN purge, scheduled cron and outbound mail, and assign each one a replacement and a new endpoint. Ask your Acquia contact or review your Acquia configuration to confirm the full list, since some services are easy to overlook until they stop.
The migration sequence from inventory to decommissioning Acquia
This sequence moves a Drupal site from Acquia to infrastructure you control in a order that proves each layer before production traffic depends on it. Each step ends with a named artifact that the next step relies on, so the cutover is a recorded decision rather than a leap of faith.
Build the inventory register
Your team, with DeployOpen if you engage us, lists every contributed and custom module, theme, Composer dependency, PHP and Drupal core version, environment, cron job, queue worker, search index, cache layer, third-party integration and DNS record that the site touches. Each item gets an owner, a license note and a decision: keep, replace, or drop. Acquia-specific pieces such as platform settings, Acquia Purge, Acquia Search and any environment-level configuration are flagged explicitly. The sequence is complete when the register is reviewed and signed off by both the site owner and the engineering lead.
Rebuild the environments and pipeline
Provision the target hosts for production, staging and development, with the database engine and web server that match your inventory. Recreate the deployment pipeline from the Git repository so code, Composer lock files and configuration exports deploy the same way on every environment. Confirm the PHP version against the Drupal requirements for your target core version before anything is installed. The output is a build and deploy runbook plus a passing empty-site deployment to the staging host.
Run a pilot restore into staging
Take a fresh database backup from Acquia using the Acquia CLI or the interface, then copy uploaded files separately, since backups do not include them. Restore both into the new staging copy and run database updates, configuration import and cache rebuild in order. Record every error, missing file, failed module and drift between the restored site and production. The output is a restore report with a pass or fail result for each check, and the site is not moved forward until the report shows no open blockers.
Replace Acquia-specific modules and settings
Work through the register and swap each Acquia-specific dependency for a self-hosted equivalent or a removal decision. Typical replacements include a cache purge mechanism, a search backend your team operates, a file storage layer, and any secrets handling tied to the platform. Authentication integrations are re-pointed at your own identity provider, for example through the contributed SAML Authentication or OpenID Connect modules where they fit your design. The output is a passing staging build with a updated register showing each replacement, its owner and its test result.
Capture a performance baseline and test
Measure the production site on Acquia and the staging copy on the new host using the same scripted page set, traffic pattern and cache state. Include authenticated editorial paths, search, forms and cron-driven work, not only anonymous home page requests. Compare response times, error rates and database load, then tune web server, PHP, database and cache settings until the staging results are acceptable to the business owner. The output is a performance baseline document that states the test conditions and the agreed acceptance thresholds.
Run a parallel period with a content freeze
Keep Acquia as the production system while the new host runs in parallel for a period agreed in writing. Publish a content freeze rule that tells editors when changes are paused, or how any edits made during the window are reconciled, and document who approves an exception. Verify DNS changes such as lowered TTLs, certificates and email records in advance. The output is a parallel run log and a signed freeze and reconciliation procedure that the cutover depends on.
Cut over DNS with a documented rollback
Execute the cutover runbook in a planned window: a final database and file sync, a content freeze confirmation, the DNS change, and smoke tests on the critical paths. Keep the Acquia environment intact and write down the exact DNS values and the conditions under which you revert to it. Monitor errors, logs and performance during the first hours and days, and check that scheduled jobs run once only. The output is a cutover record with timestamps, test results and the rollback trigger that was never needed or was used.
Decommission Acquia after a stable period
Once the new host has run the production workload through a stable period that the owner has agreed in advance, export a final archive of the Acquia database, files and configuration for retention. Confirm with your contract owner the notice and termination terms that apply to your agreement, and ask Acquia to confirm what data is removed and when. The output is a decommissioning checklist with the retained archive location, access revocation records and the closed subscription confirmation.
How the Acquia to self-hosted Drupal cutover is structured
The cutover works best as a parallel run on the new host, not a rebuild on launch day. Before anything moves, stand up the self-hosted environment with the same Drupal core version, the same contributed modules and the same composer.lock as production, then restore the database and files exported from Acquia into it. Run the restored copy against a test hostname and compare it with production on the pages, forms, search and cron jobs your editors and visitors use most. Keep the Drupal major version fixed during the move. Changing core, PHP and modules at the same time makes a failed cutover hard to diagnose.
Choose the target major version and PHP version first, because the calendar will not wait for the move. The Drupal core release schedule lists Drupal 10 end of life on December 9, 2026, and Drupal 12 for the week of December 7, 2026. 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. Confirm with your team whether you will land on Drupal 11 now and upgrade later, or whether a Drupal 10 site should move straight to a version that is still supported. Set the PHP runtime and web server settings in the new environment before the restore, not after.
Define the cutover window with editors in the plan. Either pause content entry for the window, or agree on a content re-sync step where you export the database and files again just before DNS changes and import the delta. Lower the DNS TTL on the production record several days ahead, so resolvers pick up the change quickly. At cutover, switch the record, watch error logs, the Drupal status report and cache behavior, and keep Acquia running and unchanged until you have signed off. Write down the rollback steps in advance: which record to point back, who makes the call and how editors are told to stop writing to the new site. Confirm the TTL values, cache layers and certificate steps with your DNS provider and your own network team.
What drives migration cost and duration
This table lists the factors that most change the effort of moving an Acquia-hosted Drupal site to your own infrastructure, with why each one matters and how to reduce it. Use it to scope a fixed-scope quote, since no supplied figures set prices or durations for any driver.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Custom and contributed modules | Each custom module needs review for Acquia-specific code, and each contributed module must match the target Drupal version and PHP requirements. | Inventory modules from the codebase, remove unused ones, and confirm each contributed project supports your target Drupal version before the move. |
| Acquia-specific settings | Settings tied to Acquia's environment, such as hosting-generated configuration, cache, and file paths, must be found and replaced in every environment. | Search the codebase and settings files for Acquia references, then document each replacement so it can be tested once and reused across environments. |
| Database and file store size | Larger databases take longer to export, transfer and restore, and large file stores need separate copying and verification. | Confirm the export restores cleanly on a test host early, and clear stale content, logs and unused derivatives before the final copy. |
| Environments and pipelines | Each environment (such as development, staging and production) needs its own build, deployment and configuration, and pipelines must be rebuilt for the new host. | Reduce the number of active environments before migration and build one reproducible pipeline that all environments share. |
| SSO and integration count | Each single sign-on connection, third-party API or webhook must be reconfigured, retested and sometimes re-registered with the external provider. | List every integration with its owner and test path, then retire unused connections. Drupal's contributed SAML and OpenID Connect modules cover common SSO patterns, but confirm each one with your identity provider. |
| Performance targets | Caching, CDN, and load testing requirements determine how much infrastructure tuning and testing is needed before cutover. | Agree on specific page load and availability targets in writing, measure the current Acquia baseline, and test against those targets rather than open-ended goals. |
| Major version upgrade bundled in | Moving to a new Drupal major version adds module, theme and code changes on top of the host change, and it expands testing scope. | Separate the host move from the version upgrade when possible, so the migration can be tested and rolled back on the current version first. |
How the move differs by site size and starting point
A single Drupal 10 or 11 site is the most direct case. The codebase already runs on current core, so the work is mostly about reproducing the hosting environment rather than changing the application. Your team exports the database, copies the files directory separately and rebuilds the web server, PHP and database layers on infrastructure you control. Drupal 10 requires PHP 8.1 or later and Drupal 11 requires PHP 8.3 or later, so confirm the runtime matches before you start.
- Environment parity: Match the PHP version, extensions and database engine (MariaDB, MySQL, PostgreSQL or SQLite) to what the site uses on Acquia.
- Acquia-specific code: Find modules, settings and hooks tied to the Acquia platform and replace them before the first deployment.
- Files and private storage: Copy the public and private file directories separately, since database backups do not contain them.
- Pipeline rebuild: Recreate the build and deploy steps from your Git repository in your own CI system.
- Cutover window: Lower DNS time-to-live ahead of the switch and keep Acquia running until the self-hosted copy passes checks.
Before cutover, confirm that a restored database and file set reproduce the same content, cron behavior and search indexes on a staging copy.
A multisite Drupal installation shares one codebase across several sites, each with its own database and files. The move still uses one codebase, but the export, verification and cutover run once per site, and shared settings must be reconciled. Plan the order of sites by business risk and dependency, not by the order they appear in configuration. Sites that share a database, a domain pattern or a single-sign-on setup often need to move together.
- Site inventory: List every site, its database, domain, file paths and any shared services such as search or single sign-on.
- Shared settings: Review the multisite configuration and any sites-level files that Acquia injects, and recreate them explicitly.
- Wave planning: Group sites into waves so that dependent sites move in the same window.
- Per-site verification: Repeat restore and smoke tests for each site rather than testing one and assuming the rest.
- Routing and certificates: Update virtual host rules, TLS certificates and CDN origins for every domain.
Confirm with your team how many sites share a database and whether any site depends on a platform service that will not be available after the move.
Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. Drupal.org documentation describes migrating them into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush. This is a rebuild of content mapping and presentation, not a database copy. Themes must be rebuilt because they cannot be migrated, which makes this the longest path of the four situations.
- New site build: Stand up a fresh Drupal 10 or 11 site on your own infrastructure as the migration target.
- Content mapping: Map content types, fields, taxonomies and users from the old schema to the new one, and test each mapping on a copy.
- Theme rebuild: Budget design and front-end work for every theme, because existing themes will not carry over.
- Contributed modules: Confirm a maintained replacement exists for each module before you start mapping.
- Parallel running: Keep the legacy site available until the new site is verified, and plan redirects for changed URLs.
Ask your implementation partner to confirm the migration scope in writing, including which content, users and redirects are in scope.
Some sites run a Drupal version that is past its security support window. Drupal 7 security support ended on January 5, 2025. The Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors for sites that cannot migrate yet. Using such a provider buys time for the migration; it does not replace it. The migration sequence should start with the riskiest sites, and the extended support contract should cover the period until the replacement is live.
- Exposure assessment: Identify which sites are on an unsupported branch and which of them are public-facing.
- Interim support: Ask a listed provider to confirm scope, start date and the coverage period in writing.
- Priority order: Move internet-facing and regulated sites first, with the extended support contract covering them until cutover.
- Compensating controls: Restrict admin access, limit exposed modules and monitor logs while the site remains unsupported.
- Exit date: Set a decommissioning date for the old platform and record it in the migration plan.
Confirm the provider's coverage period and the security scope before you rely on it, and keep the end-of-life site off Acquia only after the replacement has passed verification.
What usually goes wrong and how to prevent it
Most failed Acquia exits do not fail on the code. They fail on what sits around it: files, settings, versions and the DNS path users take. The cards below cover the failure points we see most often in this kind of move, each with a check you can run before cutover.
Files missing after database restore
A database backup holds rows, not the uploaded images, PDFs and media in the files directory. If only the database is restored, pages render with broken media and nobody notices until editors do. Compare file counts and checksums between the Acquia file store and the new host, and confirm that private files and the public files path are both copied. Run a sample of media URLs against the new environment before you cut over.
Configuration drift between environments
Drupal stores much of its site configuration in exported YAML, and the database holds the active copy. If production has been edited directly, the Git repository and the live site disagree, and a fresh deploy can silently revert content types, views or permissions. Run a configuration export on the source and diff it against the repository, then import into the target and confirm that the configuration status reports no differences.
Acquia-specific settings left in code
Acquia sites often include settings files that read Acquia environment variables, Acquia Purge hooks or Cloud API credentials. On a self-hosted server these references point at nothing, causing errors, or they fail quietly and disable caching or search. Search the codebase for Acquia identifiers, remove or replace them with your own settings, and confirm that cache, search and cron hooks still run after the first deploy on the new host.
PHP and web server mismatches
A Drupal release sets a minimum PHP version, and the target server must meet it along with the required database and web server. Acquia may run a PHP version your new stack does not, or the reverse. Check the PHP version your target Drupal release requires, confirm the PHP extensions in your composer dependencies, and test the rewrite rules for your web server before any traffic moves.
Unplanned major upgrades during cutover
Moving hosts while also moving to a new Drupal major version doubles the failure modes and makes rollback ambiguous. Keep the cutover on the same major version your site runs today, and schedule the upgrade as a separate change after the new platform is stable. Confirm the core release schedule for the version you run, so the upgrade window does not collide with a planned end of life date.
DNS and TTL delays
Cutting DNS over is not instant, because resolvers cache records for as long as the TTL allows. Lower the TTL on the record well before the change, so a rollback can take effect quickly. Keep the old Acquia environment running until traffic has clearly moved, and check that both the apex domain and any www or CDN hostnames point at the expected origin.
Loss of the security update routine
On Acquia, platform patching and some security work are handled for you. After the move, your team owns the update cycle, including core and contributed module releases and the PHP runtime. Subscribe to the Drupal Security Team advisories, assign an owner for each advisory, and rehearse one security update on staging before go-live so the routine is proven, not assumed.
Questions buyers ask before moving Drupal off Acquia
How much effort does moving Drupal off Acquia take?
The effort depends mostly on the size of the codebase, how many Acquia-specific modules and settings the site relies on, the number of environments, and how much of the content and integration surface must be tested before cutover. Moving a site is a migration of code, database, files, configuration and deployment, not a file copy. Get a written breakdown from your team or a partner that lists each of these components, the number of environments to rebuild, and the performance and regression tests you expect. Ask which steps are one-time (building the new hosting, pipelines and tests) and which recur (patching, backups, monitoring). Treat any duration you are given as a claim to verify against your own site inventory.
What does the team need to provide for the move?
You need people who can own the target platform after cutover, along with access and information that only your organization holds. Typically that includes the Git repository and branch model, the database and file backups taken from Acquia, environment variables and secrets, DNS and certificate control, third-party service credentials, and the list of Acquia add-ons in use. Someone must approve the content and security acceptance criteria and sign off on cutover. Ask any partner to name the roles it expects from your side so these commitments are agreed in the written scope before work starts.
Can an internal team move Drupal off Acquia without outside help?
Yes, if the team already runs Drupal in production and has the skills in Linux administration, the web server and database, Composer based deployments, backups and monitoring. Drupal is GPL licensed, so the code itself can run anywhere you choose. The harder parts are usually replacing Acquia-specific tooling, rebuilding the deployment pipeline, setting up performance testing and writing a tested rollback. A useful self-check is whether the team has ever restored a full backup into a clean environment. If that answer is uncertain, a fixed-scope engagement can cover the gap, with the scope, deliverables and timelines agreed in writing before work starts.
How do I keep a rollback path during the cutover?
Keep Acquia running and unchanged until the new environment has passed its acceptance tests, then lower the DNS record time to live well before the switch so that a change can be reversed quickly. Take a fresh database and file backup immediately before cutover and confirm it restores cleanly. Define in advance the conditions that trigger a rollback, such as failed login, broken forms or elevated error rates, and who is authorized to make the call. Plan how content edited on the new site during a short overlap will be handled if you roll back, because that is the step teams most often miss.
Does moving off Acquia change Drupal licensing costs?
Drupal itself has no licensing fee to remove. Drupal and contributed projects on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal, so self-hosting does not create a license purchase. The costs that change are the ones Acquia bundles into its subscription, such as hosting, managed platform tooling, support and some add-ons. Before deciding, check each commercial or third-party module you use for its own license terms, and check whether any Drupal extended support arrangement you plan to rely on has its own fees. Ask for a line-by-line quote that separates these components.
What ongoing work follows once Drupal runs on our own infrastructure?
Drupal core bugfix releases come out on the first Wednesday of each month, and security releases come out on the third Wednesday. Major versions typically arrive every three years, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Plan a monthly patch window, a security response process that can apply a release within days, and regular testing of contributed modules before each update. Drupal 11 is the current major version, and Drupal 12 is scheduled for the week of December 7, 2026. Budget for at least one major upgrade cycle in your operating model and confirm the upgrade approach in writing.
Which PHP and database versions must the new hosting support?
Your hosting must match the Drupal version you run. According to the Drupal.org PHP requirements page, 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, and no supported version runs on PHP 7. Drupal runs on Apache, Nginx and other web servers, with MariaDB, MySQL, PostgreSQL or SQLite as the database, according to the Drupal.org system requirements page. Confirm that your chosen database engine and version are supported by the Drupal release you plan to deploy, and that your existing contributed modules work with it before cutover.
How DeployOpen scopes and runs the Acquia exit
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Drupal inside your own infrastructure, whether that is your cloud accounts, a data center or an air-gapped network. The work covers the parts Acquia currently handles for you: the database and file backup routine, the non-production environments, the deployment pipeline, the web and cache tier, monitoring, and the replacement for Acquia-specific tooling. Before any build starts, the scope is written down: which sites and environments move, which Acquia add-ons need a replacement, who owns each runbook after handover, and what the cutover and rollback steps look like. Most engagements are fixed-scope, so the deliverables and timelines are agreed in writing first, and a quote follows from that written scope.
Scope is where most exit risk sits, so the questions to settle early are concrete. Confirm which Acquia-provided services your team relies on, such as the managed certificate and CDN configuration, search, scheduled tasks and access controls, and which of them have an owner on your side once Acquia access ends. Confirm the Drupal version you run and whether an upgrade is needed on the way out, because that changes the test plan and the timeline. Ask for the deliverables in writing, including the restore test of a database and file export, the hardening baseline, the backup and restore runbook and the cutover and rollback plan. Ongoing support, upgrades and continuous testing are available as retainers, which keeps security updates on Drupal's release windows from falling to a team that has just taken over the platform.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as the configuration records, access reviews, backup test results and change logs that an assessor will ask for. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so confirm early with your assessor which evidence they expect from a self-hosted Drupal platform and which records must come from your own tooling. If your organization has a compliance obligation tied to the hosting change, agree that evidence list in the written scope so the cutover produces it.
