DNS TTL and zero downtime cutover when you move host

Moving a site to a new host means pointing its domain at a new IP address. Done carelessly, that switch drops visitors and bots onto a server that is not ready, or splits traffic between the old and new box for hours. Done properly, nobody notices at all. The single most useful lever you have is DNS TTL, and if you run a network of sites on dedicated Class C IPs, getting the cutover clean matters even more because a botched move can look like a footprint problem when it is really just stale caching.

This guide explains what TTL actually controls, how to plan a cutover so there is effectively zero downtime, and the extra care that multi-site and PBN operators should take when many domains move at once.

What TTL really controls

TTL (Time To Live) is a number of seconds attached to every DNS record. It tells resolvers and caches how long they may keep a cached answer before they must ask again. If your A record has a TTL of 3600, a resolver that looks up your domain can reuse that answer for one hour before checking for a fresh value. The TTL does not make a change happen faster or slower; it sets the maximum time a cached old answer can linger after you publish a new one. The formal definitions of these terms live in the IETF DNS terminology document, RFC 9499.

Two things follow from this. First, a high TTL is good for stability and cache efficiency during normal operation. Second, a high TTL is your enemy on migration day, because old resolvers keep sending users to the old IP long after you have flipped the record. The trick is to lower the TTL in advance, migrate, confirm, then raise it back.

The core sequence for a zero downtime cutover

The whole method rests on one idea: never point traffic at a server that is not already serving the correct site. You copy first, verify on the new IP, then flip DNS, and only then decommission the old box. TTL timing wraps around that so the flip propagates quickly.

1. Lower the TTL well in advance. At least one full old-TTL period before the move, drop the A record (and AAAA if you use IPv6) TTL to something short such as 300 seconds. You must do this early, because the change itself is only picked up at the speed of the previous TTL. If the record sat at 86400, resolvers may cling to that day-long value for up to a day after you lower it.
2. Copy the site and data to the new server. Move files, databases, email if applicable, and cron jobs. Keep the old site live and untouched during this step.
3. Verify on the new IP before any DNS change. Test the new server directly by its IP, or with a local hosts file entry, so you load the exact new box. Check the homepage, a few deep pages, forms, HTTPS, and redirects. Nothing should point at the new IP publicly until this passes.
4. Flip the DNS record. Change the A record to the new IP. With a 300 second TTL, most resolvers will be serving the new address within five to ten minutes, and stragglers clear soon after.
5. Keep the old server running. Leave it live for at least 24 to 48 hours. Some resolvers ignore short TTLs, and some users have long-lived caches. As long as both servers serve the same site, a visitor on either IP has a correct experience.
6. Raise the TTL back up. Once traffic has clearly moved and logs on the old box have gone quiet, restore a normal TTL such as 3600 or higher for efficiency and stability.

Why both servers serving the same content is the real safety net

The reason a careful cutover has zero downtime is not clever timing alone. It is that during the overlap window, the old IP and the new IP both return the same working site. TTL determines how long that overlap needs to last, but the overlap itself is what prevents a single dropped request. This is why you never delete the old account the moment DNS flips, and never point DNS at a half-migrated server. Treat the old server as a live fallback until you have proof it is idle.

Extra care for Class C IP networks and multi-site operators

If you run one site, the sequence above is all you need. If you run a network of sites, each on its own dedicated IP for reputation isolation, a few extra points matter. A dedicated IP is not a ranking boost in itself; its value is defensive, keeping your site off an address shared with spammers and giving you control over the network footprint. A messy migration can undermine both of those things.

• Migrate in waves, not all at once. Flipping fifty domains to fifty new IPs on the same afternoon concentrates risk and makes any single failure hard to isolate. Move a small batch, confirm it is healthy across a day, then continue.
• Keep IPs genuinely diverse on the new host. The point of moving to separate Class C ranges is footprint control. Confirm the new addresses are spread across distinct C blocks rather than sequential neighbours, which is the whole premise of multiple Class C IP hosting.
• Do not change URLs at the same time. A host move that keeps every URL identical is invisible to search. If you also restructure URLs, you have layered a site move on top of a host move and multiplied the ways it can go wrong. Keep them as separate projects. Google documents the difference between the two clearly in its site move guidance.
• Watch each site independently after cutover. Check server logs, uptime, and index coverage per domain. A single site that quietly returns errors from the new box can look, weeks later, like a reputation issue when it was only a broken migration.

Common mistakes that cause downtime

• Lowering the TTL and flipping DNS in the same hour. The short TTL has not propagated yet, so the old high value still governs how long caches hold on.
• Deleting or suspending the old account immediately after the flip. Any resolver still on the old IP now hits a dead server.
• Pointing DNS at the new IP before the site is fully copied and tested there.
• Forgetting records other than the A record, such as MX for mail, TXT for SPF and DKIM, or a CAA record, which can break email or certificate issuance even when the website itself moves cleanly.
• Relying on a single propagation check from one location. Test from several networks, because caches expire independently.

Where to go next

Planning a move is the right time to review the whole checklist, not just DNS. Our migrating to ASEOHosting hub walks through account setup, data transfer, and validation, and the DNS and IP management hub covers records, propagation, and reverse DNS in more depth. Handle the TTL first, verify on the new IP before you flip, keep the old server warm through the overlap, and a host move becomes a routine operation your visitors never see.