Moving a WordPress site to a new host is one of those tasks that sounds simple and goes wrong in creative ways: missing images, broken login, emails vanishing, or the dreaded hours-long outage while DNS “propagates.” The good news is that every one of these failures is preventable. A zero-downtime migration is not luck — it is a sequence of deliberate steps, each one verified before the next begins.
This guide gives you that sequence: a proven, phase-by-phase checklist used by professionals to move sites of all sizes without visitors ever noticing the switch.
Why Migrations Go Wrong
Almost every migration disaster traces back to one of three mistakes. The first is migrating without a verified backup — if the transfer corrupts something, you have nothing clean to restore. The second is changing DNS before the new site is fully tested, which sends live visitors to a half-built copy. The third is forgetting the invisible parts: scheduled tasks, email routing, SSL certificates, and hardcoded URLs buried in widgets or theme settings.
The method below eliminates all three by keeping your old site live and untouched until the new one is proven working, and by treating DNS as the very last step rather than the first.
Phase 1: Prepare Before You Touch Anything
Preparation is where zero-downtime migrations are won. Start with a full inventory of what you are moving:
- Files: everything under your WordPress root — core, themes, plugins, uploads. Note any custom directories outside the standard structure.
- Database: all tables, including any created by plugins. Check its size; very large databases need special handling during import.
- DNS records: list every record at your DNS provider — A, CNAME, MX, TXT — not just the main domain. Email routing lives here and is the most commonly forgotten piece.
- SSL certificate: confirm whether your new host provides one automatically or you must install it yourself.
- PHP version and extensions: check what your old server runs and make sure the new one matches or exceeds it before you move.
Next, take a complete backup of the live site — files plus database — and store it somewhere independent of both hosts, such as your own computer or separate cloud storage. Then verify the backup: a backup you have never tested is a hope, not a plan. If your backup tool offers verification or a test restore, use it.
Finally, lower your DNS TTL (time to live) to something short — 300 seconds is typical — at least 24 to 48 hours before migration day. TTL tells resolvers how long to cache your DNS records; a short TTL means that when you finally switch, visitors move to the new server within minutes instead of hours.
Phase 2: Copy the Site and Test Thoroughly
Set up a blank WordPress install (or empty hosting account) on the new host, then transfer your files and import your database. Many hosts offer a free migration tool or will do this for you — take the help if it is offered, but verify the result yourself regardless.
Once copied, you need a way to view the new site before DNS points at it. Use one of these methods:
- Temporary URL or staging domain provided by the new host — simplest when available.
- Local hosts-file edit on your own computer, mapping your domain to the new server’s IP address. Only your computer sees the new site; everyone else still reaches the old one. This is the professional’s preferred method because it tests the exact domain.
Now test like a skeptical visitor. Log in to the admin panel. Click through key pages. Submit every form. Complete a test purchase if you run a store. Check that images load, menus work, and no URLs still point to the old server or a temporary domain. Search the database for leftover references to old paths. Only when everything works do you move to the next phase.
Do not forget the invisible parts
Verify scheduled tasks are running on the new host — WordPress cron depends on site visits, and some hosts disable it by default. Confirm email sending works if your site sends notifications or order confirmations. Check that any server-level redirects, caching rules, or security headers from the old host are recreated on the new one.
Tip: keep a simple migration log — a text file noting each step and its result. If anything behaves oddly later, the log tells you exactly what changed and when, which turns a mystery into a five-minute fix.
Phase 3: Switch DNS and Monitor
With the new site fully tested, it is time to point visitors at it. Update your DNS records to the new host’s IP addresses. Because you lowered the TTL earlier, most visitors will move over within minutes; full global propagation can still take several hours, so be patient.
During the propagation window, both copies of your site are live simultaneously. This creates one subtle risk: data divergence. If visitors can create content — comments, orders, form submissions, account changes — those actions will land on whichever server each visitor currently resolves to. For high-activity sites, the cleanest approach is to briefly enable maintenance mode or pause new submissions during the switch, then reconcile any straggler data afterward.
Monitor aggressively for the first 24 hours: check uptime, watch error logs, confirm SSL is valid on the new server, and verify email still flows. Keep the old hosting account active for at least a week as an instant fallback — if anything goes seriously wrong, you can point DNS back in minutes.
What About Email During Migration?
Email is the single most overlooked part of a host migration, and the damage is silent: lost messages do not bounce visibly or trigger alarms. Before migration day, answer one question precisely — where does your email actually live? There are three common setups, each with different migration needs.
If your email is handled by a third-party provider (a dedicated mail service or workspace suite), your move is simple: your MX records already point away from your web host, so changing the website’s A record does not touch email at all. Just make sure you migrate the entire DNS zone carefully and do not accidentally delete or overwrite the MX and TXT records during the switch.
If your email runs on your web hosting account itself, you must decide its future home before migrating. Options include keeping mailboxes on the old host temporarily while the website moves, migrating mailboxes to the new host first, or — the most robust long-term choice — moving email to a dedicated provider so future web host moves never threaten it again. Whatever you choose, create the mailboxes and test sending and receiving before you switch DNS.
After the switch, send test emails in both directions and check spam folders. Ask a colleague to email you from an outside address. Email problems after migration are almost always DNS problems — a missing SPF record, an outdated MX entry, or a TTL that has not expired yet — and they are fixable within hours once identified.
Phase 4: Clean Up and Confirm
After a week of stable operation, finish the job properly. Raise the DNS TTL back to a normal value (such as 14400 seconds or higher) to reduce DNS query load. Take a fresh backup of the site on its new home. Cancel the old hosting account only after you are certain nothing — no subdomain, no email forwarder, no cron job — still depends on it.
Run one final end-to-end check: homepage, key landing pages, checkout or contact flow, admin login, and a backup restore test on the new host. Document the new host’s support contacts, backup schedule, and any credentials in the same place you keep your other site records.
Common Migration Pitfalls and How to Avoid Them
- Mixed content warnings: after moving, some assets may still load over plain HTTP. Ensure the site URL uses HTTPS everywhere and that SSL is active before switching DNS.
- Serialized data corruption: never run a naive find-and-replace on the database for URL changes — serialized plugin and theme settings will break. Use a migration tool that handles serialized data correctly.
- Upload limits: large sites can exceed the new host’s file upload or PHP execution limits during import. Check limits first and import in parts or via SSH if needed.
- Email downtime: if email is tied to your hosting, migrating DNS without a mail plan causes silent mail loss. Decide where email lives before migration day.
- Forgetting subdomains: staging sites, CDNs, and verification records often live on subdomains. Migrate the full DNS zone, not just the main record.
Host migrations feel risky because so many small things must go right at once. But notice the pattern in this checklist: nothing is destructive, nothing is rushed, and every step is reversible until the final DNS switch — and even that can be undone in minutes. Follow the phases in order, verify as you go, and your visitors will never know anything happened. That is what zero downtime actually means: not speed, but discipline.
