DNS Cutover Tutorial (2026): Move a Website to a New VPS With Low TTL, Split-Horizon Testing, and Safe Rollback

A hosting move rarely fails because of rsync. It fails when DNS flips at the wrong time. Caches behave differently per ISP. Or you discover that email or TLS still points to the old server.

This DNS cutover tutorial uses a predictable cutover workflow for 2026. You’ll lower TTL ahead of time. You’ll test the new VPS without touching production. Then you’ll switch records in a controlled order, with a rollback you can execute in minutes.

You can use this workflow for WordPress, a custom PHP app, or a static site. The examples assume you’re moving from shared hosting or an older VPS to a new Linux VPS (Ubuntu/Debian). The DNS mechanics are the same on dedicated servers.

DNS cutover tutorial: what you’ll build (and why it works)

The idea is simple. Set DNS up for a fast switch. Validate the new server without exposing it to the public. Then change only what you need and confirm real traffic lands correctly.

• Low TTL phase: reduce caching time ahead of the move (hours to a day before).
• Split-horizon testing: preview the new VPS using local overrides and a temporary hostname, without breaking live traffic.
• Cutover: update A/AAAA, verify HTTPS and app health, then finalize email/DNS extras.
• Rollback: revert DNS quickly if needed while keeping data integrity.

If you need a clean VPS to move into, start with a HostMyCode VPS.

If you’d rather not babysit patching, snapshots, or service restarts during your cutover window, managed VPS hosting keeps the operational chores out of your way.

Prerequisites and a quick inventory checklist

Before you touch DNS, write down what exists right now. Most “DNS downtime” is really “we missed one record” or “we changed the wrong target.”

• Domain registrar and current DNS host (authoritative nameservers)
• Current A/AAAA records for root (@) and www
• Any CDN/proxy settings (orange cloud / reverse proxy / WAF)
• MX records (where mail goes), plus SPF/DKIM/DMARC TXT records
• Subdomains that matter (api, app, mail, cp, webmail, autodiscover)
• Certificate approach: Let’s Encrypt on server vs. provider-managed TLS

On the old host, capture current answers. This gives you a clean “before” snapshot:

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

Tip: If the move also includes email changes, treat that as a separate project. A web cutover already has enough sharp edges.

If you must move mail, do it after the website cutover is stable.

Lower TTL the right way (without creating a mess)

TTL controls how long resolvers cache an answer. If your TTL is 14400 (4 hours) and you switch IPs, some users will keep hitting the old server for up to four hours.

If you drop TTL to 300 (5 minutes) the day before, the cutover window is easier to control.

1. In your DNS provider, find the A/AAAA records for @ and www.
2. Set TTL to 300 (or 600 if your provider limits it).
3. Wait at least the previous TTL duration before cutover. If TTL was 4 hours, wait 4+ hours.

Do not change nameservers during the web cutover unless you have no choice. Nameserver switches add another caching layer.

They also make propagation uneven in ways that are hard to reason about.

If you want a clearer mental model for what “propagation” looks like in practice, this walkthrough helps: DNS propagation troubleshooting.

Bring up the new VPS and make it production-shaped

Cutovers go smoothly when the new server behaves like the old one. Match PHP version, extensions, upload limits, and web server behavior before you point production traffic at it.

On Ubuntu 24.04/26.04 or Debian 12/13, you’ll typically run Nginx + PHP-FPM or Apache. If you host multiple sites, build clean vhosts/server blocks.

Confirm you can reload safely.

For an exact Nginx pattern, use: Nginx server blocks for multiple domains.

Minimum checks on the new VPS:

• Web server runs and serves a test page
• Application runs with the same environment variables/config
• Database connectivity is correct (even if DB stays remote)
• HTTPS can be issued for the domain (or you have a temporary hostname for testing)
• Firewall allows 80/443 and your admin IP for SSH

If you need to tighten SSH before opening a cutover window, follow: SSH lockdown on a VPS.

Test the new site without changing public DNS (three reliable methods)

You want to test the real domain against the new server while everyone else still hits the old one. Pick the method that matches your workflow and your TLS setup.

