Lower the TTL the day before the move, not on the day

Every DNS migration guide says to lower your TTL. Most people do it as the first step of the migration itself, which is roughly a day too late to help.

Why the timing is the whole point

A TTL is not an instruction to your nameservers. It is an instruction you gave to everyone else's resolvers, at the moment they last asked.

If your A record has a TTL of 86400 — one day, a very common default — then a resolver that looked you up an hour ago has been told it may keep that answer for the next twenty-three hours. It is not going to ask you again. It has no reason to.

So when you lower the TTL to 300 on cutover morning, that new value only reaches resolvers that ask you after the change. Every resolver already holding the old record is still holding it under the old terms, and will keep sending your visitors to the old server for up to a full day.

Lowering the TTL is a message that has to arrive before it is useful. And it only arrives when the previous one expires.

The timeline

Two days before. Find every record you are going to change — usually the apex A or AAAA, www, and possibly MX — and note their current TTLs. That number is your lead time.

One full old-TTL period before the move. Lower them to 300 seconds. If the old TTL was 86400, this means doing it a day ahead. Change nothing else. You are simply waiting for the world to expire its old copy and pick up the short one.

Cutover. Make the actual change. Because everyone is now holding a five-minute copy, the change propagates in about five minutes rather than a day. This is the entire payoff.

After it is stable. Put the TTLs back up — 3600 or so for records that change rarely. A permanent 300-second TTL means every resolver in the world re-queries your nameservers twenty times as often, for no benefit once the move is done, and makes you more fragile to a DNS outage rather than less.

The window nobody plans for

Between the change and the last cache expiring, some visitors reach the new server and some reach the old one. A five-minute window is a detail. A day-long window is an incident, and the shape of the incident depends on what the service does.

A static site: harmless. Visitors see one of two identical copies.

A site with logins: some sessions land on a server that does not have them. People get logged out at random.

A site that writes data: this is the one that hurts. Orders, form submissions and uploads are landing in two separate databases, and neither is complete. Merging them afterwards is manual, error-prone, and entirely avoidable by shortening the window first.

Email is worse again, because the sender does not retry on success — mail delivered to the old server is simply there, in a mailbox nobody is reading any more. Mail is the one thing worth a final sweep after the MX change, to bring across whatever arrived at the old provider during the window.

Two things the TTL does not cover

The registry has its own TTL. Nameserver delegation and DS records live in the parent zone, and their TTL is set by the registry, not by you. Commonly a day or two, and you cannot shorten it. If you are changing nameservers rather than records, plan for that longer window — it is a different move from changing an A record and deserves a different timeline.

Some resolvers ignore you. A minority of ISP resolvers enforce their own minimum TTL, and some consumer routers cache with enthusiasm and no discipline. Plan for a long tail. Keep the old server answering correctly for a day or two after the move rather than switching it off the moment the change looks complete — the cheapest insurance in the whole exercise.

The short version

The TTL you are waiting on during a migration is the one that was in place before you started. Set it low a day early, move, then set it back. It is five minutes of work at exactly the moment it feels least urgent, and it is the difference between a five-minute cutover and a day of two servers disagreeing about who owns your data.