Back to tutorials
Tutorial

DNS Migration Tutorial (2026): Move a Domain to New Hosting Without Downtime or Email Breakage

DNS migration tutorial for 2026: move a domain safely with low TTL, record audit, and email checks—no downtime.

By Anurag Singh
Updated on Aug 03, 2026
Category: Tutorial
Share article
DNS Migration Tutorial (2026): Move a Domain to New Hosting Without Downtime or Email Breakage

A DNS cutover is where “simple hosting migrations” tend to explode. One wrong A record and you still hit the old server. One missing SPF include and email starts bouncing. This DNS migration tutorial shows a controlled move to new hosting with minimal downtime, predictable propagation, and clear checks for web, mail, and SSL.

You can use the same process on shared hosting, a VPS, or a dedicated box. The examples assume you’re moving to a new Linux server (Ubuntu/Debian/AlmaLinux). You’ll also update authoritative DNS at your registrar or DNS provider.

What you’ll need before the cutover

  • Access to your current authoritative DNS zone (registrar DNS, Cloud DNS, cPanel Zone Editor, etc.).
  • The new server IP(s): IPv4 and IPv6 if you use it.
  • Where email will live after the move (same provider, cPanel, Google Workspace, Microsoft 365, or a mail VPS).
  • A terminal with dig (Linux/macOS) or Windows WSL. Optional: curl and openssl.

If you’re migrating to a VPS and want tighter control over DNS, caching, and mail routing, start with a HostMyCode VPS. If you’d rather keep the admin overhead low, managed VPS hosting covers OS updates, baseline hardening, and routine maintenance.

Step 1: Inventory your current DNS zone (don’t trust memory)

Before you change anything, capture the zone exactly as it exists. This surfaces the “forgotten” pieces, like old verification TXT records, app subdomains, and mail records.

Those records often only hurt when they’re missing.

Quick record checklist

  • A / AAAA for @ and www
  • CNAME (common: www, autodiscover, smtp, mail)
  • MX (mail routing)
  • TXT for SPF, DKIM, DMARC, site verification, and sometimes app config
  • SRV (rare, but used by some VoIP/IM apps and certain mail clients)
  • CAA (controls which CAs can issue TLS certificates for your domain)

Pull the live records with dig

Replace example.com with your domain. Run these from your workstation:

dig +short NS example.com

dig +short A example.com
 dig +short AAAA example.com

dig +short A www.example.com
 dig +short AAAA www.example.com

dig +short MX example.com

dig +short TXT example.com
 dig +short TXT _dmarc.example.com

If DKIM is stored in DNS, it usually lives under a selector like default._domainkey or a provider-specific selector.

If you don’t know the selector, check your mail provider or cPanel first.

For a deeper propagation and “wrong nameserver” diagnosis flow, keep this guide handy: DNS propagation troubleshooting steps.

Step 2: Lower TTL ahead of time (and understand what it really affects)

TTL is how long resolvers cache an answer. Lowering TTL won’t flush existing caches.

It only shortens how long the next cached answer will stick around. For most migrations, set TTL to 300 seconds (5 minutes) on records you plan to change.

What to lower

  • A / AAAA for @ and www
  • MX if mail routing will change
  • Any app subdomain you’re moving: api, app, cpanel, webmail

Timing

Do this at least 24 hours before cutover if you can. If you’re in a hurry, even 2–6 hours helps.

Don’t expect perfect behavior from resolvers that ignore TTLs.

Pitfall: don’t lower the TTL on NS records unless you are changing nameservers. Many DNS control panels don’t allow it anyway. It also doesn’t matter for an A-record cutover.

Step 3: Prepare the new hosting and make it serve the correct site

DNS should be the last switch you flip. First, make sure the new server responds for your domain and serves the correct vhost/app.

Test the new IP with curl (without changing DNS)

Assume the new server IPv4 is 203.0.113.10. You can request that IP while forcing the Host header:

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

If you terminate TLS on the new server, test HTTPS too:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Expected result: a 200, 301, or your normal application response.

If you see a default page, you almost certainly have a vhost/server block mismatch.

Temporary hosts-file test (optional but useful)

If you want a real browser test, add a temporary hosts entry on your computer. Remove it after you’re done.

Otherwise, you’ll confuse yourself later.

  • Linux/macOS: /etc/hosts
  • Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.10 example.com www.example.com

