WordPress hosting for sites leaving Flywheel.
Most Flywheel plans give you no shell access at all, so a migration that assumes SSH cannot even start. The export has to be planned around that first.
What a Flywheel migration has to work around.
The constraint is not the site, it is what the platform lets you take out of it.
No shell, no problem
Shell access is absent on most plans, so the copy is pulled over the access you do have rather than assuming a route that is not there.
FlyCache, replaced not carried
Their cache is a platform layer rather than a plugin, so there is nothing to move. Caching is set up here instead, and any leftover configuration pointing at it is cleared.
The Local copy on somebody's laptop
Teams frequently have a Local by Flywheel export more recent than anything the panel will produce. That is a legitimate starting point and we will work from it.
Staging environments
Flywheel staging is a separate environment that often holds work nobody merged. We list what exists so it is retired on purpose rather than by accident.
Platform plugins
Anything installed to talk to Flywheel's control panel has nothing to talk to afterwards, so it comes out during the copy.
Whatever access you have is enough.
The usual blocker on this move is somebody discovering halfway through that the export path they planned needs a shell they do not get. We establish that at the start.
- Available access confirmed before the export begins
- Staged copy on a temporary domain for review
- Cutover at a time you choose
- Old host left running until you confirm
Caching you can see the rules for.
Replacing a platform cache with one you can inspect is most of the change here - the same pages, served from rules that are written down.
What we change when a site arrives from Flywheel
These are the specific things this move needs, and most of them follow from how little the platform lets out.
| Setting | What we do | Why |
|---|---|---|
| Export route | Planned around the access your plan actually grants | Most Flywheel plans provide no shell, so a migration designed around SSH stalls before it starts. |
| FlyCache configuration | Cleared, with caching rebuilt here | Their cache is a platform layer with no portable equivalent, and leftover settings point at something that will never answer. |
| Local exports | Accepted as a source when a live pull is not possible | A Local copy is frequently more current than anything the panel will export, and refusing it means rebuilding work that already exists. |
| Staging environments | Enumerated and retired by decision | Flywheel staging is separate infrastructure and regularly holds changes nobody merged into production. |
| Platform plugins | Removed once the host-side counterpart is gone | A plugin whose only job is talking to a control panel becomes overhead the moment you leave it. |
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.
Flywheel does not give me SSH. Can you still migrate the site?
What replaces FlyCache?
I have a Local by Flywheel copy. Is that any use?
Does my staging site come across too?
Do I need to cancel Flywheel before you start?
Leave Flywheel without needing a shell you never had.
Free migration planned around your actual access, and caching rebuilt with rules you can see.