The cutover is the moment of a migration everyone fears — the flip of the switch that sends your visitors from the old host to the new one. But done right, it is actually the least dramatic step, because all the risky work happened before it. The cutover is a DNS change, DNS changes propagate gradually, and if you have prepared properly, that gradual switch happens with no visitor ever meeting a broken or missing site. This cornerstone guide shows you exactly how to run a zero-downtime DNS cutover.

You will learn what the DNS cutover actually is, the preparation that makes it safe (testing and TTL), the two ways to switch (nameservers versus A record), how propagation works and why you keep the old host alive, the step-by-step of the cutover itself, and how to confirm it completed. By the end you will be able to switch hosts at the DNS level with confidence and no downtime.

What the DNS cutover is

The DNS cutover is the step where you point your domain at the new host instead of the old one, by changing your domain’s DNS. Until this moment, your domain still resolves to the old host, so the public sees the old site even though your migrated copy is ready and waiting on the new host. The cutover is the deliberate flip that redirects traffic to the new server.

It works through DNS — the system that translates your domain name into the server address browsers connect to. Your domain’s DNS currently says ‘this domain lives at the old host’s address’; the cutover changes it to say ‘this domain lives at the new host’s address.’ Once that change propagates, browsers looking up your domain are sent to the new host, and visitors see the migrated site.

So the cutover is fundamentally a DNS change — updating the record that maps your domain to a server so it points to the new host. This is why it feels momentous (it is the switch that makes the new site live) yet is technically simple (it is editing a DNS setting). The art is not in the change itself but in the preparation and sequencing around it that make the switch happen without downtime, which is what the rest of this guide covers.

The preparation that makes it safe

A safe cutover depends almost entirely on two things you do before you touch DNS. The first is testing: your migrated site must be fully verified working on the new host before you cut over, so that when the switch sends visitors there, they meet a confirmed-working site, not a broken one. Because your domain still points to the old host, you test privately first (via a hosts-file preview), fixing any problems with zero public impact.

The second is lowering your DNS TTL a day or two in advance. TTL (time to live) controls how long DNS records are cached around the internet, and it governs how fast your cutover will propagate. By lowering it ahead of time (to a short value like 300 seconds), you ensure that when you make the switch, caches refresh quickly and visitors move to the new host in minutes rather than hours, shrinking the transition window dramatically.

So the two preparations — test the new site fully, and lower the TTL a day or two before — are what make the cutover safe and fast. Testing guarantees the destination works; the lowered TTL guarantees a quick, clean switch. With both done, the cutover itself becomes almost anticlimactic: you are simply flipping a pointer to a site you know works, and the flip reaches everyone quickly. Skipping either preparation is what turns a smooth cutover into a risky one.

Two ways to switch: nameservers or A record

There are two ways to point your domain at the new host, and knowing which you are using matters:

• Change the nameservers: point your domain to the new host’s nameservers, handing all DNS management to the new host. This moves your whole DNS (website and, unless you’re careful, potentially email records) to the new host at once — the common approach when the new host will manage everything.
• Change the A record: keep your current DNS management but update just the A record (the record mapping your domain to a server IP) to the new host’s server IP. This switches only where the website points, leaving other DNS records (like email MX records) untouched.
• Which to use: the A-record method is more surgical (it moves only the website); the nameserver method is simpler but moves all DNS, so you must recreate other records (especially email) on the new host to avoid breaking them.
• Mind your email: whichever you use, ensure your email’s MX records end up correct on the new DNS, or mail will break.

The crucial caution with both methods is email: changing nameservers moves all your DNS to the new host, so if your email records are not recreated there, mail breaks — whereas changing only the A record leaves email untouched. So if the new host will manage all your DNS, use nameservers but recreate your email MX records there; if you want to move only the website and leave email exactly as it is, the A-record change is cleaner. Knowing which you are doing prevents the classic ‘website moved fine but email died’ mistake.

How propagation works and keeping the old host alive

When you make the DNS change, it does not take effect for everyone instantly — it propagates. DNS records are cached all over the internet (by ISPs, resolvers, and devices), and each cache holds the old record until its TTL expires, after which it fetches the new one. So different visitors switch from the old host to the new one at different times, over a window that ranges from minutes (with a lowered TTL) to, occasionally, up to 48 hours.

During this propagation window, some visitors reach the new host and some still reach the old one — which is precisely why you keep the old host fully running throughout. If you cut over and immediately take down or cancel the old host, the visitors whose caches still point there hit a dead site: downtime, caused entirely by retiring the old host too soon. Keeping both alive during propagation is what guarantees everyone reaches a working site.

So propagation is a gradual, unavoidable transition, and the rule that makes it zero-downtime is simple: keep the old host running until propagation is complete and everyone is reaching the new site. Because you tested the new site first, both old and new are working during the window, so whichever a visitor hits, they get a functioning site. Patience here — not retiring the old host until you are certain the switch is complete — is the final safeguard of a no-downtime cutover.

The cutover step by step

Putting it together, here is the cutover sequence. Beforehand (a day or two): lower your DNS TTL, and fully test the migrated site on the new host privately, confirming it works. Also make sure you know your email’s MX records so you can preserve them. These preparations are what make the actual cutover safe.

At cutover: make the DNS change — either update your domain’s nameservers to the new host’s (and recreate your email MX records there), or update the A record to the new host’s server IP (leaving email untouched). This is the single action that begins the switch. The moment you save it, propagation starts, and visitors begin moving to the new host as caches refresh.