If you’re moving the full site as well, align this step with your cutover plan from: hosting migration checklist.

Step 4: Plan your email routing (MX, SPF, DKIM, DMARC) before you touch A records

Most “website migrations” that go sideways didn’t fail on HTTP. They failed because mail was treated as an afterthought.

Treat email like a production service. It has routing, authentication, and deliverability requirements.

Decide: are you moving mail too?

  • Mail stays where it is: keep existing MX, SPF includes, DKIM, and DMARC. Don’t change them during the web cutover.
  • Mail moves (to cPanel/WHM or another mail service): plan an MX cutover and validate new authentication records.

If mail moves to your new server: set up these records in advance

  • MX: points to the new mail host (often mail.example.com or a provider host)
  • A/AAAA for mail host: if MX points to mail.example.com, it needs an address record
  • SPF TXT: authorizes your new sending IP/service
  • DKIM: publish the DKIM selector TXT record from your mail system
  • DMARC: start with a monitoring policy (p=none) if you’re unsure

If you’re using cPanel/WHM for mail, HostMyCode’s managed VPS hosting is a sensible option for production email.

Deliverability issues often require coordinated OS + DNS + MTA work, not just control-panel changes.

Useful companion tutorials (don’t skip these if email matters):

Step 5: Cutover option A (same nameservers): change A/AAAA records safely

This is the common case. You keep the same authoritative DNS provider and only update IP records to point to the new server.

Recommended order of operations

  1. Confirm the new server serves the correct site via curl --resolve.
  2. Lower TTL (done earlier).
  3. Update A record for @ to the new IPv4.
  4. Update AAAA record for @ if you use IPv6.
  5. Update www (A/AAAA or CNAME) to match your intended setup.
  6. Keep the old server online for at least 24–48 hours to catch stragglers.

WWW patterns that avoid surprises

  • Simple: www as a CNAME to @ (if your DNS provider supports CNAME flattening/ALIAS for root).
  • Explicit: set www A/AAAA to the same new IP as root.

Verify the change from multiple resolvers

Don’t rely on whatever your laptop happens to use. Query public resolvers directly:

dig @1.1.1.1 A example.com +short
dig @8.8.8.8 A example.com +short

For IPv6:

dig @1.1.1.1 AAAA example.com +short

Step 6: Cutover option B (changing nameservers): replicate the zone first, then switch NS

Nameserver changes carry more risk because you’re moving the entire zone authority.

Do this only if you have a concrete reason (new DNS provider, moving into cPanel DNS clustering, splitting mail/web, etc.).

Safe workflow

  1. Create the zone at the new DNS provider.
  2. Copy every record (A/AAAA/CNAME/MX/TXT/SRV/CAA). Keep TTLs low during the migration window.
  3. Validate the new zone by querying the new provider’s authoritative nameservers directly (they will provide hostnames).
  4. Only then change your domain’s NS at the registrar.

How to validate the new authoritative DNS before switching

If the new provider gives you NS like ns1.newdns.example and ns2.newdns.example:

dig @ns1.newdns.example A example.com +short
dig @ns1.newdns.example MX example.com +short
dig @ns1.newdns.example TXT example.com +short

If these answers aren’t correct, stop and fix the zone. Don’t touch registrar nameservers until the new authority is clean.

Step 7: SSL/TLS reality check after DNS changes

After cutover, the most common surprise is a certificate warning or mismatch. This usually means one of three things:

  • the new server is presenting a default cert
  • TLS terminates somewhere other than you think
  • AAAA still points to an old IPv6 host

Confirm what certificate users see

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Quick fixes that actually work

  • Wrong vhost: ensure your web server has a vhost/server block for example.com and www.example.com.
  • IPv6 mismatch: either configure the site on IPv6 too, or temporarily remove the AAAA record until ready.
  • Automation: use Let’s Encrypt with a working HTTP-01 challenge path.

If you need the full issuance + renewal workflow, use: SSL certificate deployment tutorial.

Step 8: Post-cutover verification (web, email, and “quiet” subdomains)

Verify in layers. Start with DNS answers. Then check HTTP response, the app itself, and mail flow.

Web checks (5 minutes)

  • Confirm DNS points to the new IP on multiple resolvers.
  • Check HTTP status and redirects:
curl -I http://example.com/
curl -I https://example.com/
curl -I https://www.example.com/
  • Confirm your origin sees the right client IPs if behind a proxy/CDN (look at access logs).

