Data Center Migration Planning: A Practical Guide

A data center migration plan answers five questions before anything is unplugged: what you have, what depends on what, where it is going, how it will move, and how you will undo the move if it goes wrong. Most failed migrations skipped one of those. This guide walks through each in the order you will need them, then covers what outside migration services should include and how to scope them.

TL;DR

• Start with a full inventory and dependency map. Plans built on an incomplete asset list fail at cutover, not on paper.
• Choose a migration approach per workload (rehost, replatform, swing, push/pull), not one approach for everything.
• Do not build the business case on savings alone. Federal consolidation lessons warn that this leads to unrealistic expectations.
• Write the rollback plan before the cutover plan, and keep the source environment reachable through the first validation window.
• If you bring in outside help, scope it by phase and deliverable: assessment, design, sourcing, logistics, cutover, handover.

Table of Contents

• What a data center migration is, and how it differs from a relocation
• Decide whether to migrate at all
• Step 1: Inventory everything before you plan anything
• Step 2: Map dependencies
• Step 3: Choose the target and the approach for each workload
• Step 4: Build the schedule, budget and governance
• Step 5: Plan for risk: downtime, security, data integrity, connectivity
• Step 6: Execute, test and hand over
• Data center migration checklist
• What data center migration services cover, and how to scope them
• Our perspective: where migrations really go wrong
• How Dormedia can help
• FAQ
• Sources

What a data center migration is, and how it differs from a relocation

A data center migration is the movement of an existing data center environment to another type of environment, such as the cloud or an off-premises facility. It covers physical, logical and operational components, not just servers. That last word matters: runbooks, monitoring, access rules and on-call duties all move too.

The definition is wide. One widely used checklist counts any movement of data center assets from one location to another, including a move to a new facility, a move within the same facility, a move to colocation, or migrating applications to the cloud.

In practice, "relocation" usually means the same equipment in a new room or building, while "migration" often implies a change in platform or environment. The two overlap, and many projects are both: some racks are moved, some workloads are rebuilt in a new place, and some are retired. Plan for the mix instead of arguing over the label.

Decide whether to migrate at all

Migration is disruptive and expensive. The reasons that justify it tend to fall into a few groups:

• Capacity. Power, cooling or floor space can no longer support planned growth. This is increasingly common with dense AI and HPC hardware, which draws far more power per rack than general enterprise servers.
• End of lease or facility life. The building, contract or hardware refresh cycle forces a decision.
• Consolidation. Several sites are merged into fewer.
• Platform change. Workloads move to cloud, colocation or a hybrid arrangement.
• Risk and resilience. The current site has a single point of failure you cannot fix in place.

Be careful with cost as the sole argument. A lesson from large federal consolidations was to avoid over-focusing on cost savings as the primary business case, because it often leads to unrealistic expectations and failure of the mission. Put capacity, risk, performance and time to deploy next to cost, and write down which one wins when they conflict.

The same GAO report points to defining clear success measures and holding detailed, routine meetings with all business stakeholders to keep expectations realistic throughout the move. Write the success measures first: acceptable downtime per application, target cost per month after the move, performance thresholds, and a completion date with a named owner.

Step 1: Inventory everything before you plan anything

The inventory is the foundation. Federal guidance on migration and consolidation lists what to capture: data centers, physical and virtual systems, operating systems, software versions, applications, owners, usage cycles, resource requirements, dependencies, networks and common services. It also tells planners to assess physical security, building capacity, and cooling and heating requirements.

A useful inventory goes past a hardware list. For each workload, record:

1. The business owner and a technical contact who can approve downtime.
2. The hardware or virtual host, firmware and OS versions, and support status.
3. Usage cycles: month-end close, seasonal peaks, batch windows, training runs that cannot be interrupted.
4. Resource needs: CPU, GPU, memory, storage, network throughput, and power draw.
5. Compliance and data residency constraints.
6. The last time anyone confirmed the system is still needed.

That last item pays for itself. Every server you retire before the move is a server you do not pay to ship, rack, cable and test.

Step 2: Map dependencies

