Migrating WordPress Without Downtime: A Developer's Step-by-Step Playbook

Most WordPress migrations that go wrong don't fail because the developer picked the wrong host. They fail because someone changed a DNS record before verifying the new server actually worked. That mistake takes down client sites for hours — orders lost, forms silently failing, a support inbox filling up before anyone notices.

You can migrate WordPress without downtime. The method is a "test-before-you-switch" protocol: clone the site to the new server, validate every piece of it using a hosts file override so only you can see it, and only then flip DNS — with a delta database sync right before cutover so nothing created during the move gets lost. None of this requires exotic tooling. It requires sequencing, and WP-CLI.

Gartner's oft-cited research puts the failure rate of data migrations at 83%, and separate industry analysis found that 23% of organizations lose some data during a migration event. Neither number is WordPress-specific, but they explain why "just copy the files over" is not a real plan. Below is a five-stage sequence rather than thirteen disconnected steps, because a runbook you can actually follow beats one that just looks thorough.

Key Takeaways

• Reducing DNS TTL to 300 seconds (5 minutes) 24–48 hours before cutover is what makes near-instant global propagation possible — skip it and you're waiting on cached records for up to a day.
• A hosts file override lets you fully test the new server — forms, checkout, layout — before any public DNS record changes, so the public never sees a broken build.
• WordPress serialized data breaks under plain SQL find-and-replace; wp search-replace is the only safe way to change domains or paths in the database.
• Active WooCommerce stores and forums need a "delta" database sync immediately before DNS cutover, or you lose every order and comment made during the migration window.
• Gartner reports 83% of data migrations run into some form of failure, and separate research puts data-loss incidence at 23% — both are why testing on the new server before cutover isn't optional.
• ITIC's 2024 benchmark puts enterprise downtime at $300,000+ per hour, which is the real cost this entire playbook exists to avoid.

What "Zero-Downtime Migration" Actually Means

A zero-downtime WordPress migration is a transfer process where the live site keeps serving visitors from the old server the entire time you build, test, and validate the new one. Nothing goes dark, because the DNS record never points anywhere until the new environment has already proven it works.

That's a different discipline than "backup, restore, hope." The old way treats DNS cutover as the first test of whether the migration worked. This way treats it as the last step, after the new server has already survived a full walkthrough under a fake domain resolution. The gap between those two approaches is where most of that 83% failure rate lives.

Phase 1: Pre-Migration Audit and DNS Prep

Before you copy a single file, audit the site you're about to move. Skipping this is how developers end up debugging a "broken" migration that was actually just an environment mismatch.

Check PHP version compatibility. Confirm the new host runs the same major PHP version as your current site (8.1, 8.2, or newer). Deploying WordPress core or an older plugin onto a PHP version it wasn't built for throws fatal errors, and you'll be debugging those instead of doing the actual migration.

Audit and prune the database. Delete expired transients, spam comments, and old post revisions before you export anything. A bloated database doesn't just slow the transfer — on a shared host, a multi-gigabyte SQL export is exactly the kind of job that hits a script timeout halfway through.

Find hardcoded paths. Grep your theme and plugin files for hardcoded IPs or absolute file paths. They're rare in well-built themes, common in inherited client sites, and they will break silently on the new server rather than throwing an obvious error.

Drop your DNS TTL now. This is the step people skip and regret. Log into your DNS provider — Cloudflare, Route 53, whoever manages the domain — and lower the TTL on your A record to 300 seconds. Do this 24 to 48 hours before you touch anything else. TTL controls how long resolvers cache your DNS answer; a typical default of 86400 seconds (24 hours) means a change you make on cutover day could take a full day to reach every visitor. At 300 seconds, that same change is effectively global within minutes.

Phase 2: Moving the Database and Files

With the audit done, it's time to actually duplicate the site. For a small brochure site, a plugin like Duplicator is fine. For anything with real traffic or a large media library, command-line tools are faster, more reliable, and don't choke on execution time limits the way web-based export tools do.

