Lowering your DNS TTL before a migration is the single most effective thing you can do to make the cutover fast and clean — it is the difference between your host switch propagating in minutes versus dragging out over many hours. It is also the one preparation people most often forget, because it has to be done days in advance to work. This guide explains what TTL is, why lowering it matters so much for a migration, and exactly how and when to do it so your cutover propagates almost instantly.

You will learn what TTL does, why a lowered TTL shrinks the cutover window, the crucial timing (why you must do it days ahead), how to actually lower it, what value to set, and how to restore it after the migration. By the end you will be able to prepare your DNS so that when you cut over, the switch reaches your visitors in minutes rather than hours.

What TTL is and does

TTL, or time to live, is a value attached to each of your DNS records, measured in seconds, that tells the rest of the internet how long to cache that record before checking with the authoritative source for a fresh copy. It is essentially the record’s cache lifetime: a TTL of 3600 means servers may hold the record for an hour before rechecking; a TTL of 300 means they recheck every five minutes.

This matters for migration because when you cut over — changing a DNS record to point at the new host — that change only reaches each cache around the internet once the cache’s held copy of the old record expires, which is governed by the TTL. A high TTL means caches hold the old record (pointing at the old host) for a long time, so your change propagates slowly; a low TTL means they refresh quickly, so your change propagates fast.

So TTL is the dial that controls how quickly your eventual cutover will reach everyone. Understanding that TTL = how long the internet remembers your old record before rechecking makes its role in migration obvious: the lower the TTL when you cut over, the faster the world picks up the change. That is exactly why lowering it before a migration is such a powerful preparation — you are shrinking how long the internet clings to the old host after you switch.

Why a lowered TTL shrinks the cutover window

The cutover window — the transition period during which some visitors reach the new host and some still reach the old one — is governed almost entirely by TTL. With a typical default TTL (often an hour or several hours), caches hold your old record for that long after you cut over, so the transition drags out over hours; some caches with long TTLs, plus ISPs that ignore TTL, can stretch the tail toward the oft-quoted 48 hours.

Lower the TTL to a short value like 300 seconds (five minutes) before cutting over, and that window collapses dramatically: caches refresh every five minutes, so within minutes of your DNS change, the vast majority of the internet has picked up the new record and is sending visitors to the new host. The transition that would have taken hours now takes minutes.

This matters because the cutover window is the fragile period of a migration — the time you must keep both hosts alive and during which any inconsistency between them can show. Shrinking it to minutes rather than hours makes the whole cutover cleaner, faster, and less risky: less time maintaining two hosts, less time in the mixed-state transition, and a quicker confirmation that everyone has moved. That collapse of the risky window is the entire payoff of lowering TTL, and why it is the highest-leverage migration preparation.

The crucial timing: days ahead

Here is the catch that makes TTL preparation easy to get wrong: lowering your TTL only takes effect after the old, higher TTL has expired from caches — which takes as long as the old TTL was. So you cannot lower the TTL at the moment of cutover and expect a fast switch; the low value will not have propagated yet, and the cutover will still happen at the old, slow TTL.

To have a genuinely low TTL in force at cutover, you must lower it in advance — long enough for the old TTL to expire everywhere. Since default TTLs are often an hour to a day, lowering your TTL a day or two before the planned cutover is the safe rule: that gives the old value time to age out of all caches, so that by cutover time, everyone is caching your records at the new low TTL, and your actual DNS change then propagates in minutes.

So the crucial discipline is to lower the TTL days ahead of the cutover, not simultaneously with it. This makes TTL preparation the very first step of your DNS timeline, done before the visible migration work. Plan backward from your intended cutover date and lower the TTL a day or two earlier. Forgetting this — or doing it at the same time as the switch — is exactly why some well-executed migrations still propagate slowly: the person lowered the TTL, but too late for it to help.

How to lower the TTL

Lowering the TTL is done wherever you manage your domain’s DNS — which is your domain registrar, your DNS provider, or your host, depending on where your nameservers point. You log into that DNS management interface, find your DNS records, and edit the TTL value on the relevant records.

• Find your DNS management: log into wherever your DNS is managed (registrar, DNS host, or web host — wherever your nameservers point).
• Locate the records: find the records that will change at cutover — chiefly the A record (and www) for the website, or note that changing nameservers is a special case.
• Edit the TTL: change the TTL field on those records to a short value (like 300 seconds), and save.
• Do it a day or two before cutover: so the old TTL expires and the new low value is in force by switch time.

The key records to lower are the ones you will actually change at cutover — typically the A record (and its www counterpart) if you are switching by A record. Note a special case: if your cutover will be a nameserver change rather than an A-record change, the TTL that matters is on the domain’s NS/nameserver delegation, which is often controlled by the registry and less freely adjustable, so an A-record-based cutover gives you more direct TTL control. In most DNS panels, lowering the TTL is a simple edit of a number on your records, done a day or two ahead.

What value to set

A short TTL of around 300 seconds (five minutes) is the standard, sensible choice for migration preparation. It is low enough that your cutover propagates within minutes, but not so aggressively low that it causes an excessive volume of DNS lookups in normal operation. Five minutes is the commonly recommended migration TTL, striking the right balance between fast propagation and reasonable caching.

You could go even lower (some go to 60 seconds) for maximum speed, but there is little practical benefit over 300 for a migration, and extremely low TTLs mean more frequent lookups. Conversely, do not leave it at a high value if you want a fast cutover — the whole point is to get it low. 300 seconds is the reliable default that gives you a minutes-long cutover window without downsides.

