DNS Migration Checklist: Moving Providers Without Downtime

DNS migrations go wrong in predictable, avoidable ways — almost always because a step was skipped, not because the destination provider did anything wrong. Here's a checklist that avoids the common failure modes.

Before you touch anything: audit the current state

You can't migrate what you haven't inventoried. Before making any change:

1. Export every record from the current provider — not just A/CNAME/MX, but TXT (SPF, DKIM, domain verification strings for third-party services), CAA, SRV, and anything else present. A missed TXT record is the single most common migration breakage, because it's invisible until the service that depends on it (email deliverability, a verified integration) silently stops working.
2. Run a full scan of the domain and save the results as a reference — DNSDecode's DNS Records table shows every record type in one place, which is a faster cross-check than hunting through a provider's dashboard export.
3. Note current TTLs, especially for MX and A records at the apex.

Lower TTLs in advance

Do this at least 24-48 hours before the actual cutover, on the current provider. Set critical record TTLs (A, AAAA, MX) down to something short, like 300 seconds. This is the single highest-leverage step for a low-downtime migration — see our DNS propagation guide for why this works. Skipping this step is what turns a clean cutover into a multi-hour window of inconsistent answers.

Build the new zone before switching

Recreate every record at the new provider first, while the old provider is still live and authoritative. Don't change nameservers yet. Once built:

• Double-check MX priority values match exactly — a typo'd priority can silently misroute mail.
• Verify SPF, DKIM, and DMARC TXT records are copied exactly, character for character — a single dropped character in an SPF record breaks the whole mechanism.
• Confirm CAA records (if present) still permit your actual certificate authority, or certificate issuance/renewal will start failing after the switch.

Verify the new zone independently before cutover

Most providers let you query their nameservers directly even before delegation changes. Do that, and separately, run a scan against the new configuration if your tooling supports pointing at specific nameservers. Confirm every record matches what you intended before the domain depends on it.

Change nameservers, then watch closely

Once you switch the domain's NS records at the registrar, monitor propagation actively for the following hours — check DNS propagation across multiple public resolvers to see how the change is spreading, and re-run a full scan periodically to confirm DNSSEC (if enabled), SSL, and email all remain healthy as the new provider takes over as authoritative.

After cutover: don't delete the old zone immediately

Keep the old provider's zone intact and unchanged for at least a week after cutover, even though it's no longer authoritative. If something was missed, this gives you a clean reference to diff against rather than trying to remember what the old configuration was.

The one-line version

Audit everything → lower TTLs early → build the new zone fully before switching → verify independently → switch → monitor propagation actively → keep the old zone as a reference for a week. Most migration incidents come from skipping the TTL step or missing a TXT record — both are avoidable with a checklist, not luck.