Export the database with WP-CLI, not phpMyAdmin. phpMyAdmin's browser-based export is notorious for timing out on anything beyond a small database, and it doesn't recover cleanly when it does. WP-CLI runs from the command line with no execution time cap:

wp db export backup.sql --allow-root

Compress and transfer the files. Archive your full site directory — not just /wp-content/, since you'll want theme and core files too for a clean reference — and pull it down over SFTP:

tar -czf site-files.tar.gz public_html/

Upload, extract, and import on the new server. Push the archive to the new host's document root, extract it, create a fresh MySQL database, and import your export:

wp db import backup.sql --allow-root

Update wp-config.php. Open the file on the new server and set DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to match the credentials for the database you just created. This step alone accounts for a surprising share of "the migration is broken" support tickets — it's almost always a typo'd credential, not a corrupted transfer.

Multisite Adds Its Own Checklist

If you're moving a WordPress Multisite network, the standard flow above isn't sufficient on its own. Three things need separate verification:

• Domain mapping. Confirm every subdomain or subdirectory site in the network is correctly mapped in the new host's dashboard before you test anything.
• Wildcard SSL. The new host needs a wildcard certificate provisioned and active, or every subsite except the primary domain will throw certificate warnings.
• Multisite constants in wp-config.php. Double-check MULTISITE, SUBDOMAIN_INSTALL, and DOMAIN_CURRENT_SITE match the new server's paths, and cross-reference the wp_blogs and wp_site tables against your actual network structure. A mismatch here doesn't throw a clean error — it just silently serves the wrong subsite content.

Large Media Libraries: Use Rsync, Not SFTP

Once a site's uploads folder crosses into tens of gigabytes, ZIP archiving and SFTP downloads start failing on execution time limits before they finish. The fix is rsync over SSH, which streams server-to-server, compresses in transit, and — critically — resumes automatically if the connection drops instead of starting over:

rsync -avz --progress -e ssh user@oldserver:/var/www/public/wp-content/uploads/ /var/www/newserver/wp-content/uploads/

This moves files directly between servers without routing them through your laptop's upload bandwidth, and it preserves timestamps and ownership. For a media-heavy site, this single command change is often the difference between a migration that finishes overnight and one that's still running the next afternoon.

Phase 3: Fixing URLs, Cron, and Redirects on the New Server

The files and database exist on the new server now. Before you go anywhere near DNS, there's configuration work that determines whether the site actually functions once it's live.

Never run a plain SQL find-and-replace on a domain change. WordPress serializes PHP arrays into strings that include an explicit character count — s:19:"http://old-site.com" isn't just text, the 19 is load-bearing. Swap http://old-site.com for https://new-site.com with a raw MySQL query and every string length shifts, but the serialized count doesn't update. The result is corrupted theme options, broken widgets, and plugin settings that silently reset — a genuinely common root cause behind "the migration broke everything" support tickets.

WP-CLI's search-replace command exists specifically to avoid this — it deserializes the data, performs the replacement, recalculates the lengths, and reserializes it correctly:

wp search-replace "http://old-site.com" "https://new-site.com" --skip-columns=guid --allow-root

The --skip-columns=guid flag matters more than it looks like it should: it leaves RSS feed GUIDs untouched, which stops every subscriber's feed reader from re-flagging your entire archive as "new" posts the moment the migration goes live. WP-CLI also supports --export=<file> if you'd rather write the transformed output to a fresh SQL file than apply it directly — useful when you want a reviewable diff before committing the change.

Move wp-cron.php off the page-load trigger. By default, WordPress checks for scheduled tasks — post publishing, security scans, email queues — on every single page view. That's tolerable on a low-traffic site and wasteful on a busy one. Migrations are a good moment to switch to a real system cron:

• Disable the default behavior by adding define('DISABLE_WP_CRON', true); to wp-config.php.
• SSH into the new server, run crontab -e, and add a line that fires the cron file on a fixed schedule instead: */10 * * * * wget -q -O - https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

