How a Site Moves Without Downtime (DNS, TTL and Your Email)

Every migration page on this site promises no downtime, including ours. It is worth explaining what that actually means, because the mechanism is genuinely simple and knowing it tells you which parts of a cutover are risky and which are theatre.

Both sites exist at the same time#

The thing that makes zero downtime possible: your new site is fully built and running before anything changes for visitors.

It lives at a temporary address, a staging URL or a host-provided one, while your old site continues serving customers at your domain. Nothing about the old site is touched during the build. You could abandon the whole project on day six and no visitor would ever know it happened.

Cutover does not move the site. It changes which of the two your domain points at.

What a DNS record actually does#

Your domain name does not host anything. It is a lookup entry that says "portmysite.com is at this address", and browsers resolve that entry before fetching a page.

Changing where your site lives means editing that entry to point at the new server. The site itself does not travel anywhere.

Because the change is a lookup rather than a move, there is a window where different visitors get different answers. One person's resolver still has the old address cached and reaches the old site. Another's has refreshed and reaches the new one. Both sites are live and both work, which is why nobody sees an error, and why a store can keep taking orders throughout. It is also why you want the old site left running rather than switched off.

Propagation is mostly a myth#

"DNS propagation takes 24 to 48 hours" is the most repeated and least accurate sentence in this whole subject.

Nothing propagates. There is no global broadcast being waited on. Each resolver independently caches your record for as long as its TTL says, then asks again. The 24 to 48 hour figure is just the worst case for a record with a long TTL and an unlucky cache.

In practice, with TTLs lowered beforehand, most of the internet sees the change within minutes.

TTL is the number that actually matters#

TTL is seconds. A TTL of 3600 means a resolver may serve a stale answer for an hour after you change it.

The move is: lower the TTL to about 300 a day or two before cutover, make the change, then raise it back afterwards. The reason this matters is not speed for its own sake. It is rollback.

If something is wrong in the first ten minutes, reverting is another DNS change, and it is subject to exactly the same cache. With a 3600 TTL you have committed to an hour of a broken site. With 300 you have committed to five minutes. That is the whole argument, and it is why a plan that lowers TTLs the day before is a sign someone has done this properly.

Your email is a different record#

This is the fear worth killing directly, because it is common and it is misplaced.

Your email does not live at your website. Mail delivery is governed by MX records, and authentication by TXT records holding SPF, DKIM and DMARC. Those point at your mail provider, which is usually a completely different company from your web host.

Pointing your website at a new server does not touch any of them. Web and mail are separate rows in the same table.

Email breaks during migrations for one main reason: somebody moves DNS management to a new provider and rebuilds the zone from scratch, recreating the web records and forgetting the mail ones. The site works, and mail silently stops. The fix is not to be clever, it is to inventory the existing records before touching anything and confirm every non-web row survives.

If your email is bundled with your current site host, that is the one case where it does need planning, and it should be flagged in the audit rather than discovered at cutover.

Choosing the hour#

Search engines do not care what time you cut over. Your customers do, and the first 48 hours are when mechanical faults surface.

Pick the genuinely quiet hour from your own analytics rather than assuming nights: a restaurant's is mid-afternoon, a B2B site's is overnight. And avoid Friday, so a broken form is not discovered by customers over a weekend when nobody is looking. When to migrate covers the wider timing question, including which month.

The first hour after#

Three checks, in order:

1. Spot-check your top URLs. Each should return a single 301 to a working page, not a chain and not a 404. Use the Search Console export, sorted by clicks.
2. Check nothing is blocking crawlers. robots.txt allowing crawling, and no stray noindex left over from staging. This is the mistake that collapses traffic rather than denting it.
3. Submit the new sitemap.

Then leave the old subscription running for a fortnight. It is cheap insurance and it is the only thing you would roll back to. Before you cancel covers what to retrieve first.

The short version#

Both sites are live during the changeover, so there is no gap for a visitor to fall into. Propagation is cache expiry, not a broadcast, and TTL is the dial that controls it. Your email is a separate record and stays untouched unless somebody rebuilds the zone. Cut over at a genuinely quiet hour, never on a Friday, and keep the old site alive until the new one is verified.

For where the cutover sits in the wider schedule, the migration timeline puts it in context: it is the shortest phase on the chart, and the one everyone pictures when they imagine the risk.