How to export your site from Acquia

How to export your site from Acquia: what you can take and what you rebuild

The Drupal codebase is yours to keep. Drupal core and contributed projects on Drupal.org are licensed under GPL-2.0-or-later, so the code you run on Acquia can be copied, hosted elsewhere and run without a license fee. What you must actively export is everything Acquia holds for you: the database, the uploaded files in the public and private file directories, the configuration and the environment settings. Those four items, plus the platform tooling around them, decide whether a renewal or residency deadline can be met on time. Start with an inventory of each environment (production, staging and development) because the database and files may differ between them.

Take the database from Acquia's interface or with the Acquia CLI, and copy the files separately, since database backups do not contain uploaded assets. Pull your Drupal configuration from the Git repository and confirm that the exported configuration matches what is live. Then list the Acquia-specific pieces, such as environment variables, cron schedules, CDN and caching rules, load balancer or Varnish settings, and any Acquia modules or add-ons, so each has a named replacement. Acquia's documentation changes over time, so check every export command, backup path and retention setting against the current Acquia pages before you run them. Acquia-side steps are not covered here in full.

Prove the export before the contract ends. Restore the database and files into a clean environment on your own infrastructure, run drush cr and drush updb, and compare content counts, menus, users, redirects and media against the live site. Confirm that the restored site runs on a PHP and database version your target host supports. Keep a dated, checksummed copy of each artifact in storage you control, and ask your Acquia account team in writing what they will retain and for how long after termination. The migration plan, cutover and DNS work sit in the sibling move guide, so use this checklist as the gate that decides whether that work can start.

Which Acquia site data you can export, and how

This table lists each part of an Acquia-hosted Drupal site, the method used to export it, the format it arrives in, and the limits to confirm. Database and file exports are separate steps, so a backup alone does not give you a working site. Confirm command names and size or retention limits with Acquia support before you plan the cutover.

Data type	Export method	Format	Limits to confirm
Database backups	Acquia Cloud interface or Acquia CLI backup command (confirm exact command name in current Acquia docs)	Database dump, typically SQL (unverified)	Backup retention window and maximum download size (unverified, confirm with Acquia support)
Public and private uploaded files	Copy separately from the environment file system, not included in database backups	Original file tree as stored on the server (unverified)	Total file volume, transfer speed and access rights to the private file system (unverified)
Codebase	Clone the project's Git repository hosted by Acquia	Git repository with full history	Confirm branch and tag coverage and any Acquia-specific build files included (unverified)
Drupal configuration	Export active configuration to the codebase with Drush config export, then commit it	YAML files in the config directory	Confirm the config directory is committed and matches the live site before export (unverified)
Environment-specific settings	Review environment variables, settings files and secrets held in Acquia's environments	Settings PHP files, environment variables and service credentials (unverified)	Acquia-managed secrets may not be downloadable; confirm with Acquia support which values you can retrieve (unverified)

What Acquia does not hand over, and how to replace it

Acquia's platform bundles hosting, edge delivery, monitoring and secrets handling in ways that a database and file export does not capture. Each item below needs a named owner and a replacement before the cutover date. Confirm each one against your own environment and against what Acquia's support team says is included in your exports.

Acquia-managed hosting and runtime

Acquia runs the web servers, PHP runtime, database service and environment layout for each site. None of that comes with the codebase. Record the PHP version, web server, database engine and version, and any cron or queue workers your site depends on, then rebuild them in your own container or VM definitions. Check that your Git repository holds every custom and contributed module and the composer lock file, so the same build runs elsewhere.

CDN and edge configuration

Caching rules, purge behavior, and any edge redirects or header rules configured in Acquia's interface live outside your repository. Export the rules you rely on by screenshot or by asking Acquia support what format is available, then recreate them in your own CDN or reverse proxy. Plan the DNS change and TLS certificate issuance so traffic moves in a controlled step, with a rollback path to the old host.

Platform monitoring and alerts

Uptime checks, platform alerts and log retention configured in Acquia do not move with your site. Inventory every alert your team currently receives and which person acts on it. Rebuild the same checks with your own monitoring stack, and confirm that the new alerts fire on a test failure before the old ones are switched off.

Acquia-specific modules and integrations

Some sites depend on Acquia modules, connectors or search and content services that are tied to the platform. Audit the composer dependencies and the settings files for any Acquia-specific module, then replace each with an open-source contributed module or a service you run. Test each replacement on a copy of the production database before cutover.

Environment variables and secrets

