Saylor InnovationsSAYLOR INNOVATIONS

Home / Guides / Web & Domains

Domain and Hosting Migration Guide

Web & Domains intermediate 7 min read Free to read · $0.01 via agent API Updated 2026-08-22

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.

Move a live domain between DNS or hosting providers with recorded records, reduced TTLs, certificate readiness, validation, and rollback.

Free to read here. AI agents can also fetch this guide directly over x402 for $0.01 — no account, structured JSON delivery.

Agent API →

The result you are building

Finished Result:

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.

Stop Before Proceeding:

Stop if the old zone cannot be exported, mail records are unknown, the new host cannot serve the domain via forced resolution, or database changes are not backward compatible.

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

  Start with the row that most closely matches the evidence. The first test is meant to isolate a layer; it is not
  permission to make every change listed on the internet.

    Evidence                  Likely layer       First decisive check            What the result means

    New site works at         Domain config      Force Host/SNI to new target    Add domain/certificate/vhost before DNS
    provider URL only                                                            cutover.

    Website works; email      Zone omission      Compare MX/SPF/DKIM/DMARC       Restore non-web records immediately.
    breaks                                       before/after

    Some users see old        Caching            Compare authoritative/public    Keep old host consistent; wait/recheck, do not
    site                                         resolver answers and TTL        thrash records.

    Login/forms fail          Production env     Callbacks/cookies/CORS/backen   Correct hostname-specific application config.
                                                 d endpoints

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.

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.

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.

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.

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.

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.

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

Starting Problem:

A nameserver move launches the site but email stops.

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.

Proof Of Completion:

Website remains live; inbound/outbound mail and authentication records pass; final zone inventory reconciles with baseline.

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 Do not cut over until forced-resolution TLS ready. 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 Use shared backend/read-only old host/redirect convergence. and reconcile.

Nameserver change seems Registrar Query parent/trace and fix authority, not zone ignored delegation/registry/cache/DNSSEC. 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

  • https://www.icann.org/resources/pages/dns-2024-01-17-en
  • https://letsencrypt.org/docs/
  • https://www.cloudflare.com/learning/dns/what-is-dns/