Most of a move from Pantheon is eWay's work: building the new environment, adapting the code, copying the data, and switching over. Your part comes down to three things: giving access, making a handful of decisions, and testing before the switch. This article lists all of it, so nothing waits on a question nobody asked.
Who does what
| Your organization | eWay |
|---|---|
| Add eWay to the Pantheon site team | Inventory the site, its code, and Pantheon dependencies |
| Confirm the contract end date with Pantheon | Build the AWS environments from infrastructure as code |
| Name a person who can approve DNS changes | Adapt the code and replace Pantheon-specific pieces |
| Make the decisions listed below | Copy code, database, and files, and rehearse the cutover |
| Test on the temporary address and sign off | Run the cutover, verify, and monitor afterwards |
Access eWay needs
- Pantheon dashboard: an invitation to the site's team so eWay can read the settings and take backups. Terminus, Pantheon's command-line tool, then lets eWay download the code, database, and files directly.
- DNS: access to your DNS provider, or a contact who can make changes on request.
- Integrations: a list of services the site connects to, such as a CRM, payment gateway, single sign-on, or email service, and who owns each one.
Pantheon features to account for
A site that has lived on Pantheon quietly depends on parts of the platform. Each one gets a replacement on AWS:
| On Pantheon | What it does | On eWay-managed AWS |
|---|---|---|
| Pantheon settings files | PHP version, protected paths, and database credentials, in pantheon.yml and Pantheon code in wp-config.php or settings.php | Environment settings and a secrets store |
| Global CDN and free HTTPS | Page caching at the edge and certificates | CloudFront and managed certificates |
| Object Cache (Redis) | Speeds up database-heavy pages | Managed Redis |
| Pantheon Search (Solr) | Site search | Managed Solr or OpenSearch |
| Quicksilver hooks | Scripts that run on deploys and other events | Steps in the deployment pipeline |
| Multidev and Dev, Test, Live | Environments for development and review | Separate environments with the same workflow |
| Platform cron and Pantheon plugins or modules | Scheduled jobs and cache clearing | Scheduled tasks; Pantheon-only plugins removed |
Common surprises
- Allow lists. Partners or internal systems that only accept connections from your current host's addresses need the new addresses before cutover.
- Hard-coded paths and domains. Content or code that refers to Pantheon file paths or the
pantheonsite.iotest domain. - Search tuning. Relevance settings that lived in the hosted Solr configuration rather than in the site.
- Email records. SPF and DKIM need updating when the site starts sending through a new service.
Decisions only you can make
- The cutover window. Pick a quiet time, away from deadlines, enrollment, campaigns, or public meetings.
- The content freeze. Editors stop publishing for a few hours during the final copy. Decide who tells them and when.
- What to leave behind. Old Multidev environments, unused plugins or modules, and stale files do not need to move.
- Who signs off. One named person who confirms the site is ready to switch.
Testing: your sign-off checklist
Before the switch, eWay gives you a temporary address for the new site. Check the things your visitors and editors rely on:
- Key pages look right, including the home page and your most visited pages
- Every form submits and its email arrives
- Search returns current results
- Editors can sign in, edit, and publish
- Integrations work end to end, such as payments or CRM updates
Cutover day
eWay lowers DNS caching times in advance, freezes content, runs a final copy of the database and files, and switches DNS. The Pantheon site is not changed until you accept the new one, so switching DNS back is the rollback. Most visitors see the new site within minutes; a few may reach the old one for a short while, which is why Pantheon stays untouched until afterwards. Keep the Pantheon plan active until you have signed off.
How eWay runs Pantheon migrations
A single WordPress or Drupal site typically takes six to ten weeks from start to cutover; multi-site or heavily integrated platforms take longer. eWay builds the new environment from infrastructure as code on a temporary domain, rehearses the DNS and certificate cutover end to end, and plans for no unplanned downtime. After go-live, eWay operates the site: updates, security, monitoring, backups, and support.
What to include in a support ticket
- The Pantheon site names and their live domains
- Your Pantheon contract end date
- Integrations and who owns each one
- Dates to avoid for the cutover
eWay customers can open a ticket in the support portal or email support@ewaycorp.com. Related reading: keeping redirects and search rankings when you move, managing DNS, and migrating from Acquia Cloud.
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