How to migrate to a VPS without downtime

Whether you are outgrowing shared hosting, escaping a slow provider, or just chasing a better price, moving to a new VPS is one of those jobs that feels scarier than it is. The trick is to keep the old server running until the new one is proven, so a mistake costs you nothing but time. Here is how to plan the move, transfer everything, and cut over without your visitors ever noticing.

Plan the target before you touch anything

A clean migration starts with an inventory of what you actually run: the web server and its config, databases, application code, cron jobs, environment variables, TLS certificates, and any background workers or queues. Write them down, because the thing that breaks a move is almost always the small piece nobody remembered — a firewall rule, a system user, a scheduled backup script. While you are listing, note the real resource usage of each part so you size the new machine to the load rather than guessing. If you are not sure how much CPU, RAM, or disk the new box needs, our how to choose a VPS checklist walks through the trade-offs, and the sizing calculator on our home page turns a rough workload into a concrete plan.

Pick the target provider and region with the move in mind, not just today's price. If your users are concentrated in one part of the world, put the server near them — network distance adds latency that no amount of CPU can claw back, as our note on server location and latency explains. Provision the new VPS a day or two ahead of the actual cutover so you have time to install the base stack, patch the OS, and get comfortable on it while the old server keeps serving traffic. Paying for two machines for a few days is cheap insurance against a rushed, error-prone move; if budget is tight, the deals on our VPS deals page make that overlap almost painless.

Move your data and services

With the new server prepared, copy the static pieces first: application code, uploaded files, and configuration. rsync over SSH is the workhorse here — it copies only what has changed, so you can run it once to move the bulk of the data early and again just before cutover to catch anything new. Databases need more care than a file copy, because a live database changing under you produces a corrupt dump. Use the database's own tool — mysqldump, pg_dump, or a managed export — to take a consistent snapshot, transfer it, and import it on the new machine, then verify the row counts and a few sample records match before you trust it.

Before you take that final snapshot, make a full backup of the source server so you have a known-good copy to fall back to if the migration goes sideways; our guide to VPS backups and snapshots covers how to do that properly. Once the data is on the new box, bring the services up and test them in isolation — point your own machine at the new server by editing your local hosts file, and click through the site, log in, submit a form, run the checkout. You want every moving part exercised on the new server while the public is still hitting the old one, so any problem is yours to fix quietly rather than a live outage.

Cut over cleanly — and keep the old server

The switch itself is a DNS change, and the secret to a smooth one is planning the TTL. A day or two before cutover, lower the TTL on the relevant DNS records to something short like 300 seconds, so that when you finally change the record the world picks it up in minutes instead of hanging on to the old address for hours. Just before flipping the record, run one last rsync and a fresh database sync to catch anything created since your test import, then update the DNS to point at the new server's IP. For a busy database-backed app, briefly putting the site in read-only or maintenance mode during that final sync guarantees no writes are lost in the gap.

After the record changes, watch both servers. Traffic will drain from the old machine to the new one over the TTL window, so keep the old VPS running and untouched for at least a few days — it is your instant rollback if something surfaces under real load that your testing missed. Check the new server's logs for errors, confirm cron jobs actually fire, and make sure your backups are running on the new home before you decommission the old one. Only when the new machine has carried live traffic cleanly for a while should you shut the old server down and cancel it. If the move was about cost, this is also the moment to right-size — our cheap VPS guide covers how to trim spend without cutting the corners that matter.