Server Migration Checklist
A server migration checklist and plan template: inventory, rehearsal, data sync, cutover and decommission steps for moving a server or app to new hosting.
- Typical schedule per migration
- The checklist 5 sections, 25 items
- Variables
{{server}}{{target}}
Use this checklist when you move a running server or application to new hardware, a new data centre or a cloud provider. It fits a single server or a small group of servers moved in one cutover, which is the typical case for small teams and agencies. For a multi-month programme, use one run per server or per wave, so each cutover has its own record.
Who owns it
One engineer owns the migration from inventory to decommission. They schedule the cutover, decide on go or no-go and keep the rollback option open until the old server is switched off. The application owner signs off that the service works on the new host.
Common pitfalls
- The forgotten dependency. Cron jobs, hard-coded IP addresses, firewall allow-lists at partners, SMTP relays and licence keys bound to a MAC address. Look at real network connections and the crontab, not only the documentation.
- DNS TTLs lowered too late. A TTL only takes effect after the previous TTL expires. Lower it at least one full old-TTL period before cutover.
- No rehearsal. A test migration shows how long the data sync really takes and which steps break. Without it, the cutover window is a guess.
- Deleting the old server too early. Keep it stopped but intact for an agreed period, in case a missing file or job turns up later.
Runbook keeps the run open across the weeks between preparation and decommission, so the final steps are not forgotten.
The checklist: Migrate {{server}} to {{target}}
Inventory
-
Services, ports and processes on
{{server}}listedUse the running system (e.g. ss -tlnp, systemctl list-units, Task Manager) as the source, not old notes.
-
Scheduled jobs listed: cron, systemd timers, Task Scheduler
-
Inbound and outbound dependencies listed: databases, APIs, SMTP, file shares, partner allow-lists
-
Data volumes, sizes and change rate recorded
-
Certificates, licence keys and secrets on the server identified
Prepare {{target}}
-
Target sized for CPU, memory, disk and network based on current usage
-
OS, runtime and package versions match or upgrades are tested
-
Firewall rules, security groups and access for the team set up on
{{target}} -
Monitoring, logging and backups configured on
{{target}}before cutover -
Rehearsal migration done and the data sync duration measured
-
DNS TTLs for affected records lowered well ahead of cutover
Cutover
-
Cutover window, rollback deadline and go/no-go owner agreed and announced
-
Fresh backup of
{{server}}taken and verified -
Writes stopped on
{{server}}: maintenance mode, services stopped or read-only -
Final data sync completed and checksums or row counts compared
-
DNS records, load balancer targets or IP addresses switched to
{{target}} -
Partner allow-lists and outbound IP changes confirmed optional
Verify
-
Smoke test of the main user flows passes on
{{target}} -
Scheduled jobs ran successfully at least once on
{{target}} -
Logs on
{{server}}show no remaining traffic after DNS propagation -
Application owner signed off
Decommission
-
{{server}}stopped but kept intact for the agreed retention period -
DNS TTLs restored to normal values
-
Final backup of
{{server}}archived, then the server and its disks deleted -
Inventory, documentation and monitoring updated to remove
{{server}}
Checklist as Markdown
Frequently asked questions
What should a server migration plan include?
A useful plan covers an inventory of services and dependencies, target sizing, a rehearsal, a cutover window with a rollback deadline, verification steps and decommissioning. The rollback deadline is the most often skipped part. Decide in advance at what time you switch back if things are not working.
How do I migrate a server with minimal downtime?
Sync data in advance and keep it in sync, so the final sync during the cutover is small. Lower DNS TTLs early and switch traffic with a load balancer where possible. The downtime then shrinks to the final sync and the switch itself.
Is a cloud migration different from a server migration?
The mechanics of a lift-and-shift move are the same: inventory, sync, cutover and verify. Cloud moves add work on networking, identity and cost controls, and often mean changing managed services such as databases. Treat each of these as its own section or its own run.
Updated