Migrating to a dedicated server

Updated October 28, 2026

The goal is a cutover measured in minutes of read-only time. The trick is to copy almost everything while the old server is still live, then sync only the difference at the end.

Before the move

1. List everything the old server does: ss -tlnp for listening services, crontab -l for each user, /etc/cron.d, systemd timers, mail, and firewall rules.
2. Match software versions on the new server (PHP, database major version, Node, Python) or plan the upgrade as a separate step.
3. Lower the TTL on every DNS record you will change to 300 seconds, at least one old-TTL period before cutover.

First copy, while live

# files: run from the NEW server
rsync -aHAX --numeric-ids --info=progress2 olduser@OLD_IP:/var/www/ /var/www/

# MySQL / MariaDB: consistent dump without locking InnoDB tables
mysqldump --single-transaction --routines --triggers --all-databases | gzip > all.sql.gz

# PostgreSQL
pg_dumpall | gzip > all.sql.gz

Load the dumps on the new server and test every site through a hosts-file entry pointing at the new IP.

Cutover

1. Put the application into maintenance or read-only mode on the old server.
2. Run the same rsync again; it only copies what changed, so it is fast.
3. Take and load a final database dump (or promote a replica if you set one up).
4. Change DNS to the new IP. With a 300-second TTL most clients follow within minutes.
5. Reissue TLS certificates on the new server once DNS points at it.

After

• Watch web server and application error logs for the first day.
• Check that cron jobs and mail run on the new server and no longer on the old one.
• Keep the old server for a week before cancelling it, in case something was missed.
• Raise DNS TTLs back to normal.

Prefer to hand this off? We do it for a flat fee; see migration.