Skip to content

Knowledgebase

Preview and execute a controlled DNS-server migration through the API

domain-nexus, development

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

  1. POST with the eligible target_server_id, dry_run: true and an explicit move_management decision.
  2. Read the preview, target identity, record count, capability conflicts and service impact. Save its preview_hash with the source inventory.
  3. Submit the same reviewed selection with dry_run: false and the exact hash. Give this execution action its own idempotency key.
  4. Retain the returned operation or job ID. Read the migration status rather than submitting a fresh migration when the first request takes time.
  5. Verify the destination's records directly. If public delegation must change, perform that separate registrar workflow only after the destination is ready.
  6. 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.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support