A website DNS migration checklist should answer three questions before anything changes: which records must survive, how email will keep routing, and exactly how the old configuration can be restored. Export the current zone, inventory every dependent service, stage the destination, and validate it before changing nameservers. Treat the cutover as a controlled change with an owner, a time window, and a rollback trigger.

Build the record inventory first

Start with an export from the current provider and keep an untouched copy. Cloudflare's import and export guidance explains that zone records can be moved by file, while also noting format details such as fully qualified names and trailing dots. An export is a starting point, not proof that the destination is complete.

Create a second human-readable inventory with one row per record. Include the hostname, type, value, TTL, whether traffic is proxied, the service that depends on it, and the person who can verify that service. Pay special attention to records that are easy to overlook:

  • MX records and mail-routing hosts
  • SPF, DKIM, and DMARC TXT records
  • ownership-verification TXT records
  • subdomains used by applications, APIs, forms, or customer portals
  • CAA, SRV, and certificate-validation records
  • redirects or provider-specific flattening behavior

Do not remove a record merely because its purpose is unclear. Mark it unknown, identify the owner, and investigate it before the cutover.

Protect email as a separate workstream

Website traffic and email may share the same domain but fail in different ways. Google explains in its MX setup guidance that MX records control mail delivery and that DNS changes can take time to propagate. Record the current MX values exactly, along with the related SPF, DKIM, and DMARC entries. If a help desk, newsletter service, invoice platform, or form sender uses the domain, document that dependency too.

Before the move, capture a known-good inbound and outbound mail test. After the change, repeat both tests with an external mailbox and inspect authentication results when possible. A homepage loading successfully does not prove that new messages, password resets, and form notifications are arriving.

Stage and inspect the destination

Cloudflare's migration planning guidance recommends mapping dependencies, considering DNSSEC and TTLs, choosing a migration window, and preparing rollback. Import the zone at the new provider, then compare it line by line with the inventory. Confirm how the destination handles apex records, proxies, aliases, and DNSSEC rather than assuming the providers use identical behavior.

Where the provider allows it, query the destination nameservers directly before delegation. Check representative A, AAAA, CNAME, MX, TXT, CAA, and SRV responses. Also test the application by using a temporary hostname or another controlled method that does not expose customers to an incomplete configuration.

Define the cutover and rollback decision

Write down the old nameservers, registrar access path, DNSSEC state, destination nameservers, change owner, start time, and verification steps. Set a specific rollback trigger, such as missing mail records, certificate failures, or a critical application host returning the wrong address. Keep the old zone active during the observation period.

The actual change should be small: update delegation only after the destination has passed comparison and direct-query checks. Then verify authoritative answers from more than one network or resolver, load the website over HTTPS, submit a test form, and complete the email tests. Record timestamps and results.

Final verification checklist

  1. Confirm that the exported zone and written inventory are stored outside the DNS provider account.
  2. Compare record counts and every high-impact value at the destination.
  3. Verify MX, SPF, DKIM, and DMARC separately from the website.
  4. Check DNSSEC and remove or replace registrar DS records only as the provider procedure requires.
  5. Query the new authoritative nameservers before changing delegation.
  6. Test the homepage, key subdomains, HTTPS certificates, forms, and transactional messages after cutover.
  7. Keep the old configuration available until the observation window ends.
  8. Document what changed, who verified it, and when the next review occurs.

A successful migration is not simply a nameserver update. It is a reversible, evidence-backed transfer in which web, mail, and hidden service dependencies are all checked independently.

Sources

  1. Import and export records — Cloudflare
  2. Phase 1: Plan — Cloudflare
  3. Set up MX records for Google Workspace — Google Workspace Admin Help

Related reading