Domain Transfer Step-by-Step: Move Your Website and Hosting Without Downtime

If moving your website sounds like changing tires while the car is in motion, you’re not far off—but it’s very doable with a plan. This guide walks you through a clean, low-stress migration: moving your domain, DNS, hosting, and email with no (or near-zero) downtime. We’ll mix practical steps with current industry developments so you’re not just copying files—you’re future-proofing your stack.

What “no downtime” really means in 2026

No downtime means users don’t see errors, and background systems (APIs, payment gateways, email) keep working. A few nuances:

– DNS “propagation” isn’t a fixed 48 hours anymore. Traffic moves as caches expire based on your TTL (time to live). Lower TTLs in advance and your cutover can be minutes, not days.
– Anycast DNS and CDNs reduce risk by routing users to the nearest, healthy edge. If you plan well, the switch can be seamless.
– SSL/TLS and email deliverability are now first-class citizens. If you move fast but forget certs, DKIM, or DMARC, you’ll trade uptime for broken padlocks or spam-folder purgatory.

Map the moving parts: registrar, DNS, hosting

There are three systems that people conflate:

– Domain registrar: where your domain is registered (the billing/ownership layer).
– DNS host: where your DNS zone is managed (nameservers + records).
– Hosting: where your web app, files, databases, and sometimes email live.

You can move them together or separately. For zero downtime, moving hosting first (and DNS second) is often safer. Registrar transfers can wait until after traffic is stable.

Pre-flight audit (do this before anything else)

– Domain status: Locked? When does it expire? Registrar login access confirmed? WHOIS contacts current? Any 60-day transfer lock after a recent ownership/contact change?
– DNS inventory: Export your zone. List A/AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), SRV, and any ALIAS/ANAME. Note TTLs.
– DNSSEC: Is DS enabled at the registry? Capture current DNSSEC settings.
– SSL/TLS: Where are your certs issued (Let’s Encrypt, provider-issued)? Are you using HTTP-01 or DNS-01 validation?
– Email: Are you on Google Workspace, Microsoft 365, or your host’s mail? Record all MX and TXT values. If you send >5,000/day, align with Gmail/Yahoo 2024 bulk-sender rules (SPF, DKIM, DMARC p=reject/quarantine, RFC-compliant List-Unsubscribe).
– App specifics: Framework versions (PHP/Node/Python), database versions, cron jobs/queues, file storage paths, cache stores, environment variables, secrets.
– Third-party services: CDN/WAF (Cloudflare, Fastly), image/file storage (S3), search (Elasticsearch), payments (Stripe webhooks), social logins (OAuth callback URLs).

Build the destination first

Stand up the new hosting before you touch DNS.

– Provision servers or a managed platform with the right versions and extensions.
– Create databases and users with least-privilege access.
– Copy files and import the database. For large sites, do an initial bulk copy, then plan a delta sync at cutover.
– Replicate cron jobs/scheduled tasks and background workers.
– Ensure environment variables and secrets (.env, KMS, Vault) are in place.

Testing without exposing it publicly:

– Use a temporary domain from your host or edit your local hosts file to map your domain to the new server IP.
– Test end-to-end: logins, carts/checkout, forms, search, file uploads, webhooks, API integrations, and email sending.
– Confirm performance and caching behaviors (application cache, CDN cache headers).

SSL/TLS on the new stack:

– If you’re changing DNS providers or hosts that issue certs automatically, pre-provision certificates. DNS-01 validation can be done in advance at your current DNS provider by adding TXT records.
– If you use HSTS, keep preload considerations in mind. Never enable preload until you’re sure HTTPS is working everywhere.

CDN/WAF:

– If you use Cloudflare (or similar), add the site at the new account/provider and pre-create DNS records in “DNS-only” mode to test origin connectivity. You can flip the proxy back on at cutover.

Prepare DNS for a clean cutover

DNS timing buys you the “no-downtime” cushion.

– Lower TTLs: 24–48 hours before the move, reduce TTLs for A/AAAA, CNAME, MX, and TXT to 300 seconds (5 minutes) or even 60 seconds for hot paths. Do this at your current DNS host.
– Export your zone: Take a full backup as a safety net.
– Pre-create the zone at the destination DNS provider if you’re changing nameservers. Add all records (including MX/SPF/DKIM/DMARC).
– DNSSEC: If you’ll change nameservers, plan to temporarily disable DS at the registry shortly before the switch to avoid validation failures, then re-enable with the new provider’s DS after the cutover.
– Email readiness: If you’re not changing email providers, copy the exact MX/SPF/DKIM/DMARC values to the new zone. If you are changing email providers, coordinate MX and DKIM switches with lower TTLs and test mail flow.

