DNS Cutover Checklist for MSPs: How to Migrate Clients Without Downtime

· Unified DNS Team · 14 min read

Overview

DNS cutovers are one of the highest-risk routine tasks in MSP work. Done correctly, they're invisible: the client never notices. Done wrong, email stops, websites go down, and you're on the phone at 11pm explaining why the business is unreachable.

The failure modes are almost always the same: TTLs weren't reduced ahead of time, records were transcribed manually and something was missed, the migration happened during business hours, or nobody had a tested rollback plan.

This guide is a systematic checklist for migrating a client domain from one DNS provider to another, whether that's registrar-to-registrar, GoDaddy to Cloudflare, or any other combination. It covers every phase: audit, TTL reduction, building and verifying the new zone, executing the cutover, post-migration verification, and rollback.

What Counts as a DNS Cutover?

A DNS cutover means changing the nameservers for a domain. It points the domain from its current DNS provider to a new one. This is different from updating individual records within the same provider. When you change nameservers, the entire zone moves. Every record needs to be present and correct in the new provider before you make the switch.

What You'll Need

The Cutover Checklist at a Glance

Here's the complete checklist. Each phase is detailed in the sections below.

72–48 hours before cutover:

24–48 hours before cutover:

Cutover day:

Post-cutover (24–72 hours):

Phase 1: Audit and Export

Before touching anything, get a complete picture of what you're moving.

Export the Zone File

Most DNS providers let you export a full zone file in BIND format. This is the most reliable way to capture every record without manual transcription errors.

Finding the export option:

If your provider doesn't offer an export, query all record types manually:

# Pull all common record types for a domain
for type in A AAAA CNAME MX TXT NS SRV CAA PTR; do
  echo "=== $type ==="
  dig $type yourdomain.com +short
done

# Check known subdomains too
for sub in www mail autodiscover _dmarc selector1._domainkey selector2._domainkey; do
  echo "=== $sub.yourdomain.com ==="
  dig A CNAME $sub.yourdomain.com +short
done

Build a Record Inventory

Create a table of every record before migrating. This becomes your verification checklist and your rollback reference.

TypeNameValueTTLPriorityNotes
A@203.0.113.103600—Main website
Awww203.0.113.103600—www redirect
MX@mail.protection.outlook.com36000M365 mail
CNAMEautodiscoverautodiscover.outlook.com3600—M365 Autodiscover
TXT@v=spf1 include:spf.protection.outlook.com -all3600—SPF
CNAMEselector1._domainkeyselector1-...3600—DKIM
TXT_dmarcv=DMARC1; p=quarantine; ...3600—DMARC

Things That Are Easy to Miss

Wildcard records: *.yourdomain.com entries that catch unmatched subdomains. Some providers don't show these prominently.

SPF record complexity: The TXT value may be long and contain multiple includes. Copy it character-for-character.

DKIM selectors: Check for multiple selectors (selector1, selector2, google, s1, k1, etc.). A domain may have DKIM configured for Microsoft 365, Google, HubSpot, and a transactional email service simultaneously.

CAA records: These control which Certificate Authorities can issue SSL certificates for the domain. Missing CAA records can cause SSL renewals to fail silently. See our guide on What Is a CAA Record? for full details.

SRV records: Used for Microsoft Teams, SIP, and other services. Easy to overlook because they're less common. See What Is an SRV Record?.

Third-party managed subdomains: Some subdomains may be delegated to third-party nameservers (Atlassian, HubSpot custom domains, etc.) via NS records. These need to be recreated exactly.

Email routing records: If the client uses an email filter (Mimecast, Proofpoint, Barracuda), the MX records point to the filter, not directly to the mail server. Don't replace these with a generic M365 or Google value.

Phase 2: Lower TTLs

TTL (Time To Live) controls how long DNS resolvers cache a record before checking for updates. If you cut over nameservers while TTLs are still at 3600 or 86400, some users will continue resolving to the old provider for hours after the switch.

The TTL Reduction Schedule

Lower TTLs at least 48–72 hours before the cutover window. This gives existing cached entries time to expire.

72 hours before:  Reduce all record TTLs to 300 seconds (5 minutes)
48 hours before:  Verify TTL reduction has propagated globally
Day of cutover:   Confirm TTLs are still at 300 before executing

What to Reduce

Reduce TTLs on all records in the current provider:

