How to Migrate a WordPress Site Without Downtime

Planning to migrate a WordPress site to a new host? The single biggest risk isn't losing data — it's downtime. A botched cutover can mean hours of 502 errors, broken checkout pages, and a Google crawl that catches your site mid-collapse. The good news: with the right sequence and a bit of DNS patience, you can move a live WordPress or WooCommerce site with zero visible downtime, even for stores taking orders in real time.

This guide walks through the exact process agencies and site owners use to migrate WordPress without downtime — from pre-migration prep through DNS cutover and post-launch verification.

Why WordPress Migrations Usually Go Wrong

Most migration horror stories share the same root cause: the DNS switch and the file/database copy happen as a single rushed step instead of two separate, verifiable ones. Common failure points include:

• Stale database exports — content changes on the old site after the export is taken, so the new site launches with missing orders, comments, or posts.
• Hardcoded URLs — the siteurl and home values, plus URLs baked into post content and serialized widget data, still point at the old domain.
• Mixed DNS states — some visitors resolve to the old server, others to the new one, during propagation, so sessions, cart contents, and logins break inconsistently.
• Missed dependencies — cron jobs, mail routing (SPF/DKIM), SSL certificates, and redirects that quietly break during the move.
• No rollback plan — if something goes wrong post-cutover, there's no fast way back to the working version.

A zero-downtime migration avoids all five by keeping the old site fully live and untouched until the new one is proven to work.

Step 1: Audit and Prepare the Source Site

Before touching anything, document what you're moving:

• PHP version and extensions — match or exceed these on the new host to avoid fatal errors.
• Plugins and themes — note any license keys tied to the domain (some premium plugins deactivate on a URL change).
• Custom cron jobs — WP-Cron tasks, server-level cron, and any scheduled WooCommerce jobs (stock sync, abandoned cart emails).
• Email sending method — SMTP plugin, transactional email service, or server mail — this needs to keep working post-move.
• SSL certificate type — free (Let's Encrypt/AutoSSL) certificates are easy to reissue; if you have a purchased cert, you'll need the private key.

If you're moving to a managed WordPress host, most of this environment matching is handled for you, but it's still worth confirming PHP version and installed extensions match what your plugins expect.

Step 2: Stage the New Site on a Temporary URL

This is the step that makes zero downtime possible: build and test the destination site before any DNS change, using a temporary domain or a hosts-file override so only you can preview it.

1. Provision the new hosting environment and create the destination site.
2. Copy files (themes, plugins, uploads) via SFTP, a migration plugin, or your host's built-in migration tool.
3. Export the database from the live site and import it into the new environment.
4. Search-and-replace the old domain with the new one across the database — including serialized data (use a tool built for this, like WP-CLI's wp search-replace with the --skip-columns=guid flag, rather than a plain SQL find-and-replace, which corrupts serialized arrays).
5. Update wp-config.php database credentials to match the new environment.

At this point you have a fully functional copy of the site, reachable only by you, while the original remains live and serving real traffic untouched.

Testing Before Cutover

Edit your local machine's hosts file to point the domain at the new server's IP address temporarily, then load the site as if it were already live. Check:

• Homepage, key landing pages, and blog posts render correctly
• Login and admin dashboard work
• Forms submit and email notifications arrive
• For WooCommerce: product pages, cart, checkout, and a full test transaction in sandbox mode
• Site speed — this is a good moment to compare load times against the old environment
• Broken links or missing images from the URL search-and-replace step

Don't remove the hosts-file override until every one of these passes.

Step 3: Handle the Database Delta

Because the site kept running on the old server while you built the new one, any orders, comments, or posts created after your initial export are missing from the new copy. For low-traffic brochure sites this delta is often negligible, but for an active WooCommerce store it isn't.

Two approaches work well:

• Schedule the final sync during low-traffic hours (overnight or early morning for your primary customer base), then do a final, fast database re-sync of just the delta immediately before flipping DNS.
• Use a migration tool with live sync that mirrors database writes to the new environment in near real time, so there's effectively no delta to catch at cutover.

Either way, the final sync should happen within minutes of the DNS change, not hours before it.

Step 4: Lower the DNS TTL in Advance

DNS propagation delay is what causes visible downtime, and it's entirely avoidable if you plan ahead. At least 24–48 hours before your migration:

1. Log in to your DNS provider and find the A record (and any relevant CNAME records) for the domain.
2. Lower the TTL (Time to Live) value to 300 seconds (5 minutes) or less.
3. Wait out the old TTL period so the low value has propagated everywhere.

If you're unfamiliar with how records and TTLs interact, our guide on how DNS works breaks down nameservers, record types, and propagation in more detail.

With a short TTL, once you do change the A record to the new server's IP, most resolvers worldwide pick up the change within minutes instead of the default 24–48 hours.

Step 5: Flip DNS and Do the Final Sync

This is the actual cutover, and it should take only a few minutes:

1. Run the final database delta sync (or let live sync catch up) so the new site has every order and comment from the old one.
2. Update the DNS A record to point at the new server.
3. Confirm SSL is active on the new server so HTTPS doesn't break the moment traffic arrives (most managed hosts auto-provision this on first request).
4. Monitor both servers — keep the old one running and untouched as a fallback for at least 24–48 hours.

Because the TTL is low, visitors shift to the new server within minutes, and because the new site was already fully built and tested, they never see an error page — just a seamless continuation.

Step 6: Post-Launch Verification

Once DNS has propagated (check with a global propagation checker rather than just refreshing your own browser, since your ISP may cache the old record locally):

• Re-run the full test checklist from Step 2 against the live domain
• Confirm outbound email (order confirmations, password resets) is landing in inboxes, not spam
• Check Google Search Console for crawl errors
• Verify any redirects from an old URL structure are working
• Watch server error logs for the first few hours for anything unexpected

Keep the old hosting account active for a couple of weeks as a safety net before cancelling it — that's your rollback plan if something surfaces after launch.

When to Let Someone Else Handle It

A zero-downtime migration is very achievable to do yourself, but the margin for error on a live WooCommerce store — with real orders, real customers, and real revenue — is thin. If the checklist above feels like more risk than you want to carry, a managed migration service handles the staging, search-and-replace, DNS timing, and rollback plan for you, so the only thing you notice is that the site is suddenly faster and living somewhere new.

The Bottom Line

Zero-downtime WordPress migration isn't a special trick — it's sequencing. Build and fully test the new site first, keep the old one live the entire time, minimize the DNS TTL in advance, and only cut over once everything is verified. Followed in that order, visitors and search engines never see a gap, and you keep a working fallback until you're confident the move succeeded.