DNS Cutover Checklist for VPSGrid Migration

Customer-executed DNS

VPSGrid does not change your registrar DNS for you. You lower TTL, update records, and monitor propagation. VPSGrid does not guarantee zero-downtime migration.

Short answer

Before VPSGrid migration DNS cutover: lower TTL to 300s, verify site on VPS IP, record old A record values, update A/AAAA to VPSGrid primary IP, monitor propagation with multiple resolvers, obtain SSL after HTTP resolves, keep old host online until TTL expires.

Overview

Customers moving websites to VPSGrid who control DNS at a registrar or DNS provider — complements Migrate WordPress from Shared Hosting to VPSGrid, Migrate from cPanel Shared Hosting to VPSGrid VPS, and Pre-Migration Backup Checklist for VPSGrid.

VPSGrid sells unmanaged VPS with root or administrator access. Guest OS configuration, application data, backups, and patching inside the VM are your responsibility unless a separate product is documented. Review What Is an Unmanaged VPS at VPSGrid? and Security Responsibilities on Unmanaged VPS before expecting support to perform stack work.

US-Based VPS infrastructure

VPSGrid provides unmanaged Linux and Windows VPS on US-Based KVM infrastructure with NVMe storage and Proxmox virtualization. You manage the guest OS, applications, backups, and security. Current plan specifications appear at checkout on vpsgrid.net — articles do not publish fixed pricing.

DNS Cutover Checklist Flow Lower TTL Test on IP Update A Monitor SSL VPSGrid does not control registrar DNS — you execute cutover Keep old host online until TTL expires and tests pass

Diagram: Lower TTL, test on VPS IP, update A record, monitor propagation, then obtain SSL.

Decision guidance: cutover timing

Signal	Ready to cut over	Wait
Site loads on VPS IP	Yes	—
TTL lowered 24–48h ago	Yes	High TTL still cached
Final DB sync done	Yes	Stale data on VPS

Schedule cutover during low-traffic windows. Outage length depends on prior TTL and resolver caches — not VPSGrid SLA.

Checklist: before cutover

Document current A, AAAA, CNAME, MX, TXT records
Lower TTL on records you will change (24–48h ahead)
Confirm VPS web stack responds on primary IP
Prepare rollback A record values in a safe note

Checklist: cutover execution

Final content/database sync on source and VPS
Update A record to VPSGrid primary IP
Update AAAA if using IPv6 and assigned on service
Do not change MX unless migrating mail
Monitor HTTP from external networks

dig +short example.com A @8.8.8.8

What it does: Queries Google public resolver for current A record.
Why it matters: Confirms propagation from one major resolver.
Expected result: Returns VPSGrid IP when cutover visible.
If it fails: Old IP still returned — wait for TTL or check registrar save status.

dig +short example.com A @1.1.1.1

What it does: Queries Cloudflare resolver — second opinion.
Why it matters: Propagation is uneven across resolvers globally.
Expected result: Both resolvers return VPSGrid IP when widely propagated.
If it fails: Split results — normal during TTL window; wait and retest.

grep example.com /etc/hosts || echo "PRIMARY_IP example.com" | sudo tee -a /etc/hosts

What it does: Local hosts file override for pre-cutover testing on your workstation.
Why it matters: Tests site before public DNS changes.
Expected result: Browser loads VPS copy when hosts entry active.
If it fails: Remove hosts entry after testing to avoid stale local cache.

Verify

curl -I http://example.com returns 200 from VPS
TLS certificate issued after HTTP valid — Let's Encrypt SSL with Certbot on VPSGrid
Forms, logins, webhooks function
MX records unchanged if mail stays at old host

Troubleshooting matrix

Symptom	Likely cause	What to check
Old site still shows	TTL not expired	Wait or flush local DNS cache
SSL fails after cutover	HTTP not on VPS yet	Verify A record; port 80 open — How to Configure UFW Firewall on Ubuntu/Debian
Email stopped	MX changed accidentally	Restore MX; web A independent of mail
A vs CNAME at apex	Registrar limitation	Use A record or ALIAS/ANAME per registrar docs

Rollback guidance

Revert A record to previous IP if VPS copy fails validation. Keep source hosting active until stakeholders sign off. Document rollback values before you change anything.

Security considerations

Verify you edit DNS at legitimate registrar — phishing panels cause hijacks. Enable registrar lock after cutover.

A record vs CNAME at apex

Apex domains (example.com without www) typically use A records pointing to VPSGrid primary IP. Some DNS providers offer ALIAS/ANAME for apex CNAME-like behavior — consult registrar docs. www subdomain may CNAME to apex or use separate A record.

IPv6 (AAAA) considerations

If VPSGrid assigns IPv6 and you publish AAAA records, verify web server listens on IPv6 and UFW allows v6 rules. Mismatch between A and AAAA causes partial user outages.

Monitoring propagation systematically

Check from multiple networks: office DNS, mobile hotspot, and external tools like Checking DNS Propagation for Your VPSGrid Domain. Record timestamps when major resolvers flip — helps explain support tickets during TTL window.