How to Migrate a Website to a New Host With Zero Downtime

Last updated: August 2026

Before you start: the pre-flight list

Gather access to both hosts, your domain registrar and your DNS provider (often, but not always, the same as the registrar). Take a fresh, complete backup of files and database and download it off-server. Note your current PHP version and any special server settings. Finally, freeze content: no new posts, orders or form entries mid-migration, or schedule the move for your quietest hours and plan a re-sync.

Step 1: Lower your DNS TTL (do this first, a day early)

TTL tells the internet how long to cache your DNS records. If it is set to 24 hours, some visitors will keep hitting your old server for a full day after you switch. Log into your DNS, find the A record for your domain, and drop the TTL to 300 seconds. Do this at least 24 hours before the switch so the old, long TTL expires everywhere.

Step 2: Copy everything to the new host

Move all site files and export the full database, then import both on the new server. On WordPress, plugins like Duplicator, All-in-One WP Migration or your new host's free migration service handle the packaging. On a managed host, this step is usually done for you: send access, they migrate. Either way, the site now exists in two places, and the world still sees only the old one.

Step 3: Test on the new server BEFORE switching

This is the step that makes the migration zero-downtime, and the one people skip. Two ways to preview the new copy: use the temporary URL your new host provides, or edit your computer's hosts file to point your domain at the new server's IP just for you. Then test like a customer: homepage, key pages, images, contact form submission, login, and on a store, a full test checkout. Fix everything you find. The public site remains untouched while you do.

Step 4: Re-sync if the site changed

If orders, comments or posts arrived on the old server while you tested, export and re-import the database once more just before the switch. Brochure sites can usually skip this; stores cannot.

Step 5: Switch DNS

Update the A record (and www CNAME if separate) to the new server's IP. With the low TTL from step 1, the world moves over within minutes. Keep the old hosting running for at least a week as a safety net; do not cancel it the same day, however tempting the refund.

Step 6: The post-switch checklist

Reissue or confirm SSL on the new server immediately, because a certificate mismatch is the most common post-migration surprise. Then verify: forms deliver email (SPF records may need the new server added), scheduled tasks run, the site appears correctly for someone on mobile data, and Search Console shows no crawl spikes. After a clean week, back up the new server, cancel the old plan, and raise the TTL back to something normal like 3600.

Where migrations actually go wrong

The failure patterns are consistent: DNS switched before testing (the classic), email breaking because mail was hosted on the old server and nobody noticed, hardcoded URLs pointing at the temporary domain, SSL not provisioned before the switch, and PHP version differences surfacing as errors that were invisible on the old host. Every one of these is prevented by the order of operations above, which is precisely why the order matters more than the tools.

The zero-effort version

Any host worth moving to migrates you free: you hand over access, they do steps 2 through 6, you approve the tested copy before DNS moves. Our managed VPS hosting includes exactly this, free migration with zero downtime, and because the same team then runs both the server and the website maintenance, "was it the host or the site" stops being a question anyone has to ask.

FAQ

How long does a website migration take? Active work: 2 to 5 hours for a typical site. Calendar time: two days, because the TTL change needs a day of lead time. Large stores with big databases take longer.

Will my Google rankings drop after moving hosts? Not from the move itself if the domain and URLs stay identical. Rankings react to downtime and errors, which a tested, zero-downtime migration avoids.

Can I migrate during business hours? With this method, yes, because the switch moment is seamless. Stores should still pick quiet hours to simplify the re-sync step.

My developer says we need downtime. Are they wrong? For a standard site, planned downtime usually signals a copy-then-pray migration rather than a test-then-switch one. Special architectures can be exceptions; ask what specifically prevents parallel testing.