Why You Should Lower DNS TTL Before a Migration

The mistake most people make

The common approach: change the DNS record on migration day and hope it propagates quickly. If the record's TTL was left at a long default — 3600 seconds (1 hour) or worse, 86400 seconds (24 hours) — every resolver that cached the old value keeps serving it until that TTL expires, regardless of when you actually made the change. Some fraction of your traffic keeps hitting the old server for up to a full day, at the exact moment you least want split traffic.

The two-step fix

Step 1 — well before the migration: lower the TTL on the record you're about to change to something short, typically 300 seconds (5 minutes) or even 60 seconds. Do this at least as long in advance as the current TTL — if the record is currently set to 86400 seconds, wait a full 24 hours after lowering it before treating the short TTL as fully propagated. This is the step people skip, and it's the one that actually matters.

Step 2 — on migration day: make the actual record change (new IP, new CNAME target, whatever the migration requires). Because the TTL is now short, resolvers across the internet pick up the new value within minutes instead of hours, and you can verify the cutover quickly instead of waiting anxiously.

Optionally, once the migration is confirmed stable — a day or a few days later — raise the TTL back to a longer value to reduce load on your nameservers for a record that isn't expected to change again soon.

Why "up to 48 hours" advice is mostly outdated

The old rule of thumb that DNS changes take "24-48 hours" mostly comes from registrar-level nameserver delegation changes, which do have longer and less predictable caching at the registry level. For an ordinary record change on an already-delegated domain — A, CNAME, MX, TXT — propagation time is bounded almost entirely by TTL. A minority of ISP or corporate resolvers cache longer than they should regardless of TTL, which is the real source of most "it's still not working" reports, but it's the exception, not the rule.

Verifying the cutover

Query a public resolver directly rather than relying on your own machine's cache — dig @1.1.1.1 yourdomain.com or dig @8.8.8.8 yourdomain.com bypasses any local caching and shows you what the wider internet is actually seeing.

Plan the timing yourself with the DNS Propagation & TTL Calculator — enter your current TTL and planned change time to get an estimated fully-propagated-by date.