Environment variables, API keys and database credentials held in Acquia's environment settings are not part of a code export. Build an inventory of every variable each environment reads, then move the values into your own secrets manager and reference them from settings.php or the environment. Rotate credentials after the move so the old platform no longer grants access.

User accounts and password hashes

A database backup includes the user table, but the format of password hashes and any linked single sign-on identities determines whether users can log in on the new host without a reset. Ask Acquia which account data is included in the export and whether it covers SSO mappings. Test a sample login on the restored copy before you announce the cutover.

Export sequence: from database backup to a verified copy

This sequence produces a complete, point-in-time copy of your Acquia-hosted Drupal site (database, files, code, configuration and environment settings) stored somewhere you control, with a check at each step that proves the copy is intact. Work through it in order, because each step assumes the previous one is finished.

Freeze content or schedule a maintenance window
Decide with the content owners when editing stops, then announce a maintenance window or disable editorial access for the duration of the export. The site lead or project manager owns this decision, and the on-call engineer confirms that no scheduled jobs, content imports or deployments are queued. Record the agreed start time and the name of the person who approved the freeze. The step is done when nobody can change content between the database backup and the file copy, which keeps the two sources consistent.
Take a fresh database backup
Create a new database backup of the production environment through the Acquia interface or the Acquia CLI, and do not reuse an older backup taken before the freeze. Confirm the exact commands and backup options in Acquia's current documentation, since they can change between CLI releases. Record the backup identifier, the timestamp and the file size. Download the file, then generate a SHA-256 checksum on your side and store it next to the file. The step is done when the local checksum matches the value you recorded at download, and the file opens in a database client without errors.
Copy uploaded files separately
Database backups do not include uploaded files, so copy the public and private file directories as a separate operation. Confirm with Acquia support or the documentation which file paths and transfer methods apply to your subscription and environment. Compare the file count and total size on the source with the copy, and generate a checksum manifest for the directory tree. Keep the manifest with the database backup. The step is done when the counts and sizes match and a random sample of images and documents opens correctly from the copy.
Export the codebase at the deployed tag
Clone your Git repository and check out the exact tag or commit that is currently deployed to production, not the tip of the main branch. Confirm which reference is live by comparing the deployed code information in the Acquia interface with your repository. Create a bundle or archive of that revision, including the composer.json and composer.lock files, so the dependency versions are preserved. Record the commit hash in your migration log. The step is done when the commit hash matches the one deployed to production and the archive builds in a clean environment.
Export configuration and record environment settings
Export the Drupal configuration from the production environment into the codebase, then compare it with the configuration files in the Git revision from the previous step. Any differences mean that changes were made in the interface and must be committed before you proceed. Separately, list every environment variable, secret reference, domain, cron schedule, trusted host pattern, SMTP setting, and Acquia-specific setting file, and store the secrets in a password manager or secrets store rather than in plain text. The step is done when the configuration export shows no unexplained differences and the settings inventory has a reviewer's sign-off.
Store everything in a location you control
Move the database backup, file manifest, code archive, configuration export, settings inventory and migration log to storage that your organization owns, such as an encrypted object store or a backup server in your own infrastructure. Keep at least two copies in separate locations and restrict access to named people. Write a short index that lists each artifact, its checksum and the commit hash. The step is done when every checksum in the index can be recomputed from the stored copies and the access list is recorded.
Restore the copy and verify it elsewhere
Restore the database, files and codebase into a separate test environment that does not connect to Acquia services or production email, and then run the site's core pages, search, logins and content editing. Compare record counts for key content types and user accounts with the production figures captured in the freeze window. Confirm the restored site renders the same pages as the source, using a sample of URLs. The step is done when a named reviewer signs off on the test results, and any gaps are logged as blockers before the production cutover starts.

Why the Drupal codebase is the easy part to keep

The Drupal codebase is the part of an Acquia site you can keep with the least legal friction. Drupal core and the contributed projects hosted on Drupal.org are licensed under GPL-2.0-or-later, and there is no paid edition of Drupal itself. Acquia sells hosting, tooling and add-ons around Drupal, not a license to the core code. The GPL also does not require you to publish code that is only used to run your own website, so running the same codebase on your own servers creates no obligation to share your configuration or deployment scripts. Confirm the details against the Drupal.org licensing page before you rely on them in a contract review.

Custom modules, custom themes and any Acquia-supplied or proprietary code need their own license check. Ask Acquia in writing which of your repository components came from its tooling, which packages are under a commercial license, and whether any template or starter code carries terms that differ from GPL. Make a list of every custom module, theme, and Composer dependency that is not from Drupal.org, and record its license beside it. Those entries decide what you can copy, what you must rewrite and what needs a written grant from the vendor.