Sync data and pick your cutover window

– For CMS/e‑commerce sites, schedule the final cutover during your lowest traffic window. Communicate brief “order processing may be delayed” messaging if needed.
– Do a final rsync or incremental file sync.
– Temporarily freeze writes or switch the app to maintenance/read-only for the final DB sync to avoid split-brain data.
– Snapshot both old and new systems before you proceed. Snapshots make rollbacks trivial.

Switch traffic intelligently

There are three common patterns:

Option A: Keep nameservers, switch A/AAAA records

– Update the A/AAAA records at your current DNS host to point to the new server IP. For subdomains behind a CDN, update the origin IP at the CDN.
– With a low TTL, most users will move within minutes. Some resolvers will hold older IPs until TTL expiry; that’s why you keep the old host up for at least the max TTL plus a buffer.

Option B: Change nameservers (move DNS providers)

– Disable DNSSEC (remove DS at the registrar).
– Change nameservers at your registrar to the new provider’s nameservers.
– Wait as resolvers refresh NS and then the new zone records. With low TTLs, this can complete quickly, but budget a few hours.
– Re-enable DNSSEC using the new provider’s DS record once traffic stabilizes.

Option C: Cloudflare or another proxy

– Add the site at the new account/provider, import or recreate DNS records.
– Keep the proxy off for initial origin testing (DNS-only), then enable the proxy once the origin is healthy.
– If switching Cloudflare accounts, NS changes are required. Follow Option B, then proxy.

Validation steps:

– From multiple networks (mobile, ISP, VPN), curl your domain and confirm the server signature or a unique header from the new host.
– Check IPv4 and IPv6. If your new host supports IPv6 and the old didn’t, add AAAA records intentionally.
– Test TLS for all hostnames and subdomains (www, bare domain, API, admin).
– Spot-check email: send and receive from multiple providers, verify SPF pass, DKIM pass, DMARC alignment. Tools like Gmail’s original message view and mail-tester help.

Keep the old host running for at least 24–72 hours. Don’t cancel it yet.

Transfer the registrar (optional, do it last)

Many teams conflate hosting and registrar transfers. You don’t need to move your registrar to move hosting. If you do want consolidation or better pricing:

– Unlock the domain at the current registrar.
– Retrieve the Auth/EPP code (now often called a TAC—Transfer Authorization Code).
– Disable WHOIS privacy if your registrar requires it to send approval emails (some don’t).
– Initiate transfer at the gaining registrar, pay the fee (normally adds a year to the registration; ccTLD rules vary).
– Approve the transfer via email or in the losing registrar’s dashboard. Completion can be minutes to a few days.
– Note locks: After ownership/contact changes, some registrars impose a 60-day lock; many now offer an opt-out when you change contact data. Plan accordingly.
– DNS: Registrar transfer shouldn’t affect DNS if you’re not changing nameservers simultaneously. If your nameservers are the registrar’s, migrate DNS first.

Industry context:
– ICANN has been modernizing transfer flows, and many registrars are standardizing on the TAC terminology and streamlined approvals.
– After Google Domains’ sunset and migration to Squarespace, many orgs are consolidating portfolios. If you’re moving off legacy registrars, stagger transfers to avoid service disruption.

After the move: harden and monitor

– Re-enable DNSSEC with your new DNS provider’s DS record.
– Raise TTLs back to sane defaults (e.g., 3600–14400 seconds) for stability.
– Verify 301 redirects, canonical URLs, and robots.txt are intact.
– Check for mixed content on HTTPS pages and enable HTTP/2 or HTTP/3 if supported.
– Add uptime, SSL expiry, and DNS change monitoring. Set alerts in your logging/APM for error spikes.
– Backups: Confirm automated off-site backups (files and DB) and test a restore.
– Webhooks: Ensure third-party providers (Stripe, Shopify, auth providers) can reach your new origin IP/host.
– Analytics and Search Console: If the domain didn’t change, you don’t need a “Change of Address,” but verify crawl and index health.

