Server Migration Checklist:Moving to a New VPS or Dedicated Server

A server migration succeeds when nothing is forgotten and nothing is rushed. The process is: inventory everything the old server does, build and secure the new server, copy and sync data, test thoroughly, switch traffic with a short DNS TTL, and keep the old server available until you are sure. This checklist covers whole-server moves; for moving a single website, see how to move a website to a new host without downtime.

Phase 1: Inventory the old server

Write down everything. Servers accumulate responsibilities nobody remembers.

• Sites and applications, their domains and document roots
• Software versions: OS, web server, PHP and extensions, database, Redis, Node.js, etc.
• Databases and their sizes, users and privileges
• Cron jobs for every user (crontab -l per user, plus /etc/cron.*)
• Background services and queue workers (systemd units, supervisor)
• Email: mailboxes, forwarders, outgoing mail used by applications
• TLS certificates and how they renew
• Firewall rules and any IP allowlists at third parties (payment gateways, APIs, partners)
• DNS records that point to the server's IP
• Backups and monitoring configured on the old server
• Credentials and secrets in configuration files and environment variables

Check listening services with ss -tulpn and running services with systemctl list-units --type=service to find anything undocumented.

Phase 2: Prepare the new server

• Size it from monitoring data; see how to choose VPS specs
• Install the OS and harden it; see the Linux server hardening checklist
• Install matching or deliberately upgraded software versions
• Recreate users, permissions and directory structure
• Configure firewall, backups and monitoring before going live
• Lower DNS TTLs on affected records to around 300 seconds, at least one TTL period ahead

Phase 3: Copy and sync data

• Files: use rsync over SSH, which can be repeated to copy only changes:

rsync -aHAX --numeric-ids --info=progress2 /var/www/ newserver:/var/www/

• Databases: dump and import, or for large databases set up replication from old to new for a near-zero-downtime switch.
• Email: copy mailboxes with a sync tool appropriate to your mail server.

Do an initial full copy, then a final incremental sync during the cutover window.

Phase 4: Test before switching

• Point your own computer at the new server with a hosts-file entry
• Test every site: pages, logins, forms, uploads, payments in test mode
• Run cron jobs and workers manually and check their output
• Check outgoing email and PHP mail from applications
• Check logs for errors
• Confirm TLS certificates are valid on the new server

Phase 5: Cutover

1. Announce a maintenance window if writes must pause.
2. Put applications in maintenance mode or stop writes on the old server.
3. Run the final sync of files and databases.
4. Update DNS A records (and any other records) to the new IP.
5. Update IP allowlists at third parties.
6. Watch logs and monitoring on the new server.

Phase 6: After the cutover

• Keep the old server running, read-only, for several days
• Watch for traffic still arriving at the old IP (cached DNS, hard-coded IPs)
• Confirm backups run on the new server and test one restore
• Raise DNS TTLs back to normal
• Decommission the old server only when you are confident, after a final backup

Example cutover timeline

For a VPS hosting an online shop, with a planned switch on a Tuesday night:

When	Action
Friday	Lower DNS TTLs to 300 seconds; final review of the inventory
Saturday–Monday	New server built, hardened and tested; initial rsync and database copy
Tuesday 6 pm	Announce maintenance on the site and social media
Tuesday 11:00 pm	Put the shop in maintenance mode; stop cron jobs and queue workers on the old server
11:05 pm	Final rsync of uploads; final database dump and import (or stop replication)
11:20 pm	Smoke test on the new server through a hosts-file entry
11:30 pm	Switch DNS A records; update payment gateway and API allowlists
11:35 pm	Disable maintenance mode on the new server; start cron and workers
11:35 pm–1 am	Watch logs, orders, email and monitoring
Wednesday	Keep the old server stopped but intact; confirm backups run on the new server
Following week	Raise TTLs; decommission the old server after a final backup

The exact times depend on your data size and traffic, but writing the timeline down in advance prevents forgotten steps under pressure.

Rollback plan

Decide in advance what would make you roll back and how: usually pointing DNS back to the old server, which is still intact. Avoid writing important data to both servers at once, or you will have to reconcile it.

Frequently Asked Questions

How long does a server migration take?

Data copying depends on size and bandwidth; planning, testing and DNS changes take most of the time. Allow days for preparation and a defined window for the cutover itself.

Can I keep the same IP address?

Usually only if both servers are with the same provider and it supports moving IPs. Otherwise, plan the DNS change.

Should I upgrade software during the migration?

It is tempting but adds risk. If you do, test the upgraded stack thoroughly before cutover, or migrate first and upgrade later.

Related reading

For the fundamentals, see what is a VPS and VPS vs dedicated server. Moving to dedicated hardware? See ServerNeed managed dedicated servers.

Sources

• rsync manual page
• MariaDB documentation: Setting up replication