Timing the DNS change is one of the most consequential decisions in a migration, because updating DNS too early sends visitors to a site that is not ready, while updating it without preparation makes the switch slow and messy. The DNS update is the cutover — the moment the world starts moving to the new host — so knowing exactly when in the migration sequence to make it, and what must be true beforehand, is what separates a clean switch from a self-inflicted problem. This guide pins down the timing precisely.

You will learn where the DNS update sits in the migration sequence, the two conditions that must be met before you touch DNS, why updating too early is the classic mistake, the ideal timing and why a low-traffic window helps, the TTL preparation that must happen days earlier, and what to do in the period right after the update. By the end you will know exactly when to pull the DNS trigger for a smooth, safe cutover.

Where the DNS update sits in the sequence

To time the DNS update correctly, you have to see where it belongs in the migration sequence, because it is not a free-standing action but the pivot the whole process turns on. The sequence is: back up, set up the new host, copy the site (files and database), reconnect and configure it, test the migrated site privately, and then — and only then — update DNS to cut over, after which you verify and eventually retire the old host.

The DNS update sits near the end, deliberately, because everything before it is preparation done invisibly while the old site keeps serving visitors, and everything after it is the transition and confirmation. The DNS update is the hinge between ‘preparing the new site privately’ and ‘the world moving to the new site’ — it is the single action that changes the migration from private to public.

So the DNS update’s place in the sequence tells you its timing at a high level: it comes after the site is fully copied, configured, and tested on the new host, and before the verification-and-retire phase. Updating DNS is not the start of the cutover work but the culmination of it — the moment all the prior preparation is cashed in. Understanding this placement is the foundation for the precise timing conditions that follow.

The two conditions before you touch DNS

Two specific conditions must both be true before you update DNS, and they are non-negotiable, because each prevents a distinct problem:

• Condition 1 — the new site is fully tested and working: you have verified the migrated site on the new host (via a private preview), confirming pages, images, links, forms, and functionality all work. This ensures the switch sends visitors to a working site.
• Condition 2 — your TTL is already lowered: you lowered your DNS TTL a day or two earlier, so the update will propagate fast. This ensures the switch is quick and clean rather than dragging out over many hours.
• Both, not either: testing without a lowered TTL means a working site but a slow switch; a lowered TTL without testing means a fast switch to a broken site. You need both.
• Plus: know your email plan: you know how your email MX records will be preserved through the DNS change, so mail doesn’t break.

These two conditions are the gate: do not update DNS until both are satisfied. The first (testing) is what makes the switch safe; the second (lowered TTL) is what makes it fast. Both being true is what lets you update DNS knowing the cutover will be both a flip to a confirmed-working site and a quick, clean propagation. If either is missing, you are not ready to update DNS yet, no matter how eager you are to finish — meeting both conditions first is the whole discipline of timing the DNS update.

Why updating too early is the classic mistake

The most common and damaging DNS-timing mistake is updating too early — pointing your domain at the new host before the migrated site is fully tested and working there. This is tempting because updating DNS feels like ‘finishing’ the migration, but doing it prematurely inverts the safe order and sends live visitors straight to whatever broken state the new site is in.

When you update DNS too early, the problems you should have caught privately — missing images, a database-connection error, broken checkout — are now hitting real visitors, and you are debugging under pressure with your site publicly broken. Worse, because DNS has propagated, you cannot simply ‘undo’ quickly; reverting DNS also takes time to propagate, so you are stuck with a public problem for a while. The premature update turns catchable private problems into a public incident.

So the discipline is to resist the urge to update DNS until the new site is genuinely verified, because updating early is precisely how a migration that could have been seamless becomes a visible failure. The DNS update should be the last thing you do, from a position of tested confidence — never an early action taken in eagerness to be done. Almost every ‘my migration went wrong’ story is really a ‘I updated DNS before the site was ready’ story.

The ideal timing and low-traffic windows

Beyond the two conditions, there is an ideal moment within them to actually make the DNS update: during a low-traffic window for your site. Since propagation creates a transition period where visitors are moving between old and new hosts, doing it when few visitors are around minimises how many people experience the transition at all, and gives you a quieter environment to monitor and handle any post-cutover issues.

Identify your site’s lowest-traffic period — often the middle of the night for your primary audience’s time zone, or a known quiet day — and schedule the DNS update for then. This is not strictly necessary for a well-prepared, tested migration (which should be seamless regardless), but it adds a margin of safety: fewer visitors during the switch means fewer people affected if any unexpected issue does surface, and less load while you verify the live site.

So the ideal timing is: both conditions met, and then the update made during a low-traffic window. The low-traffic timing is a best-practice refinement rather than a hard requirement — a properly tested cutover with a lowered TTL should be smooth at any time — but it is a sensible extra precaution, especially for a busier or more critical site. Choosing a quiet moment to pull the DNS trigger gives your cutover the calmest possible conditions to happen in.

The TTL preparation days earlier

One of the two conditions — the lowered TTL — is unique in that it must be done days before the DNS update itself, which affects your migration timeline. TTL controls how long DNS caches hold your records, and lowering it only takes effect once the old, higher TTL has expired from caches, which itself takes as long as the old TTL. So to have a genuinely low TTL in force at cutover, you must lower it a day or two ahead.

This means the DNS-timing plan actually starts before the visible migration work: you lower your TTL first (say, to 300 seconds), then wait a day or two for that low value to propagate and take hold, and only then does your eventual DNS update propagate quickly. If you skip this and lower the TTL at the same time as the cutover, the low value has not taken effect yet, so the cutover still propagates at the old, high TTL — slowly.

