How to Migrate a WordPress Site to a New Host Without Downtime

Moving a WordPress site to a new host feels risky because it is the one task where a mistake is instantly public: visitors hit error pages, forms stop working, and search engines start crawling a broken site. The good news is that downtime during a migration is almost never caused by the migration itself — it is caused by switching DNS too early, forgetting to lower the DNS TTL, or having no rollback plan. All three are avoidable with a little sequencing.

This guide is for anyone leaving a slow or oversold shared host for something better — whether you run a blog, a client site, or a WooCommerce store. You will learn the exact order of operations: prepare DNS days in advance, clone the site to the new server, test it on a temporary URL before anyone else can see it, and only then flip DNS while both servers keep serving traffic in parallel.

We will use two destination hosts as working examples — Kinsta (fully managed, with a human migration team that does the work for you) and Cloudways (configurable cloud hosting with a free migrator plugin) — but the workflow applies to any move between hosts.

Table of contents

• How zero-downtime migration actually works
• Step 1: Lower your DNS TTL 24–48 hours before the move
• Step 2: Take a full backup and freeze major changes
• Step 3: Move the site — managed migration vs. plugin
• Step 4: Test the new site before DNS ever changes
• Step 5: Switch DNS and ride the overlap period
• Step 6: Post-migration checklist
• Common mistakes and user-reported issues
• FAQ

How zero-downtime migration actually works

The core trick is simple: your old site keeps running the entire time. You build a complete, working copy of the site on the new server while the old one serves all real traffic. Only when the copy is verified do you repoint DNS. During the propagation window, some visitors reach the old server and some reach the new one — but both serve a working site, so nobody sees an error page.

Downtime happens when people invert this order: they cancel the old host first, or point DNS at a half-configured server. Keep both hosts active through the transition and the “downtime” question largely disappears.

Prerequisites before you start:

1. Access to your DNS management panel (your domain registrar, or Cloudflare if you proxy through it)
2. Login credentials for your current hosting control panel
3. An account on the destination host
4. A recent full backup stored somewhere that is not either hosting account (local disk or cloud storage)

Step 1: Lower your DNS TTL 24–48 hours before the move

TTL (time to live) tells DNS resolvers how long to cache your domain’s IP address. Default TTLs commonly range from a few hours up to 86,400 seconds (24 hours) depending on your DNS provider — and the higher that number is, the longer resolvers around the world keep serving your old server’s IP after you change the record.

1. Log in to wherever your DNS records live (registrar or Cloudflare).
2. Find the A record for your root domain (and www if it has its own record).
3. Change the TTL from its current value to 300 seconds (5 minutes).
4. Do this at least 24 hours before you plan to switch, so the old, long TTL has fully expired from resolver caches worldwide.

With a 300-second TTL in place, the eventual cutover propagates in minutes instead of hours. This one step is the difference between a seamless switch and a day of split traffic.

Step 2: Take a full backup and freeze major changes

1. Create a full backup of files and database using your current host’s backup tool or a plugin such as UpdraftPlus, and download it off-server.
2. If you run WooCommerce, a membership site, or an active comment section, plan the DNS cutover for your lowest-traffic window, because orders or comments placed on the old server after the site was copied will not exist on the new one.
3. Freeze non-essential changes: no plugin updates, no new posts, no theme edits between the copy and the cutover. The shorter this window, the less content drift you have to reconcile.

Step 3: Move the site — managed migration vs. plugin

There are two realistic paths, depending on how hands-on you want to be.

	Managed migration (Kinsta)	Plugin migration (Cloudways)
Who does the work	Kinsta’s dedicated migrations team	You, via the Cloudways WordPress Migrator plugin
Cost	Free and unlimited on all plans	Plugin is free
Typical timing	Within ~2 business days standard; expedited as fast as ~8 hours	Depends on site size; runs while you wait
Best for	Anyone who wants zero technical involvement	Users comfortable copying SFTP credentials
DNS switch	You flip DNS only after Kinsta confirms the copy works	You flip DNS after verifying the migrated app

Option A: Managed migration (Kinsta)

Kinsta includes unlimited free migrations from any host, performed by a team whose full-time job is moving WordPress sites. The workflow:

1. Sign up for a Kinsta plan and open the dashboard.
2. Request a migration and provide access details for your current host (control panel or SFTP credentials).
3. The team copies your site to Kinsta and sets it up on a temporary URL — your live site is untouched.
4. You review the copy on the temporary URL and confirm everything works.
5. You update DNS to point at Kinsta to go live. Kinsta states there is no downtime during the migration process itself, since your original site keeps running untouched while the copy is built — you control when DNS actually changes.

Standard migrations typically complete within two business days; an expedited option can finish in as little as eight hours.

Option B: Plugin migration (Cloudways)

Cloudways provides a free WordPress Migrator plugin (listed on WordPress.org with 20,000+ active installations) that automates the copy from any host:

