Nexcess bundles a lot into the platform — caching layers, image compression, a plugin performance monitor. None of it is in your database, so none of it arrives with a copy of the site.
The files and database transfer cleanly. What needs planning is everything Nexcess was doing around them.
Nexcess stacks object caching and an edge layer with their own invalidation rules. Copy the site without reproducing them and a fast store becomes a slow one overnight.
If their optimiser was serving compressed derivatives, your originals are what actually transfers. The same pages get heavier unless something replaces it.
Their dashboard flagged which plugin was slowing the site. That visibility is a real loss on migration day if nothing takes its place.
Scaling on traffic spikes is useful and it is metered. Knowing what your peaks actually cost is worth establishing before you compare plans, not after.
The site is copied and verified here first, so the cutover is a change of address rather than a rebuild happening in production.
A Nexcess migration rarely goes wrong on the content. It goes wrong on two or three things the platform was quietly providing that were never written down.
Work the host was doing becomes your server's, and whether that is faster or slower depends entirely on what replaced it.
These differ from a standard WordPress site on the same plan, and each follows from features that belonged to the platform rather than to the site.
| Setting | What we do | Why |
|---|---|---|
| Cache layer inventory | Enumerated from the old environment and rebuilt explicitly here | Object caching and the edge layer are configured outside WordPress with their own invalidation rules, so a files-and-database copy inherits none of what made the site quick. |
| Image derivatives | Regenerated and weighed against the previous pages | A host-side optimiser serves compressed versions your library never held, so migrating the originals alone makes every page heavier without anything in the site changing. |
| Performance visibility | Plugin-level timing set up before cutover, not after | The platform dashboard that identified a slow plugin does not come with you, and losing it on the day the environment changes is when it is needed most. |
| Cron execution | Kept on a real scheduler rather than reverting to visitor traffic | Managed platforms run cron from the system, so a migration that quietly restores the WordPress default makes scheduled work depend on someone visiting the site. |
| Capacity planning | Sized against your measured peaks instead of an auto-scaling allowance | Scaling that happened automatically also billed automatically, so the real comparison needs the peak figures rather than the plan's headline. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, cache layers reproduced, and image weight checked page by page.