What should I inventory before migrating a server?
A migration inventory should describe the service and its dependencies, not just the server’s files. Missing scheduled jobs, credentials or external allowlists can cause failures after an otherwise successful transfer. Give each component a destination, owner and acceptance check.
Before you start
- Authorised access to the current service configuration and its application owners.
Instructions
1. Record the running service
List operating-system and application versions, databases, installed extensions, data locations and storage mounts. Include web virtual hosts, background workers, scheduled tasks and local mail delivery. Identify which files are generated, which are authoritative data and which are deployment artifacts that should be rebuilt.
2. Map connections and identities
Record incoming domains and ports, outgoing APIs, database endpoints, IP allowlists and private-network dependencies. Inventory service accounts, SSH trust, certificates and secret identifiers without copying secret values into the plan. Check whether licences or external integrations depend on the current IP address or hardware.
3. Assign migration and verification steps
For every dependency, specify whether it moves, remains in place or is replaced. Define data-consistency requirements, the final transfer sequence and how the owner will confirm success. Include monitoring, recovery access and the rollback boundary so the new server can be operated as well as launched.
Check the result
- Every critical component has an owner, destination and validation method.
- The migration sequence accounts for dependencies outside the server itself.
Troubleshooting
- The website works but overnight processing fails
- Check scheduled jobs, worker queues, file paths and service credentials that were not exercised by a browser test. Add these checks to the inventory and rehearsal.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.