Email checks (10 minutes)

  • Confirm MX:
dig +short MX example.com
  • Confirm SPF and DMARC TXT records exist and look sane:
dig +short TXT example.com
dig +short TXT _dmarc.example.com

If SMTP clients start failing after the move, walk through: SMTP troubleshooting tutorial.

Quiet subdomain audit

These often break because nobody wrote them down in the first place:

  • autodiscover.example.com (mail clients)
  • webmail.example.com / cpanel.example.com (if you used them)
  • api.example.com, staging.example.com, assets.example.com

Step 9: Keep the old server alive briefly (and control what it serves)

Even with a low TTL, some networks and devices hold onto stale answers longer than they should.

If you pull the plug too early, you create avoidable downtime.

Minimum safe overlap

  • Web: keep the old server online for 24–48 hours.
  • Email: if you changed MX, keep the old mail system able to accept mail for 48–72 hours, or configure forwarding/relaying if possible.

Optional: “migration notice” on the old site

If the old server must stay reachable, keep it predictable. Serve a lightweight page for admin paths, or keep the old app but disable writes (app-dependent).

For WordPress, the safest pattern is usually a brief freeze on orders/comments during final sync, then cutover.

Step 10: Cleanup after the cutover (raise TTL, remove legacy records, document)

Once traffic is stable and you’ve confirmed everything lands on the new hosting, raise TTLs back to normal.

This reduces DNS query volume and makes your zone less twitchy during minor resolver issues.

Suggested steady-state TTLs

  • A/AAAA: 3600 (1 hour) for most sites; 300–900 if you expect frequent IP changes.
  • MX: 3600–14400 depending on your mail strategy.
  • TXT: 3600 is fine unless you are actively rolling out mail auth changes.

Remove dangerous leftovers

  • Old A records for subdomains that now point nowhere.
  • Old verification TXT records you no longer use (keep only what you can explain).
  • Stale AAAA records that point to an IPv6 you haven’t configured.

Common failure patterns (and the fastest way to diagnose them)

“Some users see the new site, some see the old site”

  • Check TTL changes were done early enough.
  • Query multiple resolvers: dig @1.1.1.1, dig @8.8.8.8, and your ISP resolver.
  • Confirm no extra A records exist (some panels allow multiple A answers).

“HTTPS shows the wrong certificate”

  • Check AAAA isn’t pointing to an old server.
  • Confirm SNI is configured for the domain.
  • Run the openssl s_client command above to see what’s actually presented.

“Email started bouncing after migration”

  • Confirm MX points to the intended destination.
  • Check SPF doesn’t exclude the new sender IP/service.
  • If you moved mail to a VPS/cPanel server, make sure reverse DNS (PTR) is set for the sending IP.

If you want DNS cutovers to be boring, build on infrastructure you can test before you switch traffic. A HostMyCode VPS gives you clean IP ownership and predictable networking, and HostMyCode migrations can run the move with a documented cutover plan.

FAQ

How long should I keep TTL at 300 during a DNS migration?

Set it 24 hours before cutover if possible, keep it low through the switch, then raise it back (often 3600) once traffic is stable—usually within 24–48 hours.

Should I change DNS first or move the website first?

Move the site first, test the new server using curl --resolve or a hosts-file override, then change DNS. DNS should be the final step.

Do I need to change MX records if I’m only moving the website?

No. If email stays with the same provider, keep MX and mail-related TXT records unchanged. Only change what’s required for the web cutover.

Why does HTTPS break after DNS cutover even though the site loads?

Most often it’s an IPv6 mismatch (stale AAAA), a default vhost catching the request, or a missing certificate on the new server. Verify with openssl s_client and check both A and AAAA answers.

What’s the safest way to migrate DNS and hosting with minimal risk?

Lower TTL ahead of time, replicate records carefully, test the new origin by forcing the Host header, and keep the old server online for at least 24–48 hours after cutover.

Summary: a DNS cutover plan you can repeat

Good migrations look almost dull: inventory records, drop TTL, prove the new server works before switching, then validate web and mail end-to-end.

The difference is sequencing and verification, not luck.

If you’re planning a move to faster infrastructure or want predictable admin access for troubleshooting, use a HostMyCode VPS, or choose managed VPS hosting when you’d rather have experts handle the operational sharp edges.