Quickstart: your first migration

Open Connections and choose Connect a provider. Search for the current DNS host, open it, and follow its setup steps. Provider-specific instructions live under Supported providers; for example, see Cloudflare or Amazon Route 53.

Give the connection a recognizable Name, enter the requested values, and choose Connect. Creating a connection immediately runs an access check. A successful row is marked Active and shows Read or Read + write. If you change permissions at the provider later, use Check access on the connection row.

Use the narrowest permission that fits the job. A source only needs to list and read its zones for a normal migration.

Use Connect a provider again for the destination account. Grant the write permissions named in that provider’s guide if you plan to apply through DNSMigrator. A read-only destination can be selected for a preview, but the provider will reject an apply.

Connections are workspace-scoped. You can migrate between two accounts at the same provider as long as they are different connections; the preview labels that case Same provider, different account.

Choose New migration in the app rail. Under Where is the zone now?, leave Connected provider selected, pick the source Connection, and select the zone. DNSMigrator asks the provider to list visible zones. If that API cannot list them, enter the zone manually with Use this zone.

You can instead select Zone file and paste an export. A file cannot preserve API-only metadata such as proxy state, provider aliases, or routing policies, so compare the export with the source provider before relying on it. See BIND zone files and Previews and record statuses.

Under Where is it going?, select the destination connection. Choose Zone file if you want a translated download and no provider write. File-to-file conversion belongs in the zone translator, so that destination is disabled when the source is already a file.

Review the sentence under Preview, then choose Create preview. This queues reads of the source and, for a connected destination, the destination’s current zone. Nothing is written during this stage.

The Preview section classifies each source record as Exact, Translated, Warning, Unsupported, or Skipped. Read every warning and unsupported reason. The plan separately counts Create, Update, Delete, and Already correct operations against the destination’s live state.

The default destination mode is Keep extra records. Records found only at the destination remain untouched. Select Make an exact copy if those extra records should be deleted. Changing the mode rebuilds the preview.

Use Translation rules for apex aliases, proxy state, routing, TTL, and TXT behavior. Download the zone file or open Report if you need a review artifact before applying.

Applying is a paid step unless the workspace already has an applicable entitlement. The required offer is shown in the apply card; see Plans and billing.

When ready, type the zone name into the confirmation field and choose Apply N changes. DNSMigrator creates the destination zone if needed, reads its current records, stores a destination snapshot, and calculates the plan again. If the live plan differs from the preview, Activity records the revised counts and apply uses those fresh operations rather than replaying the old plan. The source is not used as a write target.

The activity timeline reports each stage and provider error. A partial apply records only successful operations so those writes can still be rolled back.

After apply, DNSMigrator asks the destination provider’s own authoritative nameservers for every target record set. Literal records pass only when the returned value set exactly matches the target. An ALIAS, apex CNAME, or provider-resource alias is queried as an address record; a CDN or load balancer may resolve to different but valid addresses and is reported as informational rather than silently treated as equal.

The Verification panel puts mismatches first and lists missing or extra answers. DNSMigrator retries initial mismatches. Use Verify again after fixing a provider-side issue. Do not cut over until required records answer correctly. See Apply and verify.

Once records have been applied, the Cut over panel offers We switch it and I'll switch it. Automatic mode requires an active registrar connection and the Automated one-time tier. Guided mode shows the nameservers to set and checks your work.

If DNSSEC is active, the cutover sequence removes the old DS record, waits before changing nameservers, enables signing at the destination when its adapter supports that operation, and publishes the new DS record. When a registrar or provider cannot perform a step through its API, the panel pauses with the exact manual action. Read Nameserver cutover and DNSSEC transitions before starting.

The optional TTL-lowering checkbox updates eligible source records and waits out their previous TTLs. Otherwise, both providers should keep serving matching answers while recursive resolvers move to the new delegation.

During the offer’s rollback window, Roll back removes records DNSMigrator created, restores records it changed, and recreates records it deleted. At the start of the rollback job, the destination is read again. If someone changed one of those records after the migration, DNSMigrator skips it instead of overwriting the newer value.

If nameservers have already changed, use Switch back to the old provider before rolling back destination records. The source zone remains available either way; only its eligible TTLs were modified if you selected TTL lowering. Read Rollback for the exact scope.