# Target value: 300 seconds on every record
yourdomain.com.    300    IN    A      203.0.113.10
www.yourdomain.com. 300   IN    A      203.0.113.10
yourdomain.com.    300    IN    MX     0 yourdomain-com.mail.protection.outlook.com.
yourdomain.com.    300    IN    TXT    "v=spf1 include:spf.protection.outlook.com -all"

Also reduce the SOA (Start of Authority) TTL and minimum TTL if your provider exposes them.

Confirming TTL Reduction Has Propagated

After lowering TTLs, verify that resolvers are seeing the new values:

# Check TTL on the A record (look for 300 in the ANSWER SECTION)
dig A yourdomain.com

# Check from multiple resolvers
dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1
dig A yourdomain.com @9.9.9.9

The TTL in the response will count down from 300 as the cache ages. If you see values near 300, the reduction has propagated. If you still see 3600, wait longer or verify the change saved correctly in your DNS provider.

Why Bother with TTL Reduction?

Without TTL reduction, you're at the mercy of whatever TTL the records were set to previously. A 24-hour TTL means some resolvers won't pick up the new nameservers for a full day after the switch. During that window, users may resolve to the old (now empty or decommissioned) DNS zone.

With 300-second TTLs, the worst case after cutover is a 5-minute window where some resolvers still see the old zone. For most clients, that's acceptable. For clients with strict uptime requirements, you can go as low as 60 seconds, though some providers don't support sub-300 TTLs.

For a deeper explanation of how TTLs work, see our guide on What Is TTL in DNS?.

Phase 3: Build and Verify in the New Provider

Build the new zone before changing nameservers. The new zone should be complete and verified in isolation; you're not making any live changes yet.

Import or Manually Create Records

If the new provider supports zone file import, use it:

If importing, review the results carefully. Zone file imports can mishandle some record types (particularly SRV and CAA), and some providers strip or modify records during import. Always compare the imported zone against your export.

If building manually, work through your record inventory row by row.

Verify Records Against Your Inventory

After building the zone, query the new nameservers directly to confirm each record is correct before any user traffic reaches them.

Find the new nameservers:

# Get the nameservers for the new zone
dig NS yourdomain.com @new-ns1.provider.com

# Or check your provider's dashboard for the assigned nameservers
# e.g., Cloudflare shows: ns1.cloudflare.com, ns2.cloudflare.com

Then query each record type directly against those nameservers:

# Replace ns1.newprovider.com with the actual new nameserver
NEW_NS="ns1.newprovider.com"

# A record
dig A yourdomain.com @$NEW_NS +short

# MX record
dig MX yourdomain.com @$NEW_NS +short

# SPF (TXT)
dig TXT yourdomain.com @$NEW_NS +short | grep spf

# DKIM
dig CNAME selector1._domainkey.yourdomain.com @$NEW_NS +short
dig CNAME selector2._domainkey.yourdomain.com @$NEW_NS +short

# DMARC
dig TXT _dmarc.yourdomain.com @$NEW_NS +short

# CAA
dig CAA yourdomain.com @$NEW_NS +short

# SRV (if applicable)
dig SRV _sip._tls.yourdomain.com @$NEW_NS +short

Compare every result against your record inventory. If anything is missing or wrong, fix it now, not after the cutover.

Set TTLs in the New Zone

Set TTLs to 300 seconds in the new zone as well. After the cutover is confirmed and stable (24–48 hours later), you'll raise them back to normal values.

DNSSEC Considerations

If the domain uses DNSSEC, the migration requires additional steps. DNSSEC ties cryptographic signatures to specific nameservers. Changing nameservers without handling DNSSEC properly will cause DNSSEC-validating resolvers to reject DNS responses for the domain entirely.

The safe sequence for DNSSEC migrations:

  1. Disable DNSSEC at the registrar (remove the DS record from the parent zone). This takes effect based on the DS record's TTL, typically 3600–86400 seconds.
  2. Wait for the DS record removal to propagate
  3. Execute the nameserver cutover
  4. Re-enable DNSSEC in the new provider and add the new DS record at the registrar

Attempting to cut over nameservers while DNSSEC is active on the old provider is one of the most common causes of total domain outages during migrations. See our guide on What Is DNSSEC? for how the trust chain works.

Phase 4: Execute the Cutover

With TTLs low and the new zone verified, you're ready to switch nameservers.

Choose the Right Window

The Nameserver Change

