Migrating a VPS to a new server

What this is#

Moving everything from one VPS to another: coming from another provider, replacing a server, rebuilding after a compromise, or switching product lines here (there's no automatic Linux VPS → Premium VPS conversion, this guide is the path). One carve-out first: if you only want the same VPS in a different location, don't migrate at all, we offer an automated location migration for a $4 fee, ordered from your client area (your IP changes with it, so the checklist below still applies). And if you're coming from shared hosting, that's the other guide.

Don't copy the disk, move the workload#

The instinct is to image the old disk onto the new server; resist it. Different platforms differ in kernel, network configuration, and boot plumbing, and a transplanted disk drags along every accumulated quirk (and, if you're rebuilding for security reasons, the compromise itself). The clean method mirrors the backup doctrine: the OS and services are rebuildable, the data is irreplaceable, so install fresh and move only the data.

1. Deploy the new VPS and set up the stack (web server, runtime, database, the site plumbing), old server untouched and live.
2. Move data (below).
3. Test, cut over, run in parallel, decommission.

Move files server-to-server#

Both machines are servers on fast links, so transfer directly between them over SSH, never down to your home connection and back up:

rsync -avz --progress [email protected]:/var/www/ /var/www/

Run it from the new server (pulling), inside tmux so a dropped SSH session doesn't kill a long transfer. rsync is restartable by nature, re-running continues where it left off.

Databases move by dump, not by file copy#

Copying /var/lib/mysql between servers invites version and consistency trouble; a dump restores cleanly across versions. Pipe it straight over SSH, no intermediate file:

ssh [email protected] "mysqldump --single-transaction --all-databases" | mysql

(--single-transaction gives a consistent snapshot of InnoDB databases without locking the live site. PostgreSQL: the same pattern with pg_dumpall.)

The two-pass trick: minutes of downtime at any size#

Big sites don't need long outages, split the copy:

1. Pass one, live: run the full rsync and DB import while the old server keeps serving. Takes as long as it takes; nobody notices.
2. Freeze: at cutover time, stop writes on the old server (put the app in maintenance mode or stop its services).
3. Pass two, delta: re-run the same rsync (it now transfers only what changed since pass one, seconds to minutes) and re-import the database dump.
4. Switch DNS. Total write-downtime: the delta pass, not the migration.

The new-IP checklist#

The server moved; its IP address didn't come along. This list is what prevents the week-two surprises:

• DNS: A and AAAA records to the new IP (lower TTL a day ahead, and test first with the hosts-file trick).
• SPF: if the server sends mail, your SPF TXT record names the old IP, mail keeps flowing but starts landing in spam, silently. Update ip4: to the new address.
• rDNS: set the new IP's PTR to your hostname from the Network tab (mail servers especially).
• SSL: issue fresh certificates on the new server with certbot once DNS points there, cleaner than hauling the old keys across.
• Hardcoded IPs: grep your app configs, firewalls elsewhere, and monitoring for the old address.
• Third-party allowlists: payment gateways, external APIs, and remote databases that allowlisted your old IP need the new one, this is the one that always gets forgotten until something 403s.

Cut over, overlap, decommission#

Switch DNS, then run both servers in parallel for a few days: watch the old server's access log, real traffic still arriving there means cached DNS or a record you missed. When the old log goes quiet: take one last data snapshot for your off-site backups, then decommission the old server, and if the old one is with us, cancellation deletes it and its data permanently, so the snapshot comes first.

As always: the hands-on work is yours on a self-managed service, and every command above is safe to ask an AI chatbot to adapt to your exact stack.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP, and where you're migrating from,
• which step you're on (copy, database, DNS cutover), with the exact error.

Related questions#

• "How do I migrate my VPS from another provider?"
• "How do I move from Linux VPS to Premium VPS?"
• "How do I transfer a large site with minimal downtime?"
• "Should I copy the whole disk or reinstall and move data?"
• "What breaks when my server's IP changes?"
• "When is it safe to cancel the old server?"