How to Do a WordPress Migration Without Downtime
Moving a WordPress site to new hosting is routine work that becomes a crisis the moment visitors hit a “site not found” error mid-migration. Doing a WordPress migration without downtime is entirely achievable with the right sequence — the key is never pointing your domain at the new server until the new copy is fully verified working.
Why Migrations Usually Cause Downtime
The typical mistake is switching DNS or updating the domain before confirming the new site actually works — so any problem (a missing plugin, a database connection error, a broken permalink structure) becomes visible to live visitors instead of being caught in testing.
A Zero-Downtime Migration Sequence
1. Set Up the New Environment First, Fully Separate
Build the new site on the new host under a temporary URL or staging subdomain — nothing about your live domain changes yet. This gives you a fully working copy to test against before any visitor is affected.
2. Migrate Files and Database
Copy your wp-content directory (themes, plugins, uploads) and export/import your database. A dedicated migration plugin (Duplicator, All-in-One WP Migration, or your host’s built-in migration tool) handles most of this automatically and is more reliable than a fully manual copy for most site sizes.
3. Test Everything on the Temporary URL
Check every major page, form submission, and plugin-dependent feature (search, checkout, contact forms) on the staging URL before touching DNS. This is the step that actually prevents downtime — catching problems here means visitors never see them.
4. Lower Your DNS TTL in Advance
A day or two before the actual cutover, lower your domain’s DNS time-to-live (TTL) value. This makes the eventual DNS change propagate faster once you do flip it, shrinking the window where some visitors might briefly hit the old server.
5. Cut Over, Then Verify Immediately
Once the new site is fully tested, update your DNS to point at the new host. Monitor the live site closely for the next hour, and keep the old hosting active (don’t cancel it) for at least a week as a safety net in case something surfaces that testing missed.
A Simple Checklist for the Cutover Day
| Step | Why It Matters |
|---|---|
| Full backup of the old site | A safety net if anything goes wrong mid-migration |
| Staging URL fully tested | Catches issues before visitors ever see them |
| DNS TTL lowered in advance | Speeds up propagation, shrinks the risk window |
| Old host kept active post-migration | Rollback option if a delayed issue surfaces |
Keep Backups Running After the Move
Once you’re settled on the new host, make sure automatic backups are configured immediately — see our guide on setting up automatic website backups so a future problem doesn’t turn into a repeat of the migration process out of necessity.
Frequently Asked Questions
How long should I keep the old hosting active after migrating?
At least one to two weeks — enough time to catch anything that testing missed, especially issues tied to specific traffic patterns or scheduled tasks that didn’t run during initial testing.
Will migrating hurt my SEO rankings?
Not if the domain stays the same and the migration preserves URLs, redirects, and site structure — rankings are tied to your domain and content, not your hosting provider.
Can I do this without a migration plugin?
Yes, manually via phpMyAdmin and FTP, but a migration plugin significantly reduces the risk of a missed file or database error, especially for larger sites — most are worth the small cost or free-tier limitations.
The Bottom Line
A zero-downtime WordPress migration comes down to sequencing: build and fully test the new site before touching DNS, lower your TTL in advance, and keep the old host as a safety net. Skipping the testing step on a temporary URL is where most “quick migrations” turn into visible outages.
One Comment