Migrating a project from VPS to a dedicated server
The move takes four steps: build a mirror of the environment on the new machine, sync files with rsync and the database with a dump, test the project by IP without touching DNS, then switch the records with a short TTL. With this sequence downtime is the few minutes of the final re-sync, not hours.
- Lower the TTL of your DNS records to 300 seconds a day before the switch, or part of your visitors will keep hitting the old server for another day.
- Move files with rsync in two passes: a long draft pass on the live project and a short final pass after writes stop.
- Move the database with a dump taken inside a transaction, never by copying the data directory of a running engine.
- Keep the old VPS paid for another week — it is the cheapest rollback plan there is.
Step 0. Inventory and preparation
Write down what actually runs on the VPS: versions of PHP, Python or Node, the web server and its configs, the database engine and its version, cron jobs, systemd units, certificates, deploy keys, external mounts.
On the new server do the basic setup right away: SSH keys, updates, firewall, monitoring. The order of first steps on a fresh machine is covered in dedicated server acceptance, and the general logic of moving between hosting types is in dedicated server or VPS.
| What moves | With what | What to watch |
|---|---|---|
| Site files and uploads | rsync with -aHAX | Permissions, owners, hard links, xattrs |
| MySQL or MariaDB | mysqldump with single-transaction | Charset, routines, triggers, events |
| PostgreSQL | pg_dump in custom format | Extensions, roles, schema privileges |
| Packages and versions | dpkg or rpm listing | PHP version and modules, engine version |
| Scheduled jobs | crontab and systemd timers | Job owner, environment variables |
| Certificates | Copy the directory or reissue | Chain, private key permissions |
Step 1. Data
# first pass: safe to run while the project is live
rsync -aHAX --numeric-ids --delete \
-e 'ssh -p 22' /var/www/ root@NEW_IP:/var/www/
# MySQL/MariaDB dump without locking InnoDB tables
mysqldump --single-transaction --quick --routines --triggers --events \
--databases shop > /root/shop.sql
# ship it and restore on the new server
scp /root/shop.sql root@NEW_IP:/root/
ssh root@NEW_IP 'mysql shop < /root/shop.sql'
# PostgreSQL: dump and parallel restore
pg_dump -Fc -U postgres shop > /root/shop.dump
pg_restore -U postgres -d shop -j 4 /root/shop.dump
# package list from the old machine to reproduce the environment
dpkg --get-selections | grep -v deinstall > pkgs.txt
Dump flags and restoring individual tables are covered in mysqldump: backup and restore.
Step 2. Verify before switching DNS
Do not switch the domain "just to see how it turned out". The new server is tested by address, and only then do you touch the zone:
# request the new server with the right host name and SNI
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' \
--resolve example.com:443:NEW_IP https://example.com/
# compare the responses of the old and new nodes
diff <(curl -s --resolve example.com:443:OLD_IP https://example.com/) \
<(curl -s --resolve example.com:443:NEW_IP https://example.com/)
# confirm services are up and listening on the right ports
systemctl is-active nginx php8.3-fpm mariadb
ss -lntp | grep -E ':80|:443|:3306'
Copying the database data directory on a running server with an ordinary copy command produces a corrupted database: some pages land in the copy before a write and some after, and InnoDB tables fail their checks. The symptom is delayed — the site opens fine, and a day later integrity errors appear on individual tables. Move the database with a dump, or stop the engine before copying files. Post-migration check: run a table check and compare row counts in 5–10 key tables against the old machine; the numbers must match exactly. Check mail separately: if the project sends its own messages, confirm the outgoing SMTP policy — on VDS, ports 25, 465 and 587 are closed by default and are opened on request for verified customers.
Step 3. The switch
- A day ahead, lower the TTL of the A and AAAA records to 300 seconds.
- Put the old server into read-only mode or open a short maintenance window.
- Run the final rsync and a fresh database dump — it takes minutes because the bulk is already moved.
- Point the A record at the new server, then watch propagation and the logs of both nodes.
- A day later restore the normal TTL and decommission the old VPS.
Step 4. What changes after the move
On a dedicated server the hypervisor neighbours disappear, and so does the floating disk performance. New duties appear: watch the RAID array and SMART, update microcode and the kernel, plan backups, because hypervisor snapshots are gone. Build the backup scheme immediately, following backing up a dedicated server.
Pick a configuration for the grown workload under dedicated servers: a typical move from VPS lands on Dedicated Start DE at $49 or on Pro DE with 32 GB ECC and NVMe at $99 per month.
Key takeaways
- The order is: inventory, environment mirror, data, verification by IP, DNS.
- Lower the TTL in advance, otherwise the switch drags on for a day.
- The database moves as a dump; copying the data directory of a live engine corrupts tables.
- Test the new node with curl and a resolve override before touching the zone.
- After the move, set up hardware monitoring and backups from scratch.