How to Move a WordPress Site to a New Host Without Downtime

Short answer: build the site fully on the new host and test it there before you change DNS. The old site keeps serving visitors the entire time. The switch itself is then a DNS change with nothing left to go wrong.

Downtime happens when people change DNS first and then start moving things.

What you are actually moving

Four separate things, and forgetting one is how migrations go wrong:

1. Files — WordPress core, themes, plugins, uploads
2. The database — posts, pages, products, settings, users
3. Email — if the domain receives mail, this is the dangerous part
4. DNS — where the domain points

Most guides cover one and two and stop. Three is what loses a business a day of enquiries.

Before you touch anything: record your DNS

Do this while the old setup still works.

dig MX yourdomain.com +short        # mail routing
dig TXT yourdomain.com +short       # SPF and verification
dig A yourdomain.com +short         # the website

Save the output. If your domain receives email, moving hosts is how businesses lose it — that article covers the mail side properly, and it is worth reading before you continue.

Step 1: copy the site to the new host

Either a migration plugin (Duplicator, All-in-One WP Migration and others do this well) or by hand: archive wp-content, export the database with mysqldump, upload both, import, update wp-config.php.

A plugin is usually the right call. Do it manually when the site is too large for the plugin’s limits, or when it is already broken.

Step 2: test it properly before switching

This is the step that prevents downtime, and the one people skip.

Edit your computer’s hosts file so only you resolve the domain to the new server. Everyone else still gets the old one.

# /etc/hosts on macOS or Linux
# C:\Windows\System32\drivers\etc\hosts on Windows
203.0.113.45    yourdomain.com www.yourdomain.com

Now browse the real domain on the new server. Check:

• The homepage and several inner pages
• Images actually load — broken ones usually mean paths in the database
• Logging into /wp-admin
• Submitting a form
• On a store: a product, the cart, and a test order

Found a problem? Fix it with nobody watching. The live site is untouched.

Remove the hosts entry when you are done.

Step 3: lower the TTL a day ahead

TTL is how long the world caches your DNS. At 24 hours, your change takes a day to reach everyone. Drop it to 300 seconds the day before and the switch propagates in minutes.

Step 4: switch

Two ways, and they are not equal:

Change the A record only — point the domain’s A record at the new server’s IP and leave the nameservers where they are. The website moves. MX, SPF and DKIM are untouched, because you never handed over the zone. This is the lower-risk option and my default.

Change the nameservers — only if you want the new host managing DNS. Recreate every record, mail included, at the new host before switching.

Step 5: check within the hour

dig A yourdomain.com +short
dig MX yourdomain.com +short      # must be unchanged

Then send a test message to an address at the domain from an outside account. If mail still arrives, the risky part is behind you.

Also: install the SSL certificate on the new host, confirm https:// works without warnings, and submit the sitemap in Search Console if the structure changed.

Keep the old host running

Do not cancel it for at least a week. DNS propagation is uneven, and some visitors will still reach the old server for a day or two. Leave it running and anyone who lands there sees a working site rather than nothing.

It also means you can revert instantly if something only shows up under real traffic.

What usually goes wrong

Mixed content warnings — the database still holds http:// URLs. A search-replace fixes it, but use a tool that handles serialised data rather than raw SQL, or you will corrupt theme settings.

Missing images — usually file permissions or an uploads path that did not come across.

Email stops — covered above, and the reason to record MX first.

White screen — almost always a PHP version mismatch. Check what the old host ran and match it, then upgrade deliberately afterwards.

---

Rather not risk it? Tell me what you are moving — migrations with live email on the domain are routine work for me, and the plan above is the one I follow.