How to Migrate a Website Without Downtime

The phrase "zero downtime migration" makes it sound like a special technique. It is not. It is mostly about sequencing: you build the new site somewhere visitors cannot see it, you test it thoroughly, and only then do you point the domain at it. Almost every migration that causes an outage skipped one of those steps to save time.

Why migrations usually go wrong

The common mistake is treating migration as a single event: copy the files, switch the domain, done. That approach works fine for a static portfolio site with no database. It falls apart for anything with a database, user accounts, a shopping cart or scheduled content, because there is no way to guarantee the copy is complete and correct until someone actually checks it, and checking takes time you do not have once the domain is already pointed at the new server.

The fix is to separate the copy from the cutover. The copy can take hours or even days, because nobody is looking at it yet. The cutover should take minutes, because everything has already been checked before you touch DNS.

Step 1: build the new site on a temporary URL

Set up hosting on the new server and get the site running there before doing anything to the live domain. Most hosts let you preview a newly uploaded site through a temporary URL or by editing your own computer's hosts file to point the domain at the new server just for you, without changing anything for the public.

This is also the point to copy the database, not just the files. For a WordPress site, that means exporting the database from the old server, importing it on the new one, and updating the site URL references inside it, since WordPress stores its own domain in several database fields.

Step 2: test everything before anyone else sees it

This is the step people skip under time pressure, and it is the one that actually prevents downtime. Load every important page. Submit the contact form. Log in as a test user. If there is a store, add something to the cart and walk through checkout in test mode. Check that scheduled tasks like backups or cache warming are configured on the new server, not still pointing at the old one.

• Homepage, key landing pages and any page with a form
• Login and account pages if the site has user accounts
• Search functionality and any custom database queries
• Checkout flow for a store, including tax and shipping calculation
• Email sending, such as order confirmations or contact form notifications
• Redirects for any URLs that changed as part of the move

Step 3: lower the DNS TTL in advance

DNS records include a time-to-live value that tells other servers how long to cache the answer before checking again. If that value is set to, say, 24 hours, then some visitors will keep reaching the old server for up to a day after you change the record, even though everything else is ready. Lowering the TTL to a few minutes a day or two before the actual cutover means the change propagates much faster when you make it.

Step 4: handle the database gap

Here is the part that trips up a lot of migrations involving a database: whatever gets written to the old site's database between your last copy and the actual cutover will not exist on the new server unless you account for it. For a low-traffic brochure site this rarely matters. For a store taking orders, a membership site, or anything where visitors submit data, it matters a lot.

The safest approach is to do a final, fresh database copy right before cutover, after briefly pausing new submissions if the platform allows it, or to schedule the switch during the site's quietest hours and accept a short window where a handful of late submissions might need to be manually reconciled. Either way, decide on this in advance rather than discovering the gap afterward.

Step 5: switch DNS and watch closely

With the new site tested and the TTL already lowered, update the domain's A record or nameservers to point at the new host. Because of the shorter TTL, most visitors should be redirected within minutes to a couple of hours rather than a full day.

Keep the old server running and untouched during this window. If something unexpected shows up on the new site, you can point DNS back at the old server while you fix it, and nothing has been lost. This fallback is the real safety net in a zero-downtime migration, more than any specific tool.

Step 6: confirm and clean up

Once traffic has clearly moved to the new server, check server logs or analytics to confirm real visitors are landing there, verify SSL is working correctly on the new domain, and test the site again from a network you have not used before, such as a mobile connection, to rule out anything cached locally. Only after this confirmation should you cancel or downgrade the old hosting account.

• Confirm the SSL certificate is valid on the new server
• Check that email routing (MX records) was not accidentally changed if using a nameserver switch
• Watch error logs for the first 24-48 hours
• Keep the old hosting active for at least a few days as a rollback option
• Update any hardcoded links in ads, business listings or documentation

Where migration assistance actually helps

This process is entirely doable by a small business owner for a simple site, but it gets more involved with a large database, a busy store or custom server configuration. WordPress optimized hosting plans that include free migration exist mainly for this reason: someone experienced does the file transfer, database export and URL updates, and checks the result before the domain moves, which removes most of the risk described above without you having to learn DNS propagation timing under pressure.

Whether you do it yourself or have it handled for you, the underlying discipline is the same: build first, test thoroughly, then switch. Downtime almost always comes from collapsing those three steps into one.