Why do DNS moves cause downtime (and why don't they have to)?
Downtime during a DNS move almost never comes from DNS being 'slow to propagate.' It comes from the new provider serving an incomplete zone. When you change your nameservers, the internet gradually stops asking the old provider and starts asking the new one. If the new provider is missing your mail record, or has the wrong IP for your website, then every resolver that switches over gets a broken answer — and you can't un-ring that bell instantly because of caching.
The fix is conceptual, not technical: treat nameserver cutover as the last step, not the first. If the new zone is a perfect copy of the old one before you switch, then it does not matter whether a given resolver is still on the old provider or has already moved to the new one. Both return the same records, so the transition is invisible. Everything else in this guide exists to make that 'perfect copy' real and to verify it before you commit.
Step 1: Lower your TTLs before you do anything else
TTL (time to live) tells resolvers how long to cache a record before asking again. If your records have a 24-hour TTL, a change can take up to a day to be seen everywhere. Before a migration, lower the TTL on your important records — the root A/AAAA record, www, and MX records — to something short like 300 seconds (5 minutes). Do this in your current provider, and do it at least one full old-TTL period before the cutover so the short value has time to circulate.
This step does not speed up the nameserver change itself, but it shrinks the blast radius if you need to correct a record mid-migration. With a 5-minute TTL, a mistake is a 5-minute problem instead of a day-long one. After the migration is confirmed stable, raise the TTLs back to normal values (often an hour or more) so you're not generating unnecessary lookup traffic.
Step 2: Export and recreate every record at the new provider
Get a complete list of your current zone. Many providers can export a zone file; if not, use a lookup tool to enumerate your records, and cross-check against what actually exists. You are looking for the following record types, and any subdomains that point at third-party services:
- A and AAAA records — the addresses your website and hosts resolve to
- CNAMEs — including mail-subdomain aliases that are easy to overlook
- MX records — your mail servers, copied with matching priority
- TXT records — SPF, DKIM, DMARC, and domain-verification strings for services like Google, Microsoft 365, or SaaS tools
- SRV records — service location records
- CAA records — which certificate authorities can issue for your domain
Recreate all of them at the new provider, matching type, host, value, and priority exactly. This is where discipline matters: a single missing TXT record can break email deliverability or invalidate a service verification without any obvious symptom on your website. Do not add or 'clean up' records during the copy — reproduce the zone faithfully first, verify it, and make improvements as a separate change later.
Step 3: How do you verify the two zones answer identically?
Before changing nameservers, query the new provider's nameservers directly and compare their answers to the old provider's. Most DNS tools let you specify which nameserver to ask. Ask both the old and new servers for each critical record and confirm they return the same values. Command-line users can do this with dig by targeting a specific server; anyone else can use a web-based DNS lookup that lets you choose the nameserver.
Confirm parity on at minimum: the apex record, www, MX and its associated SPF/DKIM/DMARC TXT records, and any subdomains hosting live services. If everything matches, you have proven that a resolver moving to the new provider will get correct answers. If anything differs, fix it now — while nobody is being sent to the new zone yet.
Step 4: Change nameservers and watch propagation
Update the nameservers at your domain registrar to point to the new provider. This is the single action that actually moves traffic. Because both zones are identical, resolvers switching over during propagation get correct answers either way, so there is no downtime window. Propagation typically completes for most users within a few hours and fully within 24–48 hours, bounded by the TTL of the nameserver (NS) records at the registry, which you do not control.
During this period, keep the old zone intact and unchanged. Some resolvers are still using it, and you want them to keep getting correct answers until they migrate. Monitor from multiple locations — a global DNS propagation checker is useful here — and confirm the new nameservers are being returned worldwide before you consider the move complete.
Step 5: Decommission the old zone (only after full propagation)
Wait until propagation is complete everywhere and the domain has been stable on the new provider for at least a full day before you delete or cancel the old DNS zone. There is no rush, and removing the old zone early is a common way to cause an outage for the last stragglers still resolving against it. Once you're confident, you can raise TTLs back to production values and, if you were paying for the old DNS service separately, cancel it.