The key takeaway: a WordPress migration causes downtime when the steps happen in the wrong order — DNS switched before the new site is verified, or content changed on the old site after the database was already exported. Doing the work in parallel on the new environment, testing it fully before cutover, and lowering DNS TTL in advance is what makes the switch invisible to visitors.
Why Migrations Usually Cause Downtime
The default, unplanned way to move a WordPress site — export the database, copy the files, point DNS at the new server, then start fixing what broke — creates a window where the site is either completely down or serving a half-migrated, broken version. Every step in that sequence happens to the live site itself, so any mistake is immediately visible to visitors.
Zero-downtime migration solves this by inverting the order: build and fully verify the new environment while the old one keeps serving traffic untouched, and only switch over once everything is confirmed working. The live site is never in an intermediate, broken state because the migration work never happens on it directly.
Pre-Migration Checklist
- Take a full backup of the current site's files and database, stored somewhere outside the current hosting account.
- Lower the DNS TTL on the domain's A record to 300 seconds (5 minutes) at least 24-48 hours before the planned cutover — see the technical detail below on why timing this in advance matters.
- Inventory active plugins and themes, noting versions, since the new environment needs to match PHP version and extension requirements.
- Confirm the new host is fully set up — WordPress installed, ready to receive the migrated files and database, but not yet publicly linked to the domain.
Step 1: Lower DNS TTL Before You Start
DNS TTL (time to live) controls how long resolvers around the internet cache a domain's current IP address before checking again. A typical default TTL of several hours (sometimes 24 or more) means that even after DNS is updated to point at the new server, a meaningful share of visitors keep hitting the old one until their resolver's cached copy expires. Cloudflare's own explanation of DNS TTL covers this mechanism in more technical depth.
Lowering the TTL to 300 seconds a day or two before the actual cutover means that by the time DNS is switched, the propagation delay is minutes rather than hours — the single most impactful preparation step for a genuinely low-downtime cutover.
Step 2: Build the New Environment in Parallel
Set up WordPress on the new host completely independently of the live site — same PHP version, same required extensions, ready to receive content but not yet linked to the live domain in any publicly visible way. This is the step that makes "zero-downtime" possible: all the setup work happens on infrastructure nobody is visiting yet.
Step 3: Migrate Files and Database
Tools like Duplicator or the All-in-One WP Migration plugin package the site's files and database into a single transferable archive, handling the technical details of a clean database export and import. For agencies managing frequent migrations, a host-to-host migration tool built into managed hosting platforms (Kinsta, WP Engine, and others offer this) often handles the process with less manual work.
A specific technical trap to avoid here: don't run a plain search-and-replace on the database to update the domain from the old URL to the new one. WordPress stores serialized PHP data — used by many widgets, some plugin settings, and theme options — as strings with an embedded character-length prefix. A naive text replacement changes the string's length without updating that prefix, silently corrupting the data. WP-CLI's search-replace command is built specifically to handle serialized data correctly and is the standard tool for this exact step.
Step 4: Test the New Site Using Your Own Hosts File
Before touching public DNS, edit your own computer's local hosts file to point the domain at the new server's IP address — this affects only your machine, letting you browse the new site using the real domain name (testing login, checkout, contact forms, and anything else that depends on the domain matching) without any other visitor being affected. This is the step that catches migration problems before they're public.
Step 5: Reconcile Content Changes Made During the Migration Window
If the live site kept receiving comments, orders, or form submissions after the database was exported, that content exists on the old site but not the new one. For most brochure sites this window is small enough to ignore; for anything transactional (e-commerce, membership content), export just the new records created during the migration window and import them into the new database before cutover.
Step 6: Cut Over DNS
With the new site fully tested via the hosts file method and any content gaps reconciled, update the domain's DNS A record to point at the new server. Because the TTL was lowered in advance, most visitors resolve to the new server within minutes rather than hours.
Step 7: Verify and Monitor After Cutover
- Confirm SSL is active on the new server for the domain, since a missing or misconfigured certificate immediately breaks HTTPS access.
- Check for mixed-content warnings caused by any hardcoded http:// URLs left in the database or theme files.
- Verify redirects still work if the migration included a URL structure change, and check Google Search Console for a spike in crawl errors over the following days.
- Watch server logs for 404s on previously working URLs, which usually point to a missed file or an incomplete search-replace.
Migration Timeline at a Glance
| Phase | Timing | Key Actions |
|---|---|---|
| Pre-migration | 24-48 hours before | Lower DNS TTL, take backup, confirm new host is ready |
| Parallel build | Before cutover | Set up new environment, migrate files/database with a proper tool |
| Verification | Before cutover | Test via local hosts file using the real domain |
| Cutover | Migration day | Reconcile any content gap, switch DNS |
| Post-migration | First 48-72 hours | Verify SSL, check for mixed content, monitor logs and Search Console |
Common Migration Mistakes
- Skipping the DNS TTL lowering step, leaving cutover propagation at the mercy of whatever the old TTL happened to be set to.
- Running a plain find-and-replace on the database instead of a serialization-aware tool like WP-CLI's search-replace, silently corrupting widget and theme settings.
- Switching DNS before testing the new site, discovering a broken plugin or missing file only after visitors are already hitting it.
- Forgetting content created during the migration window, losing comments, orders, or submissions that landed on the old site after export.
- Not confirming SSL on the new server before cutover, causing a visible certificate warning the moment DNS switches.
When to Get Help Showing Progress to a Client
Agencies migrating a client's site often need to show the parallel new environment for approval before the actual cutover — without handing over hosting credentials or a confusing hosts-file workaround for a non-technical client to follow. A tool like Erdo Client Preview or Erdo Draft Links gives a client a simple link to review the new site directly, which pairs naturally with the testing habits covered in our WordPress staging guide and our broader WordPress speed and hosting guide for evaluating the destination host itself.
Wrapping Up
In short, a zero-downtime WordPress migration comes down to sequencing: lower DNS TTL well in advance, build and fully test the new environment in parallel using your own hosts file rather than public DNS, use a serialization-aware tool for any URL updates, and only switch DNS once everything is verified working. Follow that order and the live site never sits in a broken intermediate state — visitors simply resolve to the new server once it's already confirmed ready.