Migrate a site

Moving an existing WordPress site onto managed.dev is free and white-glove. You grant read access, the migration team copies your database, files, plugins, and themes, and the site comes up as a branch environment with a preview URL. You review it against your live site, and only after you sign off does DNS cut over — with zero downtime. Your old host keeps serving traffic the entire time.

Nothing changes on your live site

Migration is a copy, not a move. Your current host stays live and authoritative until the DNS cutover. If the review surfaces a problem, your production traffic is never affected.

Supported sources

We migrate from the common managed-WordPress hosts and from raw infrastructure:

• WP Engine
• Kinsta
• Pantheon
• Flywheel
• Pressable
• Rocket.net
• Cloudways
• A raw VPS or cPanel server

If your source isn’t listed, it’s almost certainly still supported — anything we can reach over SSH/SFTP or a database export plus a files archive can be brought in. Ask when you start the migration.

How a migration runs

1. Start the migration. From a team, choose Migrate a site and pick your source host. You’ll tell us the domain and how we should connect.

2. Grant read access. Provide read-only credentials or a temporary access grant for the source — for managed hosts that’s typically SFTP/SSH plus database access; for a VPS, read access to the webroot and a database dump. We only ever need read access to copy your site.

3. We copy everything. The migration team copies the database, the files (uploads and wp-content), and your installed plugins and themes at their current versions. managed.dev detects the runtime (Bedrock, vanilla, or static) and assembles the right site profile.

4. It comes up as a branch environment. Your site is provisioned as an isolated environment — its own database and files — with a live preview URL, exactly like any other branch environment. Nothing touches your real domain yet.

   A migration review screen in app.managed.dev showing the imported site as a “migration” environment with a preview URL, a checklist of copied assets (database, uploads, plugins, themes) each marked complete, and a “Looks good — schedule cutover” button.

5. You review. Open the preview URL and compare it to your live site — pages, media, forms, checkout, admin. Run WP-CLI against it over the SSH gateway if you want to inspect more deeply. Take as long as you need; the preview stays up.

6. Zero-downtime cutover. When you sign off, we schedule the DNS cutover. TLS is issued automatically ahead of time so the certificate is ready, and traffic moves to managed.dev with no downtime. Your old host can be decommissioned once you’re satisfied the cutover is clean.

Plan the cutover with the checklist

Before the DNS change, walk the go-live checklist — domains, DNS records, TLS, caching, and search-replace — so the cutover is a formality rather than a scramble.

After cutover

Once DNS has moved, the migrated site behaves like any other managed.dev site: push branches for preview environments, deploy with git push, and get the full security and observability pipeline. The migration environment can be promoted to production or retired, your choice.

Next steps

Migrate from WP EngineA step-by-step walkthrough of a WP Engine move, from access grant to cutover.

Go-live checklistEverything to verify before and after the DNS cutover, in order.

Custom domainsAdd your domain and prepare DNS for a clean cutover.

Core conceptsUnderstand sites, environments, and runtimes before your first deploy.