Version planning decides what you export into. Drupal 11 is the current major version, Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026, with PHP 8.5 or later required. Match the PHP version and the database to the Drupal version you will run on the target host, and check the Drupal core release schedule for the current dates. If your site is on Drupal 10, the export is also the moment to decide whether you move to Drupal 11 first, because a database restored into a newer or older stack can fail for reasons unrelated to the content.

Confirming the export restores on your own servers or another host

On a virtual machine or bare-metal server you control, the restore test starts with the stack. Drupal runs on Apache or Nginx, and its database can be MariaDB, MySQL, PostgreSQL or SQLite, according to Drupal's system requirements. Install the same database engine and major version as the Acquia source, then import the dump and confirm the import completes without errors.

Web server: Confirm Apache or Nginx serves the document root and that rewrite rules route requests to Drupal's front controller.
Database: Import the Acquia dump into a matching engine, then check table counts and the users and node_field_data tables for expected rows.
PHP version: Match the PHP version to the Drupal version in use. Drupal 10 requires PHP 8.1 or later, and Drupal 11 requires PHP 8.3 or later, per Drupal's PHP requirements.
File permissions: Make the public and private file directories writable by the web server user and not world-writable, and confirm settings.php is readable only as needed.
Configuration import: Run drush config:import against the exported configuration and resolve any reported differences before continuing.

Finish with a login and content smoke test: sign in as an administrator, open several content types, and confirm images and attachments load. Record the exact web server, database, PHP and Drupal versions used.

A managed PHP or Drupal host has its own control panel, file layout and version policy, so the checks depend on what the provider offers. Ask the host which web server, database engines and PHP versions it supports, and confirm the Drupal version it runs before you import anything. Some hosts restrict shell access or database imports, which changes how you run the configuration import.

Web server and database: Confirm the host runs Apache or Nginx and offers a database engine that matches the source, and that you can import the dump through its tools or support.
PHP version: Select the PHP version the Drupal release requires, and check that the host lets you set it for the site without affecting other applications.
File permissions: Upload the public and private files to the locations the host expects, then confirm the web user can read and write only the directories Drupal needs.
Configuration import: Run drush config:import if shell access is available, or confirm with the host how the configuration files will be applied.
Login and content smoke test: Sign in, open representative pages, and check that media, redirects and forms behave as they did on Acquia.

Keep a written list of the host's versions and any settings the host changed from defaults.

What to plan before the Acquia contract renews or ends

The export itself is the smallest part of leaving Acquia. The items below decide whether a restore on another host succeeds on time, and several depend on each other: the notice period sets the rehearsal date, and the Drupal release calendar sets the target version. Confirm every contract term with Acquia directly.

Confirm export terms in writing

Ask Acquia, in writing, what data-return support it provides, in which formats, within what period, and whether database and file exports are available after the subscription ends. Ask how long Acquia keeps your backups after termination and whether it deletes them on request. Notice periods and renewal windows are set by your contract, so confirm them with Acquia rather than assuming a standard term.

Schedule a dated export rehearsal

Work backward from your notice deadline and book a full export and restore before it. A rehearsal should restore the database and files into a clean environment on the target host, then record how long each step took. Treat the first run as a test of your process, not as the final export, so that the real cutover has no unknowns left.

Choose the target Drupal version

Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Decide whether you move to Drupal 11 now or go directly to a newer major version, because each one raises the minimum PHP version and may require contributed modules to be updated. Check your current modules and themes against the target before the export, not after.

Plan DNS and TLS cutover

Lower DNS record TTLs well before the cutover so changes propagate quickly, and issue or copy TLS certificates for every hostname before traffic moves. Keep the Acquia environment live until the new host has passed smoke tests and a short period of real traffic. Define the rollback path in advance: which record you revert, who approves it, and how content edited on the new site during the overlap is reconciled.

Budget for the team that runs it

After cutover, someone must apply Drupal's monthly bugfix releases, its security releases, PHP upgrades, backups and monitoring that Acquia previously handled. Identify the named owners, decide whether they are internal staff or a support partner, and get a quote that covers those recurring tasks, not only the initial migration. This cost continues every year, so it should appear in the renewal comparison.

Keep an export archive

Store a complete, checksummed copy of the final database export, the file archive, and the Git tag that matches the production code. Decide with your legal and records teams how long the archive must be kept, who can access it, and where it is stored. Test that the archive still restores after several months, because a backup that has never been restored is an assumption rather than evidence.

Common questions before exporting a site from Acquia

