WordPress hosting for teams moving off Pantheon.
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.
A Pantheon site carries the shape of the platform it was on.
Several years of working around platform constraints leaves configuration that no longer has a reason to exist.
Code that worked around a read-only filesystem
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.
A dev, test and live workflow to replace
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.
nginx rules instead of .htaccess
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.
Object caching, if it was a paid add-on
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.
Edge behaviour the site relied on
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.
The workflow matters as much as the site.
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.
- Deployment process mapped before the copy
- Platform workarounds identified and removed
- Cutover at a time you choose
- Old environment left running until you confirm
Not arriving slower than you left.
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.
What we change when a site arrives from Pantheon
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. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
My plugins were configured around a read-only filesystem. What happens?
What replaces the dev, test and live environments?
There is no .htaccess on Pantheon. Where does that configuration go?
Was Redis an extra there?
Can you match our current deployment process?
Move off Pantheon without carrying its constraints with you.
Free migration, workarounds unwound, and your deployment process agreed before anything switches.