A DNS migration is often described as copying records and changing nameservers. That skips the hard part: proving that the copied zone represents every service and that operators can recover if delegation or proxy behaviour differs from the old provider.
Build an authoritative inventory
Export the existing zone and compare it with application, mail, certificate, and vendor records. Pay attention to records created outside normal change processes. Identify which hostnames are proxied, which must remain DNS-only, and which services depend on source IP visibility or non-HTTP protocols.
Separate record migration from delegation
Create and review the destination zone before changing nameservers. Check A, AAAA, CNAME, MX, TXT, CAA, SRV, and DNSSEC-related state. Resolve critical names directly against the destination authoritative servers where possible. This isolates record errors from delegation errors.
Plan mail and certificate checks
Validate MX targets and SPF, DKIM, and DMARC records as exact DNS data. Confirm certificate validation records and CAA policy. A website can appear healthy while email delivery or renewal automation is already broken.
Change delegation with evidence ready
Record the old nameservers, registrar state, destination nameservers, and validation results. Monitor authoritative answers from multiple resolvers after the change. Do not treat one cached answer as proof of global state.
Know what rollback can and cannot do
Restoring old nameservers is a rollback action, but resolver caches mean it is not instantaneous. Keep the old zone intact during the transition and avoid unrelated record changes until delegation is stable. Document which provider is authoritative at each stage so operators do not update the wrong copy.