Inventory tells you what exists. Dependency mapping tells you what must move together. Look at application-to-application calls, shared databases, authentication and directory services, DNS, licensing servers, storage replication, and network paths with latency requirements.

Group systems into move waves based on those dependencies. A tightly coupled set of systems moves in the same window. A standalone tool can go early as a rehearsal. Leave the most entangled systems for later waves, after the team has practiced the process on easier ones.

For GPU clusters and HPC environments, add the interconnect and storage fabric to the map. A cluster whose nodes are split across two sites for even a weekend can behave very differently from the same cluster in one room, so treat the cluster as a single move unit unless you have tested otherwise.

Step 3: Choose the target and the approach for each workload

The target can be a new owned facility, colocation space, a cloud platform, or a combination. Decide using the requirements you wrote in the success measures, not preference.

For approach, the cloud industry's "7 Rs" are a handy vocabulary: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. Not every workload deserves the same one. AWS notes that refactoring is the most complex strategy and is not recommended for large migrations; it suggests rehosting, relocating or replatforming first, then modernizing after the move. That ordering is sound beyond cloud: change the location or the platform, stabilize, and only then redesign.

For physical moves, federal migration guidance separates two patterns:

Swing migration needs spare capacity somewhere to host workloads during the move, which is a cost to budget. Push/pull needs new hardware at the destination, which is a procurement and lead-time issue. For GPU-heavy infrastructure, lead times for servers and components can set the whole schedule, so start sourcing as soon as the design is stable.

Step 4: Build the schedule, budget and governance

Work backward from the hardest constraint: a lease end date, a hardware delivery date, or a business blackout period such as fiscal year-end. Then fill in:

• Waves. Which dependency groups move in which window, and what is rehearsed first.
• Long-lead items. Servers, GPUs, network gear, racks, power distribution, cabling, and any customs or tariff handling for cross-border shipments.
• Facility readiness. Power, cooling, floor loading, network handoffs and carrier circuits at the destination, confirmed in writing before equipment ships.
• Dual-running costs. You will pay for two environments for some period. Estimate it explicitly.
• Contingency. A schedule with no slack is a schedule that will slip at the worst moment.
• Governance. A single accountable project owner, a change approval path, and a routine meeting cadence with stakeholders.

MITRE's work on cloud migration planning notes that without a standardized planning framework, organizations often replicate inefficiencies, leading to increased risk and duplication of effort. A written, repeatable plan template for every wave is the practical remedy.

Step 5: Plan for risk: downtime, security, data integrity, connectivity

Treat each of these as a line in the plan with an owner, not as general concerns.

Downtime. Agree a maximum outage per application with its business owner. If the plan cannot meet it, change the approach (for example, replicate data ahead of time and cut over in a short window) instead of hoping.

Security. Decide how data is protected in transit, who has physical access during the move, how decommissioned drives are sanitized, and how firewall rules and identity configuration are reproduced at the destination. Moves are when emergency exceptions get made and then forgotten, so log every one.

Data integrity. Verify backups before touching production, and prove they restore. Use checksums or application-level reconciliation after transfer.

Connectivity. Circuits often have the longest lead times and the least flexibility. Order early, plan IP addressing and DNS changes, and test paths between old and new sites before the first wave.

Rollback. Write it first. Cloud migration guidance states that rollback plans must be maintained and validated throughout the migration, and that the source environment should stay accessible during the initial post-cutover validation window. In practice, that means you do not decommission, wipe or resell source hardware until the validation window has closed and the owner has signed off.

Step 6: Execute, test and hand over

A cutover runbook should be specific enough that someone who was not in the planning meetings could run it: ordered steps, named owners, expected durations, checkpoints with go/no-go criteria, and the exact trigger for rollback.

After cutover, the same guidance lists regression testing, verification, and handoff of operational monitoring to the operations team as post-migration activities. Treat handover as a deliverable. The operations team should receive updated diagrams, asset records, monitoring configuration, runbooks and escalation paths, and should confirm they can operate the environment before the project closes.

Data center migration checklist

What data center migration services cover, and how to scope them

Outside help ranges from a single specialist to full project delivery. Most engagements break into the same parts, and you can buy any subset:

