MERLONIX
Sign inStart free

DNS Migration Checklist for Agencies: What to Verify Before, During, and After Moving a Client's DNS

DNS migrations — moving a client's domain from one registrar, one DNS provider, or one nameserver configuration to another — are among the highest-risk operations an agency performs for a client. Done correctly, they are invisible: the domain continues to resolve, email continues to deliver, SSL certificates continue to renew, and every subdomain continues to point at the correct platform. Done incorrectly, they generate a cascade of failures that are difficult to diagnose and embarrassing to explain to clients.

This checklist covers what to verify before starting a DNS migration, what to check during the migration window, and what to confirm after the migration is complete.

Before the Migration

1. Export and document the complete current DNS zone

Before touching anything, export the full DNS zone file from the current provider. This is your rollback baseline. If the migration goes wrong, you need an authoritative record of every DNS record as it existed before you changed anything.

Most DNS providers offer a zone file export in BIND format. If the current provider does not support zone export, document every record manually:

  • All A and AAAA records (including apex, www, and any subdomains with direct IP records)
  • All CNAME records (especially subdomains pointing at third-party platforms: Vercel, Netlify, Shopify, WP Engine, etc.)
  • All MX records with priority values
  • All TXT records (SPF, DKIM, DMARC, domain verification records for Google Workspace, Stripe, etc.)
  • All SRV records
  • All NS records for delegated subdomains
  • TTL values for every record

Do not rely on memory or assume you know all the records. Export everything.

2. Identify every SSL certificate that depends on CNAME delegations

SSL certificates on managed platforms — Cloudflare Pages, Vercel, Netlify, WP Engine, Shopify, and others — are provisioned and renewed based on the CNAME record pointing the domain at the platform. If the CNAME breaks during migration, the platform loses the ability to renew the SSL certificate. The existing certificate remains valid until its expiry date, but renewal will fail.

