How to Move a WordPress Site to a New Host (Zero Downtime Method)

Most guides to WordPress migration treat the move as a single moment. You export the site, import it, change a setting, then cross your fingers while the internet catches up. For a brochure site nobody is watching at 11pm, that gamble usually pays off. For a site taking orders or bookings, it does not. There is a window in every careless migration where the domain is half pointing at the old host and half at the new one, and an order placed during that window lands on whichever copy the visitor reached. If that copy is the old host you are about to retire, the order is gone, and nobody finds out until the customer emails asking where their confirmation is.

So here is how to migrate WordPress hosts without downtime, stated plainly before the detail. You never let the switch be one risky moment. You lower your DNS TTL several days ahead so the eventual change clears in minutes. You build a complete copy on the new host while the old one stays fully live. You verify that copy on the real domain using a local hosts-file override, so you are the only person routed to the new server. You run a final database delta sync to capture anything that happened during the build. Then you flip DNS, keep both hosts online through propagation, and hold a one-line rollback ready. This article is that runbook, in order. It is the sequence our team follows on a WordPress site migration, and the reason it is dull every time is that the risk has been engineered out of it.

Step one, days early: lower your DNS TTL

Everything about a zero-downtime move depends on one number: the TTL on your domain's A record. TTL, time to live, tells every resolver on the internet how long it may cache the answer to "where does this domain live." A common default of 14400 seconds is four hours; 86400 is a full day. Whatever it is, that is roughly how long visitors keep hitting your old host after you change the record.

The catch is that lowering the TTL is itself a DNS change, and it propagates at the old, slow TTL. If your record is cached for a day, a reduction you make this afternoon is not fully respected until tomorrow afternoon. That is why this is step one and happens days early, not on migration day. Two or three days before you move, drop the A record (and AAAA, if you have IPv6) to 300 seconds, five minutes. By the time you flip, every resolver is honouring that short cache, and the switch clears in minutes rather than trailing for hours.

You can confirm what the world currently sees from the command line:

dig +nocmd example.com a +noall +answer

The number in that line, before the record type, is the live TTL a resolver near you reports. Watch it count down toward 300 and you know the pre-staging has landed. Leave the TTL low; you raise it back to a normal value only after the migration has proven stable, because that short TTL is also what makes your rollback fast.

Copy the site across while the old host stays live

With the TTL pre-staged, you build the new home. The principle is simple and absolute: the old host stays fully live and serving real traffic the entire time you work on the new one. Nothing you do in this step is visible to a visitor, because the domain still points where it always did.

How you copy the site matters less than people think. A migration plugin such as Duplicator or All-in-One WP Migration packages the files and database into an archive you restore on the new host. A manual move works just as well: files over SFTP or rsync, database via mysqldump. The method is not where migrations go wrong. Sequencing is.

What you must get right is the new host's configuration. The wp-config.php file on the new server needs the new database name, user, and password, and you should confirm the table prefix matches what you imported. If the old site had WP_HOME or WP_SITEURL constants hardcoded in wp-config.php, decide deliberately what they should say rather than letting a stale value override the database. And before you go further, make sure the new host has a valid HTTPS certificate ready for the domain. Many hosts can pre-issue one; a Let's Encrypt certificate using DNS validation can be issued before the domain points anywhere near the new server. You do not want to discover a certificate problem after the flip, in front of customers.

At the end of this step the new host holds a complete, working, but slightly stale copy of your site. The clock on that staleness starts now, which is what the delta sync is for.

Test the new host before the flip with a hosts-file override

This is the step that separates a real zero-downtime method from a hopeful one, and it is the step almost every competing guide skips. You need to fully test the new host, on the real domain, before a visitor is sent there. The obvious approach, visiting the new host's temporary URL or raw IP, does not give you a trustworthy test. WordPress has a home URL baked into its database, and when you browse it under a different address, links, redirects, canonical tags, and some assets misbehave. You end up debugging the test harness instead of the site.

The clean solution is to lie to your own computer and nobody else's. Every operating system has a hosts file it checks before asking a DNS server. By adding one line, you make your machine alone resolve the real domain to the new host's IP, while the rest of the internet still goes to the old host.

On Windows the file is at C:\Windows\System32\drivers\etc\hosts, edited as administrator. On macOS and Linux it is /etc/hosts, edited with sudo. The line you add uses the new host's IP and your real domain:

203.0.113.10    example.com www.example.com

Save it, flush your DNS cache, and load your site. You are now looking at the new host, on the genuine domain, exactly as a visitor will once you flip. Walk it properly: open the home page, click into a few templates, log into wp-admin, run a test checkout end to end, submit a contact form, check that images and stylesheets load over HTTPS without warnings. This is your dress rehearsal. Anything broken here is broken privately, with the old site still serving everyone else, and you fix it with no pressure. When you are finished, remove the line so your machine goes back to seeing what the world sees.

The delta sync: catching the orders placed mid-migration

