Why this matters
How to move DNS without downtime during a migration comes down to one idea: control what resolvers cache and when they stop trusting the old answer. The edit in a DNS panel is fast. Propagation is not. A resolver that fetched your A record an hour ago keeps using it until the TTL expires, even if your authoritative server changed a second later.
A migration usually changes more than one record. You may move the zone to a new provider, point hostnames at new IPs, shift mail routes, or all three. If you change delegation before the target zone answers correctly, some users get errors while others see the old site. If you delete the old zone too early, cached queries that still land there return SERVFAIL.
The safe pattern is to run both providers in parallel and let the old one answer until caches drain. You are not flipping a switch. You are setting up two correct sources of truth, then moving the parent delegation and waiting.
Before you start
Ask the current provider for a zone export or try AXFR. If neither works, copy every record into a spreadsheet. Include TXT for domain verification, DKIM selectors, SPF, DMARC, CAA, SRV, MX priorities, wildcards and every subdomain. Note the TTL on each record.
Confirm who controls the registrar and whether the domain is DNSSEC signed. Check for a DS record at the parent. If DNSSEC is on, moving NS without moving keys correctly causes validation failures that look like random outages. Decide whether you will keep the same keys, use the new provider's keys, or turn DNSSEC off during the move and back on after.
Stand up the target zone early, but do not delegate to it. Publish the same records, then query the new authoritative nameservers directly. Check every name and type against the export. Lower TTLs on records you plan to change to 300 seconds or less. Do this at least one old TTL period before the cut.
Pick a cut window when traffic is low, but do not rely on that alone. Write down the exact NS set you will restore if something breaks. Save screenshots of the current registrar settings and zone.
How to do it
Treat the move as a sequence, not a single change. First make the new zone correct, then make the old zone match it, then change delegation, then wait. Keep the old provider's account active and paid through the process. Do not cancel anything until you have checked from more than one network and the parent TTL has passed.
At the registrar, change the nameserver set to the target provider. The parent TTL controls how long resolvers can cache the old NS records, so plan for that window. During the window, both providers should answer identically. If you need to change an IP or a mail record, change it in both zones, not just the new one.
Email needs extra care. MX records point to hostnames, and those hostnames need A or AAAA records in the same zone. If you move DNS and forget the mail host records, mail queues. TXT records for SPF and DKIM must move too, or outgoing mail fails authentication. CAA records can block certificate issuance if they point to a CA you no longer use.
If you have child zones or delegated subdomains, move them in the same change or update their NS records at the same time. DNSSEC changes should be staged: sign the new zone, publish the DS record, wait, then remove the old DS. Do not remove the old DS before the new chain validates.
- Export the full zone and build a record inventory. Pull every record, including TXT, CAA, SRV, wildcards and mail hosts. Put the values, types and TTLs in one table and use it as the checklist for both providers.
- Lower TTLs on records that will change. Set A, AAAA, CNAME, MX and TXT records to a short TTL such as 300 seconds. Do this before the cut and wait at least one old TTL period so caches pick up the new value.
- Create the target zone and test it directly. Publish all records at the new provider and query its authoritative nameservers with dig. Compare answers to the inventory before you touch delegation.
- Sync the old zone with late changes. If you change an IP, a mail host or a verification TXT, apply it to both zones. The old provider must keep answering correctly during the cache drain.
- Change the NS records at the registrar. Replace the old nameserver set with the new one and save the change. Record the time, the old set and the new set.
- Keep both providers live for the parent TTL window. Do not delete the old zone. Watch query logs and resolver answers until the old nameservers stop receiving meaningful traffic.
- Move DNSSEC in stages. If the domain is signed, publish the new DS record, wait for it to be visible, then remove the old DS. Check validation with a DNSSEC-aware resolver after each change.
- Roll back at the registrar if answers are wrong. If the new zone returns bad answers, restore the old NS set. Because the old zone is still live, rollback is a delegation change, not a rebuild.
How to check it worked
Check from the outside, not from your laptop. Use dig +trace example.com to see the delegation path. Query the new authoritative nameservers directly with dig @ns1.newprovider.example example.com A. Then query public resolvers and confirm they return the same answer.
Check record types separately. A and AAAA for the website and API. MX and the mail host A records. TXT for SPF, DKIM and domain verification. CAA for certificate issuance. If you use SRV records for chat or voice, check those too. Look at the TTL in the answer and watch it count down.
Test application behavior. Load the site over HTTPS, sign in, send a test email in and out, and request a certificate if your setup does that automatically. Check negative answers: a typo subdomain should return NXDOMAIN, not a stale A record. Use a DNS monitoring service from several regions if you have one.
After the parent TTL passes and logs show little traffic to the old nameservers, keep the old zone in read-only mode for a while. A cached query can still arrive from a resolver that ignored TTLs or from a device with a hardcoded DNS setting.
Mistakes to avoid
The common failure is changing NS before the new zone is complete. Another is deleting the old zone on the same day. Both create gaps that only some users see, which makes them hard to debug.
Do not raise TTLs back to long values until the move is stable for a few days. Do not test only from your office network. Local caches and split-horizon DNS can hide a broken public record. Do not put a CNAME at the apex of a zone; use A and AAAA or an ALIAS or ANAME feature if the provider supports it.
Watch DNSSEC and CAA. A missing DS record breaks validation. A stale CAA record blocks a new certificate. For mail, a missing MX or a wrong priority sends mail to the wrong host. Keep the old provider's billing active until you are done.
For a larger migration where DNS is one dependency among many, Cloudverg's Discovery and roadmap sprint is $9,500/month and covers architecture, risks and a phased plan. A simple zone move usually does not need it. If you use it, bring your record inventory and cutover window to the first session.
Frequently asked questions
How long does a DNS move take?
The registrar change is quick, but caches can hold the old NS records for the parent TTL. Plan for that window plus a margin. The zone itself can be ready days earlier.
Can I avoid downtime by lowering TTL?
Lower TTL helps only if you do it early enough for caches to pick up the shorter value. It does not override the parent NS TTL or a resolver that ignores TTLs. Keep both providers answering during the change.
What should I check first after changing nameservers?
Query the new authoritative nameservers directly, then check public resolvers for A, AAAA, MX and TXT records. Confirm the site loads, mail flows and certificates still issue.