List every domain and subdomain that uses a platform-managed SSL certificate:

  • Primary domain (www and apex): which platform hosts it, what the CNAME target is
  • Every subdomain with a platform CNAME: shop, blog, app, api, staging, etc.
  • Any subdomains with manually managed certificates (Let's Encrypt, purchased certificates)

This list tells you which records are critical to preserve exactly during migration. A missing or incorrect CNAME in the new DNS provider will eventually produce an SSL error — possibly weeks after the migration, when the current certificate expires.

3. Identify all email-related records and verify current deliverability

MX records, SPF TXT records, DKIM TXT records, and DMARC TXT records are critical. A DNS migration that drops or corrupts any of these causes immediate or delayed email delivery failures.

For each domain:

  • Record all MX records with exact priority values and hostname targets
  • Record the SPF TXT record exactly (the v=spf1 ... value) — any alteration breaks SPF validation
  • Record every DKIM TXT record — these are long TXT records often subdivided across multiple TXT records for the same selector; verify the complete value
  • Record the DMARC TXT record on _dmarc. subdomain

Send a test email from the client's domain to an external address before migration. Verify it passes SPF and DKIM checks using an email header analyzer. This establishes a baseline — if email stops working after migration, you know it was working before.

4. Lower TTLs 24–48 hours before migration

DNS TTL (Time to Live) determines how long resolvers cache a record before re-querying authoritative nameservers. For most records, the default TTL is 1–24 hours. During a migration, you want the new records to propagate quickly.

Lower all TTLs to 300 seconds (5 minutes) at least 24 hours before the migration window. This gives the reduced TTL time to propagate before you make the actual changes. During the migration, new records will propagate to resolvers within 5 minutes rather than 24 hours.

After the migration is verified complete, raise TTLs back to a normal value (3600–86400 seconds).

5. Identify the new provider's CNAME limitations

Some DNS providers do not support CNAME records at the apex (root) domain — for example, you cannot set a CNAME on clientdomain.com (without www). If the current configuration uses CNAME flattening or ALIAS records at the apex, verify that the new provider supports the same capability. Cloudflare, AWS Route 53, and some other providers support CNAME-equivalent records at the apex; many traditional DNS providers do not.

If the new provider does not support apex CNAME equivalents and the current configuration requires them (for example, a Netlify site served from the apex domain), the migration requires a different approach — either a Cloudflare proxy in front, a redirect from apex to www, or a platform change. Discover this before the migration, not during.

During the Migration

6. Add all records to the new provider before changing nameservers

The standard safe approach for a nameserver migration:

  1. Add all DNS records from your export to the new provider
  2. Verify every record is present and correct in the new provider's interface
  3. Change the nameservers at the registrar to point at the new provider

Do not change nameservers until all records are in the new provider. The window between nameserver change and full propagation is when the domain is in a split-brain state — some resolvers use the old nameservers, some use the new ones. If any records are missing from the new provider during this window, some requests will fail.

7. Verify every critical record in the new provider before changing nameservers

After adding records to the new provider, check each one manually:

  • Do the CNAME targets exactly match the originals? (Case matters for some platforms)
  • Are MX records present with correct priority values?
  • Is the SPF TXT record character-for-character identical to the original?
  • Are DKIM TXT records complete? (Long TXT values are easy to truncate during copy-paste)
  • Are TXT records for domain verification (Google Workspace, Stripe, etc.) present?
  • Are any delegated NS records for subdomains preserved?

A one-character error in a DKIM TXT record breaks email signing. A missing MX record drops inbound email. Verify before proceeding.

8. Use multiple resolvers to verify propagation after nameserver change

After changing nameservers, check propagation using multiple DNS resolvers — not just the resolver on your own network. Different resolvers return different results during propagation because each caches the old answer independently until TTL expires.

Tools to check propagation:

  • dig @8.8.8.8 clientdomain.com NS — Google resolver
  • dig @1.1.1.1 clientdomain.com NS — Cloudflare resolver
  • dig @208.67.222.222 clientdomain.com NS — OpenDNS resolver

When all three return the new nameserver values, propagation is substantially complete. With 5-minute TTLs set before migration, this typically takes 15–30 minutes.

9. Test SSL, email, and each critical subdomain during the propagation window

As propagation completes, verify each critical system:

  • Navigate to the primary domain in a browser and verify the SSL certificate is valid and issued by the expected issuer
  • Verify the www redirect works if one is configured
  • Navigate to each subdomain (shop, blog, app, api, staging) and verify SSL is valid
  • Send a test email from the domain and verify it arrives and passes SPF/DKIM checks
  • Check any webhook endpoints the client uses (Stripe, GitHub, Slack) by triggering a test event
  • Verify any third-party integrations that use DNS-based domain verification (Google Search Console, analytics tools)

After the Migration

10. Set up monitoring for every CNAME and SSL certificate before closing the ticket

After a DNS migration, every CNAME delegation in the new provider should be monitored for integrity. The most common post-migration failure is a future DNS change in the new provider that accidentally drops or modifies a CNAME configured during the migration. Monitoring catches this within minutes rather than days.

Before closing the migration ticket:

  • Add every migrated domain and subdomain to your SSL monitoring tool
  • Verify CNAME integrity monitoring is active for every platform CNAME
  • Set expiry alerts for every SSL certificate
  • Add domain registration expiry monitoring for the apex domain

This is the time to set up monitoring — not after something breaks six months later.

11. Raise TTLs back to production values

After propagation is verified complete and all systems are functioning, raise TTLs back to production values. Long TTLs (3600–86400 seconds) reduce resolver query load and improve DNS lookup speed for visitors.

Update every record's TTL — not just the commonly-changed records. Low TTLs left in place after migration waste resolver cache efficiency without providing any operational benefit.

12. Document the migration in the client record

Record what was migrated, from which provider to which provider, on what date, and who performed the migration. Note any complications that arose and how they were resolved. Note the new nameserver values and the new DNS provider's login details.

This documentation matters when:

  • A client DNS change six months later breaks something and you need to understand the current configuration
  • A new team member needs to make a DNS change for the client
  • A client changes agencies and needs to hand off DNS access to someone else
  • A client's IT department makes an unauthorized change and you need to verify what the configuration should look like

The DNS migration is complete when the zone is migrated, verified, and documented — not when the nameservers finish propagating.

Common Migration Mistakes

Changing nameservers before adding all records. This causes a split-brain window where some resolvers return correct answers (from old nameservers) and others return missing records (from new nameservers with incomplete configuration).

Truncating DKIM TXT records. Long DKIM public keys are often split across multiple TXT records or get truncated during copy-paste. Always verify the complete DKIM value character-for-character after adding it.

Forgetting subdomain NS delegations. If any subdomain uses a different DNS provider via NS delegation (for example, a subdomain managed by the client's IT team in a separate DNS zone), those NS records must be recreated in the new provider exactly as they appear in the old zone.

Not testing email deliverability post-migration. SPF and DKIM failures are not immediately obvious — email is delivered but marked as spam or rejected by some recipients. Test with an email header analyzer tool within an hour of completing migration.

Not monitoring after migration closes. A DNS migration that completes cleanly today can be disrupted by a future change in the new provider. Setting up monitoring after migration is the only way to detect drift before it causes a client incident.