Why TTL matters more than you think during a migration

You picked a low-traffic window, updated the A record, and refreshed the page. The new server loaded instantly on your machine, so you called the migration done. Then the support tickets started: half your visitors were still landing on the old host, some for another full day.

Nothing was broken. That is the frustrating part. DNS did exactly what you told it to do, weeks or months earlier, when someone set a time to live of 86400 seconds and never thought about it again.

TTL is the single biggest factor in how long a migration takes to actually complete, and it is the one most teams only learn about after a cutover goes sideways. Here is how it works and how to plan around it.

What TTL actually controls

Every DNS record carries a TTL value: the number of seconds a resolver is allowed to cache the answer before asking your authoritative nameserver again. The field dates back to RFC 1035, the 1987 specification that still defines DNS today, and its purpose has not changed: keep the world from hammering authoritative servers with the same question over and over.

The key word is resolver. When someone visits your site, their query almost never reaches your nameserver directly. It goes through their ISP's resolver, or a public one like Google's 8.8.8.8 or Cloudflare's 1.1.1.1, and that resolver serves the cached answer to everyone behind it until the TTL runs out. You do not control those caches. You cannot flush them. The TTL you set is a promise about how stale an answer is allowed to be, and the internet holds you to it.

So a TTL of 86400 (24 hours) means this: after you change a record, some visitors can legitimately be routed to the old value for up to a full day. Not because propagation is slow or mysterious, but because you told every resolver on earth that a day-old answer was fine.

The mistake: cutting over at the default TTL

Most DNS hosts assign a default TTL of 3600 seconds (1 hour) or more, and plenty of zones still carry 86400 from whenever they were first configured. That is a sensible default for records that never change. It is a trap during a migration.

The failure mode looks like this: you update the record and test from your own machine, which either queries a resolver that has not cached the old answer or has had its cache flushed. Everything looks perfect. Meanwhile, the large resolvers that serve most of your real traffic are still confidently handing out the old IP, and they will keep doing so until their copy expires. During that window you are running a split-brain site: some users on the new server, some on the old one.

For a static brochure site, that is cosmetic. For anything with logins, carts, form submissions, or a database, it means writes landing on a server you are about to decommission. If you shut the old server down early, the users still pinned to it get connection errors, and there is nothing you can do but wait.

Email is the same story with higher stakes. Change MX records under a long TTL and inbound mail splits between the old and new provider for hours. Messages delivered to a mailbox you no longer check are effectively lost.

The pre-migration TTL playbook

The fix is simple, but it requires acting before the migration, not during it.

A few days out: audit your current TTLs. Look up every record the migration will touch and note its TTL. Do not trust the value in your DNS host's control panel alone; query it live, because what resolvers see is what matters. A DNS lookup against the live zone shows the actual TTL on each record type.

At least 24 to 48 hours before cutover: lower the TTL. Drop the records you plan to change to 300 seconds (5 minutes), or 60 if your DNS host allows it. Here is the step people miss: lowering the TTL does not take effect immediately. Resolvers that cached the record under the old TTL will hold both the old value and the old TTL until that cache expires. If the current TTL is 24 hours, you need to lower it a full 24 hours before the change matters. The waiting period is set by the old TTL, not the new one.

Cutover: make the change. With a 300-second TTL in place and fully aged in, the change reaches essentially all resolvers within about five minutes. Your split-brain window shrinks from a day to the length of a coffee break.

Verify before you celebrate. Check the new value from multiple public resolvers, not just your own machine. If you tested early and suspect your own resolver is holding a stale answer, Google Public DNS has a cache flush tool that clears its copy on demand, and Cloudflare offers the same for 1.1.1.1. That fixes your view, but remember it does nothing for anyone else's resolver.

After a day or two of stability: raise the TTL back. A permanently low TTL means every resolver re-queries your nameserver constantly, which adds latency for visitors and load on your DNS host. Once you are confident the migration will not roll back, restore something reasonable, typically 3600 or higher for stable records.

The records everyone forgets

Migrations rarely touch just one A record. Walk the whole zone before you plan the cutover:

• The www CNAME and other subdomains. If www is a CNAME pointing at the apex, or subdomains point at the old infrastructure, they each carry their own TTL and each needs the same lowering treatment.
• MX records. If the migration includes email, MX changes deserve an even more conservative TTL plan than the website, because misrouted mail is silent and unrecoverable.
• TXT records for SPF, DKIM, and verification. Moving email providers means these change too, and a cached stale SPF record can cause receiving servers to reject your mail as unauthenticated mid-migration.
• Negative caching. If a record does not exist yet on the new setup and a resolver asks for it, the "no such record" answer gets cached too, using the minimum TTL from your SOA record as defined in RFC 2308. Create new records before anything queries them, not after.

One more post-cutover check that has nothing to do with DNS but always shows up alongside it: redirects. New hosting stacks frequently change how the HTTP to HTTPS and www to apex redirects behave. A quick pass with a redirect checker after cutover confirms the chain still resolves in one hop instead of three.

Verifying the cutover actually propagated

The honest answer to "has it propagated?" is never a single lookup. It is the same query asked from many vantage points. AcuityScan's DNS lookup checks your records against 20 global DNS resolvers, including Google, Cloudflare, Quad9, and OpenDNS, so you can see exactly which resolvers have picked up the new value and which are still serving the old one, instead of guessing from your own cache.

TTL planning is also the kind of thing worth catching before a migration is ever on the calendar. The full site scan at acuityscan.com runs 350+ checks across 8 modules, and the DNS health module flags unusually high TTLs along with nameserver redundancy, DNSSEC status, and record-level issues, so the 86400 sitting quietly on your A record gets noticed while it is still harmless.

Run a free scan before your next migration. Five minutes of reading the DNS module beats a day of split-brain traffic.