How to migrate a website with no downtime

"Zero downtime" sounds like it needs specialist tooling, load balancers, or a maintenance window at 3am. For the great majority of websites it needs none of that. It needs the steps done in an order where the site is always being served by something — first the old server, then the new one — and never by neither.

Why migrations normally go wrong

There are really only two ways to cause an outage during a move:

• Switching DNS before the new server is ready. Visitors start arriving at a site that is half-copied, missing a database connection, or not yet configured — and there is no way back except switching DNS again and waiting for it to spread a second time.
• Cancelling the old hosting too early. DNS does not update everywhere at once. Some visitors' resolvers hold onto the old answer for hours after you have made the change. If the old server is gone by then, those visitors get nothing.

Neither is a technical problem. Both are solved by sequencing, which is what the rest of this guide walks through.

Step 1 — Build the new site without touching the old one

Set up the destination hosting account, add the domain, create the database, and match the PHP version to what the old host runs. None of this affects the live site, because nothing has been pointed at it yet — DNS is still sending every visitor to the old server.

Step 2 — Copy files and database across

Upload the site files into the new web root, including hidden files like .htaccess, and import the database. For anything too large for phpMyAdmin's upload limit, the command line handles it without complaint:

mysql -u newuser -p newdatabase < backup.sql

Update the site's configuration file — wp-config.php, .env, configuration.php or settings.php depending on the platform — with the new database credentials. The old site is completely unaffected throughout; you are working on a private copy.

Step 3 — Lower the DNS TTL ahead of time

TTL (Time To Live) controls how long other people's DNS resolvers are allowed to cache your current records. If it is currently set to a high value such as 86400 seconds (24 hours), a change made today might not reach everyone until tomorrow. Drop it to 300 seconds at least a day before you plan to switch, and the eventual change will spread in minutes instead. See how DNS propagation actually works for the detail.

Step 4 — Prove the new server works before anyone else sees it

This is the step that makes zero downtime possible rather than hopeful. Add an entry to your own computer's hosts file mapping the domain to the new server's IP address — the value is shown in your new host's control panel or welcome email. Only your machine will use it; the rest of the world keeps loading the old site as normal.

Full instructions are in previewing a site with your hosts file. With it active, check every part of the site that matters: the home page, inner pages, any form that submits, the admin login, and — for a store — adding to basket and reaching checkout. A full pre-launch testing checklist covers this in more depth.

Step 5 — Switch DNS

Only once testing has passed cleanly. Update the nameservers or the relevant record — usually an A record — using the values your new host gives you, then remove the hosts file entry from step 4 so your own machine starts behaving like everyone else's.

Choosing a quiet period for your traffic, rather than your busiest hour, reduces the number of people who experience the brief overlap while DNS is spreading — see picking the right time to migrate.

Step 6 — Do not touch the old hosting for a week

Even with a low TTL, some resolvers cache longer than instructed, and mobile networks in particular can lag behind. For roughly a week, both servers effectively coexist: the new one for most visitors, the old one for the stragglers. This is expected and is exactly why cancelling the old account immediately is the single most common cause of a migration outage that otherwise did everything right.

What "zero downtime" cannot protect against

This method eliminates downtime caused by the migration process itself. It does not fix a site that was broken before you started, and it will not stop a busy store from losing orders placed in the exact window between the last database copy and the DNS switch — for that case, see migrating a WooCommerce store without losing orders, which covers taking a final, fresh export immediately before cutover.