# Migrating a VPS to a new server Source: https://vpsdime.com/knowledgebase/getting-started/migrating-a-vps Last reviewed: 2026-07-02 Summary: Moving from one VPS to another, from another provider, between product lines, or as a rebuild, done the clean way: rebuild services, move data server-to-server with rsync over SSH, dump databases rather than copying files, the two-pass rsync for minutes of downtime, and the new-IP checklist (DNS, SPF, rDNS, SSL, allowlists) that prevents the post-move surprises. ## What this is Moving everything from one VPS to another: coming from another provider, replacing a server, rebuilding after [a compromise](https://vpsdime.com/knowledgebase/troubleshooting/compromised-vps-recovery), or switching product lines here (there's no automatic Linux VPS → Premium VPS conversion, this guide is the path). One boundary: this is a **Linux-to-Linux** guide, between Linux and Windows there's no migration in this sense, applications get reinstalled on the new OS and you copy data files across, then cancel the old service. One carve-out first: if you only want the **same VPS in a different location**, don't migrate at all, we offer a [location migration](https://vpsdime.com/knowledgebase/client-area/services/migrate-location) for a $4 fee, ordered from your client area and carried out by our team, and if you don't need the data at all, we'll re-provision the VPS in the new location for free (your IP changes either way, so the checklist below still applies). And if you're coming from *shared hosting*, that's [the other guide](https://vpsdime.com/knowledgebase/getting-started/migrating-to-a-vps). ## 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](https://vpsdime.com/knowledgebase/getting-started/backing-up-your-vps): 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](https://vpsdime.com/knowledgebase/getting-started/hosting-a-website)), 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 root@OLD.SERVER.IP:/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 root@OLD.SERVER.IP "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](https://vpsdime.com/knowledgebase/getting-started/pointing-your-domain), and test first with the [hosts-file trick](https://vpsdime.com/knowledgebase/getting-started/migrating-to-a-vps)). - **SPF**: if the server sends mail, your SPF TXT record names the **old IP**, mail keeps flowing but starts [landing in spam](https://vpsdime.com/knowledgebase/troubleshooting/emails-going-to-spam), silently. Update `ip4:` to the new address. - **rDNS**: set the new IP's PTR to your hostname from the [Network](https://vpsdime.com/knowledgebase/client-area/services/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](https://vpsdime.com/knowledgebase/getting-started/backing-up-your-vps), then decommission the old server, and if the old one is with us, [cancellation](https://vpsdime.com/knowledgebase/client-area/services/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](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management), 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](https://vpsdime.com/open-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?"