Nameservers are updated at the registrar, not at the DNS provider. Log into the registrar where the domain is registered and update the NS records to point to the new provider's nameservers.

The exact steps vary by registrar, but you're looking for:

Record the exact time of the change. This is your reference point for monitoring propagation and your starting point if you need to roll back.

What Happens Next

After updating nameservers at the registrar, the change propagates through the DNS hierarchy:

  1. The registrar updates the parent zone (e.g., the .com TLD zone) with the new NS records
  2. The parent zone's TTL for NS/glue records expires on recursive resolvers globally (typically 172800 seconds / 48 hours for TLD records). This is why TTL reduction on your zone records matters; the NS delegation itself propagates independently.
  3. Resolvers begin querying the new nameservers and caching results at the new TTL (300 seconds)

Most traffic shifts within 15–30 minutes. Full global propagation can take up to 48 hours due to TLD-level NS caching, but in practice the vast majority of users see the new zone within an hour.

For a detailed explanation of how propagation works, see our guide on What Is DNS Propagation?.

Phase 5: Post-Cutover Verification

Don't close the ticket the moment you change nameservers. Verification is a distinct phase.

Immediate Checks (first 30 minutes)

Check propagation from multiple geographic locations:

Use an online propagation checker (dnschecker.org or whatsmydns.net) to see where the new nameservers have propagated. You're looking for the majority of nodes showing the new NS values.

# Confirm NS records are updating globally
dig NS yourdomain.com @8.8.8.8
dig NS yourdomain.com @1.1.1.1
dig NS yourdomain.com @9.9.9.9
dig NS yourdomain.com @208.67.222.222  # OpenDNS

Verify critical records are resolving correctly from public resolvers:

# Website
dig A yourdomain.com @8.8.8.8 +short
curl -I https://yourdomain.com  # Check for HTTP 200

# Mail
dig MX yourdomain.com @8.8.8.8 +short
dig TXT yourdomain.com @8.8.8.8 +short | grep spf

# DKIM
dig CNAME selector1._domainkey.yourdomain.com @8.8.8.8 +short

# DMARC
dig TXT _dmarc.yourdomain.com @8.8.8.8 +short

Send a test email to and from the client's domain from an external address. Confirm delivery and check headers to verify DKIM signing and SPF pass.

Extended Monitoring (first 24 hours)

Check again at the 1-hour, 4-hour, and 24-hour marks:

If the client uses tools like Microsoft 365, check the M365 admin center's DNS health tab for any flagged records.

Restore TTLs

Once you're confident the migration is stable (typically 24–48 hours post-cutover), raise TTLs back to production values in the new provider:

# Restore to standard production TTLs
yourdomain.com.    3600    IN    A      203.0.113.10
yourdomain.com.    3600    IN    MX     0 yourdomain-com.mail.protection.outlook.com.
yourdomain.com.    3600    IN    TXT    "v=spf1 include:spf.protection.outlook.com -all"

Use higher TTLs for records that rarely change: 86400 (24 hours) is reasonable for MX, NS, and SPF. Keep A and CNAME records at 3600 if the client's IP or infrastructure might change.

Rollback Plan

Every DNS cutover should have a tested rollback plan documented before you start, not improvised if things go wrong at midnight.

The Rollback Steps

  1. Log back into the registrar and revert the nameservers to the original values
  2. Confirm the time of the revert. Use the same process as for the original cutover.
  3. Monitor propagation using the same tools as the initial cutover
  4. Verify the old zone is still intact. Do not delete or modify the old zone during the migration window.

The rollback is fast because:

Keep the Old Zone Intact

Do not decommission the old DNS zone immediately after cutover. Keep it intact and unmodified for at least 72 hours. If something goes wrong (a record you missed, a service you forgot about), the rollback is a single NS change away.

After 72 hours of confirmed stable operation, you can archive the old zone and clean it up.

What to Have Ready

Common Mistakes

These are the errors that cause actual outages in DNS cutovers.

Not Reducing TTLs Ahead of Time

This is the most common mistake and the one with the longest blast radius. If TTLs are at 86400 when you cut over, some users and services will continue hitting the old nameservers for up to 24 hours. If the old zone gets decommissioned before that window closes, those users see NXDOMAIN for every record.

The fix: reduce TTLs 72 hours before the cutover, verify propagation, then proceed.

Missing Records in the New Zone