Common pitfalls (and how to avoid them)

– DNSSEC left on during nameserver change: leads to hard failures. Remove DS before changing NS; re-add after.
– Forgetting AAAA: Adding IPv6 without proper firewall/cert configuration can expose issues you didn’t see on IPv4.
– MX records lost or misordered: Copy them exactly and watch TTLs. Always replicate SPF/DKIM/DMARC.
– Let’s Encrypt challenges failing: If you moved DNS but cert automation still uses HTTP-01 at the old host, reconfigure ACME on the new host or switch to DNS-01.
– Hardcoded IPs: In code, firewalls, or third-party allowlists. Update allowlists and environment configs.
– Asset URLs: Absolute URLs pointing to old hostnames or buckets. Update environment variables and CDNs.
– Cron/queues not migrated: Background jobs stuck on the old server. Move and verify.
– CDN cache: Stale assets after go-live. Purge caches at cutover.

Two short examples

WordPress on shared hosting to managed WordPress + Cloudflare
– Prework: Lower TTLs to 300s. Export DNS zone. Add the site at Cloudflare, import DNS, keep orange-cloud off.
– Build: Migrate with a plugin or rsync + mysqldump. Test via hosts file. Enable object caching (Redis) at new host.
– SSL: Pre-issue Origin Certificate or Let’s Encrypt on the new host.
– Cutover: Point A/AAAA at new host if staying with current DNS; or switch nameservers to Cloudflare and then enable proxy.
– Email: If email is Google Workspace, just copy MX/SPF/DKIM/DMARC to Cloudflare DNS beforehand; verify DKIM selector.
– Post: Re-enable DNSSEC with Cloudflare DS. Turn on WAF rules and Bot Fight Mode conservatively. Raise TTLs.

Node/Next.js app from VM to container platform + managed Postgres
– Prework: Containerize app, set env vars, secrets, health checks. Set up load balancer and autoscaling.
– Data: Create replica of Postgres (logical replication) or use a one-time dump/restore with a short write freeze.
– Test: Blue environment behind a temporary hostname, validate edge caching, API routes, and image optimization.
– Cutover: Update A/AAAA or switch ingress DNS to new load balancer IP; purge CDN. Keep old VM up for 24 hours.
– Post: Enable HTTP/3, confirm WebSockets over the new LB, reissue certs if SNI changed.

Market and technology trends affecting migrations in 2026

– Anycast DNS is the default for serious uptime. Managed DNS from providers like Cloudflare, NS1, and Route 53 offers health checks and traffic steering that make zero-downtime switches easier. Free DNS works, but paid plans add failover and advanced routing.
– .com pricing has ticked up over time under ICANN-approved increases, while .ai and other trendy TLDs carry premium registration and transfer fees. Budget accordingly if you’re moving domains across registrars.
– Email deliverability is stricter. Gmail and Yahoo tightened bulk sender policies in 2024; SPF, DKIM, and DMARC alignment plus low complaint rates are table stakes. Migrations that forget DKIM keys or change sending IPs without warming will feel the pain.
– Google Domains’ exit pushed many orgs to reevaluate registrar/DNS strategy. Know where your domain lives and separate control of DNS from hosting to reduce vendor lock-in.
– Edge and zero-trust models mean more stacks are fronted by CDNs/WAFs. Treat the CDN as part of your migration—not an afterthought.

A minimal, repeatable checklist

– Inventory domain, DNS, SSL, email, app dependencies.
– Lower TTLs at current DNS provider.
– Build and test destination hosting (files, DB, jobs, SSL).
– Export DNS zone; pre-create it at new DNS host if applicable.
– Plan data sync and a short write freeze window.
– Cut over: update A/AAAA (or nameservers if moving DNS). Handle DNSSEC correctly.
– Validate from multiple networks. Test web and email.
– Keep the old host alive for 24–72 hours.
– Re-enable DNSSEC, raise TTLs, set monitoring and backups.
– Optional: Transfer registrar once stable.

Final thought

Migrations don’t have to be dramatic. With a short runway (low TTLs), parallel infrastructure, and a crisp checklist, you can move house overnight and wake up with the coffee already brewing. If in doubt, rehearse on a staging domain, keep the old stack warm for a day, and let your DNS do the quiet heavy lifting.