Define exactly what is moving
A website redesign, a move to a new web host, a change of DNS provider and a registrar transfer are different operations. This guide addresses the DNS provider or hosted-zone change: authoritative name servers for an existing domain will change. The website may continue on the same server, and the domain registration may stay with the same registrar. Write down the current provider, proposed provider, registrar account, zone name and person authorised to make the delegation change. List the customer-facing services that depend on the zone before planning a switch: the main website, www, email reception, outgoing mail authentication, booking links, payment callbacks and any verification records. Treat subdomains as separate entries rather than assuming they follow the main address. This scoping step prevents a team from celebrating a working homepage while mail or a supplier integration has disappeared.
Capture the old state
Export or manually record every relevant record name, type, value, TTL and any provider-specific routing or health-check setting. Include A, AAAA, CNAME, MX, TXT and CAA records where present, as well as any delegated subzones. Record the old authoritative name servers and the registrar-side delegation separately; these are related but not interchangeable. Keep sensitive account credentials out of the editorial change sheet. A record inventory is useful only if an owner checks what each entry supports: an unfamiliar TXT token may be essential for mail, certificate issuance or a connected service. Compare the list with configuration held by the web host, mail provider and payment or booking supplier. Mark records whose purpose is genuinely unknown for investigation before cutover, rather than deleting them because they look obsolete.
Prepare the new zone before delegation
Create the destination zone and populate it with the intended records while the old provider still serves live traffic. AWS Route 53 migration guidance explicitly separates creating the new hosted zone, copying records, and then updating name servers. Use that sequence even if your chosen provider has different screens. A pasted record is not necessarily equivalent: providers may handle aliases, root-domain records, trailing dots, proxied traffic and health checks differently. Review every transformed entry against the service owner. If the new provider assigns its own set of name servers, record the exact assigned names rather than reusing a generic example. Do not point the registrar at an empty zone to make progress appear visible. The preparation stage should end with a new zone that answers the expected records directly, while the old zone remains available for customers.
Plan TTL without promising instant propagation
TTL tells a resolver how long it may cache a DNS record before querying again. AWS recommends temporarily shortening TTLs for critical changes so a rollback can take effect sooner, and its hosted-zone migration guide also discusses lowering NS TTL on both sides. Make such a change ahead of the planned switch and allow the previous, longer cache lifetime to expire; changing a value five minutes before cutover does not evict answers already cached for much longer. Choose a value appropriate to the provider and operational load, and document it rather than promising a fixed global propagation time. AWS gives a 60 to 900 second recommendation for NS TTL in its particular migration procedure, not a universal guarantee for every DNS setup. After the transition settles, the team can restore a normal TTL based on its operating needs.
Check DNSSEC and certificate dependencies
If DNSSEC is enabled, delegation is more than replacing an NS list. The DS record at the parent zone has to agree with the keys used by the new DNS setup; an inconsistent chain can make valid-looking records fail validation. AWS migration instructions specifically require removing the old DS record before a Route 53 hosted-zone migration and re-enabling DNSSEC afterward with a new DS record. Follow the destination provider and registrar instructions for the actual service, and plan this step with someone who understands the current signing arrangement. Also identify certificate renewals or validation challenges that may need DNS changes during the window. AWS calls out certificate renewal as an operation that can interfere with migration. Avoid scheduling the switch alongside another service change that makes a failed lookup hard to diagnose.
Rehearse a website and mail check
Consider a shop whose root domain serves a website, www is an alias, and MX records route orders to a mail provider. Before changing delegation, query the new zone directly for the root, www and MX answers, and compare them with the approved inventory. Check the mail-related TXT entries rather than assuming an MX match proves sending will work. Open the intended website through the new route in a controlled test where possible, confirm that its certificate covers the expected hostname, and submit a harmless enquiry or booking test. The exact testing method depends on the hosting architecture; changing a local resolver or test hostname must not accidentally alter live customer traffic. Keep test identifiers so staff can remove the sample records. The example values are deliberately unspecified: the business must use its own approved records, not copy an invented address from a guide.
Make the delegation change observable
At the agreed window, one authorised operator changes the registrar-side name servers and another person records the exact time and values. Query authoritative answers from the destination and then test what several recursive resolvers return over time. Different resolvers may temporarily give different answers because they hold different cache states. Do not describe a provider dashboard saying the change is complete as proof that every customer can already reach every service. For Route 53, AWS documents an INSYNC status for propagation of a change within its own service; that status is useful operational evidence but does not erase external caches or verify website and mail behaviour. Monitor actual website responses, TLS, enquiry delivery and mail receipt while retaining the old zone during the observation period.
Set rollback triggers in advance
Agree what failure justifies reversing the delegation: for example, the approved web hostname resolving to an unexpected endpoint, a certificate error, or missing business mail after the normal provider checks. Assign the decision owner and document the old name servers and old zone state before the window. Reverting the NS values is a plan, not an instant undo button, because some resolvers may still cache the new delegation. Correcting a bad record in the new zone may be faster for one defect, while a wider zone problem may warrant rollback. Decide based on the observed fault and the operational impact. Keep both zones coherent while mixed cached answers are possible. Do not delete the old zone or cancel the old service on the same day merely because a handful of spot checks pass.
Close only after service-level evidence
A complete handover contains the approved record diff, change time, direct authoritative-query results, checks from external resolvers, website and mail test outcomes, certificate status, any DNSSEC action and the owner for future updates. Repeat tests from more than one network where practical. Ask service owners to confirm their own flows, particularly a payment notification or appointment confirmation that a DNS lookup alone cannot validate. Log anomalies with time, affected hostname and the resolver or service used; this makes a delayed cache answer distinguishable from a bad destination record. Restore the intended steady-state TTL after the change is stable. Finally, update the runbook with the new authoritative provider and registrar contact route. The useful success claim is that named business services passed named checks, not that the internet has somehow been proven universally consistent.
Decide who signs off
The person who changes DNS can confirm that records were entered and that authoritative servers answer, but cannot alone verify every business journey. Ask the mail owner to confirm inbound and outbound messages, the web owner to confirm the intended hostnames and certificate, and the owner of any booking or payment integration to confirm a controlled event. Agree which results are required before the old zone can be retired. Keep the old-zone subscription active until the observation window and service owners have finished, since a later rollback cannot use a deleted configuration. If the provider is also changing web hosting, track that as a separate release with its own application tests. This separation makes a failed order confirmation diagnosable: the team can check DNS answers, then application behaviour, instead of assuming every symptom has the same cause.
Before you release the change
- Inventory web, mail and verification records before the switch.
- Verify the destination zone and DNSSEC plan before changing NS.
- Keep old service and a tested rollback decision path during observation.
