Pantheon is opinionated in ways your site has adapted to: a read-only filesystem, no .htaccess, and a three-environment workflow. The migration is largely a matter of undoing those adaptations.
Several years of working around platform constraints leaves configuration that no longer has a reason to exist.
Plugins that normally write into wp-content were reconfigured to write elsewhere, or disabled outright. The filesystem here is writable, so those workarounds are removed rather than carried forward as dead configuration.
Their three-environment model is replaced by cloning and pushing from the dashboard. It is a different shape rather than a direct equivalent, so we map how your team deploys before the move.
Configuration held in pantheon.yml and their nginx layer has no equivalent file in a WordPress backup. We read it and reimplement whatever it was doing.
Redis was an extra there and is on by default here, so the site does not arrive slower than it left while somebody works out why.
Asset URLs and edge configuration are reproduced on our edge, so a site tuned around a particular caching layer for years does not lose that behaviour overnight.
Teams moving off a three-environment model are the ones most likely to be caught out after cutover, so the replacement gets agreed before the move rather than discovered during a release.
If the object cache was an add-on you were paying for, a migration that quietly drops it looks like the new host is the problem.
These are the specific things a Pantheon site needs attention on, most of which exist because of how that platform is built.
| Setting | What we do | Why |
|---|---|---|
| Filesystem workarounds | Removed once the site is on a writable filesystem | Plugins reconfigured to cope with a read-only wp-content keep behaving oddly after the restriction is gone, and the configuration outlives the reason for it. |
| pantheon.yml and nginx rules | Read and reimplemented as edge and server configuration | Neither appears in a WordPress export, so anything they were doing simply stops on the day you move. |
| Deployment workflow | Mapped from dev/test/live onto cloning and pushing from the dashboard | A team used to promoting between three fixed environments needs the replacement explained before cutover, not during their next release. |
| Object cache | Redis on by default rather than as a paid add-on | If it was enabled there and not here, the site arrives measurably slower and it looks as though the migration caused it. |
| Edge configuration | Existing caching behaviour reproduced on our edge before the switch | Sites tuned around a specific edge cache for years depend on that behaviour rather more than anybody documented. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, workarounds unwound, and your deployment process agreed before anything switches.