WordPress hosting for sites moving off Servebolt.
Servebolt's value sits in an acceleration layer configured outside your site. Copying the WordPress install brings across none of the reason the site was fast.
What a performance host keeps outside WordPress.
The install copies in an afternoon. The behaviour visitors actually experienced is configured somewhere else.
Acceleration rules, rebuilt
Cache rules and edge behaviour are configured in their platform rather than in your site. We inventory what the site relies on and reproduce it here before DNS moves.
Their optimiser plugin
It exists to talk to their acceleration layer. Once you are not on it, the plugin is issuing instructions nothing receives, and it can interfere with caching that would otherwise work.
Query and index tuning
Performance hosts often carry database tuning done specifically for your workload, and none of it is visible in a site backup.
Cache behaviour, checked rather than assumed
A site tuned around an always-on acceleration layer for years leans on it in ways nobody wrote down, so the replacement is verified on staging.
The origin, before it is exposed
As with any move off a managed edge, an origin that has only ever answered through one is usually an origin nobody has needed to harden.
Match the behaviour, then switch.
The risk on this move is a technically perfect copy that is measurably slower, because everything making it fast was configured outside the thing that was copied.
- Cache behaviour inventoried and reproduced
- Verified on staging before cutover
- Cutover at a time you choose
- Old host left running until you confirm
Measured before anybody commits.
Moving off a host chosen for speed is the one migration where the comparison has to be run rather than argued about. We time both before the DNS changes.
What we change when a site arrives from Servebolt
These are specific to leaving a host whose product is performance rather than a control panel.
| Setting | What we do | Why |
|---|---|---|
| Acceleration rules | Inventoried from the old platform and reproduced on our edge before DNS moves | Cache and edge behaviour are configured outside WordPress, so a site copy contains no trace of what was making it fast. |
| Optimiser plugin | Removed during the copy | It communicates with an acceleration layer that will not be there, and left in place it can prevent caching that would otherwise work. |
| Database tuning | Captured where it exists and reapplied here | Performance hosts frequently carry workload-specific query and index tuning that no site backup records. |
| Cache behaviour | Verified on staging rather than assumed equivalent | Years of building around an always-on acceleration layer creates dependencies nobody documented, because nobody needed to. |
| Origin hardening | Verified before the proxy in front of it changes | An origin that has only ever been reachable through a managed edge is usually one nobody has had reason to protect. |
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.
Will my site be slower after moving?
What happens to the Servebolt optimiser plugin?
Is any of the performance tuning in my site backup?
Can I compare the two before committing?
What about my origin security?
Leave Servebolt with the speed reproduced, not assumed.
Free migration, cache behaviour rebuilt before cutover, and both sides timed before you commit.