A safe DNS migration copies and verifies the entire production zone before anyone changes nameservers. Moving only the website records can leave the homepage working while email, domain verification, certificate issuance, subdomains, or security controls quietly fail.

DNS is not a website setting. It is the routing layer for every service attached to the domain.

The migration plan should inventory the current zone, reduce selected cache times in advance, prepare the new provider, test authoritative answers, control DNSSEC, preserve a rollback window, and monitor each dependent service after cutover.

Start the DNS migration checklist with an inventory

Export the current zone when the provider supports it, then compare that export with public DNS queries and the services the business actually uses. Old dashboards can contain stale entries, while undocumented records may still support a live subdomain or vendor verification.

Record each name, type, value, priority, TTL, proxy state, and purpose. Include A and AAAA records, CNAMEs, MX records, SPF, DKIM selectors, DMARC, TXT verifications, SRV records, CAA, redirects implemented by the provider, and any wildcard records. Record the registrar, current authoritative nameservers, DNSSEC state, account owner, and recovery contacts too.

Do not “clean up” unfamiliar records during the move. Reproduce the known working state first. Retire obsolete entries later, when each deletion can be tested separately.

Lower TTL before the change window

A record’s time to live tells recursive resolvers how long they may cache an answer. Lowering relevant TTLs before cutover shortens the period in which old answers remain in circulation and makes a correction or rollback take effect sooner.

Make the reduction early enough for the previous, longer TTL to expire. Do not assume changing a value to five minutes immediately clears caches that already stored it for hours.

AWS’s Route 53 migration procedure recommends lowering nameserver TTLs at both providers and gives a provider-specific range of 60 to 900 seconds. That range is not universal, but the planning principle is: reduce the relevant TTLs ahead of time and restore normal values after the migration is stable.

Build the new zone before changing delegation

Create and validate the new zone while the old nameservers remain authoritative. Confirm that the new provider accepts every required record type and preserves values exactly, including trailing dots, priorities, quoted TXT values, and multiple records at one name.

Query the new provider’s authoritative nameservers directly. Check the apex and www host, every production subdomain, mail routing, DKIM selectors, DMARC, SPF, CAA, and vendor verifications. If the provider proxies web traffic, verify origin configuration, SSL mode, redirects, cache behavior, and access rules before enabling the proxy.

A green homepage is not zone validation. Use a record-by-record comparison and then test the business journeys those records support.

Protect email as a separate production system

MX records determine where receiving servers deliver mail. Google Workspace’s MX documentation, for example, requires the domain’s MX record to point to Google’s mail server and notes that recognition of changes can take time.

Copying MX alone is not enough. Preserve SPF, every active DKIM selector, DMARC, provider validation records, mail subdomains, and any routing or autodiscovery records. Send and receive test messages with internal and external accounts after cutover. Review authentication results in the message headers rather than treating inbox delivery as the only test.

If the project also changes email providers, separate that work from the DNS-hosting migration when possible. Combining two cutovers makes failures harder to isolate and rollback.

Give DNSSEC its own migration plan

DNSSEC links signed DNS responses to a delegation-signer record held at the parent zone. A mismatch can make a correctly populated zone appear nonexistent to validating resolvers.

Follow the documented procedure for the registrar, old DNS provider, and new DNS provider. Do not copy a DS value from one provider to another and assume the signing keys match. AWS documents a disable-and-reenable sequence for its hosted-zone migration. Cloudflare also documents an advanced multi-signer migration when the old provider supports the required DNSKEY exchange. These are different provider procedures, not interchangeable steps.

Cut over with rollback still available

Record the original nameservers immediately before changing delegation at the registrar. Keep the old zone active and unchanged while caches and parent-zone delegation update. Do not cancel the previous DNS service or hosting account during the observation window.

After the change, query multiple public resolvers and the new authoritative servers. Test the website with and without www, redirects, forms, transactions, APIs, email, important subdomains, certificate status, and third-party integrations. Watch application errors, mail authentication, uptime checks, and support reports.

Define rollback triggers before cutover. Missing records, DNSSEC validation failures, widespread mail rejection, or an unavailable critical service may justify restoring the original delegation while the new zone is corrected.

Close the migration deliberately

  • Confirm the new nameservers are delegated at the parent.
  • Verify all production records from multiple networks and resolvers.
  • Confirm web, email, certificates, forms, APIs, and subdomains.
  • Restore appropriate TTLs after the observation window.
  • Document DNSSEC state and renewal or rotation responsibilities.
  • Update the zone inventory, account owner, and recovery instructions.
  • Retire the old provider only after the rollback window closes.

Treat DNS changes like production releases

DNS migrations become risky when they are treated as an administrative nameserver edit. The safer approach inventories dependencies, prepares both sides, tests authoritative answers, protects email and DNSSEC, and keeps a reversible path until the new service is proven.

If a hosting, website, or email project includes a DNS change, Eckman Design can help plan and validate the cutover as part of the production release.