Migrations
Previews and record statuses
Read a DNS migration preview record by record. Understand exact, translated, review, unsupported, and skipped statuses before writing the destination zone.
6 min read
On this page
A preview explains how every source record maps to the destination and then compares the translated result with the destination’s current records. The key point is that translation status and change-plan status answer different questions: Review can still be written, while Unsupported and Managed have no destination record in the plan.
Create and read a preview#
Start from an active source
Open Migrations → New migration. Choose Connected provider or Zone file under Where is the zone now?, then choose an active connection or Zone file under Where is it going?.
Select Create preview
The worker reads the source and stores a source snapshot. For a connected destination, it also lists zones and reads the matching zone if it exists. If it does not exist, the preview plans against an empty destination.
Start with Needs attention
In Preview, use Needs attention to see Review and Unsupported rows first. Expand a row with Show details to read every note and the source values that produced it.
Compare the plan counts
Below the translation summary, check Create, Update, Delete, and Already correct. These counts describe operations against the destination, not translation quality.
Choose how to treat destination-only records
Keep Keep extra records to merge into the destination. Choose Make an exact copy only when destination-only records should be deleted. The app changes to Reading zones while it rebuilds the plan.
Preview is free and does not modify either provider. If you need to inspect a file before creating a migration, use the zone-file validator, zone translator, or the credential-free CLI.
Record statuses#
The underlying statuses are exact, translated, warning, unsupported, and skipped. The UI deliberately labels two of them differently: warning appears as Review, and skipped appears as Managed.
| UI status | Stored status | Has a target record? | What it means | Apply behavior |
|---|---|---|---|---|
| Exact | exact | Yes | The normalized source record fits the destination without a translation note. | Included. |
| Translated | translated | Yes | A behavior-preserving or explicit conversion was made, such as SPF to TXT, TTL clamping, or alias representation. | Included. |
| Review | warning | Yes | The destination record can be written, but behavior may change or needs a human check. | Included. |
| Unsupported | unsupported | No | The type, value, alias, redirect, or provider feature cannot be represented through the destination API. | Omitted. |
| Managed | skipped | No | The destination creates this record itself: SOA, DNSKEY, or apex NS. | Omitted so the provider remains authoritative for it. |
Status is assigned by note severity. A provider-managed note wins first, then a missing target or blocking note becomes Unsupported, any warning becomes Review, any informational translation becomes Translated, and a row with no notes is Exact.
What normalization changes before status is assigned#
DNSMigrator first converts provider output into its canonical zone model. Owner names become fully qualified, TTLs become nonnegative integers, values are normalized and sorted, and duplicate values are removed. Multiple records with the same owner, type, and routing-set identifier merge into one record set; the merged set uses the lowest TTL. Hostname values are lowercased and dotted, IPv6 values are compressed, and TXT/SPF presentation quotes are removed.
That means Exact means “the same canonical record,” not “the provider APIs used identical text.” A long TXT value can be split into quoted 255-character segments when serialized for DNS and remain Exact, because those segments form one logical TXT value. See Translation rules.
A row can also represent more than one source record. For example, Route 53 alias A and AAAA sets that map to one CNAME are merged. Expand the row to see each source entry.
Translation status is not a destination diff#
Consider this translated target:
www.example.com. 300 IN CNAME app.example.net.Its translation status could be Exact or Translated. The plan then compares that target with what the destination currently has:
| Destination state | Plan bucket |
|---|---|
No www CNAME | Create |
| Same normalized target and TTL | Already correct |
| Same key, but another target or TTL | Update |
| Record exists only at destination and mode is Keep extra records | No operation |
| Record exists only at destination and mode is Make an exact copy | Delete |
SOA, DNSKEY, and apex NS are excluded from destination comparison because the DNS host manages them. The diff compares name, type, TTL, normalized ordered values, proxy state, and alias DNS name. Migration plans do not compare provider comments.
Common reasons for Review#
A Review row has a writable target but a warning note. Current warning-producing cases include:
- Proxying is lost because the destination has no equivalent CDN/WAF switch. Traffic will go directly to the stored address.
- An apex alias or CNAME was converted to static A or AAAA addresses. Those addresses will not follow later target changes.
- A one-time migration routing set is flattened into ordinary answers. Non-failover policies combine their values; failover keeps non-secondary answers and loses automatic failover.
- A CNAME supplied more than one target; only the first sorted target is kept.
- A CNAME shares its owner with another destination record, which most providers reject.
Review notes do not all have equal risk. A clamped TTL may be Translated, while static alias addresses or lost proxying are Review because service behavior can change. The full matrix is in Translation rules.
Common reasons for Unsupported#
A row becomes Unsupported when the destination catalog does not include the record type, a TXT/SPF value exceeds that provider’s total-value limit, an apex alias has no valid representation, or the source record is a provider-only feature with no equivalent.
Examples include a Namecheap URL redirect moving to an ordinary DNS provider, a Cloudflare redirect or Worker route moving elsewhere, an Azure resource alias without current static addresses, and a standard record type unavailable through a particular provider API. Provider support is cataloged on each page under Supported providers.
The preview displays Not migrated for these rows. A zone-file download omits them; the CLI’s translate command additionally appends unsupported source records as comments so you can recreate them manually.
Source completeness and provider metadata#
A connected provider is the most complete migration source because its adapter can retain API metadata such as proxy state, resource aliases, and routing policy. A BIND file carries ordinary DNS presentation data but cannot describe provider redirect rules, health checks, CDN proxy intent, or an alias that was flattened before export.
These gaps are source completeness issues, not translation statuses. Preview can classify only the records and metadata it receives. Compare a file export with the source provider console, and use an API connection when provider-specific behavior matters. The Cloudflare provider page, BIND zone file guide, and DNSSEC transition guide describe common losses.
Act on the preview#
- Resolve every Unsupported row that your services depend on.
- Expand every Review row and confirm the destination behavior is acceptable.
- Check mail-related MX, SPF, DKIM, and DMARC records against Move DNS without losing email.
- Confirm whether merge or exact-copy behavior is appropriate.
- Select Report if you need a printable summary of statuses, plan counts, verification, and activity.
- Continue to Apply and verify, or choose Download zone file for a file destination.