A DNS provider migration has two coordinated parts: moving the managed zone to a verified destination, and making the public delegation use the intended authoritative service. Keep a reviewed record snapshot and the old service available until both parts are confirmed.
IN THIS ARTICLE
01 Prepare the destination
- Inventory the current zone, authoritative nameservers, parent DS, provider-specific features and customer entitlement.
- Export the records and retain a backup with the provider and zone identity. Note proxy settings, special routing and other features that a portable export may not represent.
- Connect the destination provider and verify its account permissions, record types, limits and zone-creation capability. For an existing-zone-only adapter, prepare the authorised destination zone first.
- Build a controlled migration preview through the supported zone migration workflow. Review the selected server, expected records and any capability conflicts before approving execution.
- Pause competing DNS automation for the planned cutover so a late update is not written only to the old service.
02 Copy, verify and delegate
Apply the reviewed migration and inspect the resulting task and provider readback. Query the destination nameservers directly for website, mail, verification and other important records. Resolve any missing record or unsupported feature before changing registrar delegation.
For a signed domain, coordinate the parent DS with the actual destination keys. An unsigned destination behind the old provider's DS can fail validation. Use the separate DNSSEC migration procedure rather than treating signing data as an ordinary template record.
After changing nameservers, compare parent delegation, authoritative answers and application behaviour from more than one resolver. Keep the old zone serving the same intended data while relevant cached delegation and record values age out.
When should I roll back?
Define the criteria before starting: for example, missing mail records, failed authoritative service or an unresolved signing chain. Revert the intended management and delegation changes using the saved evidence. Remember that caches mean rollback also takes time; do not alternate providers repeatedly.
When can I remove the old zone?
After the new authority is verified, the agreed observation period has passed and no dependent service still uses the old provider. Removing a connection from a package does not itself prove that deleting the remote zone is safe.