A DNS cutover rarely fails because DNS is “broken.” It fails because the new server isn’t ready, mail records get missed, or rollback takes too long. This DNS cutover checklist tutorial gives you a practical 2026 workflow for VPS, dedicated, or shared hosting moves. It includes commands and verification steps to keep surprises to a minimum.
The goal is simple: visitors keep browsing, orders keep processing, and email keeps delivering while traffic shifts to the new host.
What you’ll accomplish (and what you need before you start)
By the end, you’ll have:
- A verified copy of your site on the destination server
- DNS records ready to switch with minimal propagation risk
- A clean plan for email (the most common migration blind spot)
- A rollback you can execute in minutes
Prereqs: domain access (registrar/DNS provider), SSH or control panel access to both hosts, and a planned maintenance window (even if you expect zero downtime).
If you’re moving to a VPS where you control the stack, start from something stable. A HostMyCode VPS gives you root access for a clean migration and predictable performance.
If you don’t want to run the server day to day, managed VPS hosting is usually the safer choice for production cutovers.
Step 1: Inventory your DNS and dependencies (don’t trust memory)
Before you touch TTLs, capture what the domain actually uses.
This step prevents the classic cutover where the site works but email dies.
1A) Export current DNS records
From any Linux shell, query your current records:
# Replace example.com
DOMAIN=example.com
dig +short A $DOMAIN
dig +short AAAA $DOMAIN
dig +short CNAME www.$DOMAIN
dig +short MX $DOMAIN
dig +short TXT $DOMAIN
dig +short _dmarc.$DOMAIN TXT
If your DNS provider offers an export, download it too.
Treat that file as your rollback source of truth.
1B) Identify non-obvious services
- Email: MX, SPF, DKIM, DMARC, plus any SMTP relay provider records.
- CDN/WAF: Cloud proxying can hide the true origin IP. You may need to update an origin setting instead of DNS.
- Verification TXT: Google, Microsoft, payment gateways, search console, SSL validation.
- Subdomains: app., api., staging., mail., cp., webmail., autodiscover.
For email-specific checks and common failure modes, pair this with Email Deliverability Troubleshooting Tutorial (2026).
Step 2: Prepare the destination host like it’s already live
DNS should be the last switch you flip.
The destination must be production-ready first. Don’t settle for “mostly working.”
2A) Provision the right hosting target
- Single business site / WooCommerce: VPS with enough CPU/RAM headroom for peak traffic.
- Agency / reseller workloads: VPS or dedicated server with a control panel (WHM/cPanel, DirectAdmin, Plesk).
- Simple brochure site: shared hosting can work, but migrations are easier when you can stage properly.
If you’re migrating multiple client sites, build the destination on a VPS first.
Move accounts in batches. Validate each group before you start the next one.
HostMyCode offers both VPS hosting and higher-capacity dedicated servers when you need consistent I/O for many accounts.
2B) Baseline security checks (quick, not academic)
At minimum, confirm:
- SSH keys work and password logins are controlled
- Firewall allows only required ports (80/443, 22, and mail ports only if hosting email)
- Automatic security updates are configured appropriately for your distro
For a no-lockout SSH workflow, follow SSH Key Setup Guide Tutorial (2026).
If you need hosting-safe firewall rules, use IPTables Firewall Configuration Tutorial (2026).
Step 3: Copy the website data to the new server (and keep it repeatable)
Your first copy is rarely the last.
Plan on at least one final sync right before the cutover.
3A) For a single site (typical VPS move): use rsync
On the destination server, pull web files from the source:
# Example paths for common hosting layouts
# Source: /var/www/example.com/public_html
# Destination: /var/www/example.com/public_html
rsync -aHAX --numeric-ids --delete \
-e "ssh -i ~/.ssh/migrate_key" \
root@SOURCE_IP:/var/www/example.com/public_html/ \
/var/www/example.com/public_html/
Tip: Use a dedicated SSH key for the cutover.
Restrict it to the source IP, and keep it only for the migration window.
3B) For cPanel/WHM: migrate as accounts, not folders
If you’re moving shared hosting accounts, avoid hand-copying files unless you’re forced into it.
Use WHM’s migration tools. They keep ownership, email, and SSL aligned with each account.
Use this walkthrough for the full flow: cPanel Account Migration Tutorial (2026).
3C) Confirm permissions and ownership
After copying, confirm the web user owns the web root.
Bad ownership often causes 403/500 errors right after cutover.
# Adjust user/group to match your setup
chown -R www-data:www-data /var/www/example.com/public_html
find /var/www/example.com/public_html -type d -exec chmod 755 {} \;
find /var/www/example.com/public_html -type f -exec chmod 644 {} \;
Step 4: Stage the new site and test it before touching DNS
“It loads on the server IP” isn’t enough.
You need the real domain in the Host header, working HTTPS, and the same behavior users will see.
4A) Use a temporary staging hostname (preferred)
Create a DNS record like staging.example.com pointing to the new server IP.
Install SSL for it, then test end-to-end.
- For WordPress, confirm admin login, permalinks, media uploads, and cron behavior.
- For e-commerce, test checkout, webhooks, and payment callbacks in a staging/sandbox mode.
4B) Or override hosts locally (fast for spot checks)
On your laptop, map the domain to the new IP:
# macOS/Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.50 example.com www.example.com
Browse the site normally.
If you use HTTPS, the certificate must match the domain or the browser will warn.
4C) Validate responses with curl
# Hit the new IP but send the domain in Host header
curl -I --resolve example.com:443:203.0.113.50 https://example.com/
# Confirm HTTP->HTTPS redirect behavior if you use it
curl -I --resolve example.com:80:203.0.113.50 http://example.com/
Look for 200, expected redirects (301), and headers that match what you intended to deploy.
Step 5: Reduce DNS TTL safely (the part most people rush)
Lowering TTL makes a cutover controllable.
If your TTL is 4 hours and you switch to the wrong IP, many resolvers will cache the bad answer for 4 hours.
Do this at least 24 hours ahead.
5A) Choose a TTL that fits your risk
- 300 seconds (5 minutes): common for a cutover window
- 600 seconds (10 minutes): calmer for high-traffic sites
- 60 seconds: works, but increases query load and sometimes triggers provider limits
5B) Lower TTL on the records you will change
Typically:
@A/AAAA recordswww(CNAME or A)- Any app subdomains that also move
Don’t change MX TTLs unless you’re also changing email routing.
5C) Verify TTL is live
dig example.com A +noall +answer
dig www.example.com CNAME +noall +answer
If you want a stricter workflow with timing guidance, use DNS TTL Reduction Tutorial (2026).
Step 6: Freeze changes and do a final sync (avoid “missing orders”)
For dynamic sites, DNS propagation isn’t the biggest risk.
Divergent data is. During the switch, the old and new servers can record different orders, leads, or comments.
6A) Pick your freeze strategy
- Short maintenance mode (recommended for WooCommerce): stop writes, sync, cutover, unfreeze.
- Read-only mode: allow browsing, block checkout/forms temporarily.
- No freeze: only acceptable for mostly static sites or when you have replication.
6B) Final rsync pass
rsync -aHAX --numeric-ids --delete \
-e "ssh -i ~/.ssh/migrate_key" \
root@SOURCE_IP:/var/www/example.com/public_html/ \
/var/www/example.com/public_html/
If WordPress is involved, clear caches on the new server after syncing.
That includes page cache, object cache, and CDN cache.
A stale cache can make a clean cutover look broken.
Step 7: Handle email explicitly (MX, SPF/DKIM, and rDNS)
Moving the website doesn’t automatically mean moving email.
Decide what you’re doing before you touch records.
- Email stays with current provider (Google Workspace, Microsoft 365, third-party mail) while website moves.
- Email moves with the website (cPanel mailboxes, Postfix/Dovecot on VPS).
7A) If email stays where it is
- Keep MX records unchanged.
- Update SPF only if your website server sends mail directly (often it shouldn’t).
- Prefer SMTP relay for web app mail rather than sending from the web server IP.
7B) If email moves to the new server
- Set correct hostname and HELO/EHLO.
- Configure SPF, DKIM, and DMARC for the sending domain.
- Set reverse DNS (PTR) for the new mail server IP, and ensure forward-confirmed reverse DNS.
Two guides that cover the most common breakpoints:
Step 8: Execute the DNS cutover (A/AAAA or CNAME changes)
Once staging tests pass and the final sync is done, switch traffic.
8A) Prefer A/AAAA changes for most migrations
Update:
example.comA (and AAAA if you use IPv6)www.example.com(CNAME to root or A to the new IP)
Before you save, write the old values into a rollback note.
Don’t rely on “I’ll remember it.”
8B) Validate propagation from multiple resolvers
# Check what Cloudflare DNS thinks
dig @1.1.1.1 example.com A +short
# Check Google DNS
dig @8.8.8.8 example.com A +short
# Check Quad9
dig @9.9.9.9 example.com A +short
You want to see answers moving toward the new IP.
You also want consistency across resolvers.
8C) Confirm traffic hits the new server
On the new server, tail access logs during the cutover window:
# Nginx
sudo tail -f /var/log/nginx/access.log
# Apache (common path on Debian/Ubuntu)
sudo tail -f /var/log/apache2/access.log
Watch for spikes in 404/500 responses.
That often means missing rewrites, permissions problems, or the wrong document root.
Step 9: Post-cutover checks (first 60 minutes)
Most migration problems show up quickly.
You’ll see them faster if you check the right paths first.
9A) A quick production checklist
- Homepage loads on HTTPS with the correct certificate
- Login works and sessions persist
- Forms submit (and you receive the email)
- Checkout works (if applicable)
- Media uploads work (WordPress:
wp-content/uploadswritable) - Background tasks run (WordPress cron or real cron)
- Error logs stay clean
9B) Monitor uptime and health endpoints
If you don’t have external monitoring, you’re guessing.
Set up a basic check for your homepage and a lightweight health URL.
This guide shows a clean setup: Uptime Monitoring Tutorial (2026).
9C) Fix SSL issues immediately
After a cutover, Let’s Encrypt renewals can fail for a few common reasons:
- Port 80 is blocked
- DNS still points partly to the old server
- Your web server responds incorrectly to ACME challenges
If you hit renewal errors, follow SSL Renewal Troubleshooting Tutorial (2026).
Step 10: Rollback plan (you only need it once)
A rollback isn’t a defeat.
It’s how you keep production stable while you fix the new host properly.
10A) When to rollback
- Critical checkout failures
- Widespread 500 errors you can’t fix quickly
- Data-loss risk (orders/leads not recorded)
10B) How to rollback fast
- Switch A/AAAA records back to the old IP.
- Confirm resolver answers with
dig(as in Step 8B). - Keep investigating on the new host while production runs on the old host.
This is exactly why you lowered TTL ahead of time.
Step 11: Cleanup after a successful cutover
Once traffic is stable (often 24–48 hours), clean up.
Migrations often leave behind security risks and avoidable costs.
- Raise TTLs back to normal values (e.g., 3600 or 14400 seconds) to reduce DNS query volume.
- Remove temporary staging DNS records you no longer need.
- Disable any migration SSH keys and firewall migration-only IP access.
- Set backups on the new host and test a restore.
If you want a backup workflow built for VPS restores, use VPS Backup Automation Tutorial (2026).
Summary: your 2026 DNS cutover workflow (printable checklist)
- Inventory DNS + dependencies (especially email)
- Prepare destination host like it’s already live
- Copy data in a repeatable way (expect a final sync)
- Stage and test using real hostnames and HTTPS
- Lower TTL at least 24 hours ahead
- Freeze writes (or plan for divergence)
- Cut DNS and validate from multiple resolvers
- Watch logs and uptime checks during the first hour
- Rollback quickly if revenue-critical paths break
- Raise TTL and lock down access after success
If you’re planning a move and want predictable networking, clean IP reputation options, and the ability to tune your stack, start on a HostMyCode VPS.
For hands-off production migrations, pair the cutover plan with HostMyCode migrations so you’re not troubleshooting DNS at 2 a.m.
If you’re migrating a production site, build the destination somewhere you can stage, test, and scale without guessing. A managed VPS hosting plan from HostMyCode gives you a stable base for cutovers, plus help with the server-side details that usually create downtime.
Already have a server picked? Use HostMyCode migrations to move sites and accounts with clear validation steps and a rollback plan you can execute quickly.
FAQ
How long should I keep TTL low during a migration?
Keep it low through the cutover window and until you’ve confirmed stability (often 24 hours).
Then raise it to reduce DNS query volume.
Should I change nameservers during a cutover?
Only if you must. A nameserver move adds extra propagation variables.
If the goal is a fast, safe cutover, change A/AAAA/CNAME records at the current DNS provider instead.
Why do some users still hit the old server after I update DNS?
Caching. Some resolvers and clients keep records longer than expected.
This is common when TTLs were high before you reduced them. Lower TTL a day in advance, and keep the old host online during the transition.
What’s the safest way to migrate WooCommerce without losing orders?
Use a short maintenance window (freeze writes), do a final sync, cut DNS, then unfreeze once you confirm checkout and webhooks work on the new host.
“No freeze” migrations often miss edge-case orders.
Can I avoid email downtime if I’m also moving mailboxes?
Yes, but it requires planning: keep MX TTL reasonable, sync mailboxes, verify SPF/DKIM/DMARC, and ensure rDNS is correct for the new sending IP.
If you can, keep email on a dedicated provider and move only the website.