The safest migration builds the new server beside the old one, tests it without changing public traffic, and schedules a short final synchronization. Do not destroy the old server until the rollback window has passed.
1. Inventory the old server
Record the operating-system version, application runtime, listening ports, scheduled jobs, systemd services, databases, DNS records, and any paths that contain uploaded or generated data.
Useful starting commands:
cat /etc/os-release
sudo ss -tulpn
systemctl list-unit-files --state=enabled
sudo crontab -l
df -h
Export secrets from their existing secret store. Do not paste them into a ticket, chat, shell history, or migration notes.
2. Lower DNS TTL before the move
At your DNS provider, lower the relevant record's TTL before the migration. Do this far enough ahead for the previous TTL to expire. A shorter TTL reduces how long clients may continue reaching the old address after the switch.
3. Deploy and secure the LayerOne server
Choose enough disk for the current data plus growth, then complete Your first hour on a new server. Install the same major application and database versions where possible. Changing platforms and upgrading every component during the same maintenance window makes rollback harder.
4. Copy files while the old service remains live
Run an initial rsync from the new server:
sudo rsync -aHAX --numeric-ids --info=progress2 root@OLD.SERVER.IP:/var/www/ /var/www/
Repeat this for application data that can be copied safely. Exclude caches, temporary files, sockets, and active database data directories.
5. Move databases with a logical dump
Do not copy a live database's storage directory. For PostgreSQL:
# On the old server
sudo -u postgres pg_dump -Fc appdb > /tmp/appdb.dump
scp /tmp/appdb.dump root@NEW.SERVER.IP:/tmp/
# On the new server
sudo -u postgres createdb appdb
sudo -u postgres pg_restore --clean --if-exists -d appdb /tmp/appdb.dump
Use mysqldump --single-transaction for MySQL or MariaDB. For a busy database,
plan a maintenance window or database-native replication instead of assuming a
single early dump contains the final writes.
6. Test without changing DNS
Start the application on the new server and test its public hostname against the new address from your own machine:
curl --resolve example.com:443:NEW.SERVER.IP https://example.com/
Check login, writes, uploads, background jobs, outbound email, TLS, and any third-party callbacks. Confirm the cloud and host firewalls expose only the ports you need.
7. Freeze writes and run the final sync
At the start of the maintenance window:
- Put the old application into maintenance or read-only mode.
- Run
rsyncagain so only changed files move. - Take and restore a final database dump, or complete the planned replication cutover.
- Start workers and scheduled jobs on the new server.
- Stop those workers on the old server so jobs cannot run twice.
8. Move traffic and watch it
Update the DNS A record to the new address. Monitor both servers' access and
error logs while caches expire. Keep the old server intact and ready to receive
traffic again until the new one has completed a representative workload and at
least one backup.
A floating IP can avoid a DNS change when the move is between compatible LayerOne servers in the same location. It cannot float to or from another provider.
9. Finish deliberately
- Restore the normal DNS TTL.
- Confirm backups and monitoring from outside the new server.
- Remove old API credentials and firewall allowances.
- Destroy the old server only after the rollback period ends.