Skip to content

Migrations

Migration workflow

Follow the complete DNS migration workflow from source connection and record preview through destination apply, verification, nameserver cutover, and rollback.

6 min read

On this page

What are the DNS migration steps?#

Use the interactive DNS migration checklist alongside this product workflow for TTL, email, DNSSEC, testing, and old-provider decommissioning checks.

Choose the source

Open Migrations → New migration. Under Where is the zone now?, choose Connected provider or Zone file, then select the zone or paste the file.

A connected provider gives the most complete source because its API can expose aliases, routing, and proxy metadata. A pasted BIND zone file is useful when an API connection is not available, but it contains only what the file format can represent.

Choose the destination

Under Where is it going?, choose an active connection or Zone file. A read-only connection can be previewed but cannot complete apply. File-to-file conversion belongs in the zone translator, not the migration workflow.

Create the preview

Select Create preview. DNSMigrator reads the source, saves a source snapshot, translates each record against the destination’s cataloged capabilities, and—when the destination is connected—reads its current zone. Nothing is written in this stage.

Read Previews and record statuses before continuing. In particular, Review rows are included in the proposed destination, while Unsupported rows are omitted.

Review the change plan

The preview’s translation summary explains what happened to the source records. The separate plan shows Create, Update, Delete, and Already correct counts against the live destination.

Keep extra records is the default: records found only at the destination remain in place. Make an exact copy adds those records to the delete plan. Changing this control rebuilds the preview.

Apply and verify

For a connected destination, unlock the required migration tier, type the zone name into the confirmation field, and select Apply n changes. Apply creates the destination zone if necessary, snapshots its current records, and rebuilds the plan against that live snapshot before writing.

Verification then asks the destination’s own authoritative nameservers for every planned record set. See Apply and verify for exact comparison rules and retry behavior.

Cut over or download

Once the records are in place, use Cut over to choose We switch it or I’ll switch it. DNSSEC-aware cutovers remove the old DS first, switch the delegation, watch propagation, and then establish a new DS. Read Nameserver cutover and DNSSEC transitions before starting.

If Zone file is the destination, the workflow ends at Download zone file. No provider account is written and no apply purchase is required.

What each stage guarantees#

StageReadsWritesGuarantee
PreviewSource and, when connected, destinationMigration snapshots and plan onlyNo provider records are changed.
ApplyDestination immediately before writingDestination zone and planned record operationsThe source is not changed by apply. A fresh plan is calculated against live destination records and used for the write.
VerifyDestination authoritative nameservers; source authoritative answers for aliases when availableVerification result onlyLiteral answers must equal the plan; aliases must resolve.
RollbackCurrent destination and pre-apply snapshotOnly safe inverse operations at the destinationLater edits that no longer match DNSMigrator’s write are preserved.
CutoverRegistry delegation, DNSSEC state, propagationRegistrar NS/DS through supported APIs; optionally source TTLsDelegation work is kept separate from record apply.

The optional Lower TTLs to 5 minutes at the old provider first cutover setting is the one exception to the usual source read-only rule. It updates eligible source TTLs and does not restore them automatically. See Nameserver cutover.

Migration statuses#

The badge at the top of a migration uses these labels. A failed preview, apply, verify, or rollback job changes the migration to Needs attention while retaining snapshots and successful apply operations recorded so far. Cutover failures use the cutover panel’s separate Needs attention state.

Stored stateUI labelMeaning
draftDraftA migration record exists but previewing has not started. Normal web creation proceeds directly to reading.
previewingReading zonesThe worker is reading, translating, and comparing zones.
previewedReady to reviewThe translation and destination change plan are available.
applyingApplyingDestination operations are running.
verifyingVerifyingAuthoritative checks are running. Apply enters this state automatically.
appliedAppliedRecords were written, but one or more verification checks do not currently match.
verifiedVerifiedVerification has no failed record sets. Informational alias results may still be present.
failedNeeds attentionPreview, apply, verify, or rollback encountered an error. Read Activity and the error callout.
rolling_backRolling backSafe inverse operations are running.
rolled_backRolled backThe safe rollback plan completed.
cut_overCut overThe cutover workflow reached Done.

Cutover also has its own running, waiting, failed, done, and reverted states. Those are explained in Nameserver cutover.

Pricing and permissions#

Creating and reviewing a preview is free. Applying to a provider requires an administrator and a per-zone entitlement unless the workspace subscription includes it:

NeedTier in the appPrice and scope
Apply up to 50 translated target record setsMigrate$9 one-time; 7-day rollback window
Apply more than 50 target record sets, or use guided cutoverMigrate + cutover$29 one-time; 30-day rollback window
Let DNSMigrator call the registrar API for cutoverAutomated$49 one-time; 30-day rollback window
Start bulk migrationsAgency workspace planIncludes migrations through the guided-cutover tier, not automated cutover

The Pro subscription does not include per-zone applies. The Agency subscription includes the cutover tier, so it covers any-size apply and guided cutover. Current offers are also listed on Pricing.

Choose the right source#

Use an API connection when possible. It preserves provider metadata such as Cloudflare proxying, Route 53 aliases, and routing policies that ordinary DNS answers or transfers cannot reconstruct. Setup and capability details live under Supported providers.

Use a BIND file for an offline export when an API connection is unavailable. A file cannot preserve proxy switches, provider-resource aliases, routing policies, redirect rules, or health checks, so compare it with the provider console before relying on it.

Run the file through the zone-file validator first: the migration parser can skip unreadable lines while continuing with records it did understand.

Where to go next#

DNS migration workflow questions#

What does a DNS migration change?
A DNS migration copies or translates zone records to a new authoritative provider and later changes delegation to that provider. It does not move the domain registration unless you separately transfer the domain.
Is a DNS migration preview free?
Yes. Preview reads the source and destination, translates the records, and builds a change plan without writing provider records. Applying that plan can require a one-time migration entitlement.
Does DNSMigrator write to the old DNS provider?
Preview, destination apply, verification, and rollback do not write to the source. The only optional exception is Lower TTLs to 5 minutes at the old provider first during cutover.
When can I turn off the old DNS provider?
Keep it serving matching answers until nameserver propagation is complete and you no longer need the switch-back path. Cached delegation can continue sending some resolvers to the old provider after the registrar shows the new nameservers.