A DNS Migration Checklist That Survives Contact With Reality

Moving a domain's DNS from one provider to another is one of those tasks that looks trivial right up until it isn't. You copy some records, change a setting at the registrar, and wait. Then a week later someone notices their mail stopped, or that a certificate failed to renew, and the migration becomes a post-mortem.

The difference between a routine migration and a memorable one is almost never skill. It is preparation. Here is the checklist I use, ordered the way the work actually happens, with the parts people forget called out where they belong.

Decide what you are actually migrating

"Migrations" get conflated, and that conflation causes outages. There are at least three separate things you might be moving:

• The web hosting, which changes A and AAAA records but leaves delegation alone.
• The DNS provider, which changes the nameservers at the registrar and touches nothing else directly.
• The mail provider, which changes MX and a handful of TXT records.

Each has its own failure mode and its own timeline. Changing hosting while you think you are changing DNS, or vice versa, is the source of the single most common migration disaster: editing records at a provider that is no longer authoritative. Before anything else, write down which of the three you are doing.

Inventory before you touch anything

You cannot safely reproduce a zone you have not read. Start by exporting the current one, from the authoritative source rather than from memory or from a screenshot someone took last year.

What you want is every record, including the boring ones: MX with their priorities, all TXT records, CAA, SRV, the verification strings for services like search consoles, and anything that looks like it was added for a reason nobody remembers. The forgotten records are exactly the ones that break silently weeks later. Try it on DNS Checkers Lookup All DNS Records

One practical trick: save the export as a file and diff it against the new provider's zone when you are done. A text diff catches typos that eyeballing does not.

Check the SOA timers while you are in there

While you have the zone open, note the TTLs and the SOA record. The TTLs tell you how long the cutover will take; the SOA minimum tells you how long negative answers — "this name does not exist" — are cached.

If the current TTLs are very long, your migration window is long too. Plan the calendar around that number, not around optimism.

Lower TTLs early, and mean it

Once you know the TTLs, lower them on the records that will change, at the current provider, before the migration. Then wait out the previous TTL in full.

This step is the one people skip because it adds a day of doing nothing. Skipping it means old answers keep being served from caches throughout your change, which is precisely the situation lower TTLs exist to prevent. Lower, wait, then move. Try it on DNS Checkers Check DNS Propagation

Populate the new provider completely

Build the entire zone at the new provider before you delegate anything. Every record, not just the ones you think matter. This is your chance to fix small mistakes, so also resist the urge to "improve" things mid-migration — a migration is not the time to refactor your mail setup.

Copy verification TXT records exactly. A search console entry with one transposed character will quietly unverify your property, and you will not find out until you next need it.

Verify before you delegate

This is the step that separates a good migration from a hopeful one. Before the rest of the internet can reach your new zone, you can query it directly. Ask the new nameservers for every important record and compare the answers against the old zone, field by field.

Do the comparison as data, not as a glance. Query the apex, www, each MX, every TXT, the CAA set, and anything with a non-standard TTL. If something differs, fix it now, while the old zone is still live and nobody is affected. Try it on DNS Checkers Domain Health Check

Change delegation at the registrar

Only now do you touch the registrar. Updating the nameservers is the moment your new zone becomes real, and it is the riskiest single action in the whole process. Most registrars publish the new delegation quickly, but some TLDs and registries are slower, and parent-side caching can add delay on top.

Because of that, do this step on a weekday, during hours when you can watch it, and not at the start of a holiday. Announce it to whoever needs to know.

Watch it settle

After delegation, monitor rather than assume. Query a spread of independent resolvers and watch the answers converge on the new zone. Different resolvers will flip at different times, and that is normal — it is the cache chain working as designed, not a sign that something failed.

Keep the old provider configured and reachable during this period. Do not delete anything yet. If the new zone has a problem you missed, you want the option to point back while you fix it.

The records everyone forgets

These are the ones that turn up in post-mortems. Check each one deliberately.

• CAA. If the old provider had CAA records and you did not copy them, or copied them without every CA you use, certificate renewals fail — often weeks later, when nobody connects the failure to the migration.
• DMARC reporting. The rua address should still work after the move. If it pointed at a mailbox on the old provider, your reports go nowhere.
• SPF includes. If the migration changed sending infrastructure, the SPF record needs the same change, or authentication breaks.
• Subdomain delegations. Zones often contain NS records delegating a subdomain to yet another provider. Miss those and an entire service disappears.
• Verification and webhook TXT records. Search consoles, payment providers, and monitoring services all like to prove ownership with a TXT record and to fail quietly when it vanishes.
• Wildcards. Easy to overlook in a manual copy, and their absence is not obvious until someone hits a subdomain that used to work.

Decommission deliberately

Wait at least a week — longer if TTLs were long — before cancelling the old service. Then do a final comparison: pull the old zone one more time and diff it against the new one. If they match, and nothing has broken, you are done.

Renewing the old provider for one overlapping billing cycle is cheap insurance. Cancelling it the same afternoon is how a small problem becomes an emergency with no way back.

Tell people, and write the plan down

A migration that exists only in one engineer's head is a migration that will surprise someone. Before the window opens, write a short plan and share it: what is changing, when, what the expected brief blip looks like, and who to contact if something seems wrong.

The document does not need to be elaborate. It needs to answer the three questions everyone will ask. "Are we doing something to email?" "Will the site go down?" and "Who do I tell if it breaks?" Answer those up front and you will spend far less time reassuring people later.

Also name a second pair of eyes. Re-reading a zone export is exactly the kind of task where a second person catches a transposed digit that the original author's eyes glide right over. If nobody else is available, read it aloud — it sounds ridiculous, and it works.

If something breaks: the rollback plan

Decide your rollback trigger before you start, not in the middle of an incident. "If more than a handful of error reports arrive, or if mail stops flowing, we point the registrar back to the old nameservers" is a plan. "We'll figure it out if it happens" is a hope.

The rollback itself is usually fast, because you kept the old zone intact: change the nameservers back at the registrar and wait for the caches. The reason this works is exactly why you did not cancel the old provider. The cost of an unused month of DNS is trivial next to the cost of an outage you cannot reverse.

Two cautions. First, going back is itself a DNS change with its own propagation delay, so the fix is not instant — lower the TTLs at the old provider too if you have the chance. Second, be careful not to roll back half of a change. If mail moved but web did not, reversing only the web records can leave you in a stranger state than either the old or the new configuration. Roll back the whole delegation, or fix forward, but do not straddle the two.

Decide in advance which of those you would rather do. For most teams, rollback is safer, because it returns you to a known-good state where you can investigate calmly instead of under pressure.

The short version

Inventory the zone, lower TTLs early, build the new zone completely, verify it directly before delegating, change nameservers during watchable hours, monitor the settle, and only then turn off the old provider.

Every one of those steps is unglamorous, and together they make migrations dull. Dull is the goal. Nobody remembers a DNS migration that went exactly as planned, and that is the highest compliment this work can receive.