Move a website between VPS hosts with a safe DNS cutover

DNS changes are easy. Migrating the state behind them without dropped writes or a long rollback is the real work. Treat the move as a staged deployment.

Two days before the move

Lower the relevant A and AAAA record TTLs to 300 seconds. Do this at least one old-TTL period before the cutover. If the existing TTL is 86400, lowering it five minutes before migration changes nothing for caches that already stored the old value.

Inventory every dependency:

• Web files and uploaded media
• Database and background workers
• Cron jobs or systemd timers
• TLS certificates and environment secrets
• DNS records, redirects, and firewall allowlists
• Webhooks that depend on source IP

Build the destination completely

Install the application, restore a recent database copy, and transfer files. Keep public traffic on the old server.

Test the new origin without changing DNS:

curl --resolve example.com:443:203.0.113.50 https://example.com/

For browser testing, add a temporary hosts-file entry. Verify login, uploads, email, background jobs, certificates, and application logs.

Plan the write boundary

For a mostly static site, a final rsync is enough. For a database-backed application, choose one approach:

1. Brief maintenance mode, final dump, restore, switch.
2. Database replication, promote the destination, switch.
3. Application-level dual writing, reserved for systems already designed for it.

The first option is often safest for a small service because the write gap is obvious and bounded.

Execute the cutover

Put the old app in maintenance or read-only mode. Take the final database backup and file sync, restore them, start workers on the new host, and run a smoke test.

Change A and AAAA records. Query the authoritative nameserver directly:

dig @ns1.provider.example example.com A +noall +answer
dig @ns1.provider.example example.com AAAA +noall +answer

Watch access logs on both servers. Traffic tapering from old to new is normal while caches expire.

Keep rollback boring

Do not modify data independently on both hosts. If the new service fails before writes resume, change DNS back and remove maintenance mode on the old host. If new writes have already landed, restore or replicate those writes before rolling back.

Keep the old VPS online but read-only for at least one longest-previous-TTL period, preferably 24–48 hours. Continue monitoring both addresses directly.

After the migration is stable, raise TTLs, update monitoring and backup targets, rotate credentials copied during the move, and remove the old host. A safe cutover ends with one authoritative system, not two servers everyone is afraid to delete.

Make the checklist executable

Before the window, write down the exact commands, owners, and abort conditions. Include the final file sync, database dump, restore, service start, health checks, DNS edit, and rollback command. Have one person execute and another watch logs and external probes.

During the cutover, record timestamps for maintenance start, final backup, DNS change, first successful request, and maintenance end. If the new host is not healthy by the agreed deadline, stop adding changes and roll back. Do not keep debugging indefinitely while users receive a half-migrated service.

Afterward, compare application error rates, queue depth, database connections, and background-job success on both sides. Test IPv4 and IPv6 separately. Confirm certificates, webhooks, outbound email, backups, and monitoring now reference the destination. Migration is complete only when the operational dependencies moved with the DNS record.