Zero-downtime migration sounds like an advanced trick, but it is really just the standard careful migration done in the right order — and once you understand the one principle behind it, achieving it is straightforward. The whole secret is that you never send visitors to the new site until it is fully working there, and you never take the old site away until everyone has moved over. Get that order right, and there is simply no moment when anyone meets a broken or missing site.

This guide explains exactly how to migrate WordPress with no downtime: the single principle that makes it possible, why testing before cutover is the linchpin, how to preview the new site privately, the role of DNS TTL in shrinking the switch, keeping both sites alive during propagation, and the mistakes that reintroduce downtime. By the end you will be able to move your WordPress site with visitors none the wiser.

The one principle behind zero downtime

Every zero-downtime migration rests on a single idea: at no point should a visitor be routed to a site that is not working. There are two ways a migration creates downtime — sending visitors to the new site before it is ready, or removing the old site before all visitors have switched to the new one — and zero-downtime simply means avoiding both. That is the entire principle.

This works because a WordPress migration is a copy, not a move: while you build and test the new site, the old site keeps serving visitors uninterrupted, because your domain still points to it. The new site is being prepared invisibly, in parallel, and only becomes the visitors’ destination when you deliberately flip the switch — after it is confirmed working.

So zero downtime is not about speed or special tools; it is about order and overlap. You prepare and verify the new site fully while the old one carries on, then switch, then keep the old one alive until the switch has reached everyone. Understanding that this is the whole game makes zero-downtime migration feel not like a feat but like the natural result of doing the steps in the sensible order. Everything below is simply how to honour this principle in practice.

Test before cutover: the linchpin

The first half of the principle — never send visitors to a site that is not working — comes down to one discipline: fully test the migrated WordPress site on the new host before you point your domain at it. This is the linchpin of zero-downtime migration, because it guarantees that when you do flip the switch, the destination is already confirmed working, so no visitor ever meets a broken new site.

Because your domain still resolves to the old host during preparation, the new site is invisible to the public while you test it, which is exactly the safety you want. You copy the site over, reconnect it, and then click through everything privately — pages, images, styling, forms, logins, checkout — confirming it genuinely works on the new server. Any problem you find here is fixed with zero public impact, because the world is still being served the old site.

So testing before cutover is what makes the switch safe. The migrations that suffer downtime are almost always the ones where someone pointed the domain at the new site first and tested afterward — discovering the broken images or database error only once real visitors were hitting it. Reverse that order — test first, switch second — and you have eliminated the biggest single source of migration downtime.

How to preview the new site privately

To test before cutover, you need a way to view the new site specifically while your domain still points to the old host. There are a few standard techniques for this private preview:

• Hosts-file preview: edit your computer’s hosts file to map your domain to the new server’s IP address, so only your machine sees the new site while everyone else still sees the old — the cleanest way to test the real site on the new host.
• Temporary URL: many hosts provide a temporary address or preview domain that serves your new site directly, letting you check it without touching DNS.
• Staging environment: some hosts let you build and test in a staging area, then push to live.
• IP address (with caveats): visiting the raw server IP can work for simple sites but often misbehaves with WordPress’s domain-based links.

The hosts-file method is the gold standard for a true preview, because it shows you the site exactly as it will behave under your real domain — catching URL and link issues that a temporary URL might mask. Whichever method you use, the goal is the same: to see and thoroughly test the new site under realistic conditions before any of the public is routed to it. This private preview is what lets you honour the ‘test before cutover’ rule that zero downtime depends on.

Shrink the switch with DNS TTL

The second half of the principle involves DNS, and there is a preparation step that dramatically shrinks the risky window: lowering your DNS TTL a day or two before the migration. TTL (time to live) controls how long DNS records are cached around the internet, and it governs how quickly your eventual cutover reaches everyone. A high TTL means the switch propagates slowly; a low TTL means it propagates fast.

By lowering your TTL well before you cut over — to a short value like 300 seconds — you ensure that when you finally change your DNS to point at the new host, caches refresh quickly and visitors switch to the new site in minutes rather than hours. This compresses the propagation window during which old and new must both be maintained, making the whole cutover cleaner and faster.

So lowering TTL in advance is a small, high-leverage preparation for a smooth switch. It does not change the principle — you still keep both sites alive through propagation — but it shortens the period over which propagation happens, so the transition is quicker and the overlap briefer. Do this a day or two ahead (long enough for the old, higher TTL to expire from caches first), and your cutover becomes a fast, tidy flip rather than a drawn-out wait.

Keep both sites alive during propagation

The second way migrations create downtime is removing the old site too soon, and the fix is simple: keep the old host fully running until DNS has completely propagated and every visitor is reaching the new site. During the propagation window after cutover, some visitors’ DNS caches still point to the old host and some to the new — so both must be working, serving the same content, for there to be no downtime for anyone.

This is why you never cancel or take down the old host the moment you change DNS. For the hours (or, with a lowered TTL, minutes) that propagation takes, the old site is still receiving real visitors, and if it is gone, those people see a dead site — downtime, caused entirely by acting too early. Patience here is the whole safeguard.

