Data Center Migration Plan: 30-Week Roadmap, Runbook and Example

10 min read · 2026-10-25

A data center migration plan is the schedule, inventory and set of runbooks that move your servers, applications, storage and network from one facility to another (a new data center, a colocation site or a cloud platform) without unplanned downtime or lost data. It covers what moves, in what order, how each move is done, who approves it and how you roll back if a cutover fails.

The roadmap below covers 30 weeks in six phases, from inventory to decommissioning, each with steps and a milestone you can check. After it you will find how to choose a migration approach per application, how to build move groups, a filled-in example for a mid-sized insurer leaving a leased facility, who owns what, a cutover runbook outline, risks with owners and fallbacks, and how to report progress to the CIO and the business. Treat the durations as a starting point and size them to your own estate.

The roadmap at a glance

Goal: By week 30, every in-scope application runs in the target environment and passes business sign-off, the old facility is empty and its hardware is decommissioned with data destruction records. Duration: 30 weeks

1. Mobilize and inventory (Weeks 1-5)

   Know exactly what you have, who owns it and what the hard deadlines are.

   • Confirm the sponsor, the program manager and the exit date driven by the lease, contract or hardware end of life.
   • Build one inventory of servers, virtual machines, storage, network devices, databases and applications from your CMDB, discovery tools and hypervisor exports.
   • Name a business owner and a technical owner for every application.
   • Record each application's criticality, recovery time and recovery point objectives, and any compliance limits on where data can live.

   Milestone: An inventory validated by application owners, with every server linked to an application and an owner, and nothing marked unknown.

2. Dependencies and move groups (Weeks 4-9)

   Find what talks to what, then group systems that must move together.

   • Map dependencies with network flow data and discovery tools, then confirm them in interviews with each technical owner.
   • Pick a migration approach for every application: retire, rehost, replatform, replace or keep in place.
   • Group tightly linked systems into move groups, such as an application, its database and its file shares.
   • Arrange move groups into waves, with low-risk groups first and critical systems once the process is proven.
   • Agree change freeze dates and blackout windows with the business, such as month-end close.

   Milestone: A wave plan with every move group, its approach, its dates and its owners, approved by the change advisory board.

3. Target design and build (Weeks 8-14)

   Get the landing zone ready and tested before anything moves.

   • Design the target network, IP addressing, DNS, firewall rules, identity and backup for the new environment.
   • Set up connectivity between the old and new sites with enough bandwidth for replication.
   • Build and test monitoring, backup and security tooling in the target.
   • Choose and test the migration method: replication tools, backup and restore, or a physical move of hardware.

   Milestone: Target environment signed off by infrastructure, security and network leads after a test restore and a test failover.

4. Pilot wave (Weeks 15-17)

   Prove the process on low-risk systems and fix the runbook.

   • Pick two or three low-criticality move groups, such as internal tools or a test environment.
   • Write the cutover runbook with timed steps, owners, checks and a rollback point.
   • Run a dress rehearsal, then the live cutover with business testers on call.
   • Hold a lessons-learned session and update the runbook template.

   Milestone: Pilot move groups running in the target, tested by their owners, with no rollback needed and a revised runbook template published.

5. Migration waves (Weeks 18-27)

   Move the remaining move groups in planned waves with go or no-go control.

   • Run a go or no-go meeting before each wave with the application owners, infrastructure and service desk.
   • Rehearse each critical move group before its live cutover.
   • Run cutovers in agreed windows, with a bridge call and a timed runbook.
   • Run hypercare for a few days after each wave with a named support rota.
   • Update the wave tracker and the inventory after every move.

   Milestone: All waves complete, each application signed off by its business owner, and open hypercare issues below an agreed threshold.

6. Decommission and close (Weeks 28-30)

   Empty the old site safely and close the program.

   • Confirm that nothing still sends traffic to the old site before you power anything off.
   • Power down in stages and wait a set period before removing hardware.
   • Wipe or destroy storage media and keep certificates of data destruction.
   • Cancel circuits, support contracts and licenses tied to the old site, and update the CMDB.

   Milestone: Old site handed back or closed, destruction records filed, contracts cancelled and a closure report accepted by the sponsor.

Common mistakes to avoid

• Trusting the CMDB without checking it leaves servers nobody knew about, so validate the inventory with discovery tools and every application owner.
• Moving the most critical system first means learning on your riskiest cutover, so run a pilot wave on low-risk systems and fix the runbook before going further.
• Skipping dress rehearsals for critical applications turns cutover night into the first test, so rehearse each critical move group and time every step.
• Leaving rollback as a judgment call wastes hours during an incident, so write a rollback deadline and clear criteria into every runbook.
• Calling a move done when the servers are up misses broken business processes, so require business owner sign-off after testing.
• Powering off and removing old hardware right after the last wave risks losing a forgotten system, so power down in stages and wait before removal.

Frequently asked questions

What are the main steps in a data center migration plan?

Build a validated inventory, map dependencies, choose an approach per application, group systems into move groups and waves, build and test the target, run a pilot wave, migrate the remaining waves and decommission the old site. Each step needs a milestone and an owner.

How long does a data center migration take?

It depends on the number of applications, how well they are documented, the migration method and the freeze windows the business needs. Small estates can move in a few months, larger ones often take a year or more. Plan the timeline from the inventory and wave plan, not from a target date alone.

What is a move group in a data center migration?

A move group is a set of servers, databases and applications that depend on each other closely enough that they should move in the same cutover. Splitting them would mean slow links or broken calls between the old and new sites. Move groups are then arranged into waves.

What should a data center migration checklist include?

Include inventory sign-off, dependency confirmation, target readiness tests, backups verified, change approval, user notice, a timed runbook with a rollback point, business testers on call, service desk briefing and post-move sign-off. For the old site, add staged power-down and data destruction records.

How do you avoid downtime during a data center migration?

Use replication to keep target copies in sync so the final cutover is short, schedule cutovers in agreed low-traffic windows and rehearse critical moves. Some systems can run in both sites during the move. Agree on any planned downtime with business owners in advance.

Generate this roadmap with AI