Migrations rarely fail during file copy or database import. They fail during the DNS cutover. Caches ignore your timeline. TLS is unforgiving. And the old server always gets “one last write” at the worst time.
This DNS cutover tutorial gives you a low-risk, repeatable flow for 2026. You’ll lower TTL ahead of time and run both servers in parallel. You’ll validate the new VPS with hosts-file overrides. You’ll handle SSL before you flip. Then you’ll switch DNS with a rollback you can actually execute.
The examples lean WordPress and typical PHP stacks. The cutover mechanics apply to any site.
What you’ll accomplish in this DNS cutover tutorial
- Lower DNS TTL safely without causing resolver weirdness.
- Bring up a new VPS (or dedicated server) and mirror your site.
- Verify the new server without changing public DNS (hosts override + direct testing).
- Pre-install TLS so HTTPS works immediately after the switch.
- Freeze writes, take a final sync, and cut over with minimal risk.
- Rollback cleanly if something goes sideways.
Prerequisites and planning (10 minutes that saves hours)
Before you touch DNS, capture the details you’ll need later. Do this now, not during an incident.
Put everything in a doc you can find quickly.
- Current DNS provider and where the zone is hosted (registrar DNS, Cloudflare DNS, cPanel DNS-only, etc.).
- Current A/AAAA records for
@andwww, plus any subdomains (app, api, mail, etc.). - Current MX and mail routing. If email stays where it is, don’t touch MX.
- TLS approach: Let’s Encrypt, AutoSSL, commercial cert, or CDN edge cert.
- Traffic + write patterns: ecommerce checkouts, membership signups, contact forms, comments. These influence your “freeze window”.
If you’re moving because the old plan is maxed out, start with a VPS that has breathing room.
Extra headroom keeps you from tuning performance during the cutover.
For production migrations, HostMyCode VPS is a straightforward option. If you’d rather not manage patching and the stack, use managed VPS hosting.
Step 1: Lower DNS TTL the right way (and when not to)
TTL is the cache timer for a record. Lower it before your cutover to reduce how long resolvers keep the old IP.
- Locate your DNS zone (where A/AAAA records live).
- Set TTL for these records to 300 seconds (5 minutes):
@A (and AAAA if you use IPv6)wwwA/CNAME (depending on your setup)- Any critical app hostnames you’re moving
- Do this 24 hours before cutover if possible. This gives old caches time to expire under the previous TTL.
Don’t lower TTL for records you aren’t moving. This is especially true for MX.
Unrelated DNS edits create noise, and noise turns into support tickets.
Quick check from your workstation:
dig +noall +answer example.com A
dig +noall +answer www.example.com A
Look at the TTL value on the left. If it still shows 3600 or 14400, you likely edited the wrong record.
You may also be querying a cache that hasn’t aged out yet.
Step 2: Provision the new VPS and harden the basics
You don’t need a clever build for cutover day. You need a stable baseline.
Focus on a patched OS, predictable firewall rules, and SSH that works every time.
On Ubuntu 24.04 LTS (common in 2026 hosting), run:
sudo apt update && sudo apt -y full-upgrade
sudo reboot
After reboot, verify:
uname -a
uptime
Firewall baseline (UFW example):
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
If you’re using a control panel (cPanel/WHM, Plesk, DirectAdmin), follow that vendor’s firewall model.
Don’t layer conflicting rule sets on top.
On cPanel specifically, keep patching disciplined. Staged updates plus maintenance windows are safer than “click update and hope.”
HostMyCode already has a practical runbook: WHM update preferences and staged patching.
Step 3: Build the new web stack (or match the old one)
Cutovers go smoother when your new server behaves like the old one.
Match PHP versions, required extensions, and web server behavior.
On WordPress, missing extensions can cause an instant “white screen” with no useful error.
If you run Nginx + PHP-FPM, keep your config in the standard paths:
- Nginx site configs:
/etc/nginx/sites-available/and/etc/nginx/sites-enabled/ - PHP-FPM pools:
/etc/php/8.3/fpm/pool.d/(adjust version)
If you’re rebuilding and want a secure baseline, use a checklist.
Don’t improvise on cutover week.
Cover TLS, security headers, and safe deploy habits. This tutorial pairs well with: secure Nginx + PHP-FPM on a VPS.
Step 4: Migrate content to the new server (initial sync)
Start with an initial copy while the old site stays live. You’ll move most data with no downtime window.
Option A: Rsync for typical VPS-to-VPS migrations
On the new server, pull files from the old server. Pulling is often easier to secure than pushing.
It also plays nicer with locked-down firewalls on the old side.
sudo rsync -aHAX --numeric-ids --info=progress2 \
-e "ssh -p 22" \
root@OLD_SERVER_IP:/var/www/example.com/ \
/var/www/example.com/
Common pitfall: copying cache directories and wasting time on files you’ll regenerate.
Exclude what you can:
sudo rsync -aHAX --numeric-ids --info=progress2 \
--exclude "wp-content/cache/" \
--exclude "wp-content/uploads/cache/" \
-e "ssh -p 22" \
root@OLD_SERVER_IP:/var/www/example.com/ \
/var/www/example.com/
Option B: Control panel migrations (account-based)
If you’re on cPanel/WHM, an account transfer is usually cleaner than hand-copying files.
It also reduces ownership and permissions mistakes.
For a full cPanel account sync with mail safety, follow: cPanel Transfer Tool migration runbook.
Step 5: Verify the new server without changing public DNS
This is where “zero downtime” becomes real. You want to test the new VPS as if DNS already points to it.
You can do that without changing the public record.
Method 1: Hosts file override (most accurate)
On your local machine, temporarily map the domain to the new server IP.
- Linux/macOS: edit
/etc/hosts - Windows: edit
C:\Windows\System32\drivers\etc\hosts
Add:
NEW_SERVER_IP example.com www.example.com
Then test:
- Homepage, login, checkout/contact form
- Uploads and media thumbnails
- Admin actions that write to the DB
- Critical integrations (payment callbacks, webhooks) if possible
After testing, remove the hosts entry.
Leaving it in place can confuse you during the actual cutover.
Method 2: Direct IP testing with correct Host header
If you can’t edit hosts (locked-down workstation), use curl with the Host header:
curl -I -H "Host: example.com" http://NEW_SERVER_IP/
This confirms routing and response codes.
It won’t fully validate HTTPS for the domain unless the certificate is already correct on the new server.
Step 6: Install SSL ahead of the cutover (avoid the HTTPS faceplant)
HTTPS failures during cutover are optional. Your goal is simple.
The new server should be ready to serve a valid certificate as soon as traffic arrives.
If you use Let’s Encrypt on Nginx/Apache
You can pre-issue the cert on the new server using an HTTP challenge only if the domain already points at the new IP.
Before cutover, that’s usually not true.
For pre-issuance, you typically use one of these paths:
- DNS-01 challenge (best for pre-issuance): add a TXT record at your DNS provider.
- Temporary validation host: issue for a staging hostname that already points to the new server, then swap after DNS (less ideal).
If you want a clean Let’s Encrypt workflow end-to-end and to fix the most common HTTPS errors, use HostMyCode’s guide: SSL certificate setup guide (Let’s Encrypt + renewals + troubleshooting).
If you use cPanel AutoSSL
AutoSSL needs DNS to resolve to the server for DCV in most setups. In practice, you often run AutoSSL immediately after cutover.
Expect a short window where some clients see the certificate update within minutes.
If AutoSSL fails after cutover, don’t improvise. Work through DCV errors and routing mistakes with a checklist.
This is the runbook: cPanel AutoSSL troubleshooting.
Step 7: Prepare a write-freeze window (the part people skip)
“Zero downtime” doesn’t mean “no coordination.” If your site accepts writes, you need a short freeze.
Without it, you risk losing orders, comments, or form submissions.
Pick one:
- Maintenance mode for 5–15 minutes (cleanest for ecommerce).
- Read-only mode if your app supports it.
- Queue writes via app logic (rare for small sites).
For WordPress, the practical move is maintenance mode. Also pause cache purges until you’re stable.
If you want to tighten WordPress security, do it after the move.
While you’re already changing infrastructure, keep cutover scope small: WordPress hardening on a hosting VPS.
Step 8: Final sync (files + database) and consistency checks
Do the final sync during your write-freeze.
Your goal is simple: the new server must match the old server at the moment you flip DNS.
Files: fast delta sync
sudo rsync -aHAX --delete --numeric-ids \
--exclude "wp-content/cache/" \
-e "ssh -p 22" \
root@OLD_SERVER_IP:/var/www/example.com/ \
/var/www/example.com/
Database: dump and import (generic)
On the old server:
mysqldump --single-transaction --routines --triggers \
-u DBUSER -p DBNAME | gzip > /root/db-final.sql.gz
Copy it over:
scp /root/db-final.sql.gz root@NEW_SERVER_IP:/root/
On the new server:
gunzip -c /root/db-final.sql.gz | mysql -u DBUSER -p DBNAME
Quick sanity checks (replace DBNAME):
mysql -u DBUSER -p -e "USE DBNAME; SHOW TABLES;" | head
mysql -u DBUSER -p -e "USE DBNAME; SELECT COUNT(*) FROM wp_options;"
If your site is large, stick with a method that keeps dumps consistent and imports predictable.
Cutover day is not the time to switch tools.
Step 9: Cut over DNS (A/AAAA records) with verification loop
Now you flip the records that steer real traffic. With TTL already lowered, “propagation” becomes a series of quick checks.
- Update A record for
@toNEW_SERVER_IP. - Update A record for
wwwtoNEW_SERVER_IP(or keep as CNAME to@if that’s your style). - If you use AAAA (IPv6), update it too—or remove AAAA temporarily if the new server doesn’t have matching IPv6 networking.
Verification loop from multiple resolvers:
dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8
dig +short example.com A @9.9.9.9
Then confirm requests are landing on the new machine.
The simplest way is a temporary header that only exists on the new server.
Nginx example in your server block:
add_header X-Server "new-vps" always;
Reload Nginx:
sudo nginx -t && sudo systemctl reload nginx
Check from your workstation:
curl -I https://example.com | grep -i x-server
Step 10: Post-cutover tasks (don’t declare victory yet)
Once resolvers start returning the new IP, finish follow-up work.
TTL is still low, so changes converge faster.
1) TLS validation and mixed content
- Confirm
https://loads without warnings. - Check for mixed content (browser console or a crawl).
- Confirm redirect behavior (
http→https, non-www → www or the reverse).
2) Email and DNS records you didn’t mean to touch
If you kept MX unchanged, mail should keep flowing.
Still, verify you didn’t edit the wrong records while you were in the zone.
Basic checks:
dig +noall +answer example.com MX
dig +noall +answer mail.example.com A
3) Cron jobs, background workers, and scheduled tasks
Many sites look fine until quiet jobs fail. Abandoned carts stop processing.
Scheduled emails don’t send. Backups never run.
- Copy crontabs from old server if applicable:
/etc/crontab,/etc/cron.d/, user crontabs. - For WordPress, consider replacing WP-Cron with a real system cron after cutover for reliability.
4) Monitoring so you catch the quiet failures
The first 24 hours is where monitoring pays off. Set alerts for uptime and basic performance.
You want dashboards to tell you first, not customers.
If you want a fast implementation, use: Netdata + uptime checks for VPS and dedicated servers.
Rollback plan: the exact steps to revert without panic
Rollbacks happen. What matters is deciding fast and reverting cleanly.
Also avoid creating more data drift while you flip back.
Rollback triggers (examples):
- Checkout failures or login loops you can’t fix in 15 minutes
- Unexpected 5xx spikes
- TLS validation failure you can’t resolve quickly
Rollback steps:
- Set site back to maintenance mode (so you don’t accept writes during the flip).
- Change A/AAAA records back to the old IPs (TTL is still low).
- Validate resolvers with
digagain (1.1.1.1, 8.8.8.8, 9.9.9.9). - Remove any “new server” test headers and temporary config.
- Do a short postmortem: what failed, what you’ll adjust, and when you’ll retry.
If you want a bigger-picture restore discipline (including DNS cutover, backups, and a tested runbook), this pairs well with: disaster recovery planning with DNS cutover and restore drills.
Quick checklist (printable)
- T-24h: Lower TTL to 300s for @ and www
- T-24h: Provision new server, update OS, baseline firewall
- T-12h: Initial file sync + baseline database import
- T-2h: Validate new server via hosts override; confirm app paths and PHP extensions
- T-30m: Prepare maintenance message and freeze plan
- T-10m: Freeze writes; final rsync + final DB dump/import
- T-0: Update A/AAAA records; verify with dig + curl headers
- T+15m: Ensure TLS valid; run smoke tests
- T+60m: Re-enable writes; monitor errors and latency
- T+24h: Raise TTL back to 3600–14400 if stable
Summary: make DNS boring, and migrations get easier
A smooth cutover is mostly discipline. Lower TTL early. Test the new server without touching public DNS.
Plan SSL instead of reacting to it. Then freeze writes briefly for the final sync.
Done right, the switch feels anticlimactic. Your rollback is also ready if you need it.
If you’re moving off an overloaded shared plan or consolidating multiple sites, start with a stable base like a HostMyCode VPS. If you’d rather not own patch cycles and routine ops, managed VPS hosting keeps your focus on validation and launch checks.
If you want a calmer cutover day, build the new environment on HostMyCode VPS for predictable performance and full root access. For production sites where uptime matters, managed VPS hosting covers the maintenance work in the background while you run validation and launch smoke tests.
FAQ
How low should TTL be before DNS cutover?
For most sites, 300 seconds is a practical floor. Lower it 24 hours before cutover so caches have time to age out.
Can I really get “zero downtime” during a migration?
You can usually avoid visitor-facing downtime, but any site that accepts writes still needs a short write-freeze to prevent lost orders or form submissions.
What’s the fastest way to confirm traffic hits the new server?
Add a temporary response header on the new server (for example X-Server: new-vps) and check it with curl -I while watching dig results from multiple resolvers.
When should I raise TTL back up after the cutover?
After 12–24 hours of stable operation. Many teams set TTL back to 3600 or 14400 to reduce resolver load and avoid extra DNS queries.
What if some users still hit the old server after DNS change?
That’s normal due to resolver caching and ISP behavior. Keep the old server online during the transition window and avoid destructive changes until traffic fully drains.