Organizations usually start looking at leaving Acquia Cloud for one of three reasons: the renewal quote, a need for infrastructure they control within their own AWS agreements, or a wish for an operations partner who manages the application as well as the platform. Whatever the reason, the Drupal site itself moves fairly easily. The work is in the parts of Acquia's platform the site quietly depends on. Identify those early, and the migration becomes predictable.
Start with the calendar
Look at your Acquia contract end date before anything else, and count backwards. A single Drupal site typically takes six to ten weeks to migrate; a multi-site platform or one with complex integrations can take twelve to twenty. Add time for procurement and a buffer before renewal. Starting a few months ahead avoids paying for an extra term while the migration finishes.
Acquia-specific dependencies to find
| On Acquia | What it does | Replacement on AWS |
|---|---|---|
Platform settings include in settings.php | Injects database credentials and platform settings | Environment-specific settings from environment variables and a secrets store |
| Acquia Search (Solr) | Hosted search | Managed Solr or OpenSearch, with Search API reconfigured |
| Varnish and Acquia Purge | Page caching and invalidation | CloudFront with tag-based purging, plus Drupal's page caches |
| Memcache configuration | Cache backend | ElastiCache (Redis or Memcached) |
| Scheduled jobs | Cron and background tasks | Scheduled tasks running drush cron and queue workers |
| Cloud Hooks and Pipelines | Deployment automation | Git-based CI/CD running drush deploy |
| Acquia Connector and related modules | Platform integration and insight | Removed; monitoring handled by the new platform |
| Outgoing email handling | Sending site email | Amazon SES or your institution's mail relay |
| Site Factory (if used) | Multi-site provisioning | Multi-site platform with template-based provisioning |
A search of your codebase for "acquia" and a review of settings.php and the enabled module list usually surfaces all of these within a day.
The migration phases
- Discovery and cost comparison. Inventory code, modules, integrations, traffic, and storage. Produce a like-for-like cost comparison so the decision rests on real numbers.
- Build. Provision the AWS environments (dev, stage, production) from infrastructure as code: load-balanced web servers, managed database, cache, search, file storage, CDN.
- Adapt the codebase. Replace the Acquia-specific pieces above, remove platform modules, and wire in the new settings.
- Migrate and validate. Copy the database and files, rebuild search indexes, and test every integration, form, and scheduled job on a temporary domain. Reconcile content counts against the source.
- Rehearse the cutover. Lower DNS TTLs, practice the final sync and switch, and confirm the rollback.
- Cut over. Freeze content briefly, run a final database and file sync, switch DNS, and verify.
- Hypercare, then retire Acquia once the new environment is proven.
Keeping editors working
The only disruption editors should see is a short content freeze during the final sync, usually a few hours in a quiet window. Tell them in advance and give them a clear start and end time. Until the freeze starts, everyone keeps working on Acquia as normal.
Common surprises
- Integrations with firewall allow lists that include Acquia's IP addresses
- Files referenced by hard-coded paths that include Acquia's directory structure
- Search relevance tuning that lived in the hosted Solr configuration
- Cron jobs nobody documented, found only when something stops
- Email deliverability records (SPF, DKIM) that need updating for the new sender
Deciding whether to move
Staying on Acquia is the right answer for some organizations, particularly those relying heavily on Acquia's own products beyond hosting. The comparison should include licensing, infrastructure, support, and the operational work each option covers, not only the hosting line. A good migration partner will tell you when staying makes more sense.
Document the new environment as you build it: architecture, settings, deployment steps, and runbooks. The migration is the one moment when everything about the platform is being examined anyway, and it is the cheapest time to write it down.
How eWay runs Acquia migrations
Moving Drupal sites from Acquia Cloud to eWay-managed AWS is a common engagement for eWay. eWay provides the cost comparison before you commit, builds the environment on AWS (within your existing agreement if you have one), replaces each Acquia dependency, migrates the codebase, database, and search, validates every integration, and cuts over with no unplanned downtime. After go-live, eWay operates the whole stack: infrastructure, Drupal updates, security, monitoring, and support.
What to include in a request
- Your Acquia contract end date and the sites involved
- Rough traffic, content volume, and major integrations
- Any dates to avoid for the cutover
eWay customers can open a ticket in the support portal or email support@ewaycorp.com to start the conversation. Not a customer yet? Use the contact page on ewaycorp.com. Related reading: structuring Drupal environments and enterprise search on Drupal. More on our Drupal page.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article