So keep the old host alive and serving throughout propagation, and ideally keep both copies in sync (avoid making content changes on either during the switch, so visitors see consistent content regardless of which they hit). Only once you have confirmed, over a day or few, that everyone is reaching the new site do you retire the old host. Maintaining the overlap until propagation completes is the second pillar of zero downtime, complementing testing before cutover.

Mistakes that reintroduce downtime

Zero-downtime migration is straightforward, but a few mistakes undo it, and all of them are violations of the core principle. The biggest is cutting over before testing — pointing your domain at the new site and only then discovering it is broken, so visitors hit the failure directly. Always test privately first. The second is cancelling or breaking the old host during propagation, leaving visitors still routed there with nowhere to go.

Other downtime-causing mistakes include making DNS changes without having lowered the TTL first (so propagation drags on for many hours, prolonging the fragile window), letting a database-connection or URL problem slip through untested (so the new site is broken at the moment of switch), and changing content on the old site after starting the migration (so the two copies diverge and some visitors see stale or missing content).

So to keep downtime at zero, honour the principle strictly: test the new site fully before cutover, lower your TTL in advance for a fast switch, keep the old host alive and in sync until propagation completes, and only then retire it. Every downtime disaster is a shortcut around one of these — and every one is avoidable. Do the steps in the right order, with the overlap maintained, and your WordPress migration happens with your visitors completely unaware anything changed.

FAQs

How do I migrate WordPress with no downtime?

Follow one principle: never send visitors to the new site until it works there, and never remove the old site until everyone has moved. In practice: copy the site to the new host and test it privately (via a hosts-file preview) before touching DNS, lower your DNS TTL a day or two ahead for a fast switch, cut over, and keep the old host running until propagation completes. No visitor ever meets a broken site.

Why does testing before cutover prevent downtime?

Because it guarantees the new site is confirmed working before any visitor is routed to it. Your domain still points to the old host while you test privately, so the new site is invisible to the public and any problem is fixed with zero public impact. Migrations suffer downtime when people cut over first and test afterward, discovering breakage only once real visitors hit it.

How do I preview my new WordPress site before changing DNS?

The cleanest way is a hosts-file preview: edit your computer’s hosts file to map your domain to the new server’s IP, so only your machine sees the new site while everyone else still sees the old. Alternatively use the host’s temporary URL or a staging environment. The hosts-file method shows the site exactly as it’ll behave under your real domain, catching URL issues.

How does DNS TTL affect a zero-downtime migration?

TTL controls how long DNS records are cached, so it governs how fast your cutover reaches everyone. Lowering it to a short value (like 300 seconds) a day or two before migrating means that when you switch DNS, caches refresh in minutes rather than hours — shrinking the propagation window during which both old and new sites must be maintained, making the switch fast and clean.

Why keep the old host running after cutover?

Because DNS propagation isn’t instant — for hours after you change DNS (or minutes with a lowered TTL), some visitors’ caches still point to the old host. If it’s gone, those visitors hit a dead site — downtime caused by acting too early. Keeping the old host alive and serving until propagation completes means everyone reaches a working site throughout the switch.

What mistakes cause downtime during a WordPress migration?

Cutting over before testing (so visitors hit a broken new site), cancelling or breaking the old host during propagation (stranding visitors still routed there), not lowering TTL first (so propagation drags on), letting an untested database or URL error through, and changing content on the old site mid-migration (so copies diverge). All are violations of the test-first, keep-both-alive principle.

The bottom line

Migrating WordPress with no downtime is not an advanced trick but the natural result of one simple principle done in the right order: never route a visitor to a site that is not working. That breaks into two halves. The first is to fully test the migrated site on the new host before you point your domain at it — using a private preview like a hosts-file edit that shows the site exactly as it will behave under your real domain — so that when you flip the switch, the destination is already confirmed working and no visitor ever meets a broken new site. The second is to keep the old host alive and serving throughout DNS propagation, because for the window after cutover some visitors are still routed to the old server, and removing it early is what strands them on a dead site.

Two preparations make this cleaner still: lower your DNS TTL a day or two ahead so the eventual switch propagates in minutes rather than hours, shrinking the fragile overlap window, and keep both copies in sync during the switch so visitors see consistent content whichever they reach. Every migration that suffers downtime is a shortcut around this principle — cutting over untested, killing the old host too soon, or skipping the TTL preparation. Honour the order — test first, switch, keep both alive through propagation, then retire the old host — and your WordPress site moves to its new home with your visitors completely unaware anything happened. Zero downtime is simply careful sequencing, and it is entirely within your control.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Zero-downtime WordPress migration = one principle: never send visitors to the new site until it works there, and never remove the old site until everyone’s moved. Test the new site privately (hosts-file preview) before touching DNS, lower TTL a day or two ahead for a fast switch, cut over, and keep the old host alive and in sync through propagation. Every downtime disaster is a shortcut around this order.