So set your TTL to around 300 seconds a day or two before cutover — that is the practical recommendation. This ensures that when you make your DNS change, caches around the internet, now holding your records for only five minutes, refresh quickly and pick up the new host within minutes. There is no need to overthink the exact value; 300 is the well-established migration TTL, and it delivers the fast, clean propagation you are preparing for.

Restoring the TTL afterward

After the migration is complete and propagation has finished, you should raise your TTL back to a normal, higher value — because a permanently very low TTL, while harmless in the short term, causes more frequent DNS lookups than necessary in everyday operation, which is slightly less efficient. The low TTL was a temporary tool for the cutover, not a permanent setting.

Once your cutover has fully propagated and you have confirmed everything is stable on the new host (typically a day or few after the switch, around when you would retire the old host), go back into your DNS management and raise the TTL on the records you lowered back to a normal value — commonly an hour (3600 seconds) or a few hours, which is efficient for stable records that rarely change.

So the full TTL lifecycle for a migration is: lower it to ~300 seconds a day or two before cutover, keep it low through the cutover and propagation for a fast switch, then restore it to a normal value (like 3600) once the migration is confirmed stable. This lower-then-restore pattern is the professional way to handle TTL for any planned DNS change, giving you a fast cutover when you need it and efficient caching the rest of the time. Restoring it afterward is the small final step that returns your DNS to its efficient steady state once the migration no longer needs the speed.

FAQs

How do I lower my DNS TTL before a migration?

Log into wherever your DNS is managed (registrar, DNS provider, or host), find the records that’ll change at cutover (chiefly the A record and its www counterpart), and change their TTL value to a short value like 300 seconds, then save. Crucially, do this a day or two BEFORE the cutover, so the old higher TTL expires from caches and the low value is in force by switch time.

What is DNS TTL?

TTL (time to live) is a value in seconds on each DNS record telling the internet how long to cache it before rechecking with the authoritative source. It’s the record’s cache lifetime — a TTL of 3600 means caches hold it an hour; 300 means five minutes. It governs how fast a DNS change (like your migration cutover) propagates: high TTL = slow, low TTL = fast.

Why lower TTL before migrating?

Because it collapses the cutover window from hours to minutes. With a default TTL (often an hour or more), caches hold your old record — pointing at the old host — for that long after you cut over, dragging out the transition. Lowered to 300 seconds, caches refresh every five minutes, so within minutes of your DNS change the internet picks up the new host. It’s the highest-leverage migration prep.

When should I lower the TTL?

A day or two before the cutover, never at the same time. Lowering the TTL only takes effect after the old, higher TTL expires from caches, which takes as long as the old TTL. So if you lower it at cutover, the low value hasn’t propagated and the switch still happens at the old, slow TTL. Do it early so the low value is fully in force by switch time — it’s the first step of your DNS timeline.

What TTL value should I set for a migration?

Around 300 seconds (five minutes) is the standard, sensible choice — low enough that your cutover propagates within minutes, without causing excessive lookups in normal operation. You could go to 60 seconds for maximum speed, but there’s little practical benefit over 300 for a migration. 300 is the well-established migration TTL that delivers fast propagation without downsides.

Should I restore the TTL after migrating?

Yes. A permanently very low TTL causes more frequent DNS lookups than necessary in everyday operation, so once the cutover has fully propagated and the new host is confirmed stable (a day or few after the switch), raise the TTL back to a normal value like 3600 seconds (an hour) or a few hours. The low TTL was a temporary tool for the cutover; restore it to return your DNS to its efficient steady state.

The bottom line

Lowering your DNS TTL before a migration is the highest-leverage preparation you can make, because TTL — the value telling the internet how long to cache each DNS record before rechecking — directly governs how fast your cutover reaches everyone. With a typical default TTL of an hour or more, caches cling to your old record (still pointing at the old host) for that long after you switch, dragging the transition out over hours; lower the TTL to around 300 seconds beforehand, and caches refresh every five minutes, collapsing the cutover window to minutes. Since that window is the fragile period during which you must keep both hosts alive and visitors are split between them, shrinking it from hours to minutes makes the whole cutover faster, cleaner, and lower-risk.

The one thing that makes this preparation easy to get wrong is timing: lowering the TTL only takes effect once the old, higher value has expired from caches, which takes as long as the old TTL — so you must lower it a day or two before the cutover, not at the same moment, or the switch still propagates at the old slow rate. That makes TTL-lowering the very first step of your DNS timeline: plan backward from your cutover date, log into wherever your DNS is managed, and set the TTL on the records you will change (chiefly the A record and www) to about 300 seconds a day or two ahead. Then, once the cutover has fully propagated and the new host is confirmed stable, raise the TTL back to a normal value like 3600 seconds for efficient everyday caching. Lower early, switch fast, restore after: that lower-then-restore pattern turns your cutover from an hours-long drag into a minutes-long flip, which is exactly what makes a zero-downtime migration feel effortless.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Lower your DNS TTL to ~300 seconds a day or two BEFORE a migration cutover (not at the same time — the old TTL must expire from caches first), on the records you’ll change (A record and www). This collapses the cutover window from hours to minutes, so the switch propagates almost instantly. After the move is stable, restore the TTL to a normal value like 3600. It’s the highest-leverage prep for a fast, clean cutover.