Kinsta holds a fair amount of configuration in MyKinsta rather than in WordPress. That half of the migration is the half a plugin cannot do for you.
Export the database and files and you have most of a site. The rest is in a panel you are about to lose access to.
Redirects and IP rules configured in their panel sit outside your site entirely. We take an inventory before the move and rebuild them here, because nothing in a database export contains any of it.
Their CDN rewrites asset URLs, and those rewritten URLs get saved into post content and options over time. Left alone they keep resolving to an account you have closed.
Their mu-plugins expect the platform's own cache and CDN to be present. They are removed during the copy, so the first request after cutover is not the one that discovers them missing.
Their object cache add-on is platform-specific. We enable Redis here and warm it before the switch instead of leaving the site to rebuild a cache under live traffic.
Staging environments and old site copies usually outlive the reason they were created. We list what exists so nothing still in use gets decommissioned.
The copy is staged on a temporary domain and you look at it first. Your Kinsta site keeps serving traffic the entire time.
A site that had an object cache and arrives without one looks like the migration made it worse. Warming it before the switch is what stops that impression forming.
These are the specific things a Kinsta site needs attention on, beyond copying the database and the files.
| Setting | What we do | Why |
|---|---|---|
| MyKinsta panel rules | Inventoried and rebuilt as edge rules ahead of cutover | Rules that live in a hosting panel are in no backup, so they vanish the moment DNS moves and nobody notices until the traffic figures do. |
| CDN-rewritten asset URLs | Found and replaced across post content and options | Rewritten URLs get written into the database over time, so the CDN reference outlives the account that was providing it. |
| Platform mu-plugin bundle | Stripped during the copy, before the site is staged | They expect a cache and a CDN that will not answer after the move, and that failure shows up as a broken production site rather than a staging error. |
| Object cache | Redis provisioned and warmed pre-cutover | A cold object cache on a site that previously had a warm one makes the first hour after the move look like a regression. |
| Environment inventory | Staging and legacy copies listed and confirmed before decommissioning | Old environments frequently still take traffic or run a scheduled job that somebody downstream depends on. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, MyKinsta rules rebuilt, and an object cache that is warm before you switch.