After cutover: keep the old host fully running, and monitor propagation as visitors switch over. Verify the live site works as it reaches the new host, confirm email still flows, and watch for any issues. Do not cancel or change the old host yet. Once propagation is complete and you have confirmed everyone is reaching the working new site — typically after the TTL window and a bit of margin — the cutover is done, and you can eventually retire the old host. Prepare, switch, keep the old alive, verify: that sequence is a zero-downtime cutover.

Confirming the cutover completed

You need to know when propagation is complete, so you can confirm the migration succeeded and eventually retire the old host safely. The most reliable signal is that your domain consistently resolves to the new host’s address from multiple locations — you can check this with online DNS-propagation checkers that query your domain from servers around the world and show whether they all now return the new host’s IP.

When those checkers show your domain resolving to the new host everywhere (or nearly everywhere), propagation is essentially complete, and the vast majority of visitors are reaching the new site. Combined with confirming the live site works correctly and email flows, this tells you the cutover has succeeded and the transition is effectively over. With a lowered TTL, this can be reached within minutes to a couple of hours; without one, it may take up to a day or two.

So confirm completion by checking that your domain resolves to the new host globally (via propagation checkers), that the live site works, and that email flows — and only then, with a little margin for any lagging caches, retire the old host. This confirmation is the true end of the cutover: not the moment you made the DNS change, but the moment you have verified that change has reached everyone and the new site is serving all your visitors. Reaching it means your zero-downtime host switch is complete and safe to finalise.

FAQs

What is a DNS cutover?

It’s the step where you point your domain at the new host instead of the old one by changing your domain’s DNS — either updating the nameservers to the new host’s or changing the A record to the new host’s server IP. Until the cutover, your domain still resolves to the old host; the cutover flips it so, once propagated, visitors reach the migrated site on the new host.

How do I switch hosts without downtime?

Prepare first: fully test the migrated site on the new host privately, and lower your DNS TTL a day or two ahead. Then make the DNS change (nameservers or A record), and keep the old host fully running throughout propagation so visitors always hit a working site — the new one if they’ve switched, the old one if they haven’t. Verify propagation completes, then retire the old host. Testing plus a lowered TTL plus keeping the old host alive is the whole recipe.

Should I change nameservers or the A record?

Changing nameservers hands all DNS to the new host (simpler, but you must recreate other records there — especially email MX, or mail breaks). Changing only the A record is more surgical — it moves just the website and leaves email and other DNS untouched. Use nameservers if the new host will manage everything (and recreate email records); use the A record to move only the website. Either way, ensure email MX records end up correct.

Why do I keep the old host running after cutover?

Because DNS propagation isn’t instant — for a window after the change (minutes with a lowered TTL, up to 48 hours without), some visitors’ caches still point to the old host. If you take it down immediately, those visitors hit a dead site — downtime caused by retiring the old host too soon. Keeping it alive through propagation means everyone reaches a working site throughout the switch.

How long does DNS propagation take during a cutover?

From minutes (if you lowered your TTL a day or two beforehand, so caches refresh quickly) to occasionally up to 48 hours (with a high TTL and slow-refreshing caches). The TTL of your records is the main factor, which is why lowering it in advance is the key preparation for a fast, clean cutover. You keep the old host running until propagation is confirmed complete.

How do I know the cutover is complete?

Check that your domain resolves to the new host’s address globally using online DNS-propagation checkers (which query your domain from servers worldwide) — when they nearly all show the new host’s IP, propagation is essentially done. Combined with confirming the live site works and email flows, that tells you the cutover succeeded. Then, with a little margin for lagging caches, you can safely retire the old host.

The bottom line

The DNS cutover is the moment a migration feels most dramatic and is actually least dangerous, because all the real risk was handled before it. It is simply a DNS change — updating the record that maps your domain to a server so it points to the new host instead of the old — and its safety comes entirely from two preparations done in advance: fully testing the migrated site on the new host (via a private hosts-file preview) so the switch sends visitors to a confirmed-working site, and lowering your DNS TTL a day or two ahead so the change propagates in minutes rather than hours. With those done, the cutover is anticlimactic: you flip a pointer to a site you know works, and it reaches everyone quickly.

The switch itself is either a nameserver change (handing all DNS to the new host — simpler, but you must recreate your email MX records there or mail breaks) or a more surgical A-record change (moving only the website and leaving email untouched), so mind your email whichever you choose to avoid the classic ‘site moved fine but email died’ mistake. Then, because DNS propagates gradually — with some visitors reaching the new host and some still on the old during the window — you keep the old host fully running until propagation is complete, guaranteeing everyone hits a working site throughout. Confirm completion by checking your domain resolves to the new host globally (via propagation checkers), that the live site works, and that email flows, and only then, with a little margin, retire the old host. Prepare, switch, keep the old alive, verify: that sequence turns the scariest-sounding step of a migration into a calm, zero-downtime host switch.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A DNS cutover points your domain at the new host by changing DNS — nameservers (hands over all DNS; recreate email MX there) or the A record (moves only the website; leaves email untouched). Make it safe by testing the new site first and lowering TTL a day or two ahead. It propagates gradually (minutes to 48 hours), so keep the old host alive throughout, verify the domain resolves to the new host globally and email flows, then retire the old host.