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

Copying a WordPress site is rarely the hard part. Downtime usually comes from the moment of the switch: DNS points at a server that is not ready, the database connection fails, the certificate is missing, or a forced-HTTPS rule loops. Each of those can be found before the switch if you can open the site on the new server while the world still sees the old one.

The approach in this guide is simple: the old server keeps serving visitors until the new one has been checked page by page. DNS is changed only once, with a short TTL, so the change spreads within minutes instead of hours.

• Access to the old host (files and database, or a control panel), the new host, and the DNS provider for the domain. The DNS provider is wherever the nameservers point: often the registrar, sometimes Cloudflare or the old host.
• A full backup of the current site that you have downloaded, not one that only lives on the old server.
• The new server’s public IP address. If you are not sure which one it is, see Find your server IP.
• The PHP and database versions of the old site. Match them on the new server, or check that your theme and plugins support the newer versions.
• A list of the pages that matter: home, a post, a category, search, the contact form, the cart and checkout if you run WooCommerce, and wp-admin.

Check the current TTL of the domain’s A record now with the TTL checker. You need to know it for the timing in step 1.

1. 1

   Step 1: Lower the TTL a day ahead

   In your DNS panel, set the TTL of the A record (and AAAA, if any) to 300 seconds, still pointing at the old server. Wait at least as long as the old TTL before you switch. See Lower your TTL before a migration.

2. 2

   Step 2: Back up the old site

   Take a full backup of files and database and download it. This is your rollback plan if anything goes wrong.

3. 3

   Step 3: Copy files and database to the new host

   Use a migration plugin, the host’s transfer tool, or a manual copy with WP-CLI. Keep home and siteurl set to the production domain.

4. 4

   Step 4: Open the site on the new server

   Create a preview link with your domain and the new IP. Click through the key pages, sign in to wp-admin and upload an image to confirm file permissions.

5. 5

   Step 5: Run a QA crawl

   Run a QA report on the preview to catch broken pages, missing uploads, redirect loops, mixed content and hard-coded URLs. Fix and run it again.

6. 6

   Step 6: Freeze content and do a final sync

   Stop new orders, comments and posts on the old site for a few minutes, then copy the database once more so nothing written since the first copy is lost.

7. 7

   Step 7: Switch DNS

   Point the A record of the domain and of www at the new IP. Update or remove any old AAAA record so IPv6 visitors do not keep reaching the old host.

8. 8

   Step 8: Watch propagation and keep the old host

   Track the change with the DNS propagation checker. Keep the old hosting for a few more days, until its access logs show no real visitors.

Both work. Choose by site size and by how much access you have on each side.

For a manual copy, the commands look like this. Run the export on the old server and the import on the new one:

# Old server: export the database and pack the files
wp db export site.sql
tar -czf site-files.tar.gz --exclude=wp-content/cache .

# New server: unpack, import, check the site URL
tar -xzf site-files.tar.gz
wp db import site.sql
wp option get home
wp option get siteurl

If the new host gives you different database credentials, update DB_NAME, DB_USER, DB_PASSWORD and DB_HOST in wp-config.php before you test.

WordPress stores its own address in the database (home and siteurl) and builds most links from it. A common mistake is changing them to the server IP or a temporary hostname to test the new server. That works until the switch, and then every hard-coded link points at the temporary address.

Leave both values set to the production domain, such as https://example.com, and test the site under that name. A DNSPeek preview link does exactly that: it connects to the new IP and asks for your real domain, so WordPress behaves as if DNS had already moved. Links, redirects and login cookies are rewritten to the preview address, so you can sign in to wp-admin and click through the site. More in the docs: Preview a WordPress site on a new host.

Many hosts issue a free certificate only after the domain points at them, because the domain check runs over HTTP on the domain itself. Before the switch, the new server may present a self-signed or default certificate. That is normal and not a reason to delay.

In a DNSPeek preview, set the link’s SSL mode to Skip verification while the certificate is missing. Otherwise a forced-HTTPS plugin or rule can redirect in a loop when the preview falls back to HTTP. After the switch, confirm the real certificate with the SSL checker. Details: SSL modes.

On a shop or a site with logins, new data keeps arriving on the old server until the switch. Orders, comments and new accounts created after your copy would be lost. Plan a short content freeze: announce a maintenance window for new orders, or put the old site in maintenance mode only for the minutes of the final database sync. Pages keep loading for readers either way.

Payment gateways and sign-in providers only know your real domain, so they send customers back to whichever server public DNS points at. Test checkout with a test gateway on the preview, then place one real or sandbox order right after the switch. See what previews can’t do.