Method A: Local hosts file override (fastest)

This forces your laptop to resolve the domain to the new VPS IP.

• macOS/Linux: edit /etc/hosts
• Windows: edit C:\Windows\System32\drivers\etc\hosts

203.0.113.10   example.com www.example.com

Then flush local DNS cache:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# systemd-resolved (many Linux distros)
sudo resolvectl flush-caches

Common pitfall: If your browser has HSTS cached for the domain, HTTPS can look “broken” even when the server is fine.

Validate in an incognito profile or a fresh browser profile.

Method B: Temporary testing hostname (cleaner for teams)

Create a record like new.example.com pointing to the new VPS. Then issue a Let’s Encrypt certificate for that hostname.

This lets you test end-to-end with real DNS and real TLS (including HTTP/2/HTTP/3 settings).

• Add new.example.com A/AAAA → new VPS IP
• Configure the vhost/server block for new.example.com
• Copy the site content and database snapshot

For a clean Let’s Encrypt setup path, use: VPS SSL setup guide.

Method C: Direct IP testing with Host header (useful for API validation)

This checks your routing and virtual host behavior without changing DNS:

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

If your certificate doesn’t cover the domain yet, test HTTP on port 80 first:

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

Prepare the application for cutover (data, uploads, cron, cache)

This is where low-downtime moves are won or lost. The goal is simple: avoid data drift between the old and new servers.

WordPress: freeze writes, then sync uploads

If the site changes constantly (orders, posts, form submissions), plan a short maintenance window. For a basic site, 5–15 minutes is usually plenty.

• Put the site in maintenance mode (plugin or a simple maintenance page)
• Stop background jobs that write data (WP-Cron or external cron)
• Take a final database dump and a last rsync of wp-content/uploads

After cutover, if scheduled tasks misbehave, fix cron properly instead of letting WP-Cron run on every page view. Use: WordPress cron troubleshooting.

Don’t forget caches

Clear caches on both sides. Otherwise, you’ll waste time debugging stale content.

• WordPress page cache plugin cache
• Object cache (Redis/Memcached) if used
• CDN cache (after DNS cutover, purge key pages)

Cutover runbook: switch DNS with verification at each step

Schedule the cutover for a low-traffic period. Keep both servers online during the transition.

Don’t delete the old server until you’ve seen at least one full business day of clean traffic.

Step 1: confirm the new server is ready to serve the real domain

Before you flip DNS, confirm the vhost and TLS are correct for example.com and www.example.com.

# From your laptop, force DNS to the new IP and check headers
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/

Look for:

• 200 or expected redirect (301 to www/non-www)
• Correct server behavior (no default vhost)
• Correct canonical redirects (no loops)

Step 2: change A/AAAA records (web only)

Update these records at your DNS provider:

• A for @ → new IPv4
• A for www → new IPv4 (or CNAME to @)
• AAAA for @/www → new IPv6 (only if you serve IPv6 correctly)

IPv6 gotcha: If the new server doesn’t have IPv6 configured, remove AAAA temporarily. Many clients prefer IPv6 first.

When AAAA points nowhere, failures look random.

Step 3: verify authoritative DNS and a few public resolvers

Start by checking what your authoritative nameservers return:

dig +noall +answer example.com A
dig +noall +answer www.example.com A

Then spot-check a couple of public resolvers:

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

If you still see the old IP on public resolvers, give it a few minutes. With TTL=300, things usually converge quickly.

Some ISP caches still lag.

Step 4: watch real traffic on the new VPS

On Nginx, tail logs and confirm requests are arriving and completing:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

On Apache:

sudo tail -f /var/log/apache2/access.log
sudo tail -f /var/log/apache2/error.log

If you need a structured way to investigate spikes, 500s, or slow endpoints during the cutover, use: VPS log analysis tutorial.

Step 5: re-enable writes and background jobs

Once you’re confident traffic is landing on the new server:

• Disable maintenance mode
• Re-enable cron jobs
• Place a short-term alert on error rate and response time

