Moving a WordPress site to a new host sounds scary because most people picture the same thing: the site goes dark, visitors hit errors, and you're frantically refreshing while sales slip away. It doesn't have to go like that. With the right sequence, you can move a site to a new server and visitors never notice a thing, because the new site is already live and tested before anyone gets pointed at it. This guide walks through exactly how zero-downtime migration works, the DNS trick that makes it possible, and the mistakes that turn a clean move into a stressful one.
Why does downtime happen during migration?
Downtime happens when people switch the domain to the new server before the new site is fully working, or before lowering the DNS TTL so the switch propagates quickly. The fix is to keep the old site live, test the copy thoroughly, and only flip DNS once the new site is confirmed good.
The whole problem comes from doing things in the wrong order. If you point your domain at an empty or half-configured server, visitors land on errors. And if your DNS TTL is set high, that broken state can linger for hours while the change spreads across the internet. Get the order right and there's simply no window where anyone hits a broken site. You're never exposing visitors to a half-built server, so they won't see an error at all.
How do you migrate WordPress without downtime?
Lower your DNS TTL a day ahead, copy the site to the new host while the old one stays live, test the copy on a temporary URL, do a final sync of any new content or orders, switch the DNS, then verify and keep the old host as a fallback for a few days. The old site serves visitors until the moment the tested new one takes over.
- Lower your DNS TTL. About a day before, drop the TTL to a few minutes so the eventual switch propagates fast instead of taking up to 48 hours.
- Copy the site to the new host. Move all files and the database while the old site keeps serving visitors normally.
- Test on a temporary URL. Open the copy on a staging or hosts-file URL and check every key page, form and the checkout.
- Do a final sync. Re-copy anything added since the first copy, such as new posts or orders, so nothing is lost in the gap.
- Switch the DNS. Point the domain at the new server. Thanks to the low TTL, visitors move across within minutes.
- Verify and keep the old host briefly. Confirm the live site, check redirects and SSL, and leave the old host running for a few days as a safety net.
Our WordPress migration service handles the whole move, tested before the switch, so your site never goes dark and your rankings stay put.
What is the DNS TTL trick for zero-downtime migration?
TTL, or time to live, controls how long DNS records stay cached before refreshing. Lowering it to a few minutes a day before you migrate means that when you finally switch to the new server, the change spreads in minutes rather than up to 48 hours, so visitors cross over almost instantly with no stale-record errors.
This is the single most important detail people skip. By default, DNS records might be cached for a day or two, which means a high TTL can leave some visitors hitting the old server long after you've switched. Drop the TTL ahead of time, wait for the old high value to expire, and the actual cutover becomes near-instant. It's a small change that turns "fingers crossed for two days" into "done in five minutes".
Why must you test before switching DNS?
Because the temporary URL is your only chance to catch problems while the old site still protects your visitors. Test every key page, all forms, the checkout and any logins on the new host first. If something's broken, you fix it with no one affected, then switch DNS only once the copy is confirmed perfect.
Testing on a staging or hosts-file URL lets you browse the new site as if it were live, without changing anything for real visitors. Click through your important pages, submit a contact form, run a test order if it's a store, and check that images, fonts and SSL all load. This step is where downtime-free migrations are actually won. Skip it and you're testing in production, which is how things go dark.
What migration mistakes cause downtime or lost rankings?
The big ones are switching DNS before testing, leaving the TTL high, dropping or changing URLs so redirects break, leaving the staging copy indexable by Google, and forgetting to migrate the database or SSL. Each one either causes an outage or quietly damages your search rankings during the move.
A migration can be downtime-free and still hurt you if it's breaking links along the way. Keep the same URL structure, carry over your redirects, and don't redesign content mid-move, so Google sees the same site on a new server. Block the staging copy from being indexed so you don't end up with duplicate pages competing in search. For a smooth move that protects rankings, our migration service follows a full checklist that covers every one of these.
Should you migrate WordPress yourself or hire a pro?
A simple site is doable yourself if you're comfortable with hosting, DNS and databases. The risk lives in the details, a missed redirect or a stale TTL can cost hours of downtime. For WooCommerce or business-critical sites, professional migration removes that risk and guarantees no downtime, so you don't gamble your traffic on a single switch.
There's no shame in doing it yourself on a low-stakes site, that's how you'll learn. You don't need to be an expert, you just can't afford a misstep on a site that earns. But if your site earns money, the cost of a botched migration, lost orders, dropped rankings, a day offline, dwarfs the cost of having it done right. We migrate sites with zero downtime and a tested copy before the switch, and we'll keep your old host live as a fallback. If a move is part of a bigger refresh, pair it with our care plans to keep the new site fast and secure from day one.
Key takeaways
- Keep the old site live and tested until the moment the new one takes over.
- Lower the DNS TTL a day ahead so the switch propagates in minutes, not days.
- Test everything on a temporary URL before you flip DNS, never in production.
- Keep URLs and redirects intact, and block the staging copy from indexing.