A DNS change looks tiny on paper. In practice, it’s the step that most often creates avoidable downtime during a move. This DNS cutover tutorial shows a controlled way to switch to a new VPS: drop TTL ahead of time, validate the new server before anyone hits it, confirm answers from multiple resolvers, and keep a simple rollback ready.
This workflow fits the usual hosting upgrades: shared hosting to VPS, one VPS to another, or a fresh dedicated build. You’ll use a few basic tools (dig, curl, openssl) and a handful of guardrails that prevent the “why is it still going to the old box?” problem.
What you’ll accomplish (and what you need)
- Goal: switch DNS to a new server with minimal downtime and predictable cache behavior.
- Works for: A/AAAA changes, nameserver changes, and “temporary parallel run” cutovers.
- Assumptions: you already built the new server and your site works there by IP or hosts-file testing.
Prerequisites
- Access to your DNS provider (or registrar DNS) and the current zone file.
- New server public IP (IPv4 and optionally IPv6).
- A shell on macOS/Linux/WSL for
dig. On Ubuntu/Debian:sudo apt-get install -y dnsutils.
If you still need to migrate site files first, follow a file-sync approach with a TTL plan. HostMyCode’s existing guide pairs well with this cutover method: VPS migration tutorial using rsync and DNS TTL cutover.
DNS cutover tutorial step 1: map your current DNS and traffic shape
Before you touch TTLs, capture the current “known good” state. If you need to revert, you want the old values in front of you, not in your memory.
Export the zone (or at least inventory key records)
- A/AAAA for
@andwww - CNAMEs (especially
wwwor CDN/app endpoints) - MX and mail-related TXT (SPF/DKIM/DMARC)
- TXT for verification (Google/Microsoft), and any special app records
- SRV records if you run VoIP/chat services
Baseline what resolvers return right now
Run these from your workstation. Replace example.com.
dig +noall +answer example.com A
dig +noall +answer www.example.com A
dig +noall +answer example.com AAAA
dig +noall +answer example.com MX
dig +noall +answer example.com TXTAlso record the authoritative nameservers:
dig +noall +answer example.com NSDecide: IP-only cutover or nameserver migration
- IP-only (recommended for most moves): keep the same DNS provider, change A/AAAA records to the new server. Lowest risk.
- Nameserver migration: move the entire zone to a new DNS provider. More moving parts. Do it only when you must.
If you’re moving DNS hosting itself, plan extra validation and a longer observation window. A dedicated propagation guide helps: DNS propagation tutorial with TTL planning and rollback.
Lower TTL safely (and early) without breaking your zone
TTL changes don’t take effect instantly for everyone. Caches that already have your record will keep using the old TTL until it expires. That’s why the TTL drop has to happen before you plan to flip the records.
Recommended TTL plan for 2026
- 24–48 hours before cutover: set A/AAAA (and any relevant CNAMEs) to 300 seconds (5 minutes).
- Busy e-commerce sites: consider 120 seconds during the cutover window, but don’t leave it there for weeks.
- Don’t touch SOA/NS TTLs unless you understand your provider’s behavior.
What not to do
- Don’t lower TTL 10 minutes before switching and expect low downtime. It won’t help most users.
- Don’t forget
www. Many sites cut over@but leavewwwpointing to the old IP. - Don’t accidentally delete TXT records used for email/auth verification.
Stage the new server and validate it by hostname (without changing public DNS)
You want proof that the new VPS serves the correct site, presents the right TLS certificate, and applies the same redirects. Do that work while public DNS still points at the old server.
Option A: test with a hosts-file override
On your workstation, temporarily point the domain to the new IP.
- Linux/macOS:
/etc/hosts - Windows:
C:\Windows\System32\drivers\etc\hosts
# Replace with your new server IP
203.0.113.10 example.com www.example.comNow test the site like a normal browser would.
curl -I https://example.com/
curl -I https://www.example.com/Option B: test with curl resolve (no hosts-file editing)
curl -I --resolve example.com:443:203.0.113.10 https://example.com/
curl -I --resolve www.example.com:443:203.0.113.10 https://www.example.com/Validate TLS on the new server
Certificate issues are one of the fastest ways to turn a clean cutover into an outage. Verify what the new IP actually presents:
echo | openssl s_client -connect 203.0.113.10:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -datesIf Let’s Encrypt renewal is part of your build, keep this troubleshooting guide handy: SSL renewal troubleshooting tutorial for Let’s Encrypt on VPS.
Cutover strategy: pick the least risky switch for your workload
There isn’t a single “best” cutover pattern. The right choice depends on your app, your traffic, and how painful split sessions would be.
Strategy 1 (most common): flip A/AAAA for @ and www
- Best for: WordPress, marketing sites, most business apps.
- Risk: brief split-traffic while caches expire.
Strategy 2: parallel run behind a CDN/proxy, then switch origin
- Best for: high-traffic sites that already proxy through a CDN/WAF.
- Risk: you must validate origin headers, real client IP handling, and cache behavior.
Strategy 3: nameserver change (zone migration)
- Best for: moving away from a provider’s DNS or consolidating accounts.
- Risk: missing records and inconsistent propagation across resolvers.
If you’re doing a straight VPS move and you want predictable performance, start from a clean baseline. HostMyCode’s HostMyCode VPS plans are a solid fit for controlled migrations because you can size CPU/RAM for your current peak and scale after the cutover.
Perform the cutover (A/AAAA change) with verification checks
Pick a low-traffic window, but don’t schedule it for a time you can’t think clearly. Plan for 60–90 minutes of focused work, plus time to watch logs after.
1) Change A/AAAA records
Update these records (examples shown):
example.comA →203.0.113.10wwwA →203.0.113.10- (optional) AAAA equivalents if you serve IPv6
2) Confirm authoritative DNS answers
Query your authoritative nameserver directly. First, identify one NS:
dig +short example.com NSThen query it directly (replace ns1.yourdns.tld):
dig @ns1.yourdns.tld +noall +answer example.com A
dig @ns1.yourdns.tld +noall +answer www.example.com AIf the authoritative answer is still old, you either edited the wrong zone or the provider hasn’t published the change yet.
3) Check public resolver behavior
These checks show what major resolvers return. You want the new IP, and you want to see a small remaining TTL.
# Cloudflare resolver
dig @1.1.1.1 +noall +answer example.com A
# Google resolver
dig @8.8.8.8 +noall +answer example.com A
# Quad9
dig @9.9.9.9 +noall +answer example.com A4) Verify the site response from multiple vantage points
Once at least one public resolver answers with the new IP, test HTTP and TLS again:
curl -I https://example.com/
curl -I https://www.example.com/If you see strange redirects or the wrong site, check your web server vhost/server block. On Apache, a missing ServerName or a bad default vhost is a frequent culprit.
Stop split-brain writes (WordPress, forms, carts) during the propagation window
Propagation creates a write-consistency risk, not just a DNS timing issue. While caches expire, some users will hit the old server and others the new one. If both accept writes, you can lose orders, submissions, or password resets.
Practical options (choose one)
- Short maintenance mode (recommended for WordPress): enable maintenance for 10–20 minutes during the flip. This prevents new writes to the old server.
- Freeze writes on old server: block wp-admin logins and POST requests (advanced, easy to get wrong).
- One last content sync after TTL is low: rsync files and (if needed) database in a tight window; then flip DNS.
If you’re running WordPress and you’ve had scheduling issues during migrations, check cron behavior after the move as well. This guide helps you validate it: WordPress cron troubleshooting tutorial.
Rollback plan (you should write it down before you start)
Rollback shouldn’t be “panic and click around.” It’s a short list of specific DNS edits and a quick verification pass.
Rollback triggers
- Wrong site served (default vhost, wrong document root).
- Broken TLS or mixed content due to incorrect base URL.
- App errors you can’t fix inside 15 minutes.
- Email delivery breaks because you accidentally changed mail-related records.
Rollback steps
- Change A/AAAA records back to the old IP(s).
- Confirm authoritative answer matches old IP.
- Check at least two public resolvers.
- Keep investigating on the new server while traffic stabilizes on the old one.
Because you lowered TTL ahead of time, rollback usually converges quickly. You won’t reach every cache instantly, but the bad state should shrink within minutes.
After the cutover: restore normal TTLs and tighten the server
Once traffic has clearly moved and key flows look healthy, take the zone out of “migration mode.” Leaving low TTLs forever just increases query volume for no benefit.
1) Raise TTL back to a sane value
- Common steady-state TTL: 3600 (1 hour)
- For rarely changed records: 14400 (4 hours) is fine
2) Confirm logs and health metrics on the new server
At minimum, confirm requests are landing and error rates aren’t climbing.
# Nginx access/error (Ubuntu/Debian common paths)
sudo tail -n 50 /var/log/nginx/access.log
sudo tail -n 50 /var/log/nginx/error.log
# Apache access/error
sudo tail -n 50 /var/log/apache2/access.log
sudo tail -n 50 /var/log/apache2/error.logIf you want a lightweight dashboard with alerts, set up Netdata and lock it down. This is a practical build: Server monitoring setup guide with Netdata and alerts.
3) Re-check firewall and rate limiting basics
Cutovers have a habit of exposing ports that were never exercised on the old server. Confirm you only allow what you actually use (typically 22, 80, 443; plus mail ports if you host email).
If you run Nginx and want to block common web attacks, pairing a WAF with your new origin is a straightforward win: Web application firewall tutorial using ModSecurity and OWASP CRS.
Email and DNS gotchas that break right after a cutover
Even if you didn’t mean to touch mail, DNS edits can still break it. These are the common failures that show up right after a move.
MX records accidentally changed or removed
- Symptom: inbound mail bounces or stops arriving.
- Fix: restore prior MX exactly, confirm any required mail hostnames still resolve.
Reverse DNS (PTR) mismatch for outbound mail
- Symptom: mail sent from the new VPS goes to spam or gets rejected.
- Fix: set correct PTR for the new IP and align
HELO/myhostname.
Two quick references if you’re hosting mail from the new server:
ACME/Let’s Encrypt HTTP-01 challenges failing
- Symptom: renewal fails because some resolvers still hit the old server, or firewall blocks port 80.
- Fix: ensure both old and new answer the challenge (or pause renewals until cutover completes), confirm port 80 open.
Cutover checklist (printable)
- [ ] Export DNS zone / inventory key records (A/AAAA, CNAME, MX, TXT).
- [ ] Lower TTL to 300s for the records you will change (24–48 hours before).
- [ ] Validate new server by IP with
curl --resolveandopenssl s_client. - [ ] Plan write-freeze: maintenance mode or a tight final sync window.
- [ ] Change A/AAAA (and www) to new IP.
- [ ] Verify authoritative NS answers, then public resolvers.
- [ ] Check logs, error rates, and critical user flows (login, checkout, contact forms).
- [ ] Raise TTL back to 1h after stability.
- [ ] Keep old server online for at least 24–72 hours as a safety net.
If you want cutovers that behave predictably, start with a clean server and a bit of headroom for the switch window. A HostMyCode VPS is a good fit for most business sites, and managed VPS hosting makes sense if you don’t want to babysit SSL renewals, firewall rules, and service restarts mid-migration.
FAQ
How long does a DNS cutover actually take in 2026?
If you lowered TTL 24–48 hours ahead of time, most users shift within minutes. Some resolvers and ISP caches can still take longer, so plan for a 1–2 hour “mixed traffic” window.
Should I change nameservers or just update A records?
If you don’t need a DNS provider change, updating A/AAAA is simpler and safer. Nameserver changes introduce an extra layer of propagation and a higher chance of missing records.
Do I need to keep the old server online after cutover?
Yes. Keep it up for at least 24–72 hours. That covers straggler caches and gives you a fast rollback option if you spot an edge-case bug.
Why does my browser still show the old site even after DNS looks updated?
It may be local DNS caching, an ISP resolver, or a CDN cache. Flush local cache where applicable, test with dig @1.1.1.1, and confirm you’re not hitting cached content via a proxy layer.
Summary: make DNS changes boring
The reliable pattern stays the same: lower TTL early, validate the new server without touching public DNS, flip only the records you need, then verify at both the authoritative and public-resolver layers. Keep rollback steps written down so you can execute them quickly.
If you’re planning your next move, using a properly sized HostMyCode VPS (or stepping up to dedicated servers for heavy workloads) gives you the stability you need to run parallel checks and cut over cleanly.