Migrating a client site without the 3am panic attack

You’ve been there. Friday afternoon, the client’s old host is about to expire, someone kicks off a migration, and by 9pm you’re staring at a white screen of death while MX records point to a server that no longer exists. The client’s sales team can’t send email. Their ecommerce store is throwing 500 errors. Your phone won’t stop buzzing.

Don’t forget email deliverability during DNS changes — see our guide on preventing emails from going to spam with DKIM, DMARC and SPF.

Most website migration horror stories share the same root cause: someone treated it like a file copy instead of an infrastructure change. Export, import, point DNS, she’ll be right. Except she won’t be right — not when there are email services, SSL certificates, cron jobs, CDN configurations, and DNS propagation windows to account for.

Here’s what a migration actually looks like when you do it properly.

The cowboy migration (and why it keeps failing)

The typical agency migration goes something like this:

1. Export the site with a WordPress plugin 2. Import it on the new server 3. Change the nameservers 4. Hope for the best

This approach ignores about fifteen things that can go wrong. And they will go wrong, usually at the worst possible time.

Email disruption is the most common casualty. Change nameservers without thinking about MX records and suddenly every email to the client’s domain bounces or disappears into a queue on the old server. If the client uses Google Workspace or Microsoft 365, the MX records need to be explicitly recreated on the new DNS zone — they don’t come across automatically. Miss this, and the client’s team stops receiving email the moment propagation hits their ISP.

SSL gaps are the second classic. You migrate the site, DNS starts propagating, and visitors hitting the new server get a browser warning because Let’s Encrypt hasn’t issued a certificate yet. The certificate can’t be issued until DNS points to the new server, but DNS is already propagating. You’ve got a window — sometimes 20 minutes, sometimes two hours — where some visitors see an SSL error. For an ecommerce site, that’s lost revenue and lost trust.

Database drift is the sneaky one. You took the database export at 2pm. The client’s WooCommerce store processed six orders between then and the DNS cutover at 5pm. Those orders exist on the old server but not the new one. Good luck explaining that.

Step one: the pre-migration audit

Before touching a single file, you need a complete picture of what you’re actually migrating. Not just the WordPress install — everything.

DNS inventory. Pull the full zone file from the current host. Every A record, CNAME, MX, TXT, SRV record. Document them all. You’ll find things you forgot about: SPF records for email deliverability, DKIM keys, DMARC policies, Google Search Console verification TXT records, subdomain A records pointing to staging environments or landing pages on other platforms. Miss any of these and something breaks post-migration.

Run a dig against the domain for each record type:

dig example.com.au ANY +noall +answer
dig example.com.au MX +short
dig example.com.au TXT +short

Server-side dependencies. What PHP version is the site running? Any custom PHP extensions (imagick, ionCube)? Cron jobs? .htaccess rewrite rules that depend on specific Apache modules? Server-level redirects? Password-protected directories via .htpasswd? If the site uses WP-CLI cron instead of server cron, document that too.

Email routing. Is email handled by the hosting server (local delivery), or by a third-party service? If it’s local, you need to factor in mailbox migration — IMAP sync, not just copying Maildirs. If it’s external (Google Workspace, Microsoft 365, Zoho), confirm the MX, SPF, and DKIM records so you can replicate them exactly.

Third-party integrations. Payment gateways with IP whitelists. Firewalls or WAFs with origin IP rules. CDN configurations that reference the origin server IP. Any service that’s bound to the old server’s IP address needs updating.

Step two: DNS preparation (the part everyone skips)

This is where migrations are won or lost.

Lower the TTL well in advance. Most DNS records default to a TTL of 3600 seconds (one hour) or higher — some registrars set it to 86400 (24 hours). At least 48 hours before migration, drop the TTL on all records you’ll be changing to 300 seconds (five minutes). This means once you do the cutover, the old cached records expire within five minutes instead of sitting in resolvers for hours.

If you skip this step and the TTL is 86400, some visitors will hit the old server for up to 24 hours after you change DNS. That’s 24 hours of potential data drift, broken SSL, or downtime if the old server gets decommissioned.

; Before (typical default)
example.com.au.  86400  IN  A  203.0.113.10

; 48 hours before migration, lower TTL example.com.au.  300    IN  A  203.0.113.10

; At cutover, change the IP example.com.au.  300    IN  A  198.51.100.20

Pre-provision DNS where possible. If you’re managing DNS through a provider like Cloudflare or Route 53 (rather than at the hosting level), you can set up the new zone in advance with all the records ready. Cutover becomes a single change — updating the A/AAAA record — instead of rebuilding the entire zone under pressure.

Plan your propagation window. Even with a 300-second TTL, propagation isn’t instant. Some ISPs and corporate DNS resolvers ignore TTL and cache aggressively. Realistically, plan for a 2–4 hour window where traffic splits between old and new servers. Both need to serve the site correctly during this period.

Step three: staging and verification

Set up the site on the new server before touching DNS. The entire site — files, database, configuration — should be running and testable on the new server while the old one is still live.

