Migrations
Nameserver cutover
Change nameservers safely with a guided or automated DNS cutover, propagation tracking, DNSSEC handling, old-provider overlap, and a switch-back path.
7 min read
On this page
Requirements and modes#
The app exposes Cut over after a connected-destination migration is Applied or Verified. Start from Verified whenever possible; Applied means one or more authoritative checks still fail.
Choose one mode:
| UI choice | Stored mode | Who changes the registrar | Requirement | Minimum tier |
|---|---|---|---|---|
| We switch it | automatic | DNSMigrator calls a selected active registrar connection. | An active connection for the account holding the domain. | Automated, $49 one-time |
| I’ll switch it | guided | You make the displayed NS and DS changes; DNSMigrator polls DNS and offers I’ve done this, check now on manual checkpoints. | No registrar connection. | Migrate + cutover, $29 one-time |
Agency includes the guided-cutover tier but not automatic cutover. Pro does not include either per-zone cutover tier. See Plans and billing.
Automatic mode can still need manual work. If the selected registrar adapter cannot remove or publish DS records, the step tells you to use the registrar dashboard and keeps checking DNS. Provider and registrar capabilities are listed under Supported providers and Registrars.
How to change nameservers during a migration#
Use the interactive DNS migration checklist to confirm the records, email, TTL, DNSSEC, and rollback work that surrounds this nameserver change.
Verify destination answers
Confirm the migration is Verified and review the Verification panel. Informational alias results can be acceptable; missing literal answers are not. See Apply and verify.
Choose the mode
In Cut over, choose We switch it and select Registrar account that holds domain, or choose I’ll switch it and copy the displayed nameservers.
Decide whether to lower TTLs
Optionally select Lower TTLs to 5 minutes at the old provider first. This is available only when the source is a connected provider and is the only cutover option that writes to the old DNS zone.
Select Start cutover
DNSMigrator reads the live DNSSEC state and current registry nameservers, stores those original nameservers for switch-back, and creates only the steps needed for this zone.
Follow waiting steps
In guided mode, make the requested registrar change, then select I’ve done this, check now where offered. In automatic mode, leave the panel open or return later; jobs continue in the worker and the page refreshes while active.
Confirm completion
The workflow completes after enough propagation probes see the destination and any DNSSEC re-signing steps finish. The migration badge becomes Cut over.
Cutover step list#
Steps are conditional and run in this order:
| Step shown in the panel | When included | What the worker does |
|---|---|---|
| Lower TTLs at the source | You selected the TTL option. | Updates eligible source records, then waits out the largest old TTL among those updates. |
| Remove the DS record | Live DNSSEC detection reports the zone signed. | Removes every DS through a capable registrar API or asks you to remove it, then polls until no DS is detected. |
| Wait for the DS record to expire | DNSSEC was detected. | Waits a fixed 86,400 seconds after DS removal is observed. |
| Switch nameservers | Always. | Requests or asks for the stored destination nameserver set, then checks the registry delegation. |
| Watch propagation | Always. | Samples public resolvers for NS and continues when at least 80% of returned probes match. |
| Enable DNSSEC at the new provider | DNSSEC was on before the move. | Calls the destination DNSSEC API when available; otherwise marks the API step skipped and tells you to use the dashboard. |
| Publish the new DS record | DNSSEC was on before the move. | Reads destination DS data and publishes it through the registrar API when both sides support that, or asks you to copy it. |
An internal Done step closes the cutover and changes the migration to Cut over. If DNSSEC is not detected at start, all DS and re-signing steps are absent. Check uncertain zones first with the DNSSEC checker or DNSSEC migration checker.
Lower TTLs before the switch#
When selected, this step reads the source through its connected provider and changes records whose TTL is greater than 300 seconds. It excludes:
- SOA records.
- Apex NS records.
- Provider alias records.
- Records already at or below the target.
The service constrains a requested target to 60–3,600 seconds; the current UI requests 300 seconds. After writing, it waits for the largest previous TTL among changed records—not merely 300 seconds—so resolvers have time to discard old values. If no record needs an update, the step continues immediately.
This setting does not change the parent registry’s delegation TTL. It also does not restore the original source TTLs after completion or switch-back. For planning background, read Lower TTLs before a DNS migration.
How long does a nameserver change take?#
Nameserver propagation is bounded by cached delegation and record TTLs, not by the moment the registrar accepts the change. Estimate the overlap with How long does DNS propagation take?, then enter your own values below.
Use the dig commands for checking a DNS migration when you need to query the parent or either provider directly.
Manual NS and DS checkpoints are polled every 300 seconds. Automatic NS changes are first rechecked after 120 seconds; automatic DS publication is first rechecked after 300 seconds. The propagation step also checks every 300 seconds and stores up to the latest 100 samples for the panel.
The progress bar’s denominator is the number of public resolver probes returned by the propagation service. Completion at 80% is a workflow threshold, not proof that every resolver has expired its cache. Keep both providers answering after Complete.
Each individual step fails if it remains incomplete for more than 72 hours from when that step began. A failure leaves the cutover as Needs attention, keeps its details, writes an event, and sends configured notifications. It does not trigger an automatic revert or expose an in-place retry. Assess the DNSSEC and delegation state before using Switch back to the old provider; after that cutover is marked reverted, the panel allows a new start.
How to read the cutover panel#
| Step state | Display | Meaning |
|---|---|---|
pending | Muted dot | A prior step has not finished. |
running | Spinner | The worker is performing or checking the step now. |
waiting | Clock | DNS, a provider, a registrar, or you must complete something before the next check. |
done | Check | The condition was observed or the API operation completed. |
skipped | · skipped | No supported destination API method was available for that automated substep; follow the detail text. |
failed | Error icon | The cutover paused and displays the error. |
Overall cutover badges are Running, Waiting, Complete, or Needs attention. These are separate from the main migration status described in Migration workflow.
Switch back#
The cutover stores the original registry nameservers at start. Switch back to the old provider behaves differently by mode:
- In automatic mode, if Switch nameservers reached
done, DNSMigrator calls the registrar to restore the saved old nameservers. If the switch had not completed, it stops the workflow without an NS API call. - In guided mode, DNSMigrator cannot change the registrar. The dialog shows the saved old nameservers; you must set them there yourself. Confirming the app action marks the workflow
revertedbut does not verify that manual change first.
After switch-back, watch the propagation checker and keep the destination answering while cached delegations drain.
Do not turn off the old provider early#
The nameserver change is observed at different times by different resolvers. A resolver still using the old delegation must receive the same usable answers as one using the new delegation. Leave the old zone intact, avoid one-sided record edits during the overlap, and postpone cancellation until the old delegation is no longer in use and the switch-back path is no longer needed.
For a broader operational checklist, use How to migrate DNS without downtime. For the cryptographic order and its failure modes, continue to DNSSEC transitions.