If you don’t already have monitoring, set it up before your next migration. This lightweight stack works well on VPS and dedicated servers: VPS monitoring with Uptime Kuma + Node Exporter.

Rollback plan: how to revert without corrupting data

A rollback feels scary when you’re improvising. Define the rules before you start.

Base them on how your site handles writes.

• Static or brochure site: rollback is usually safe at any time.
• WooCommerce / membership: rollback can lose orders or account changes unless you also roll back the database or keep DB centralized.

For most dynamic sites, the cleanest rollback is DNS-only within the first few minutes. Do it before users start writing new data on the new server.

If you need a longer rollback window, keep the database on the old server temporarily and migrate it later. Or plan a real reconciliation process.

To roll back the web endpoint:

1. Change A/AAAA back to the old IPs.
2. Keep TTL low until stability returns.
3. Capture logs and error output on the new VPS for postmortem.

Post-cutover cleanup: raise TTL, tighten TLS, and protect admin endpoints

After traffic has been stable for a day (or at least through peak hours), do the cleanup. This prevents the next change from turning into an emergency.

• Raise TTL back to 3600–14400 to reduce resolver load and random query volume.
• Confirm Auto-Renew for Let’s Encrypt and run a dry-run renewal.
• Harden TLS (protocols, ciphers, OCSP stapling where applicable).
• Rate-limit login endpoints if it’s WordPress or a public admin panel.

For a solid HTTPS baseline on Nginx/Apache, follow: TLS hardening for production.

Troubleshooting: common DNS cutover failures and quick fixes

You switched DNS but some users still hit the old server

• TTL wasn’t lowered early enough (wait out the old TTL).
• Users sit behind resolvers that ignore low TTL (less common, but real).
• Your AAAA still points to the old server (or to nothing).

Fix: confirm A and AAAA answers, and ensure the new server serves both IP families if you publish AAAA.

HTTPS works on one domain but not the other (www vs root)

• Certificate doesn’t include both hostnames
• Redirect loop between www and non-www
• Default vhost catching traffic due to missing server_name

Fix: re-issue the cert with both names and check your vhost/server block ordering.

Mixed content warnings or broken admin after moving

• Hardcoded http:// URLs in database
• Old CDN origin settings
• Proxy headers not set (X-Forwarded-Proto) behind a load balancer/CDN

Fix: update site URL settings, run a search/replace carefully, and validate proxy headers.

Mail breaks even though you only changed web A records

This usually happens when mail relies on mail.example.com pointing to the same IP as the website. It can also happen when “@” A record changes indirectly affect mail autodiscovery.

• Check MX targets and the A record of the MX hostname.
• Confirm SPF includes the correct sending source.

If you run mail on a VPS, plan deliverability before you cut over. Start with: VPS email setup (SPF/DKIM/DMARC/rDNS).

Summary: a predictable DNS cutover in 2026

Lower TTL early. Validate the new server without touching public DNS. Then switch only the records that route web traffic.

Keep rollback DNS-ready, and don’t decommission the old host until you’ve watched logs through a full peak cycle.

If you want a stable target for your next migration, run your websites on a HostMyCode VPS.

If you prefer help with updates, security baselines, and recovery planning, choose managed VPS hosting from HostMyCode (Affordable & Reliable Hosting).

FAQ

How low should I set TTL before a cutover?

300 seconds (5 minutes) is a practical target. Set it at least one full “old TTL” period before the switch so caches can age out.

Should I change nameservers during a website move?

Only if you must. Nameserver changes add extra caching and make troubleshooting harder. Keep authoritative DNS where it is, do the web IP cutover, then migrate DNS later if needed.

How long should I keep the old server online after DNS cutover?

At least 24–48 hours for most sites, longer for critical systems. You want enough time to catch long-tail resolver caches and verify logs, cron, and payments/email flows.

What’s the safest way to test the new VPS without breaking production?

Use a local hosts override for quick checks, and a temporary hostname like new.example.com for full TLS and team-wide testing. Avoid ad-hoc DNS edits to the live domain until cutover time.