Can our team export a Drupal site from Acquia without a partner?

Yes, a capable in-house team can export the database, files, codebase and configuration, provided it has the right access and time. The harder part is rebuilding what Acquia runs for you, such as backups, environment replication, deployment pipelines and the Acquia-specific modules and settings in use. Teams with one or two environments and few custom integrations often manage the export internally. Teams with many environments, custom login flows or strict change windows usually benefit from a written scope with a partner, so responsibilities are agreed before cutover.

What makes an Acquia export take more effort?

Effort rises with the amount of content, the number of environments, and how much the site depends on Acquia or custom code. The main drivers are:

Site size, including database volume and the number of uploaded files
Number of environments that need replicating, such as development, staging and production
Custom integrations with CRM, search, payment or other third-party services
SAML or OpenID Connect login setup, which must be reconfigured against your identity provider. The contributed samlauth and OpenID Connect modules are common starting points, and each needs its own testing.

Ask any provider to list these items in the scope so the effort is visible before work starts.

How long does an Acquia site export take?

No duration has been established for this work, so do not plan around a number from this page. The time depends on the site's size, the number of environments, the custom code and the cutover plan. Ask any provider, including your own team's estimate, for a scoped timeline with named deliverables, dependencies and a testing window. A written scope lets you compare internal and external options on the same basis.

What does the migration need from our team?

The work needs access, people and a destination. Expect to provide:

Administrative access to the Acquia Cloud interface and the Acquia CLI for the environments in scope
Read access to the Git repository that holds the codebase
A target host, with decisions on web server, database and PHP version
A named owner who signs off on scope, content checks and the cutover date
Contacts for DNS, email, certificates and any third-party services the site calls

Confirm early who holds each credential, because access requests are often the slowest step.

Does an Acquia database backup include uploaded files?

No, a database backup does not include uploaded files. Images, documents and other media in the files directory must be copied separately, and the database only stores references to them. Check that the file copy is complete by comparing file counts and sizes between environments, and confirm that private files and any content stored outside the standard directories are included. Missing files are a common reason a restored site shows broken images after cutover.

What happens to a Drupal 6 or 7 site still running on Acquia?

Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They must be migrated into a new site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules, or with Drush. Themes must be rebuilt because they cannot be migrated. Drupal 7 security support ended on January 5, 2025, so a site still on Drupal 7 needs a plan now, whether that is a migration or a paid extended security provider. Treat the migration as a rebuild project with its own scope and testing, not as a simple export.

How do we confirm the exported site restores cleanly elsewhere?

Restore the database, files and codebase into a separate test environment that mirrors production, then check the results against a written list. Verify that:

The site loads on the target web server and PHP version, and the database connects
Uploaded files resolve on every content type that uses them
Configuration imports without errors and matches the production settings
Login, search, forms and scheduled tasks behave as expected
Email, cron and caching work in the new environment

Repeat the restore at least once before cutover, and keep the Acquia environment running until DNS and the rollback plan are proven.

Who owns security updates after we leave Acquia?

Your organization owns security updates once the site runs on your infrastructure. Drupal publishes security releases on the third Wednesday of the month, and the Drupal Security Team announces advisories that must be applied promptly. Confirm who receives those notices, who tests and deploys patches, and what the process is for emergency fixes. Also confirm that the chosen host supports the PHP version your Drupal release requires. Ask any support provider to define these responsibilities in writing.

How DeployOpen scopes and delivers an Acquia exit

DeployOpen plans and implements the move off Acquia inside your own cloud accounts, data centers or air-gapped networks, under a fixed scope agreed in writing before work starts. The work covers the database and file exports, the codebase, environment settings and a restore test so you can confirm the export works before any cutover decision.

How we scope

We confirm which Acquia environments, sites and multisite instances are in the exit, and which are retired
We inventory database backups, the uploaded files directory, Git repository access and environment settings
We agree deliverables, timelines and responsibilities in writing, with a quote that follows from that scope

How we build

We set up the export runbook, using the Acquia CLI for database backups and a separate copy for the files directory
We document Acquia-specific modules, settings and cloud hooks, and replace each one in the target environment
We test the restored site on a staging copy and record the results in the export checklist

How we hand over

You receive the runbook, the export checklist, restore test records and the inventory of what was moved
We walk your team through restoring the database, files and codebase so your staff can repeat the steps
We list open items, such as third-party integrations or DNS records, that your team must confirm

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the handover
We can support the first production cutover and the rollback plan, as set out in the written scope
We recommend you confirm Acquia's current export options and contract end dates with Acquia directly

How to export your site from Acquia