1. Launch a server and a blank WordPress application in your Cloudways dashboard.
2. On your old site, install the “Cloudways WordPress Migrator” plugin (search the plugin directory, upload via SFTP, or run wp plugin install bv-cloudways-automated-migration with WP-CLI).
3. Open the plugin, enter your email address (used for progress and error notifications), and supply the destination details from your Cloudways dashboard — including the SFTP credentials for the target application.
4. Start the migration and wait for the completion email. The plugin copies files and the database and automatically updates database values for the new environment.
5. Preview the migrated application on the temporary Cloudways URL before touching DNS.

Users reviewing the plugin on WordPress.org report real-world limitations worth planning around: it does not handle Bedrock-style custom folder structures, multisite networks sometimes need manual fixes to wp-config.php or URLs afterward, and it can deactivate other caching plugins (such as WP-Rocket) without an explicit warning — re-check your cache setup after migrating.

Step 4: Test the new site before DNS ever changes

Never trust a migration you have not clicked through. Two ways to test:

1. Temporary URL — both Kinsta and Cloudways give the migrated site a staging/temporary URL. Check the homepage, a handful of posts, images, forms, and (for stores) a test checkout.
2. Hosts-file trick — to see the site under your real domain, edit your computer’s hosts file (C:\Windows\System32\drivers\etc\hosts on Windows, /etc/hosts on macOS/Linux) and map your domain to the new server’s IP. Your machine — and only your machine — now loads the new server when you visit your domain, while the rest of the world still sees the old host. Verify HTTPS works and pages render correctly, then remove the line when done.

Also confirm the SSL certificate is issued on the new host before cutover — a migrated site that throws certificate errors is downtime by another name.

Step 5: Switch DNS and ride the overlap period

1. In your DNS panel, update the A record to the new server’s IP (or change nameservers, if your new host manages DNS).
2. Because you lowered TTL to 300 seconds in Step 1, most visitors move to the new server within minutes.
3. Keep the old hosting account active for at least a few days. During the overlap, stragglers with cached DNS still land on the old server and see a working site. This is your safety net — and your instant rollback: if something breaks, point the A record back and you are on the old server within minutes.
4. Watch traffic in your analytics and the new host’s dashboard to confirm requests are arriving.

Only cancel the old account once traffic has fully shifted and the new site has run cleanly for several days.

Step 6: Post-migration checklist

• Log in to /wp-admin on the new server and confirm the site URL settings are correct
• Re-save permalinks (Settings → Permalinks) to flush rewrite rules
• Test contact forms and outgoing email (email deliverability settings often differ between hosts)
• Re-point any CDN or Cloudflare settings to the new origin IP
• Verify scheduled tasks (backups, cron-driven plugins) run on the new host
• Raise the DNS TTL back to a normal value (e.g., 3600 seconds) once you are confident
• Update Google Search Console if your host changed how www/non-www redirects behave

Common mistakes and user-reported issues

• Switching DNS before testing. The most common cause of visible downtime: visitors get pointed at an incomplete or broken installation. Always verify on the temporary URL or via the hosts file first.
• Forgetting the TTL step. With a 24-hour TTL still in effect, resolvers around the world keep serving the old IP for hours after you flip the record — and if the old account is already cancelled, that means real downtime.
• No rollback plan. Keeping the old host alive turns any problem into a five-minute DNS revert instead of a crisis.
• Users report slow plugin migrations on large sites. Reviewers of the Cloudways Migrator plugin report that big media libraries can make the transfer slow; managed migration or a manual SFTP + database import may be faster for very large sites.
• Users report cache-plugin conflicts. The Cloudways plugin may deactivate other caching plugins without an explicit notice — check your caching setup after the move.
• Content drift on busy sites. Orders, comments, or posts created on the old server after the copy do not transfer. Freeze changes or schedule the cutover during a quiet window.

FAQ

How long does a WordPress migration take? The copy itself ranges from minutes (small site, plugin migration) to about two business days for a standard managed migration at Kinsta, with an expedited option as fast as roughly eight hours. The DNS cutover adds only minutes if you lowered the TTL in advance.

Will I lose SEO rankings by changing hosts? Changing hosts does not change your URLs, so there is no inherent SEO penalty. Risk comes from extended downtime or broken pages — which this workflow is designed to prevent. Keep URLs, permalinks, and redirects identical.

Do I need to tell my old host I’m leaving? Not before the migration — and you shouldn’t. Keep the old account active through the overlap period, then cancel once traffic has fully moved.

Can I migrate a WooCommerce store without losing orders? Yes, but timing matters: any order placed on the old server after the site was copied won’t exist on the new one. Migrate during your quietest hours, put the store briefly in catalog/maintenance mode for the final sync if order volume is high, and verify a test checkout before cutover.

What if my site uses Cloudflare? Even easier: your DNS changes propagate through Cloudflare almost instantly, and you just update the origin IP in the Cloudflare dashboard. Lowering TTL is handled for proxied records automatically.

Conclusion

A zero-downtime migration is 90% sequencing: lower the TTL early, clone while the old site keeps serving traffic, test on a temporary URL, then flip DNS with a rollback ready. If you want the entire process handled for you, Kinsta’s migration team will move your site free of charge and you only touch DNS at the end. If you prefer to drive, Cloudways’ free migrator plugin automates the copy in an afternoon. Either way, the days of your site going dark during a host change are over.

Ready to move to faster hosting with a free, hands-off migration? Get started here.