Manual transcription misses records. Common ones: DKIM selectors for secondary services (a marketing tool's DKIM that never got documented), CAA records, wildcard entries, subdomain delegations via NS records.

The fix: always export the zone file and do a record-by-record comparison, not a visual scan.

Cutting Over During Business Hours

Even a 5-minute disruption during business hours generates support calls. Email delivery delays or a brief website outage during a sales demo can have real business impact.

The fix: schedule cutovers for off-hours. If the client insists on daytime, at least avoid Monday morning and end-of-month peaks.

Forgetting to Handle DNSSEC

Changing nameservers while DNSSEC is active breaks the trust chain. DNSSEC-validating resolvers (most modern ones) will start returning SERVFAIL for all records in the domain until the DS record is updated to match the new provider's keys.

The fix: disable DNSSEC (remove DS record from registrar) before the nameserver change, wait for propagation, then re-enable after the cutover.

Deleting the Old Zone Immediately

The urge to clean up is understandable, but deleting the old zone before full propagation eliminates your rollback option. Any resolvers still pointing to the old nameservers will get NXDOMAIN.

The fix: keep the old zone for 72+ hours post-cutover before touching it.

Trusting a Single DNS Checker

A single propagation check showing success doesn't mean all global resolvers have updated. Different ISPs, corporate networks, and geographic regions update at different rates.

The fix: check from multiple resolvers (Google, Cloudflare, OpenDNS, and a regional ISP if possible) and use a geographic propagation tool.

Not Confirming Email Flow Post-Cutover

The website loading is easy to verify. Email is less obvious because delivery failures may not surface immediately. Messages queue, retry, and bounce hours later. A single send/receive test during the verification window catches this early.

Frequently Asked Questions

How long does a DNS cutover take?

The nameserver change itself takes seconds at the registrar. Propagation to most resolvers globally takes 15–60 minutes with 300-second TTLs. Full propagation, including resolvers still caching the old TLD-level NS records, can take up to 48 hours, but in practice, 95% of traffic shifts within the first hour.

Do I need to notify the client before a DNS cutover?

Yes, for anything beyond a small internal cutover. Clients should know the maintenance window, the expected impact (brief or none), and who to contact if something breaks. For clients with SLAs, a formal change request may be required.

What's the difference between a DNS cutover and a domain transfer?

A DNS cutover changes the nameservers (where DNS is hosted). The domain registration stays with the same registrar. A domain transfer moves the registration to a different registrar. You can do either independently. Most migrations MSPs handle are DNS cutovers only, not full domain transfers.

Can I do a partial cutover and move some records to the new provider first?

No. Nameserver delegation is all-or-nothing. Once you change the NS records, all DNS queries for the domain go to the new nameservers. You can't split traffic between two DNS providers for the same domain at the same time (except in rare CDN or Anycast configurations that aren't standard DNS hosting). Build the complete zone in the new provider before switching.

What if the client's domain uses a third-party mail filter (Mimecast, Proofpoint)?

The MX records should point to the filter, not directly to the mail server. When building the new zone, copy the exact MX values from the old zone; do not substitute generic Microsoft 365 or Google MX values. Also check whether the filter provider has any CNAME or TXT records that need to be included. These are easy to miss if you're only familiar with the downstream MX configuration.

How do I handle a domain that uses Cloudflare's proxy (orange cloud)?

If the current provider is Cloudflare and records are proxied (orange cloud), the IP addresses visible in DNS are Cloudflare's proxy IPs, not the origin server's real IP. Before migrating to a non-Cloudflare provider, you need to find the real origin IP and use that in the new zone. Check the server directly, review server access logs, or temporarily disable proxying on a non-critical subdomain to reveal the origin IP.

If you're migrating to Cloudflare, you'll set up the zone normally and then decide which records to proxy.

What should I do if something breaks post-cutover?

Execute the rollback plan: revert nameservers at the registrar to the original values, note the time, and monitor propagation. With TTLs at 300 seconds, most traffic reverts within 5–10 minutes. Then diagnose what broke, fix it in the new zone, and schedule a second cutover attempt once the issue is resolved.

Get Started with Unified DNS

DNS cutovers are one of the places where having a complete, pre-migration record export makes the difference between a smooth migration and a scramble. Unified DNS lets you export, audit, and compare DNS zones across Cloudflare, Porkbun, NameSilo, NameCheap, and more, so you walk into every cutover with a full record inventory already in hand.

Unified DNS is live. Try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or contact us for a walkthrough.