So the TTL preparation is a ‘do it early’ task that sits at the very start of your DNS timeline, days before the update. Plan backward from your intended cutover: lower the TTL a day or two before you plan to switch, so that when both conditions are met and you make the DNS update, it propagates in minutes. This early step is easy to forget and, if skipped, undermines the fast, clean switch you were aiming for — so bake the TTL-lowering into your schedule well ahead of the cutover itself.

The period right after the update

Timing does not end when you make the DNS update — the period right after it is part of getting the timing right, because propagation means the switch unfolds over the following minutes to hours, not instantly. Immediately after updating DNS, propagation begins, and you enter the transition window where visitors gradually move to the new host as caches refresh.

During this window, your job is to keep the old host running (so visitors not yet switched still hit a working site), monitor propagation (checking that your domain is resolving to the new host from various locations), verify the live site as it takes traffic, and re-test the DNS-dependent things — especially email — that could only be fully confirmed once the DNS change took effect. This is active monitoring, not a moment to walk away.

So the timing plan includes staying attentive through the post-update propagation window, not treating the DNS change as the finish line. Only once propagation is complete (your domain resolves to the new host globally) and you have verified everything works on the live site do you reach the true end — at which point, with appropriate margin, you can retire the old host. So the full arc of DNS timing is: lower TTL days early, meet both conditions, update during a quiet window, then monitor through propagation to completion. Get that whole timeline right and the DNS update is the smooth, controlled pivot it should be.

FAQs

When should I update DNS during a migration?

Only after two conditions are both met: the migrated site is fully tested and working on the new host (verified via a private preview), and your DNS TTL is already lowered (done a day or two earlier so the change propagates fast). The DNS update sits near the end of the migration sequence — after copying, configuring, and testing the site — and should be made from a position of tested confidence, ideally during a low-traffic window.

Why is updating DNS too early a mistake?

Because it sends live visitors to a site that isn’t ready, turning problems you should have caught privately (missing images, a connection error, broken checkout) into a public incident. And since DNS has propagated, you can’t undo quickly — reverting also takes time to propagate. Updating DNS feels like ‘finishing,’ but doing it before the site is verified inverts the safe order. Almost every failed migration is really a too-early DNS update.

What must be true before I change DNS?

Two things: (1) the new site is fully tested and confirmed working on the new host, so the switch sends visitors to a working site; and (2) your TTL is already lowered (from a day or two earlier), so the change propagates quickly. You also need a plan to preserve your email MX records through the change. Both conditions, not either — testing without a low TTL means a slow switch; a low TTL without testing means a fast switch to a broken site.

When should I lower my DNS TTL for a migration?

A day or two before the DNS update, not at the same time. Lowering the TTL only takes effect once the old, higher TTL expires from caches, which takes as long as the old TTL. So lower it early (to a short value like 300 seconds) and wait for it to take hold, so that your eventual cutover propagates in minutes. Lowering it at cutover time means the switch still propagates at the old, slow TTL.

Is there an ideal time of day to update DNS?

A low-traffic window for your site is ideal — often the middle of the night for your main audience’s time zone. Since propagation creates a transition period, doing it when few visitors are around minimises how many experience the switch and gives you a quieter environment to monitor. It’s a best-practice refinement, not a hard requirement — a well-tested cutover with a lowered TTL should be smooth at any time.

What should I do right after updating DNS?

Stay attentive through propagation — it unfolds over minutes to hours, not instantly. Keep the old host running so unswitched visitors still hit a working site, monitor that your domain is resolving to the new host from various locations, verify the live site as it takes traffic, and re-test DNS-dependent things like email. Only once propagation is complete and everything’s verified do you retire the old host, with some margin.

The bottom line

Timing the DNS update correctly is one of the most consequential decisions in a migration, because the DNS update is the cutover — the single action that changes the migration from a private preparation into a public switch — and it sits deliberately near the end of the sequence, after the site is copied, configured, and tested, and before the verify-and-retire phase. Its timing is dictated by two non-negotiable conditions that must both be true before you touch DNS: the migrated site must be fully tested and confirmed working on the new host (so the switch sends visitors to a working site), and your DNS TTL must already be lowered from a day or two earlier (so the change propagates fast). Testing without a lowered TTL gives a working site but a slow switch; a lowered TTL without testing gives a fast switch to a broken site — you need both.

The classic, damaging mistake is updating DNS too early, before the site is verified, which turns catchable private problems into a public incident you cannot quickly undo — so the discipline is to resist the urge to ‘finish’ by changing DNS until the new site is genuinely ready. Two further refinements complete the timing: the TTL-lowering is a ‘do it days early’ task that must sit at the very start of your DNS timeline (since a lowered TTL only takes effect after the old one expires from caches), so plan backward from your intended cutover; and the update itself is best made during a low-traffic window, a sensible precaution that minimises how many visitors experience the transition. Finally, timing does not end at the update — you stay attentive through the propagation window, keeping the old host alive and verifying the live site (email especially) until propagation completes. Lower the TTL days early, meet both conditions, switch during a quiet window, and monitor to completion: that whole timeline is what makes the DNS update the smooth, controlled pivot it should be.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. Update DNS only when two conditions are both met: the migrated site is fully tested and working, and your TTL is already lowered (from a day or two earlier, so it propagates fast). The DNS update is the cutover — near the end of the sequence, from tested confidence, ideally in a low-traffic window. Updating too early sends visitors to a broken site you can’t quickly undo. After the change, keep the old host alive and monitor through propagation before retiring it.