A data center migration plan is the roadmap IT teams follow to move servers, storage, network equipment and applications to a new home without breaking the services that run on them. Infrastructure and operations teams look for one when a lease ends, two sites are consolidated or workloads head to the cloud, and they need a sequence they can trust from the first inventory to the last retired server.
This guide lays out a data center migration in 10 steps, starting with an asset-by-asset inventory of what you own, what it's used for and what depends on it. It closes with a checklist you can copy for before, during and after the move, the challenges the plan prevents, and how InvGate Asset Management supports each stage.
What is a data center migration?
A data center migration is the process of moving an organization's IT infrastructure, including servers, storage, network equipment, applications and data, from one hosting environment to another. The destination can be another data center the organization runs, a colocation facility where it rents space, or a public cloud provider.
Most migrations start with a date someone else set. A lease or colocation contract ends, two sites get consolidated into one, hardware approaches End of Life, or the organization decides to run as much as possible in the cloud. Whatever the trigger, the work follows the same order: know what you have, decide what moves, and move it without interrupting the services people use.
Why the first step is an inventory of every asset
Ian Beirnes, Vice President of Infrastructure and Operations at Texans Credit Union, and his team are not renewing the lease on the data center space that hosts the credit union's secondary site, as part of a strategy to be cloud enabled to the greatest extent possible. Asked during InvGate's Industry Forum on financial services IT how to run a move like that with confidence, he started with the inventory:
“It starts with knowing what you have. That's really the fundamental baseline that you have to have. You have to be able to understand every asset that you own, what it's used for, is it still needed, what are the dependencies for it, can it be modernized, and really rationalize all of that before you make any cloud decisions. Nobody wants to pay for things that they don't need. So that whole process has to happen before you make hosting decisions. And you can't really answer those questions unless you have full visibility into all the assets in your environment.”
Ian Beirnes, Vice Presidente of Infrastructure and Operations at Texas Credit Union
Those questions give the plan its order. Each one feeds a later step, so answering them first keeps the rest of the plan from resting on guesses:
- What do you have? It builds the inventory itself (step 1).
- What depends on it? It drives the dependency map (step 2) and the risk assessment (step 6).
- What is it used for, and is it still needed? It sets the scope (step 3), where every asset gets a decision.
- Can it be modernized? It shapes the target environment (step 5) and the migration strategy (step 7).
How to plan a data center migration in 10 steps
The 10 steps below follow the order those questions set. Steps 1 to 3 decide what moves, steps 4 to 7 plan how it moves, and steps 8 to 10 move it, check it and close the old site.
1. Inventory every asset before you plan
The inventory is the baseline every later decision reads from, so it has to cover the whole environment: physical servers, storage, network equipment, virtualization hosts and the virtual machines they run, the software and databases installed on each server, and the cloud services already in use. For each asset, record who owns it, what it's used for, its warranty and support contracts, its End-of-Life date and how much it's actually used, on top of the rack, power and network details a data center inventory already tracks.
Built by hand, this inventory is outdated before the plan is approved, so most teams combine the four sources of an IT asset inventory. An agent installed on each server reports its hardware, software and usage, and a network scan finds the devices that can't run one, such as switches, routers, firewalls and storage arrays. Integrations pull virtualization hosts and cloud resources from the platforms that manage them, and manual or spreadsheet imports cover equipment without a network address.
2. Map dependencies between assets and services
Servers rarely move alone. A database runs on one server, an application on another reads from it, and both depend on storage, network segments and authentication services that may live somewhere else, so moving any one of them in isolation can take down the service they support together. Application dependency mapping tells you which assets have to move in the same window and in what order.
Start from what the servers themselves report: the services they host, the services they consume and the other machines they talk to regularly. Then confirm the picture with the owner of each application, group the assets that must travel together into move groups, and record how critical each dependency is, because that criticality drives the risk assessment in step 6.
3. Define the scope and goals
The goal usually exists before the plan does, whether it's a lease end date, a consolidation target or a cloud strategy, and it sets the deadline. Defining the scope turns that goal into a decision for every asset in the inventory, and Amazon Web Services (AWS) groups the possible decisions into seven migration strategies: retire, retain, rehost (lift and shift), relocate, repurchase, replatform and refactor.
Usage data is how you find what to retire, and AWS suggests using the utilization data from your discovery tool to spot applications that sit idle before deciding where they go. Rationalizing what you own before the move, the same exercise behind application rationalization, keeps you from paying to host what nobody needs. Close the step with success criteria everyone signs off on, such as the services that must keep running and the downtime each one can tolerate.
4. Develop a project plan
A data center migration project plan turns the scope into a schedule: the move groups in sequence, the timeline for each, the budget, the people and partners involved, and a contingency for every window. Assign an owner to each move group and build a Responsible, Accountable, Consulted and Informed (RACI) matrix so every decision has a name next to it, following the same phases of Project Management the rest of IT already uses.
The communication plan belongs inside the project plan. Tell users and stakeholders what changes, when each maintenance window happens and who to contact if something fails, and train the teams that will operate the new environment before the first move group goes live.
5. Plan the target environment
Base the destination's capacity planning on the inventory and its usage data: compute, storage and network, plus rack space, power and cooling when the destination is another data center or a colocation facility. Sizing from measured usage avoids carrying over capacity nobody uses, and the destination has to meet the same security and compliance requirements as the current site.
When the destination is the cloud, the decisions from step 3 shape the design, and a cloud migration strategy defines which services each rehosted or replatformed workload lands on. Check licensing as well, because some software licensed for on-premises servers comes with different terms in the cloud.
6. Conduct a risk assessment
Measure risk on the dependency map. Group systems into criticality tiers, define the downtime each tier can tolerate, and estimate what an outage would cost the business, since the cost of downtime is what justifies extra effort on the critical tiers.
Then list what could go wrong in transit and how you would recover: aging equipment that might not survive the move, missing backups, untested restores and contract penalties for leaving a site early. Every risk needs a mitigation and a rollback, and the move is a good moment to review how high availability and disaster recovery will work in the new environment.
7. Develop a migration strategy and testing plan
The data center migration strategy defines how each move group travels: all at once or in waves, rehosted as it is or replatformed onto new services. Applications need their own sequence of tests and cutovers, which an application migration plan sets out step by step.
The testing plan proves the strategy before the real move. Run a pilot with a non-critical move group, measure performance against a baseline taken before the migration, check data integrity, and document the rollback procedure for every window.
8. Execute the migration
Move by waves, following the move groups and their dependencies, and open a change request for each window so approvals, freezes and rollbacks follow your Change Management process. Keep a team monitoring each wave and apply the contingency plans from step 6 when something unexpected happens.
For physical moves, record serial numbers, configurations and cabling before disconnecting anything, and update each asset's location and status as it leaves the old site and arrives at the new one. That record is what step 9 checks against.
9. Verify and validate
Once each wave lands, confirm that data arrived intact, applications work, performance matches the baseline and users can reach what they need. Fix issues while the wave is still fresh, before the next one starts.
Then compare the inventory after the move with the one you built in step 1. Every asset in scope should appear in its new location or be replaced by its cloud counterpart, nothing should be missing, and the dependency map should show where each service runs now.
10. Decommission the old environment
Retire the old site only after the new environment is stable. Sanitize every drive before equipment is resold, recycled or destroyed, following the guidelines the National Institute of Standards and Technology (NIST) publishes in Special Publication 800-88 Rev. 2, and cancel the maintenance contracts, support agreements and facility lease that no longer apply.
Then retire each asset in the inventory with its status and the date it left, so finance and audit can see exactly what was removed and when. Check whether anything still depends on the retired equipment before you close the project, because a connection that still points to a decommissioned server is a service that didn't move.
Data center migration checklist: before, during and after the move
Use this data center migration checklist to track the plan from the first inventory to the last retired server. Each item maps to one of the 10 steps above, so you can copy it into your project tool and assign owners.
Before the move
Most of the work happens before anything is unplugged. These items cover steps 1 to 7:
- Inventory every physical server, storage array, network device, virtualization host and virtual machine.
- Record the software, databases and cloud services tied to each server.
- Assign an owner and a purpose to every asset.
- Capture usage, warranty, support contracts and End-of-Life dates.
- Map the services each server hosts and consumes, and the machines it talks to.
- Group dependent assets into move groups and rate the criticality of each dependency.
- Decide what happens to each asset: retire, retain, rehost, relocate, repurchase, replatform or refactor.
- Agree on success criteria and the downtime each service can tolerate.
- Build the project plan with a timeline, budget, owners and a RACI matrix for each move group.
- Publish the communication plan and schedule the maintenance windows.
- Size the target environment from measured usage.
- Confirm security, compliance and licensing terms at the destination.
- Rank systems into criticality tiers and estimate the cost of downtime for each.
- Verify backups, test restores and write a rollback plan for every window.
- Check equipment condition and the exit terms of every contract.
- Choose the migration approach for each move group.
- Run a pilot with a non-critical move group and record a performance baseline.
During the move
Execution is where the plan meets the clock. These items cover step 8:
- Open a change request for each wave.
- Record serial numbers, configurations and cabling before disconnecting equipment.
- Update each asset's location and status as it moves.
- Monitor every wave and follow the contingency plan when something fails.
After the move
The project ends when the old site is closed and the inventory reflects the new one. These items cover steps 9 and 10:
- Validate data integrity, application behavior, performance and user access.
- Compare the inventory after the move with the baseline from step 1.
- Update the dependency map to show where each service runs now.
- Sanitize drives before reuse, resale, recycling or destruction.
- Cancel the maintenance contracts, support agreements and facility lease that no longer apply.
- Retire each asset in the inventory with its status and date.
- Confirm nothing still depends on decommissioned equipment.
Data center migration challenges and how to prevent them
Most migration problems trace back to a step that was skipped or rushed. The table pairs the most common challenges with the part of the plan that prevents them.
| Challange | What prevents it | Step |
| Assets and dependencies nobody documented | A complete inventory and a dependency map built from what the servers report | 1 and 2 |
| Data loss or corruption | Verified backups, tested restores and integrity checks after each wave | 6 and 9 |
| Applications that fail in the new environment | Compatibility testing and a pilot move group | 7 |
| Broken network connectivity | A network design for the target environment and connectivity tests before cutover | 5 and 7 |
| Too much or too little capacity | Sizing from measured usage | 5 |
| Security and compliance gaps | Requirements checked at the destination and controls validated after the move | 5 and 9 |
| Coordination failures across teams | An owner per move group, a RACI matrix and a communication plan | 4 |
How InvGate Asset Management supports a data center migration
InvGate Asset Management is IT Asset Management software that offers an enterprise experience without the complexity or the price of one, with an intuitive interface, a no-code approach and fast deployment. In a data center migration, it gives you the asset-by-asset baseline from step 1 and keeps it current while assets move, retire or reappear in the cloud.
Each capability below maps to a step of the plan. Together they answer the questions the plan starts with: what you have, what it's used for, what depends on it and what can go.
- An inventory from four sources. The Agent reports hardware, software and usage from each server and classifies machines running a server operating system as servers automatically. InvGate Discovery scans the network for devices that can't run an agent, integrations bring in VMware and Hyper-V hosts plus AWS and Azure resources, and manual or CSV imports cover the rest.
-
Usage and lifecycle data for every decision. Processor and memory usage show which servers sit idle, and, in the cloud version, the Atlas AI Agent adds End-of-Support dates for Dell, Lenovo and Apple servers and for switches, routers and firewalls, plus End-of-Life and End-of-Support dates for databases, next to the warranty and contract data each asset already carries.
- Connections that document what depends on what. Connections link any two Configuration Items (CIs), such as a database and the server it runs on, with a criticality level and a description, and they show up on both profiles and in InvGate Service Management. You can filter the inventory by connection to list everything that depends on a server before you move it.
- Dependency maps built from suggestions. Business Application diagrams in the Configuration Management Database (CMDB) suggest related CIs through CMDB auto-mapping, drawing on what the Agent sees on each server (the services it hosts and consumes and the computers it talks to), on network discovery and on the VMware integration (the virtual machines on each host). You review and accept each suggestion, and you can start a diagram from any asset.
- Lists to group and verify each wave. Paste a list of hostnames or serial numbers into the Asset Explorer to find those assets at once, use the same list in a Smart Tag to label each move group, and spot any identifier with no matching asset after the move. For physical relocations, physical audits let you scan QR codes or radio-frequency identification (RFID) tags at the new site and reconcile what arrived against the inventory.
- A clean record of what left. Statuses take retired assets out of the active inventory and keep the change in each asset's history. Connections to a retired CI can stay in place with a warning, so anything that still depended on it remains visible.
A migration plan is only as good as the inventory it starts from. Start a 30-day free trial to build yours, or talk to Sales to review your environment with our team.
Frequently Asked Questions
These are the questions IT teams ask most often while planning a data center migration. The short answers below draw on the 10 steps and the checklist above.
How long does a data center migration take?
It depends on the number of assets, how tangled their dependencies are, the downtime each service can tolerate and whether you move all at once or in waves. A small environment can move in a few weeks while a large one often takes several months, and much of that time goes into the inventory, the dependency map and testing before anything moves.
What is the difference between a data center migration and a cloud migration?
A cloud migration is one kind of data center migration, where the destination is a public cloud provider. A data center migration can also move workloads to another data center or to a colocation facility, and many organizations combine destinations, moving some systems to the cloud and relocating others.
What are the most important data center migration best practices?
Start with a complete inventory, map dependencies before you decide what moves, and retire what nobody uses so you don't pay to host it. Then test with a pilot, keep a rollback plan for every window, communicate each change in advance, and compare the inventory before and after the move.
What happens to old hardware after a data center migration?
Equipment with useful life left can be redeployed or resold, and the rest goes to recycling or destruction. In every case, drives need to be sanitized first, and each asset should be retired in the inventory with its status and date so finance and audit can trace what left.
