How do you migrate a Linux VPS to a new host without losing data?

What should you write down before moving anything?

Everything that runs, everything that is scheduled, and everything that stores data. A move fails on the cron job nobody remembered, not on the main app. Run the commands below on the old server and keep the output. Note as well what lives outside the machine: DNS records, firewall allowlists at partners that name your old IP address, API keys bound to it, and the TLS certificates.

cat /etc/os-release
ss -tulpn                                   # what listens
systemctl list-units --type=service --state=running
systemctl list-timers
crontab -l; ls /etc/cron.d /var/spool/cron/crontabs 2>/dev/null
apt-mark showmanual                         # packages you installed
docker ps 2>/dev/null
df -h; du -sh /srv /var/www /var/lib/postgresql /var/lib/mysql 2>/dev/null
free -h

Should you copy the whole disk or rebuild the server?

Rebuild on a fresh image, then copy data and configuration. A disk image carries the old host's network settings, cloud-init state, drivers and every forgotten experiment. A rebuild leaves them behind and is the cheap moment to move up a release: a Debian 12 server can land on Debian 13, an Ubuntu 22.04 server on 24.04.

A release jump changes versions under your apps. From Debian 12 to 13, PHP goes from 8.2 to 8.4, PostgreSQL from 15 to 17 and MariaDB from 10.11 to 11.8. Test the app on the new server before the cutover, not after.

Order the destination early. A team member sets up every VPS by hand after your payment confirms, within 24 hours; your dashboard follows the build and then shows the IP address. Then run through the first ten minutes on a Linux VPS before copying anything onto it.

How do you copy files with rsync without losing permissions?

Use -aHAX: archive mode alone keeps neither hard links, ACLs nor extended attributes. The rsync manual says so: -a means -rlptgoD, with no -H, -A or -X.

Pull from the new server so the copy runs where the data lands. Give it a key of its own, add that public key to the old server for the move, and remove it afterwards. A trailing slash on the source copies the folder's content, not the folder. Without --numeric-ids, rsync matches owners by name, which is what you want on a rebuilt system where service users may have other numbers. Run the first pass while the old server is live; the last pass, after writes stop, then only moves what changed.

ssh-keygen -t ed25519 -f ~/.ssh/migrate -C "migrate-2026"
# add ~/.ssh/migrate.pub to /root/.ssh/authorized_keys on the old server

# first pass, old server still live
rsync -aHAX --info=progress2 -e "ssh -i ~/.ssh/migrate" [email protected]:/srv/ /srv/

# last pass after the write freeze: dry run, then the real one
rsync -aHAX --delete -n -e "ssh -i ~/.ssh/migrate" [email protected]:/srv/ /srv/
rsync -aHAX --delete -e "ssh -i ~/.ssh/migrate" [email protected]:/srv/ /srv/

How do you move a database without corrupting it?

Dump and restore; never copy the files of a running database. A copy of /var/lib/postgresql or /var/lib/mysql taken while the server writes is not consistent, and it also ties you to the old major version. pg_dump makes a consistent export while the database is in use. It covers one database; roles live in the cluster and come from pg_dumpall --globals-only. For MariaDB, mariadb-dump --single-transaction takes a consistent snapshot of InnoDB tables without blocking the application, and --databases adds the CREATE DATABASE lines. Its users and grants are not in that dump: create them again on the new server.

A dump from PostgreSQL 15 restores into 17, which is how a Debian 12 to 13 move upgrades the database on the way.

# old server
sudo -u postgres pg_dumpall --globals-only > globals.sql
sudo -u postgres pg_dump -Fc appdb > appdb.dump
mariadb-dump --single-transaction --routines --databases shopdb > shopdb.sql

# new server, after copying the three files
sudo -u postgres psql -f globals.sql
sudo -u postgres createdb -O appuser appdb
sudo -u postgres pg_restore -d appdb appdb.dump
mariadb < shopdb.sql

How do you switch DNS with only a few minutes of downtime?

Lower the TTL a day ahead, test the new server under its real name before switching, then cut over in a short write freeze.

1. A day before, set the TTL of the A and AAAA records to 300 seconds. Resolvers drop the old answer within one old TTL, so wait at least that long.
2. Test the new server with the real host name without touching DNS: curl --resolve sends the request to the new address. Get its certificate the same way you will in production, or copy /etc/letsencrypt across.
3. Stop writes on the old server: maintenance mode or a stopped app. Run the last rsync and a fresh dump.
4. Point the A and AAAA records at the new addresses. Watch the logs of both servers until the old one goes quiet, then raise the TTL again.

Mail is the trap of many moves. Outbound port 25 is closed on every VPS and is not opened on request; send mail through a mail provider on port 465 or 587. An app that sent mail directly from the old server needs its provider's SMTP settings before the cutover.

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/
curl -sI --resolve "example.com:443:[2001:db8::10]" https://example.com/

When can you turn the old server off?

When the new one has run real traffic for some days, its backups have been restored once, and nothing still talks to the old address. No plan includes backups, so keep your own copy of anything that matters. Check the old server's logs for late visitors, look for scheduled jobs that ran on the new one, and update partner allowlists with the new IP address. Then remove the migration key, take a last dump for the archive, and cancel the old plan through the old host's own process: a stopped server often keeps billing.

Which plan matches the server you have now?

Size by what the old server uses, plus room to grow: RAM in use from free -h, disk in use from df -h. The vCPU of every plan are shared: they are scheduled on physical cores that neighbouring VPS also use. The RAM and NVMe space of your plan are reserved for your VPS only. A plan costs the same in New York, Dallas, Los Angeles, London, Amsterdam and Frankfurt. Each price was set against a named plan on sale in one of the six cities on 3 November 2026: Los Angeles for Byte, Kilo and Mega, Amsterdam for Giga and Tera.

• Byte (1 vCPU / 2 GB / 40 GB): $2.25 a month on a 12-month term, $3.21 month to month.
• Kilo (2 vCPU / 4 GB / 65 GB): $4.49 or $6.42.
• Mega (2 vCPU / 6 GB / 120 GB): $6.75 or $9.64.
• Giga (4 vCPU / 8 GB / 160 GB): $13.50 or $19.28.
• Tera (8 vCPU / 24 GB / 400 GB): $20.62 or $29.46.

Coming from Vultr, DigitalOcean or Linode? Alternatives to Vultr, DigitalOcean and Linode compares how they take payment and what they ask for.