Switching VPS provider without losing a weekend.

Step 1: Inventory the old server

Most failed migrations fail on the thing nobody wrote down. Spend twenty minutes listing what runs, what listens on which port, and what cron does at night.

ss -tulpn
systemctl list-units --type=service --state=running
docker ps --format '{{.Names}}  {{.Image}}  {{.Ports}}'
crontab -l; ls /etc/cron.d
df -h; du -sh /srv /var/lib/docker /home 2>/dev/null

Note every environment file, certificate, SSH key, firewall rule and DNS record, and which services hold state (databases, uploads, queues).

Step 2: Order the new server and harden it

Pick the OS release you run today, so packages and config paths match. The VPS is online 30-60 seconds after payment. Add your SSH key via cloud-init, then do the basics.

apt update && apt upgrade -y
apt install -y ufw rsync restic
ufw allow OpenSSH && ufw allow 80,443/tcp && ufw enable
curl -fsSL https://get.docker.com | sh

Step 3: Move the files with rsync or restic

For a first pass while the old server is still live, rsync is the simplest tool. Preserve ownership, ACLs and extended attributes, and use numeric IDs so users that do not exist yet on the new host map correctly.

rsync -aHAX --numeric-ids --info=progress2 -e ssh \
  root@OLD_IP:/srv/ /srv/
rsync -aHAX --numeric-ids -e ssh root@OLD_IP:/etc/nginx/ /etc/nginx/
rsync -aHAX --numeric-ids -e ssh root@OLD_IP:/etc/letsencrypt/ /etc/letsencrypt/

If you already back up with restic, restoring the latest snapshot on the new server is a clean alternative and proves the backups work.

export RESTIC_REPOSITORY=sftp:backup@BACKUP_HOST:/repo
restic snapshots
restic restore latest --target / --include /srv --include /etc/nginx

Step 4: Move databases with dumps, not file copies

Never rsync a running database directory. Dump on the old host, import on the new one.

# old server
pg_dumpall -U postgres | gzip > /root/pg-all.sql.gz
mysqldump --all-databases --single-transaction | gzip > /root/mysql-all.sql.gz
# new server
zcat pg-all.sql.gz | psql -U postgres
zcat mysql-all.sql.gz | mysql

For Docker stacks, copy the compose files and named volumes, then start them and check that every container is healthy before you touch DNS.

cd /srv/app && docker compose pull && docker compose up -d
docker compose ps
docker compose logs --tail=50

Step 5: Lower the DNS TTL, do a final sync, cut over

A day before the switch, lower the TTL on the records you will change to 300 seconds. On the day: stop the writing services on the old box, rsync once more with --delete, import the final database dump, start everything on the new server, then point the A and AAAA records at the new IPv4 and IPv6.

rsync -aHAX --numeric-ids --delete -e ssh root@OLD_IP:/srv/ /srv/
dig +short example.com A

Test with the new IP in your hosts file first, so the first public request is not your first test.

Step 6: Keep the old server for a week

Do not cancel on cut-over day. Leave the old server running, read-only if possible, for seven days and watch the logs on the new box for a path, cron job or environment variable you missed. When the week is quiet, cancel the old one.