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.
The install copies in an afternoon. The behaviour visitors actually experienced is configured somewhere else.
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.
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.
Performance hosts often carry database tuning done specifically for your workload, and none of it is visible in a site backup.
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.
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.
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.
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.
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. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, cache behaviour rebuilt before cutover, and both sides timed before you commit.