A DNS-server migration copies a zone to an eligible target and can move its management binding. It is a controlled operation with a current preview, not a shortcut for changing a whole package's master server or updating registrar delegation.
| Method | Resource | Scope | Idempotency-Key |
|---|---|---|---|
POST |
/v2/dns/zones/{zoneId}/migrations |
dns:migrate |
Required |
GET |
/v2/dns/migrations/{operationId} |
dns:read |
Not required by this route |
01 Prepare the destination
Confirm the destination server supports the zone's record types and required features. Check the account's ownership, capacity and assignment permissions. Existing hosting, protected records or a remotely owned zone with the same name may require review. Preserve a backup and record which nameservers currently answer publicly.
Compare provider-specific settings separately. A portable DNS record set may not reproduce proxying, routing policies, signing arrangements or native secondary configuration. Do not remove the source while these dependencies remain unresolved.
02 Review and execute the migration
- POST with the eligible
target_server_id,dry_run: trueand an explicitmove_managementdecision. - Read the preview, target identity, record count, capability conflicts and service impact. Save its
preview_hashwith the source inventory. - Submit the same reviewed selection with
dry_run: falseand the exact hash. Give this execution action its own idempotency key. - Retain the returned operation or job ID. Read the migration status rather than submitting a fresh migration when the first request takes time.
- Verify the destination's records directly. If public delegation must change, perform that separate registrar workflow only after the destination is ready.
- Keep the previous DNS service available during the planned transition and monitor both web and mail answers before retiring it.
Common questions
Why does the API require another preview?
The source zone, target or ownership evidence may have changed. The execution checks the reviewed plan. A conflict means you should inspect the new differences and approve a fresh plan.
Does move_management change my nameservers?
It concerns where Domain Nexus manages the zone. Public parent delegation is a separate setting. Compare the required destination nameservers with the registrar's current set.
Can I use this to change a package's master for all customers?
Use the package replication and master-change procedure for that administrative decision. A single-zone migration does not stand in for a reviewed package-wide replication plan.
Related articles
- Move managed zones to another DNS provider with a verified rollback point
- Change a DNS package master without confusing replication and delegation
- Approve a current backup restore preview before changing DNS
- Choose hosting nameservers or DNS management for your domain
- Preview and submit a cross-zone DNS operation