This guarantees scheduled tasks actually run at a predictable interval instead of depending on the right visitor loading the right page at the right moment.

Push redirect rules into Nginx, out of plugins. A redirection plugin means every request that matches a rule queries the database before Nginx or PHP even starts building the page. For a site with a meaningful redirect map, that's needless overhead on every hit. Move the rules into the Nginx virtual host config instead:

rewrite ^/old-slug/$ /new-slug/ permanent;

Nginx handles the redirect at the web server level, before a PHP worker ever spins up. It's a small change that keeps the migrated site noticeably snappier than the one you're replacing.

Verify SMTP before you forget about it. Contact forms and order confirmation emails frequently stop working after a host switch, because a lot of managed cloud hosts block PHP's default mail() function outright. Install a dedicated SMTP plugin (WP Mail SMTP is the common choice) and route outgoing mail through a transactional provider — SendGrid, Mailgun, Postmark. While you're in DNS, update your SPF record to authorize the new sender (v=spf1 include:mailgun.org ~all) and confirm DKIM and DMARC are configured. Skip this and you won't find out it's broken until a customer complains their order confirmation never arrived.

Phase 4: Testing With a Hosts File Override

This is the step that actually makes the whole playbook "zero-downtime" rather than "hopefully-zero-downtime." At this point your files and database are live on the new server, but the public domain still resolves to the old one. A hosts file override lets you — and only you — see the new server when you type the domain into a browser, without touching public DNS at all.

Your operating system checks a local hosts file before it ever asks a DNS resolver anything. Add an entry there mapping your domain straight to the new server's IP, and your machine skips DNS entirely for that domain.

On macOS or Linux, open a terminal and edit the file with root privileges:

Open a terminal and edit the hosts file with elevated permissions using your preferred command-line text editor.

On Windows, run Notepad as Administrator and open the hosts file located at C:\Windows\System32\drivers\etc\hosts.

Add a line at the bottom of the file with the new server's IP address followed by your domain name and www subdomain, then save.

Flush your DNS cache, clear your browser cache, and load the site. You're now looking at the new server while the rest of the world still sees the old one. Use this window to actually test — not just glance at the homepage. Click through the dashboard, run a payment gateway in sandbox mode, check that images resolve, submit a contact form, and hunt for layout breaks on a couple of your highest-traffic templates. When you're satisfied, remove the entry from the hosts file so you drop back to normal DNS resolution before the next step.

Phase 5: The Delta Sync, DNS Cutover, and What Comes After

If the site is static — no orders, no comments, no user-generated content changing in real time — you can go straight to DNS once hosts file testing passes. Almost nothing is actually that static, though.

Catching What Changed While You Were Testing

If you're migrating an active WooCommerce store or a community forum, real transactions and comments kept happening on the old server the entire time you were auditing, transferring, and testing. Cut over without accounting for that window and you lose every order and post created during it — not a hypothetical, a routine failure mode on active sites.

The fix is a delta sync executed immediately before DNS cutover:

• Put the old site into maintenance mode to freeze new writes to its database.
• Export the database from the old server again — this second export captures everything created since your first transfer.
• Import that fresh export into the new server, overwriting its database so it now reflects every order and comment made up to the maintenance-mode freeze.

This closes the exact window where the migration failure statistics above tend to originate — not the bulk transfer, but the gap between "I copied the data" and "I made it live."

Flipping DNS

Log into your DNS registrar and update the A record to the new server's IP. Because you dropped the TTL to 300 seconds back in Phase 1, this change reaches most of the internet within minutes rather than a day. Watch propagation with a tool like DNSChecker.org, and don't decommission the old server until you've confirmed the new one is receiving traffic globally, not just from your own network.

DNSSEC Needs Its Own Step

