DNS migrations fail in boring ways that create expensive problems.
The homepage works, but www does not. Email reaches some employees and bounces for others. A forgotten TXT record knocks a sending service out of alignment. The old DNS provider gets canceled before caches expire. DNSSEC still points at the old signing keys, so validating resolvers return an error instead of your website.
None of those failures requires an exotic attack or a major engineering mistake. They happen when a team treats DNS like a list of website records instead of a routing layer for the whole business.
This runbook is for a nameserver change, DNS provider move, web host migration, email platform change, or any project that changes the authoritative answers for a live domain. It gives an owner, agency, or IT team one operating plan from inventory through rollback.
The short version: DNS migration checklist
Copy this table into your project ticket and assign a name to every row.
| Phase | Required action | Evidence to save |
|---|---|---|
| Scope | Define whether you are moving DNS hosting, web hosting, email, registrar, or more than one | Written change scope and named owner |
| Inventory | Export the active zone and find records that do not appear in the export | Zone file, screenshots, and discovery notes |
| Dependency map | Match every record to a service and business owner | Record-to-service worksheet |
| Access | Confirm registrar, old DNS, new DNS, hosting, and email access | Two working admin accounts where possible |
| TTL preparation | Lower TTLs before the change window | Before-and-after lookup output |
| New zone | Rebuild and compare the zone at the new provider | Record comparison with exceptions documented |
| Preflight | Query the new authoritative nameservers directly | Saved dig or provider test results |
| Cutover | Change only the approved delegation or records | Timestamp, operator, and exact change |
| Validation | Test web, email, certificates, third-party tools, and public resolvers | Test log from multiple networks |
| Monitoring | Watch uptime, forms, email, DNS errors, and support channels | Monitoring links and named responder |
| Rollback | Keep the old provider and old origin available | Tested rollback steps and decision deadline |
| Closeout | Raise TTLs, remove stale access, and archive the final zone | Final export and signed approval |
Do not use this as a memory aid during the cutover. Use it as a record of what was checked, by whom, and when. A checkbox without an owner is just optimism.
First, name the migration you are actually doing
Teams use “DNS migration” to describe several different jobs. Separate them before building the plan.
DNS host change: The authoritative nameservers move from one provider to another. The website and email services may stay where they are.
Web host change: A or AAAA records, CNAMEs, or an edge network configuration change so web traffic reaches a new origin. The nameservers may not change.
Email migration: MX records and usually SPF, DKIM, DMARC, autodiscover, and verification records change. The website may be untouched.
Registrar transfer: The company that manages the domain registration changes. A registrar transfer does not automatically require a DNS host change, and combining them adds avoidable failure points.
Domain or URL move: Visitors and search engines move to a different hostname or URL structure. This requires redirects and search migration work in addition to DNS. Google recommends permanent server-side redirects and warns against chaining multiple site moves together in its site move guidance.
Write one sentence that defines the job: “Move authoritative DNS from Provider A to Provider B while web hosting and Microsoft 365 remain unchanged.” That sentence stops people from slipping extra changes into the window.
Phase 1: Build an inventory you can trust
An exported zone is the starting point, not proof that you found everything.
Export records from the active DNS provider. Save the original file without editing it. If no export is available, collect records through the provider API or dashboard and capture screenshots of settings that may not appear as ordinary records, including redirects, proxy status, traffic policies, health checks, and provider-specific flattening.
Then query the live domain from outside the provider. Record the current answers for:
- Apex and
wwwA, AAAA, and CNAME records - MX, SPF, DKIM selectors, DMARC, and autodiscover
- CAA and DNSSEC state
- Common application subdomains such as portal, app, shop, status, api, vpn, and files
- Verification TXT records and delegated subdomains
- The zone’s SOA and authoritative nameservers
Do not delete a record because nobody recognizes it during discovery. Label it “owner unknown,” investigate it, and make an explicit keep-or-retire decision. Old-looking records can still support password resets, payment systems, call tracking, or a vendor API.
AWS recommends exporting existing record sets to create a rollback point before bulk DNS changes in its Route 53 migration guidance. Use the same principle even when you are moving between other providers.
Make a record-to-service map
For every record, document the hostname, type, value, TTL, purpose, service owner, technical contact, and whether downtime would stop sales or operations. This exposes dependencies that a raw zone file hides.
A CNAME called forms may look harmless until someone explains that every quote request depends on it. An MX record has an obvious purpose, but a DKIM TXT record can be just as important to email delivery. A _acme-challenge delegation may control automated certificate renewal.
Mark critical paths. For most small businesses, those are the main website, inbound email, outbound email authentication, forms, booking, checkout, customer login, VPN, and any API used during a sale.
Phase 2: Prepare the change window
The safest migration is mostly finished before anyone touches the registrar.
Lower TTLs early enough to matter
TTL tells a recursive resolver how long it may cache an answer. Lowering it five minutes before cutover does not clear answers already cached under the old, longer TTL.
Cloudflare recommends lowering critical-record TTLs at least 24 to 48 hours before a migration, or longer when the current maximum TTL requires it. Google also tells site owners to temporarily lower DNS TTL values before changing web hosting.
Use the longest relevant current TTL to set your lead time. If a critical record has a 86,400-second TTL, make the reduction at least a full day before cutover. A temporary TTL of 300 seconds is common for a controlled change, but check provider minimums and query volume before choosing it.
Remember negative caching. Resolvers can cache NXDOMAIN and NODATA responses under rules defined by RFC 2308. That means creating a brand-new hostname during the window can behave differently from changing an existing one. Create and test new names ahead of time when possible.
Rebuild the new zone without “cleaning it up”
Import or recreate the records at the new DNS provider. Preserve values and TTLs first. Cleanup belongs in a later change after the migration is stable.
Some providers do not represent records in exactly the same way. The root domain may use ALIAS, ANAME, CNAME flattening, or a provider-specific target. Proxying can change the public answer. Traffic policies and health checks may need to be rebuilt outside the basic zone import.
Compare old and new zones line by line. Document every intentional difference. If the new system automatically adds records, identify those too.
Handle DNSSEC as its own workstream
DNSSEC can turn a minor mismatch into a full resolution failure for users behind validating resolvers. Check whether a DS record exists at the parent and whether the old provider signs the zone.
Do not casually copy DNSKEY, RRSIG, NSEC, or NSEC3 records into the new zone. Signing keys and processes belong to the DNS operator. Follow the old provider, new provider, and registrar’s supported migration procedure.
Google Cloud’s documented process for migrating DNSSEC-enabled zones uses a transfer state and coordinated DS record changes. Your provider may use a different sequence. The key is coordination: confirm the new zone validates before removing old trust information, and do not leave the parent pointing to keys the active nameservers do not use.
If the team cannot explain the DNSSEC sequence and rollback in plain language, stop and get the DNS providers involved before cutover.
Phase 3: Run preflight tests
Public DNS will not use the new nameservers until delegation changes, but you can query the new authoritative servers directly.
For a domain such as example.com, test each new nameserver with commands like these:
dig @new-ns.example.net example.com A
dig @new-ns.example.net www.example.com CNAME
dig @new-ns.example.net example.com MX
dig @new-ns.example.net example.com TXT
dig @new-ns.example.net _dmarc.example.com TXT
dig @new-ns.example.net example.com CAATest every critical hostname, not just the apex. Confirm response codes, expected values, TTLs, and authoritative answers. Check both IPv4 and IPv6 when AAAA records exist.
AWS’s process for making Route 53 authoritative for a live domain requires teams to create the zone and verify records before changing nameservers, as described in its live-domain migration procedure. That sequence applies broadly: build, query, compare, then delegate.
Preflight also includes the destination services. Confirm the new web origin has the correct certificate and host configuration. Send test mail through the intended platform. Submit every important form and verify the message reaches the CRM or inbox. Open the booking and checkout flows. A correct DNS answer can still point to an unprepared service.
Define go, no-go, and rollback rules
Write these before the window starts:
| Decision | Example rule |
|---|---|
| Go | New zone matches all approved records, critical services pass, access is confirmed, and monitoring is ready |
| No-go | Any critical record is unexplained, DNSSEC sequence is unconfirmed, or the old environment cannot remain available |
| Rollback | More than 1% synthetic failures for 10 minutes, inbound mail fails from two external providers, or checkout cannot complete |
Choose thresholds that fit the business. The value is not in the exact percentage. The value is agreeing that one operator has authority to roll back without holding a meeting during an outage.
Phase 4: Execute the cutover
Start a timestamped change log. Record the person making the change, the old value, the new value, and the exact time.
For a nameserver migration, update delegation at the registrar only after the new zone passes preflight. Do not cancel the old DNS account. Old delegation and cached referrals may continue sending queries there while the change spreads.
For a web host change that keeps the same DNS provider, change only the planned A, AAAA, CNAME, or provider routing setting. Keep the old origin online and able to serve traffic. If the application accepts orders, accounts, or content writes, plan how data created during the overlap will be handled.
For an email migration, follow the mail platform’s coexistence and routing instructions. MX priority alone does not guarantee a clean staged move. Verify inbound delivery, outbound sending, SPF authorization, DKIM signing, DMARC alignment, and any line-of-business devices that send mail as the domain.
Change one layer at a time when the project allows it. A registrar transfer, DNS host move, web host move, and email migration in one window create too many possible causes when a test fails.
Phase 5: Validate from the user’s side
The provider dashboard saying “active” is not the finish line.
Query several public recursive resolvers and test from more than one network. Check the site on mobile data and a separate broadband connection. Confirm the apex and www, important subdomains, HTTPS, redirects, forms, checkout, login, and any API health endpoint.
Test email both ways with accounts outside your company. Inspect message headers to confirm SPF, DKIM, and DMARC results. Watch for delayed bounces. Confirm help desk, scanner, website form, CRM, and accounting-system email because those senders are easy to miss.
Monitor the old and new DNS services if logs are available. Queries continuing at the old provider are expected during the overlap. Errors, SERVFAIL responses, certificate warnings, or a sudden drop in form submissions are not.
For a hosting move, keep Search Console and server logs in view. Google recommends monitoring both the old and new infrastructure during a hosting change in its hosting migration instructions. Do not confuse normal crawl variation with proof that everything works. Test business actions directly.
Rollback without making the outage worse
Rollback is a prepared change, not “put it back how it was.” Save the old delegation, zone export, origin address, proxy settings, DNSSEC state, and account access before cutover.
If a web record change fails, restoring the old answer can be quick after lowered TTLs, but clients with cached new answers may continue reaching the new origin until their cache expires. Keep both origins healthy during that period.
If a nameserver change fails, reverting delegation can take longer because recursive resolvers may cache nameserver information. That is why the old provider must remain active and contain a working zone.
Do not improvise DNSSEC rollback. Follow the documented sequence for the active delegation and DS records. An old zone that answers correctly but no longer validates is not a working rollback.
Closeout checklist
Keep heightened monitoring through at least the longest pre-change TTL and through one normal business cycle. For email-heavy or global operations, allow more time.
Once stable, raise TTLs to the planned steady-state values. Export the final zone. Update the dependency map, password manager, vendor documentation, and emergency contacts. Remove obsolete admin access only after confirming the business owns at least two recovery paths.
Then schedule cleanup as a separate approved change. Review unknown TXT records, abandoned subdomains, stale verification tokens, old mail senders, and temporary migration entries. Separate cleanup protects you from deleting a working dependency while everyone is tired from cutover.
DNS migration FAQ
How long does a DNS migration take?
The change window may be minutes, but cached answers can remain until their TTLs expire. Nameserver delegation, record TTLs, negative caching, and resolver behavior all affect what users see. Plan the overlap around your longest relevant TTL, not a generic promise of “24 to 48 hours.”
Can we move DNS with zero downtime?
You can usually avoid user-visible downtime when the old and new zones are correct, both destination services remain available, TTLs are prepared, and DNSSEC is coordinated. “Zero downtime” is an operating goal, not a switch a provider can guarantee by itself.
Should we change DNS on a Friday?
Only if the business is staffed to test and recover throughout the cache overlap. A low-traffic window is useful, but available responders matter more than the day printed on the calendar.
When should the old DNS account be canceled?
After the new delegation is stable, old TTLs have expired, logs show the old service is no longer meaningfully queried, critical services pass, and rollback is no longer needed. Canceling it immediately removes your safest fallback.
Who should own the migration?
One change owner should coordinate it, but web, IT, email, security, and business-system owners may all have required checks. The registrar account and domain should remain under company control, even when an agency performs the technical work.
Need someone to run the migration with you?
A good DNS move is quiet. Customers keep browsing, mail keeps moving, forms keep arriving, and the team has a clean record of what changed.
If you need help planning a hosting move, rebuilding a DNS zone, or checking the web systems attached to your domain, talk to Your Web Team. We’ll map the dependencies, build the cutover plan, and test the business paths that cannot afford to break.
