Managed hosting for sites moving off Kinsta.
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.
The Kinsta configuration that lives outside WordPress.
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.
Rules held in MyKinsta, not WordPress
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.
CDN hostnames inside your content
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.
The platform mu-plugin bundle
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.
Object caching replaced, not copied
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.
Environments you may have forgotten
Staging environments and old site copies usually outlive the reason they were created. We list what exists so nothing still in use gets decommissioned.
Reviewed before anything switches.
The copy is staged on a temporary domain and you look at it first. Your Kinsta site keeps serving traffic the entire time.
- Panel configuration inventoried before the copy
- Staged copy on a temporary domain for review
- Cutover at a time you choose
- Old environment left running until you confirm
Arriving warm rather than cold.
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.
What we change when a site arrives from Kinsta
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. |
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.
What in a Kinsta setup is not in the backup?
Will my images break after the move?
Do you migrate staging environments too?
When does DNS actually change?
Should I cancel before migrating?
Move off Kinsta with the panel configuration intact.
Free migration, MyKinsta rules rebuilt, and an object cache that is warm before you switch.