How to move a WordPress site to a new host without downtime

Most WordPress moves that go badly go badly for the same reason: the domain gets pointed at the new host before anyone has confirmed the new host actually works. The site is then broken in public while you debug it, and every visitor during that window sees the failure.

The fix is boring. Change the order.

The order that works

1. Copy the site to the new host first. Files and database both. Nothing changes at your old host, which stays live and serving visitors throughout.
2. Open the copy on a preview URL. The new host gives you a temporary address that bypasses DNS entirely, so you can load the real site on the real new server while the public still sees the old one.
3. Fix what the copy surfaces. This is the whole point of the preview step. See below for what to look for.
4. Lower the DNS TTL, then wait. Drop it to 300 seconds at least a few hours before you plan to switch. This shrinks how long resolvers cache the old answer, so the actual switch propagates in minutes rather than hours.
5. Then point DNS at the new host. Because both copies are working, visitors land on one or the other and both serve the site. There is no window where nobody is served.
6. Leave the old host running for a few days. Until every resolver has caught up, some visitors are still reaching it.

Downtime in this sequence is not “short”. It is structurally absent, because at no point is the domain pointed at something that does not work.

What to actually check on the preview

Loading the homepage proves almost nothing. Homepages are the most cached, most static page on the site. Check the things that break quietly:

• Log in to wp-admin. Session and cookie problems show up here first.
• Submit a form. Contact forms fail silently when mail is not configured on the new host.
• Complete a test checkout if you sell anything. Payment callbacks are configured per site and often point at the old server.
• Load a few images and uploads. Broken media usually means the uploads directory did not come across, or file permissions changed.
• Check a page with a query string so you hit something the cache has not pre-warmed.
• Look at PHP version parity. A site running fine on PHP 7.4 can fatal on 8.3. If your new host offers a per-site PHP selector, match the old version first, then upgrade deliberately afterwards.

The database URL trap

WordPress stores absolute URLs inside the database, including inside serialized data. A naive find-and-replace across a SQL dump corrupts serialized arrays, because the stored string length no longer matches the actual string. The result is settings and widgets that vanish for no visible reason.

Use a tool that understands serialization, such as WP-CLI’s search-replace, rather than editing the dump by hand:

wp search-replace 'https://old-domain.com' 'https://new-domain.com' --skip-columns=guid

If the domain is not changing, only the host, you do not need this step at all.

Email is a separate move

Website hosting and email hosting are different things that happen to be configured in the same place. Moving the site does not move the mailboxes, and pointing the nameservers at a new host without recreating the MX, SPF, DKIM and DMARC records will stop mail reaching you.

Decide before the switch whether mail is moving too. If it is, the mailboxes need to be copied and the records recreated. If it is not, those records must be carried over to the new DNS exactly as they were.

Or let someone else do it

This is the work we do for free on every plan, in this order, with the preview step included: we copy the site across, you check it on a preview URL, and nothing changes on your old host until you tell us to switch. Most sites are ready to preview within 24 hours.