How to Plan a Safe DNS TTL Change Before a Migration

A DNS migration, server cutover, or IP change that goes wrong isn’t usually because the new record was wrong — it’s because the old record was still cached everywhere, and DNS TTL controls exactly how long that caching lasts. Changing a DNS record with a long TTL still in effect means some fraction of traffic keeps hitting the old destination for however long that TTL specifies, which can be hours, and that’s a genuinely bad time to discover a caching issue during a live cutover.

Getting the timing right means lowering TTL well in advance of the actual change, giving cached records time to expire everywhere before you need traffic to switch cleanly, then restoring TTL to normal afterward.

What planning a safe DNS TTL change actually involves

TTL, time to live, tells any DNS resolver caching a record how long it can keep serving that cached answer before checking for an update. A long TTL is generally good for performance and reduced DNS query load in normal operation, but it becomes a liability during a planned change, since resolvers holding onto a long-cached record won’t see your new value until their cache expires, regardless of when you actually make the change. The safe approach is to lower TTL well ahead of the planned change — giving existing long-cached records time to expire under the old TTL — then make the actual DNS change once TTL is already low, so new lookups pick up the update quickly and consistently. After the change has propagated and stabilized, TTL gets raised back to its normal value, since keeping it artificially low longer than necessary means giving up the caching benefits for no ongoing reason.

Getting the timeline right — how far in advance to lower TTL, how long to wait after lowering it before making the actual change, when it’s safe to raise it back — is where planning this manually gets error-prone, since the correct timing depends on the original TTL value and how much margin you want before the actual cutover.

Why people get stuck here

• Changing a DNS record without first lowering TTL means old records stay cached longer than expected. Resolvers holding a long-cached value under the old TTL won’t see the new record until that original TTL expires, regardless of when the actual change happens.
• The correct lead time for lowering TTL depends on the original TTL value. A record with a 24-hour TTL needs a different, longer lowering window than one with a 5-minute TTL, and getting this wrong undermines the whole point of the exercise.
• Raising TTL back too early risks the same caching problem in reverse. Restoring normal TTL before the change has fully propagated and stabilized can reintroduce inconsistent caching right when you’re trying to confirm the cutover succeeded.
• Manually working out the full timeline for a specific migration is easy to get wrong under time pressure. Between the current TTL, the lowering lead time, and the restoration timing, there are several interacting variables to plan correctly.

What a good DNS TTL planner looks like

Calculates the correct lowering lead time from your current TTL

Basing the lead time on your actual starting TTL value, rather than a generic rule of thumb, is what makes the plan actually safe for your specific situation.

Produces a clear step-by-step timeline

Laying out exactly when to lower TTL, when it’s safe to make the actual change, and when to restore normal TTL removes the guesswork from planning a migration.

Adapts to your specific event type

Different migration events — a server move, an IP change, a full DNS provider switch — can call for different planning considerations, and a plan tailored to the actual event type is more useful than a generic template.

Common mistakes to avoid

• Making a DNS change without first lowering TTL, leaving old cached records in place longer than expected.
• Not accounting for the original TTL value when calculating how far in advance to lower it.
• Restoring TTL to normal before the change has fully propagated and stabilized.
• Manually planning the full TTL timeline under time pressure right before a migration, risking a miscalculated lead time.

How to do it with DNS TTL Planner

Online Tool Store’s DNS TTL Planner takes your event type and current TTL and generates a step-by-step timeline for lowering and restoring DNS TTL safely, entirely in your browser.

1. Enter your migration or change event type.
2. Enter your current TTL value.
3. Get a step-by-step timeline for lowering, changing, and restoring TTL.
4. Follow the timeline for a clean, low-disruption cutover.

Because the timeline is calculated from your actual current TTL and event type, you get a plan genuinely suited to your specific migration, rather than a generic rule of thumb.

Frequently asked questions

Why does TTL matter so much during a DNS migration?

TTL controls how long resolvers cache a DNS record before checking for an update, so a record changed while its old long TTL is still in effect can keep some traffic pointed at the old destination for hours after the actual change.

How far in advance should I lower my TTL before a migration?

It depends on your current TTL value — the lead time needs to be at least as long as the original TTL, so that all existing cached records have a chance to expire before you make the actual change.

When is it safe to raise TTL back to normal after a migration?

Only after the change has fully propagated and stabilized — restoring TTL too early risks reintroducing inconsistent caching right when you’re trying to confirm the cutover actually succeeded.

Final thought

A DNS migration’s real risk isn’t the new record being wrong — it’s the old one staying cached longer than planned. Get the TTL timeline right, and cut over cleanly without leaving traffic stranded on the old destination.

Try the free DNS TTL Planner