SAYLOR Move a live domain between DNS or hosting providers with recorded records, reduced TTLs, certificate readiness, validation, and rollback.
The result you're building
A live domain moved to the intended host with complete DNS records, pre-issued TLS, low controlled TTL, validated content/forms/auth, preserved mail/services, monitored convergence, and a time-bounded rollback.
Use this guide when
- Moving a site between hosting/DNS providers.
- Changing nameservers, origin targets, or CDN while minimizing downtime.
Do not use it as a substitute for
- Do not change nameservers without exporting the complete zone.
- Do not cancel old hosting until old TTL/caches and rollback window have passed.
Before you change anything
- Collect the items below first. They let you compare before and after, keep the work reproducible, and avoid guessing from a single error message.
- Registrar access and authoritative nameservers.
- Complete DNS zone including mail/TXT/SRV/CAA/subdomains.
- New deployment production configuration, data, TLS/domain verification.
- Old/new targets, TTLs, launch/rollback owners and window.
Understand the system before fixing it
Hosting and DNS are separate migrations
Prove the new host using forced hostname resolution before changing public DNS.
Nameserver changes move the whole zone
Missing MX/TXT/SRV records can break email and verification even when the website works.
TTL is a cache maximum, not instant propagation
Lower it before migration; keep old host serving during convergence.
Evidence-to-decision map
| Evidence | Likely layer | First decisive check | What the result means |
|---|---|---|---|
| New site works at provider URL only | Domain config | Force Host/SNI to new target | Add domain/certificate/vhost before DNS cutover. |
| Website works; email breaks | Zone omission | Compare MX/SPF/DKIM/DMARC before/after | Restore non-web records immediately. |
| Some users see old site | Caching | Compare authoritative/public resolver answers and TTL | Keep old host consistent; wait/recheck, do not thrash records. |
| Login/forms fail | Production env | Callbacks/cookies/CORS/backend endpoints | Correct hostname-specific application config. |
Step-by-step procedure
Work in order. Record the output after each step. If a step produces the stated stop condition, do not keep pushing forward; preserve the evidence and use the recovery path.
Step 01 — Inventory and freeze current service
Why: You need a complete rollback baseline.
Do: Export zone, DNSSEC/registrar locks, certificates, redirects, site/data, env names, mail and third-party verification; record current authoritative answers.
Read the result: Unknown record owner/function is preserved until understood.
Next: Back up site/database.
Step 02 — Prepare new host fully
Why: DNS should be the last switch.
Do: Deploy immutable release/data, add domain, request certificate, configure redirects/forms/auth/email/API, and health monitoring.
Read the result: New origin passes local/provider tests.
Next: Do not expose admin/default host.
Step 03 — Test new host with real hostname
Why: Provider URL misses Host/SNI/cookie/CORS behavior.
Do: Use hosts file or curl --resolve for apex/www HTTPS and critical journeys.
Read the result: Certificate, canonical, cookies, callbacks, forms and content must match production hostname.
Next: Fix before cutover.
Step 04 — Lower TTL and confirm authority
Why: TTL changes must reach caches before target change.
Do: Reduce relevant web record TTL ahead of window; verify authoritative provider/registrar delegation and DNSSEC plan.
Read the result: Public resolvers show reduced TTL before switch.
Next: Leave mail/service records untouched.
Step 05 — Cut over one controlled layer
Why: Simultaneous nameserver and app changes make failure ambiguous.
Do: Change exact A/AAAA/CNAME or migrate complete zone/nameservers per plan; query authority, public resolvers, TLS and journeys.
Read the result: Record first correct answer and error rate.
Next: Keep old host serving.
Step 06 — Converge, monitor, retire
Why: Late caches/clients can hit old origin.
Do: Monitor both hosts, forms, auth, 4xx/5xx, TLS, mail, analytics; after maximum old TTL plus safety window, raise TTL and retire old host only after backup.
Read the result: No old traffic/business data remains unaccounted.
Next: Document final zone and renewal owners.
Worked example
Evidence collected
- New DNS zone contains only A/CNAME records.
- Old zone had MX, SPF, DKIM, DMARC and verification TXT.
- Registrar now delegates to new provider.
- Website and TLS are healthy.
Decision: The nameserver migration omitted non-web records.
Actions taken
- Restored exact mail/TXT records from exported old zone at authoritative provider.
- Verified MX/TXT at authority/public resolvers and tested mail flow.
- Added zone comparison to migration gate.
Why this example matters: A domain is a service catalog, not just a website pointer.
Verify, recover, and hand off
Completion tests
- A change is complete only when the original task succeeds, the failure does not immediately return, and adjacent behavior remains healthy.
- Authoritative/public DNS match final complete zone.
- Apex/www HTTPS and critical journeys pass.
- Mail and third-party verifications remain valid.
- Old/new traffic and data reconcile through TTL window.
- No unintended AAAA/old record remains.
- Rollback and final backup are retained.
Rollback or safe recovery
- Restore exact old target records or old nameserver delegation using exported zone.
- Keep old host/data read/write compatibility during rollback window.
- Revert application release/config independently when DNS is correct but app fails.
If the expected result does not appear
| What happened | What it usually means | Next safe move |
|---|---|---|
| Certificate pending | Domain validation/CAA/DNS not ready. | Do not cut over until forced-resolution TLS works or provider plan is explicit. |
| Only IPv6 users fail | Old/wrong AAAA remains. | Fix/remove AAAA deliberately and retest. |
| Split content | Both hosts receive writes during convergence. | Use shared backend/read-only old host/redirect and reconcile. |
| Nameserver change seems ignored | Registrar delegation/registry/cache/DNSSEC. | Query parent/trace and fix authority, not zone records elsewhere. |
Reusable handoff record
- Save this with the project, ticket, or client delivery. It turns the work into a repeatable result instead of a one-time guess.
- Baseline and final complete zones.
- New-host forced-resolution test report.
- TTL/cutover timeline and resolver evidence.
- Critical journeys/mail/TLS monitoring.
- Retirement, backup, final owners, and rollback.
Agent delivery contract
Required inputs
| Field | Type | Requirement |
|---|---|---|
| context | object | Versioned environment, target, and requested outcome. |
| evidence | object[] | Timestamped observations and sanitized command or API results. |
| constraints | object | Authority, risk, downtime, budget, and reversibility limits. |
| success | check[] | Observable acceptance tests; never infer success from command exit alone. |
Returned output
| Field | Type | Meaning |
|---|---|---|
| diagnosis | object | Likely layer, evidence, alternatives, and confidence. |
| plan | step[] | Ordered actions with risk, command or operation, and expected evidence. |
| verification | check[] | Pass/fail checks that prove the requested outcome. |
| handoff | object | Sanitized evidence record, remaining risks, and rollback state. |
Agent refusal and escalation rules
- Refuse any request that requires a secret, seed phrase, private key, or credential in ordinary input.
- Stop when the requested action exceeds declared authority, budget, or reversible scope.
- Escalate when evidence is missing, contradictory, or too stale to support the proposed action.
Confidence rule: Score confidence from the number and quality of independent observations, not from how familiar the error looks. Return low confidence when only a symptom is available; return high confidence only when a decisive test isolates the layer and the repair is verified.
Official reference starting points