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

Moving a WordPress site to a new host has a fearsome reputation it no longer deserves. The whole trick is a change of mindset: you are not “moving” the site, you are building a complete copy on the new host while the original keeps serving visitors, proving the copy works, and then pointing the domain at it. Do it in that order and there is no gap in which the site is down — the worst case is a brief window where some visitors see the old site and some see the new one.

This guide covers the manual method, because understanding it means no migration can ever scare you again. It applies to any WordPress setup; if you're moving to a managed platform like our managed CMS hosting, the host's team typically handles the copy-and-test steps for you (many hosts, including us, migrate incoming sites free), but you should still read the DNS and TTL sections — those are yours either way.

What actually makes up a WordPress site?

Exactly two things, and knowing this demystifies everything:

• The files — WordPress core, your themes and plugins, and your uploads, all under the site root. The irreplaceable part is wp-content/; core files can always be re-downloaded.
• The database — every post, page, comment, setting, and user lives in MySQL/MariaDB. The database connection details live in wp-config.php in the site root.

Copy both, connect them together on the new server, and you have the same site. Everything below is just doing that carefully.

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

TTL (time to live) tells the world's DNS resolvers how long to cache your domain's records. If your TTL is 24 hours, some visitors will keep being sent to the old server for up to a day after you switch — the single biggest cause of messy migrations. So, 24–48 hours before you plan to switch, go to wherever your DNS is managed (registrar or DNS provider) and lower the TTL on your domain's A/AAAA (or CNAME) records to 300 seconds. By switch time, the old long-cached records will have expired everywhere and the world will re-check your DNS every five minutes — so your eventual switchover propagates in minutes, not hours. Raise it back to normal once the migration is confirmed stable.

Step 1: Back up the files and database

Take the copy from the live site. For the files, download the entire site root over SFTP, or (much faster) SSH in and create an archive: tar -czf site.tar.gz . in the site root. For the database, either export from phpMyAdmin (Export → SQL), or from the command line: mysqldump -u USER -p DBNAME > db.sql — or, if WP-CLI is available, wp db export. If the site takes new orders or comments constantly, plan to take a fresh database export just before the final DNS switch so nothing is lost in between.

Step 2: Restore everything on the new host

1. Upload and extract the files into the new host's site root for your domain.
2. Create a database on the new host — a fresh database name, user, and password from its control panel.
3. Import your SQL dump into it via phpMyAdmin or mysql -u USER -p DBNAME < db.sql (or wp db import db.sql).
4. Update wp-config.php on the new server with the new credentials: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST (usually localhost, but some hosts use a separate database hostname — check their docs). Leave $table_prefix exactly as it was on the old site; it must match the imported tables.

Step 3: Test the new site before touching DNS

This is the step that makes the migration zero-downtime: you are going to visit the new server as if DNS had already switched, while the rest of the world still sees the old one. Edit your computer's hosts file and add a line mapping your domain to the new server's IP address:

• Windows: C:\Windows\System32\drivers\etc\hosts (edit as administrator)
• macOS/Linux: /etc/hosts (with sudo)
• Add: 203.0.113.10 example.co.uk www.example.co.uk (using your new server's real IP)

Flush your DNS cache, open the site, and test properly: log in to wp-admin, click through key pages, submit a form, add something to the basket if it's a shop, check images load (missing images usually mean an incomplete wp-content/uploads copy). Because you're browsing by your real domain name, WordPress behaves exactly as it will after the switch — no URL rewriting involved. Remove the hosts-file line when you're done testing.

What about changing URLs and serialised data?

If you are keeping the same domain — the usual case when changing hosts — skip this section entirely; no URLs change and nothing needs rewriting. But if the domain is changing too, there is a famous trap. WordPress stores some settings (widgets, theme options, some plugin data) as PHP serialised strings, which embed the byte-length of every value — s:22:"https://old-domain.com". A naive find-and-replace in the SQL file changes the URL but not the length, corrupting the data; the classic symptom is widgets and theme settings mysteriously vanishing after a move. The fix is to use a serialisation-aware tool:

• WP-CLI (best): wp search-replace 'https://old.com' 'https://new.com' --all-tables — it deserialises, replaces, and recalculates lengths. Add --dry-run first to preview.
• Better Search Replace (plugin) or interconnect/it's Search Replace DB script — both serialisation-safe alternatives if you don't have shell access.

Step 4: Switch DNS and monitor

With the new site tested, update your domain's A/AAAA records to the new server's IP (or update the CNAME if your host works that way). Thanks to the lowered TTL, traffic moves over within minutes. Keep the old hosting account running for a few days as a safety net — do not cancel it on migration day. During the brief overlap, check the new server's access logs to confirm traffic is arriving, and if the site takes orders or comments, either put the old site into maintenance mode at switch time or re-export anything created in the overlap window.

Step 5: The post-migration checklist

When should you not do this yourself?

Manual migration is genuinely fine for most sites, but hand it over if the site is a busy WooCommerce store (order data written every minute raises the stakes of the overlap window), if it's a multisite network (extra config and domain mapping), or if you have no backups and a fragile old host — in which case the first job is a backup, not a migration. Most destination hosts will do the move for you on request, and if a host charges you to bring a site in, read our guide to UK hosting pricing patterns before you commit to them at all.

The bottom line

Zero-downtime migration is a sequence, not a skill: lower the TTL a day early, copy files and database while the old site stays live, wire up wp-config.php, test through your hosts file, use a serialisation-aware search-replace only if the domain changes, then flip DNS and keep the old account for a few days. Follow the order and the scariest thing about moving hosts is deciding which hosting tier to move to.