The Data Center Migration Checklist we actually use.

Why this data center migration checklist has 147 items

Most data center migration checklists online have 30 to 60 items. I've used several. They're not wrong. They're just not complete.

A typical short checklist tells you to "backup all systems." It doesn't tell you to verify the restore. It tells you to "label cables." It doesn't say the labels need to survive shock, temperature swings, and three different sets of hands during transport. It tells you to "test connectivity" as one item, when in practice you need to validate internal connectivity, external connectivity, and partner network connectivity separately, because all three fail in different ways and at different times.

When I designed and ran data center facilities in the UAE and later in Finland, the patterns became obvious. What kills migrations isn't the headline work. It's the second-order items nobody writes down. The license tied to a MAC address that nobody knew about. The patch panel map that lived in one engineer's notebook. The destination cooling rated for 8kW per rack but actually delivering 6 under load. None of this shows up on a 50-item checklist. All of it shows up on real projects.

147 items is the minimum I'd defend for a thorough migration plan. Plenty of teams will need more.

How to actually use the checklist

Go through each phase in order. Check items off as you complete them. Hide the phases that don't apply to your project. Your progress saves locally, so you can plan across days or weeks without losing state.

Beyond the obvious, a few things make it more useful in practice.

Add notes to items where your situation differs. If "establish project budget" means "we already have a $2.4M envelope from FY27 capex," put that in the notes field. Six weeks later when you're in vendor selection and someone asks where the number came from, the note saves you. We use the notes field exactly this way internally.

Hide phases honestly, not aspirationally. If you're keeping the source site as a DR location and won't be doing decommissioning, hide Phase 12. Fine. But if you're hiding it because you don't want to think about it yet, don't. The hidden count is visible in your progress sidebar and it should reflect actual scope, not avoidance. Aspirational hiding catches up with you in month three.

Export to PDF after each major milestone. The PDF becomes a point-in-time artifact you can attach to project docs, send to the steering committee, or hand to auditors. Each export is dated. Over the life of the project you'll accumulate four or five versions, which gives you a record of how the plan evolved.

Share with your team early. The share link surfaces what you're tracking. The earlier other stakeholders can see it and add what you missed, the better your final plan. Migrations fail when IT's checklist and Facilities' checklist have a 30% gap and nobody discovers the gap until cutover week. Sharing early is how you find the gaps.

The 12 phases and why they're in this order

The phases are sequential in their logic but heavily overlapping in execution. Discovery & Inventory can't really close until Power & Cooling Assessment tells you which racks are problems. Vendor Selection needs to start during Discovery, not after, because the right vendor finds inventory gaps you didn't know existed. Use the phase order as a logical model, not a Gantt chart.

That said, three phases have hard sequencing constraints worth respecting.

Phase 1 actually has to come first. Skipping executive sponsorship and budget approval is the most expensive mistake I see teams make. One project I'm aware of ran for six weeks before someone realized the budget approval was conditional on a steering committee meeting that had never happened. By that point contracts were signed. The company was committed to a project it had not formally authorized. Get the charter signed before you do anything that costs money.

Phase 4 has to start much earlier than it looks like it should. New WAN circuits routinely take 60 to 120 days. If you wait until Phase 8 to order them, the week before cutover, you've already slipped the date. Order circuits as soon as the destination facility is confirmed, even if the rest of your migration strategy is still being decided.

Phase 11 can't be compressed. You need 24 to 48 hours of monitoring under real production load before you can honestly call the migration done. Teams under pressure to "finish" tend to compress this phase. Three weeks later, a quarterly batch process fails because it depended on a system that quietly broke during cutover. Build the validation window into the timeline at the start. Don't borrow against it.

When this checklist is enough, and when it isn't

This is the right starting point for most data center migrations under roughly 5 MW of IT load or 500 racks. That covers enterprise data center moves, server room relocations, and the majority of colocation migrations.

It is not enough for the following.

Active-active cutovers. If you need zero perceived downtime, you need a custom runbook with replication topology, traffic-shifting strategy, and rollback automation that this checklist treats as single items. Use this list as a coverage map, but expect your real runbook to be three times longer in the cutover phases.

Heavily regulated environments. PCI Level 1, HIPAA covered entities, FedRAMP workloads, financial services with FINRA or SEC obligations, all need framework-specific compliance evidence and attestation steps that vary by regulator. This checklist gives you the structural items. Your compliance team needs to add the rest.

AI compute and hyperscale facilities. Power density above 30kW per rack changes the math on cooling, electrical infrastructure, structural load, almost everything. If you're moving GPU clusters, the assumptions baked into the power and cooling items (10-15kW racks, traditional CRAC cooling, raised floor) don't really apply. We're working on a separate AI/HPC migration checklist. Until then, the PM and validation phases here will still serve you. Treat the power and cooling items as a starting point you'll need to expand.

Cross-border moves. Moving equipment across borders adds 10 to 30 items around customs documentation, export controls, destination country compliance, and data residency. If your migration crosses a border, plan for substantially more work than this list shows.

The data center migration items most teams forget

After looking at a fair number of plans, I can predict what will be missing from a homemade checklist. The patterns are consistent.

Cable labeling standards. Teams plan to "label cables" without specifying the format. Four hundred cables arrive at the destination labeled in three different conventions. Reassembly takes twice as long as planned. The standard needs to be documented before disassembly starts. Item 99.

Backup chain validation in the new environment. Backups that worked in the source environment may not work in the destination. Different network paths, different IP ranges, different replication targets. Confirming the chain works end-to-end at the destination is item 126. It gets checked off too quickly.

License servers and hardware-tied licenses. Software licensed against MAC addresses, motherboard serials, or specific IP ranges will break when hardware moves. Item 20 catches the inventory part. The actual remediation, working with each vendor to re-license or transfer, usually takes longer than teams plan for.

Post-cutover monitoring sign-off. Migrations get declared "done" when systems are running, not when monitoring has confirmed they're running correctly. The 24 to 48 hours of monitoring in Phase 11 is the difference between "moved" and "moved and verified."

Vendor address updates. All your hardware support contracts, software renewal notices, compliance certifications, and insurance policies still have the old address. Updating them is unsexy work. It also bites you 18 months later when a support engineer dispatches to the wrong building.

Physical access at the new site. Day one after cutover, the ops team needs to physically enter the new facility. Badge enrollment, key distribution, biometric setup, these can take weeks to process. Start in Phase 5.

All of these are in the checklist. Most are missing from generic plans I've reviewed. The reason isn't that teams don't know these things matter. Under deadline pressure, items that aren't on the formal plan become "we'll figure it out." Putting them on the plan, with explicit owners and rough effort estimates, is what turns "we'll figure it out" into "this is done by Tuesday."

What to do after you've worked through the checklist

If the checklist surfaced gaps you didn't know existed, that was the point. Better to find them now than during cutover week.

If your migration is large enough that having a comprehensive checklist still doesn't give you enough confidence to execute, meaning you've identified the items but you don't have the in-house expertise to deliver them, use the partner match service in the right sidebar. We route to specialist data center relocation firms in the US, UK, and Australia. The match is free, no obligation. We earn a referral commission from partners when projects close, which is what keeps the recommendations honest. We have no incentive to push you toward any specific provider beyond fit for your project.

If you find items missing from the checklist that should be there, email us. The list is updated as new failure modes surface from project debriefs. Your contribution helps the next operator who comes through.