If you're also switching DNS providers — moving to Cloudflare, for instance — don't skip DNSSEC. It's the mechanism that stops attackers from using DNS spoofing or cache poisoning to quietly redirect your visitors to a cloned malicious site without ever touching your actual hosting. The sequence matters: disable DNSSEC at your registrar before updating your A records, let the new records propagate, then re-enable DNSSEC using the new signing keys your new DNS provider issues. Doing it in the wrong order breaks DNS resolution for your domain entirely, which is its own special kind of downtime incident.

Auditing Search Console After You're Live

Once the new server is serving all traffic, check Google Search Console before you call the migration done. Server moves can quietly change HTTP/2 configuration, SSL certificate chains, or redirect behavior in ways that affect how Googlebot crawls the site, even when human visitors notice nothing. Pull the Crawl Stats report and confirm Googlebot is reaching the new server IP without timeouts or DNS errors. Cross-check your analytics too — a broken redirect chain can quietly fragment sessions or drop pageviews without throwing any visible error on the front end.

Why the Host You Land On Still Matters

Everything above works on any competent host — this is a protocol, not a product feature. But the final cutover phase is where host-level engineering actually shows up. On a host like Kinsta, restores and rollbacks run through containerized environments, which means if something looks wrong immediately after cutover, reverting to a known-good state is a fast, isolated operation rather than a manual re-deploy under pressure. That's not a reason to skip the testing in Phases 1–4 — it's a reason the last 10 minutes of a migration are less stressful when your safety net doesn't depend on you personally remembering to take a manual snapshot first. If you're evaluating hosts as part of a migration decision, that's worth weighing alongside price and support response time — covered in more detail in the Kinsta review.

Frequently Asked Questions

How long does a zero-downtime WordPress migration take?

Most single-site migrations complete in a few hours of active work, spread across the 24–48 hour DNS TTL reduction window. The bulk transfer time depends on database and media library size — a multi-gigabyte uploads folder moved via rsync can take several hours on its own, independent of your active involvement.

Can I test the new server without anyone else seeing it?

Yes — that's exactly what a hosts file override does. Editing the hosts file on macOS, Linux, or Windows maps the domain to the new server's IP on your machine only, bypassing public DNS entirely. Nobody else's browser is affected until you actually change the DNS A record.

What happens to WooCommerce orders placed during the migration?

They live on the old server's database until you run a delta sync. Put the old site in maintenance mode, export its database a second time to capture everything created since the initial transfer, and import that fresh export into the new server immediately before DNS cutover. Skip this step and those orders are gone.

Why can't I just find-and-replace the domain in MySQL directly?

Because WordPress serializes some data with explicit character counts baked into the string. A plain text replacement changes the string length without updating that count, corrupting the data. WP-CLI's search-replace command handles deserialization and reserialization correctly, which a raw SQL query cannot.

Do I need to lower DNS TTL before every migration?

Yes, if you want cutover to propagate quickly. A typical default TTL of 24 hours means resolvers may cache your old DNS answer for up to a day after you make the change. Dropping it to 300 seconds 24–48 hours ahead of cutover means the switch reaches most visitors within minutes instead.

What's the biggest cause of migration failures?

Cutting over to the new server before it's been fully tested. Gartner's research puts the overall data migration failure rate at 83%, and a separate industry study found 23% of organizations experience some data loss during migration — both numbers track back to skipped verification, not exotic technical failures.

Final Thoughts

Zero-downtime migration isn't a plugin feature, it's a sequencing discipline: build the new environment fully, test it under a fake DNS resolution nobody else can see, sync anything that changed while you were testing, and only then flip the switch. Every phase above exists because skipping it produces a specific, predictable failure — serialized data corruption, lost orders, broken cron, silent email failures. None of them are exotic. They're just what happens when someone rushes the order of operations.

If you're moving a site with real traffic or transactions, budget the extra hour for the delta sync and Search Console audit. It's cheap compared to the alternative — ITIC's benchmark puts enterprise downtime above $300,000 an hour, and even a modest store loses real orders in a bad afternoon. Run the checklist in order, and cutover day becomes the least eventful part of the whole process.