Pre-Move Inventory: Auditing Your Systems Before a Data Center Migration
Most migration problems do not start on moving day. They start weeks earlier, when nobody has written down what is actually running in the server room, which applications depend on which machines, or who holds the passwords for the vendor accounts. A small business that wants to relocate or consolidate its systems can avoid much of that trouble by treating the first phase as an inventory exercise rather than a logistics exercise. This article walks through how to build that inventory, what questions to ask along the way, and how to judge whether a prospective partner is asking the right things too.
Start with a complete list of hardware and virtual machines
Begin by listing every physical device that draws power in your server room or closet: servers, network switches, firewalls, storage shelves, uninterruptible power supplies, and any small appliance that someone plugged in years ago and forgot about. Record the make, model, serial number, rack location, and approximate age for each item. If a label has faded or was never applied, note that too, because unlabeled equipment is one of the most common sources of surprise during a move.
Next, list the virtual machines and the hosts that run them. For each virtual machine, record the operating system, allocated CPU and memory, storage volumes, and the single most important role it performs. A file server, a print server, a line-of-business database, and a domain controller each need different handling, and grouping them together early makes sequencing easier later. Include machines that appear idle, since a server that looks unused may still be a scheduled job runner or an email relay.
Map dependencies between systems and people
An inventory of boxes is not enough. Migration risk lives in the connections between them. For each system, write down what it depends on (authentication, DNS, a database, a license server, an internet connection with a fixed address) and what depends on it. A point-of-sale terminal might depend on a local database, which depends on a backup job, which depends on a network share. Drawing this as a simple diagram or a numbered list is often enough to reveal the chain.
Also document the people involved. Who approves changes? Who knows the application's quirks? Who has administrator credentials, and are those credentials stored somewhere the business controls? Who should be contacted if something fails at two in the afternoon on a Friday? If the answer to any of these lives in one person's head, record it now and confirm that the information is accessible to more than one person.
Verify ownership of licenses, domains, and vendor accounts
Many migrations stall because a license key is tied to hardware that is changing, a software subscription is registered to a former employee's email address, or a domain name is held under an account nobody can log into. Create a register of every external account your systems rely on: domain registrars, DNS providers, software licenses, cloud accounts, certificate authorities, and support contracts. For each one, record the account holder, the login location, the renewal date, and whether the business has administrative access.
This step is administrative rather than technical, but it is often the one that determines whether a cutover can proceed on schedule. Treat it as a gating item in your plan.
Questions to ask any migration partner
Whether you hire internal staff or an outside firm, certain questions separate a careful plan from an optimistic one. Ask how the partner will receive and verify your inventory before any physical work begins. Ask who will own the cutover schedule and how changes to that schedule will be communicated. Ask what the partner expects you to provide, including access windows, credentials, and staff availability during the move. Ask how they plan to confirm that each system works at the new location before the old one is decommissioned.
Be direct about scope. Ask whether the engagement includes cabling, rack layout, power planning, and labeling, or whether those items are the business's responsibility. Ask what documentation you will receive at the end. A good answer is specific and written down; a vague answer is a reason to slow down and clarify before signing anything.
A short checklist before you schedule the move
Before you pick a moving date, confirm that you have a dated hardware and virtual machine list, a dependency map, a register of external accounts with verified access, a named decision-maker, and a written answer from your partner to each of the questions above. Confirm that a current backup exists and that someone has tested a restore of at least one critical system, rather than assuming the backup is usable. Make sure the people who will be on site know the access procedures and that the inventory is stored somewhere everyone authorized can reach it.
When each of these items is in place, the migration becomes a sequence of known steps instead of a series of discoveries. The inventory phase is unglamorous, but it is the part of the project that most reliably prevents the problems businesses fear most. Take the time to do it properly, and the later stages will be far more predictable.