• Assessment and discovery: inventory, dependency mapping, capacity and facility review.
• Strategy and design: target environment, approach per workload, architecture, and business case.
• Sourcing: servers, GPUs, components and network gear for the destination.
• Logistics: packing, freight, customs, tariffs and tax treatment on cross-border moves, delivery to the site.
• Deployment and cutover: racking, cabling, configuration, migration waves, testing.
• Project management: schedule, risk log, stakeholder communication.
• Handover and support: documentation, training and ongoing operations support.

To scope it well, decide which of those your team can do itself. Most internal teams know their applications better than any outsider; they are often thinner on procurement, international logistics and parallel project management. Ask any provider for:

1. A deliverable list per phase, not just hours.
2. A named person accountable for the schedule.
3. How they handle rollback and who decides on it.
4. How they source hardware and what they do when lead times slip.
5. What is included after cutover, and for how long.
6. References for projects similar in size and type to yours, such as GPU clusters or multi-country moves.

Be wary of a plan that starts with a destination and a price before anyone has seen your inventory.

Our perspective: where migrations really go wrong

We have worked in this industry since 2011 and in HPC and AI infrastructure since 2017. The pattern we see most often is not a technical failure. It is a sequencing failure: hardware ordered before the design is settled, a facility that is not ready when equipment lands, or a cross-border shipment held up because tax and tariff treatment was left until the last week.

That is why we think of migration planning as one project across sourcing, logistics and deployment, not three. The server configuration you choose affects power and cooling at the destination. The destination date affects freight and customs timing. Rollback depends on how long you keep the old equipment, which depends on the schedule. Pulling those threads together early is cheaper than untangling them during cutover.

Our second view is that AI and HPC workloads deserve their own treatment. They are dense, they are sensitive to network and storage layout, and the hardware is often scarce. Plan the move of a GPU cluster as a unit, test it as a unit, and do not let it become the last item on a general-purpose migration plan.

— Dormedia

How Dormedia can help

If you are planning a move of HPC or AI infrastructure, we can support the parts that tend to stall projects: design, sourcing, global logistics, tax and tariff handling, project management and ongoing support. We work with a network of vendors and logistics specialists, and we scope each engagement around your environment.

Tell us what you are moving, where it is going and when it needs to be live, and we will tell you which phases are worth outsourcing. Start at Dormedia.

FAQ

How long does data center migration planning take?

It depends on the size of the environment and the quality of your existing records. A small, well-documented environment can be planned in weeks, while a large multi-site estate with poor documentation can take months, mostly because of inventory and dependency discovery. Long-lead items such as circuits and hardware often decide the real schedule, so start them early.

What is the biggest risk in a data center migration?

Missing dependencies is the most common cause of surprises: a system nobody listed turns out to be needed by a critical application. A verified inventory, dependency mapping and rehearsal waves reduce that risk. A tested rollback plan limits the damage when something still slips through.

Should we migrate to the cloud or move to a new data center?

That depends on workload behavior, cost profile, compliance and performance needs, and the answer is often a mix. Evaluate each workload against the approaches above rather than choosing a destination for everything. Steady, GPU-heavy workloads and bursty, variable ones frequently belong in different places.

What should we ask data center migration services before hiring?

Ask for deliverables per phase, a named schedule owner, the rollback approach, how hardware is sourced, and what support continues after cutover. Ask for references from projects like yours. If a provider quotes before seeing your inventory, treat the quote as a placeholder.

When can we decommission the old environment?

Only after the post-cutover validation window closes and the application owners have signed off. Keep the source environment accessible until then so rollback remains possible, and then follow your data sanitization and asset disposal procedures.

Sources

• Data Center Migration (SUSE)
• Data Center Migration Checklist (Sunbird)
• GAO-11-565, Data Center Consolidation
• DCOI Guide for Data Center Migration, Consolidation, and Closure
• About the migration strategies (AWS Prescriptive Guidance)
• Execute your migration from AWS to Azure (Microsoft Learn)
• Planning & Management Methods for Migration to a Cloud Environment (MITRE)

Made with BabyLoveGrowth for content creation