Consider what has happened while you built and tested the new host. Hours have passed, maybe a day, and the old site was live the whole time. Customers placed orders, visitors left comments, people filled in forms. Every one of those writes went into the old host's database, and none exist on the copy you made earlier. The new host is now stale by exactly that delta, and a migration that ignores it silently destroys real business data.

So just before you flip DNS, you do a final delta sync to bring across everything that changed since the original copy. On a typical content or commerce site the files barely change, so the delta lives almost entirely in the database. Put the old site into a short, deliberate holding state, a brief maintenance notice or a pause on new orders, then export its database one more time and import that fresh copy onto the new host. Now the new host has the latest orders and comments, and because the old site is held, no new writes are created behind your back.

Choose the timing with care. Schedule it for your quietest hour, because the holding state is the only genuinely sensitive moment in the process, and you want it measured in minutes. For a low-traffic site the delta may be small enough to accept a tiny gap and skip the holding state entirely. For a busy store it is non-negotiable. The old site stays read-only from here until propagation completes, which guarantees the new host is the only place new data can land.

Search-replace the database the safe way (WP-CLI)

If your domain or path is changing as part of this move, the old URL is written into the database in thousands of places: post content, widget settings, plugin options, page-builder layouts. You cannot fix that with a plain SQL find-and-replace, and this is one of the most common ways a WordPress site migration corrupts itself. WordPress stores many settings as PHP serialised data, and a serialised string records its own byte length. Change the URL with a blunt query and that recorded length no longer matches the string, the data fails to unserialise, and widgets, theme options, or builder content quietly break.

WP-CLI understands serialised data and recalculates those lengths as it goes. Run it on the new host against the freshly synced database:

wp search-replace 'https://oldsite.com' 'https://newsite.io' \
  --all-tables --precise --recount --skip-columns=guid --dry-run

Run it first with --dry-run, which reports how many replacements it would make without touching anything. Sanity-check that number, then run the same command again without --dry-run. The --skip-columns=guid part matters: the guid column is a permanent identifier for each post, not a live link, and rewriting it confuses feed readers, so you leave it alone. If only your host changed and the domain stayed identical, this step may legitimately do nothing, but still check for hardcoded IP addresses or absolute paths a previous developer baked in.

Flip DNS and ride out propagation

Now, and only now, you change the DNS record. Point the A record, and the AAAA record if you have one, at the new host's IP address, and update the www CNAME if your setup uses one. Because you lowered the TTL days ago, resolvers begin picking up the new answer within minutes rather than trailing for hours.

Propagation, though, is not an instant global event, and treating it like one is the last way a migration goes wrong. Resolvers around the world expire their cached record at slightly different times. For a window after the flip, some visitors reach the new host and some still reach the old one. This is why both hosts must stay online and identical through this window, and why the old site stays in the read-only holding state. Every visitor is served a working site; the only writes happen on the new host. Watch the switch spread with a tool like dnschecker.org, which queries resolvers in many countries at once, or run dig and nslookup from a few networks. Once the new IP shows everywhere and the new host has handled live traffic cleanly, lift the holding state. Purge any object cache and any CDN now so visitors are not served stale assets pointing at the old origin, and leave the old host running for about a week as a safety net before you cancel it.

The rollback plan, and where WitsCode fits

A zero-downtime migration is finished only when you have also written the rollback, before the flip, while you are calm. The rollback is simple, and it is the entire reason the earlier steps were built the way they were. If something breaks after the flip, you revert the A record to the old host's IP. Because the TTL is still 300 seconds, that revert clears in minutes, and because you never touched the old host, it is a known-good site waiting to take traffic back.

What you decide in advance is the trigger. Checkout errors, server 500s, a white screen, assets failing to load: name the conditions that mean abort, so the call is made on evidence rather than panic. Keep the TTL low for at least forty-eight hours after the flip so rollback stays fast for as long as anything could surface. Only once the new host has been stable for a couple of days do you raise the TTL back to a normal value and, separately, confirm your email still works, because MX records are independent of web hosting and a migration that ignores them can break mail when the old host is retired.

That is the whole zero-downtime method. Lower the TTL early, copy across while the old host serves, verify privately with a hosts-file override, delta-sync the writes you would otherwise lose, search-replace safely with WP-CLI, flip, monitor propagation, hold a rollback ready. Nothing in it is exotic. It is dull on purpose.

WitsCode runs migrations this way as part of a custom build because the dullness is the product. Across a portfolio of more than 250 sites, we have learned the failures are never the export and the import; they are the certificate that was not pre-issued, the delta window sized for a quiet site and used on a busy one, the rollback improvised at midnight. When a host move is part of a build or re-platform we do for you, we pre-stage the TTL, pre-issue HTTPS, run the hosts-file dress rehearsal, time the delta sync to your real traffic, write the rollback triggers down, and monitor propagation so you do not have to. If you are changing WordPress host and the site cannot afford to lose an order or a minute, that rehearsed version of this runbook is the work we take off your desk.