Zero-Downtime Website Migration: The DNS TTL Playbook

Thinking about moving to a faster host (hey 👋), but terrified of downtime and angry customers? This is the step-by-step zero-downtime migration guide you can follow today. No hand-waving. No guesswork. Just a clean DNS TTL strategy, a safe cutover, and a quick post-migration checklist.

What “downtime” really is (and where it hides)

When people say “my site was down during migration,” it’s usually one of three things:

• DNS propagation lag — visitors resolve old IPs for hours because TTLs were high.
• Origin issues — the new server isn’t an exact clone (missing env vars, bad DB URL, wrong PHP, etc.).
• Mixed cutover — nameservers switched and records changed at the same time, creating inconsistent states.

The fix? Lower TTL well before cutover, switch A/AAAA/CNAME records (not nameservers) during the window, and test like a maniac before traffic flips.

---

The game plan at a glance

1. 72–24 hours before: Lower DNS TTLs.
2. Clone your site to the new host.
3. Smoke test via hosts file & staging URL.
4. Cutover window: flip A/AAAA/CNAME only.
5. Post-cutover checks and raise TTLs again.

---

1) Prep (72–24 hours before): drop your TTL

Lower the TTL on your key records so the world forgets old answers quickly.

Records to adjust:

• A / AAAA for apex (yourdomain.com) and www
• Any CNAME you’ll point at the new host
• (If you have mail on the same host, treat MX/related records carefully—see Pitfalls.)

Recommended TTLs:

• 300 seconds (5 min) is a sweet spot. If your DNS provider allows 60 seconds, even better for the cutover hour.

Bonus: If you’re on a CDN (e.g., Cloudflare), review cache settings; don’t lock stale origin IPs behind the shield during cutover.

---

2) Clone your site on the new host

Make the new environment a mirror image before switching traffic.

Checklist:

• Files & DB copied (use your host’s migration tool or rsync/plugin for WordPress).
• Update environment secrets (.env, wp-config.php, salts/keys).
• Search-replace old domain → new (or staging) URL in DB if needed.
• Match PHP version, extensions, Redis/Object Cache settings.
• Ensure scheduled tasks/cron are set but disabled until cutover.

WordPress quick note: If you use an object cache (Redis/Memcached) or page cache, enable it on the new host after you confirm the site renders correctly.

---

3) Smoke test with hosts file & staging

Don’t trust luck—force your computer to resolve the new server and browse the site like it’s live.

macOS/Linux

sudo nano /etc/hosts
203.0.113.10   yourdomain.com www.yourdomain.com

Windows (Run Notepad as Admin)

C:\Windows\System32\drivers\etc\hosts
203.0.113.10   yourdomain.com www.yourdomain.com

Open a private window and validate:

• Home, key landing pages, login, checkout (if eCommerce)
• Forms, search, sitemaps, robots.txt
• Admin actions (create/update a draft, upload a media file)
• Error logs clean; no mixed content

When done, remove the hosts entries so you don’t forget later.

---

4) The cutover window (the fun part)

This is where zero-downtime happens if you stay disciplined.

1. Freeze content briefly: pause heavy writes (orders keep flowing; just avoid theme/plugin updates or massive imports).
2. Flip records, not nameservers. Update only A/AAAA/CNAME to point at the new server.
3. Purge caches (origin + CDN) where safe.
4. Verify from multiple resolvers quickly:
   • 1.1.1.1, 8.8.8.8, your ISP, mobile hotspot

Command-line sanity checks:

dig +short yourdomain.com @1.1.1.1
dig +short yourdomain.com @8.8.8.8

Both should return the new IP within minutes if TTL was lowered in advance.

---

5) Post-cutover clean-up (30–120 minutes after)

When traffic is clearly flowing to the new host:

• Re-enable crons/scheduled tasks (and WooCommerce webhooks if you paused anything).
• Raise TTL back to a sane value (e.g., 3600–14400) to reduce DNS chatter.
• Rebuild caches (object cache/page cache/CDN).
• Monitor logs: 404 spikes, PHP errors, slow queries.
• Check email: if you changed nameservers anywhere, confirm MX/SPF/DMARC are intact.

---

Common pitfalls (and quick fixes)

• You switched nameservers and records together.
  Fix: Only change A/AAAA/CNAME during cutover. Leave nameservers alone unless you must move DNS providers; if you do, pre-create all records at the new DNS and switch during a quiet window.
• Emails broke after migration.
  Fix: If mail stays with your old provider (e.g., Google/Microsoft), do not touch MX. Watch out for mail.yourdomain.com A records and auto-discovery (autodiscover, smtp, imap) subdomains.
• IPv6 forgotten.
  Fix: If you had an AAAA record, move it too—or remove it intentionally if your new stack isn’t ready for v6.
• Mixed protocol/CDN rules.
  Fix: Align HTTPS redirects, HSTS, and CDN page rules. Double-check that the CDN uses the new origin IP.

---

Minimal migration checklist (copy/paste)

• Lower TTLs to 300–60s (A/AAAA/CNAME) 24–72h in advance
• Full clone (files + DB) and env secrets updated
• Smoke test via hosts file + staging
• Freeze content; flip A/AAAA/CNAME only
• Validate via multiple resolvers (dig)
• Raise TTLs, re-enable cron/caching, rebuild CDN
• Scan logs, forms, payments, email, sitemap/robots

---

FAQ

How long should I keep TTL low?
24–72 hours before cutover is ideal. You can raise it back 30–120 minutes after you confirm traffic is hitting the new server cleanly.

Is it better to change nameservers or just A records?
For zero-downtime, just change A/AAAA/CNAME. Move nameservers only when you’re ready to migrate DNS hosting—and do that as a separate, planned step.

What if my site has heavy write traffic (orders, comments)?
Keep the database on the old host write-active until the cutover moment; minimize writes during the 5–15 minute switch. For very high-write sites, consider temporary read-only banners or replicate DB strategies.

Can I do this behind Cloudflare?
Yes. Update the origin IP in DNS (orange cloud on) and purge caches. Make sure any firewall rules or IP allow-lists include the new server.

---

Want help?

If you’d rather not DIY, we can handle a free assisted migration and run a quick performance check once you’re live. Either way, use this playbook—it’s the safest way to move without customers ever noticing.

---