Test via hosts file. Edit your local /etc/hosts (or C:WindowsSystem32driversetchosts) to point the domain to the new server’s IP. This lets you browse the site on the new server without affecting anyone else:

198.51.100.20  example.com.au  www.example.com.au

Now open the site in a private browser window and test everything: forms, checkout flows, contact pages, image loading, AJAX requests. Check the browser console for mixed content warnings or failed resource loads.

Verify server configuration. Confirm PHP version matches, permalink structure works (mod_rewrite / nginx try_files), file permissions are correct, and wp-cron runs as expected. Run a broken link check. Test email sending from the site (wp_mail). Check that any server-level caching (Redis, OPcache) is configured and working.

Performance baseline. Run a quick load test or at minimum a Lighthouse/GTmetrix scan from the hosts-file setup. Compare against the old server. If the new server is slower, fix it now — not after cutover when the client notices.

Step four: zero-downtime cutover

This is the part that separates a stressful migration from a boring one. Boring is what you want.

Final sync. Just before cutover, do a final incremental sync of files and database. Tools like rsync for files and a fresh mysqldump for the database. This minimises the drift window to minutes rather than hours.

For WooCommerce or any site with active transactions, consider putting the old site into maintenance mode for 10–15 minutes during the final sync. Yes, it’s a brief interruption — but it’s controlled, and it’s better than losing orders to database drift.

SSL pre-validation. If you’re using Let’s Encrypt with HTTP-01 validation, you can’t get the certificate until DNS points to the new server. Two ways around this:

1. DNS-01 validation. Add a TXT record to prove domain ownership. The certificate is issued before DNS cutover, so HTTPS works the moment traffic arrives. 2. Transfer the existing certificate. Export the cert and private key from the old server and install it on the new one. It’ll work until expiry, giving you time to set up automated renewal.

Option 1 is cleaner. If your hosting provider supports it, use it. No SSL gap, no browser warnings.

DNS cutover. Update the A and AAAA records to the new server’s IP. If you lowered the TTL to 300 earlier, most traffic shifts within minutes. Monitor with:

dig example.com.au A +short

Run this from multiple locations (or use a tool like whatsmydns.net) to confirm propagation across different regions.

Keep the old server running. Don’t cancel the old hosting for at least 72 hours after cutover. Stragglers with aggressive DNS caching will still hit it. If possible, set up a redirect on the old server or at least keep it serving the site so those visitors don’t get errors.

Step five: post-migration verification

The migration isn’t done when DNS propagates. It’s done when you’ve verified everything works.

Checklist:

• ☐ Site loads on HTTPS without certificate warnings
• ☐ HTTP redirects to HTTPS correctly
• ☐ www and non-www resolve correctly (and one redirects to the other)
• ☐ All pages return 200 (run a crawl with Screaming Frog or wget --spider)
• ☐ Forms submit and deliver to the correct email addresses
• ☐ Email sending from the site works (test contact forms, WooCommerce notifications)
• ☐ Client email (MX records) is delivering correctly — send test emails both directions
• ☐ SPF, DKIM, and DMARC records are in place (check with dig TXT)
• ☐ Cron jobs are running (check wp cron event list for WordPress)
• ☐ SSL auto-renewal is configured and will work at next renewal
• ☐ CDN is pointing to the new origin IP (if applicable)
• ☐ Google Search Console doesn’t show new crawl errors
• ☐ Uptime monitoring points to the new server IP
• ☐ Backups are configured and running on the new server

That’s not a short list. And every item on it is something that’s bitten someone before.

Why agencies hand this off

If you’ve read this far, you’ve probably noticed this is a lot of work for a single site migration. Now multiply it by ten clients. Or twenty. Each with different configurations, different email setups, different DNS providers, different levels of “we changed things and didn’t tell you.”

This is exactly why agencies outsource hosting management — not because they can’t do it, but because the time spent on migration logistics is time not spent on billable client work.

Related: Why Digital Agencies Should Outsource Hosting (The Maths Actually Works)

Related: Why Digital Agencies Should Outsource Hosting (The Maths Actually Works)

Related: Why Digital Agencies Should Outsource Hosting (The Maths Actually Works)

At Black Label, every hosting plan includes full site migration. Not a cPanel transfer and good luck — an actual managed migration. We run a health check and malware scan on the incoming site, harden security, configure SSL, tune performance, and handle the DNS cutover. The process described in this article is just what we do on every onboarding. You hand us the site details, we handle the rest, and you get a message when it’s done.

For large-scale or high-traffic migrations, read our comprehensive guide: Zero Downtime: Expert Strategies for Migrating High-Traffic Sites.

Managed shared hosting starts at $25/month ex GST. VPS plans from $250/month ex GST. Migration included either way.

Stop losing sleep over migrations

There’s no reason a site migration should involve panic, downtime, or a 3am phone call. The process is well-understood — it just requires discipline, preparation, and attention to the details that most people skip.

If you’d rather not add “migration project manager” to your job title, get in touch. We’ll take it from here.