Data center migration: the exit is the last phase, and the one the plan forgets

A data center migration moves workloads, data and services from one place to another. It is planned by people who think in cutovers and dependencies, and it ends, in their plan, when the last service is running at the destination. The building they left does not know that. It still holds every rack, every drive and a lease with an end date, and emptying it is a second project that the first one has to make room for. This article is about the join between the two.

Two projects with one calendar

The migration and the decommissioning share a calendar and almost nothing else. The migration is measured in services moved and outages avoided. The exit is measured in racks removed, serial numbers accounted for, and a floor handed back in the state the lease requires. Different teams, different vendors, different definitions of done. The join is a set of dates: the day each system is confirmed retired at the source, the day the last one is, and the day the landlord expects the keys. Everything in the exit hangs from those dates, and the migration plan has to produce them.

What the migration plan must reserve for the exit

Three things. First, time: the interval between the final cutover and the lease end has to hold the whole physical exit, including data destruction and reinstatement, not just the truck. Second, a decision on every asset, made before the migration starts: moved physically, retired, or resold, because that decision changes how each machine is handled on its last day. Third, ownership: a named person who holds the exit plan, because in a migration everyone owns the destination and nobody owns the source. The phases of the exit itself are set out in the sequence a data center exit has to follow.

Lease end is the deadline that does not move

Migrations slip. Cutovers get postponed, dependencies surface, a test fails. That is normal, and a good migration plan absorbs it. What does not absorb it is the lease. The end date was agreed long before, the reinstatement obligations are written, and a holdover costs whatever the contract says it costs. When the migration slips, the time it consumes comes out of the exit window, which was the smallest window in the plan to begin with. The exit plan therefore needs a stated minimum duration, so that everyone can see the day on which a further migration slip starts eating into the lease.

Cutover and the dual-running window

Most migrations run the old and new environments in parallel for a period, so that a failed cutover can be reversed. During that window nothing at the source can be touched, because it might be needed again. The removal crew cannot start, the drives cannot be sanitized, and the resale value of the equipment continues to fall. Decide in advance how long the dual-running period lasts, what the criteria are for closing it, and who signs the release that lets the exit begin. Without that signature, the exit starts on a rumour.

What goes wrong when the exit is an afterthought

The patterns repeat. Drives are pulled from retired servers by the migration team, without a manifest, to be dealt with later, and later never has a list. Equipment sits powered down but in place for months, so the resale window closes on hardware that would have sold. The removal is quoted in the final weeks, at a final-weeks price, by a crew that has never seen the floor. The reinstatement clause is discovered in the lease during the last of those weeks. None of these are failures of the migration. They are failures of the join, and they were settled when the plan was written without an exit chapter, which is why we argue that the decommissioning process is decided before day one.

Handing the old site from the migration team to the removal crew

The handover is a document: the asset register with every unit marked retired, moved or unresolved, the data classification per device, the release signed at the end of dual running, and the building constraints. With that in hand, a crew can plan the physical sequence in one visit. Without it, the first days of the exit are spent rebuilding what the migration team already knew and has moved on from.

Where we sit in the plan

We are the exit. Our involvement in a migration starts at planning, when we tell the migration team what duration the physical exit needs and which decisions it depends on, and it ends when the floor is handed back and the certificate pack is filed. What that looks like inside a migration is on the data center migration page, and the working list for the physical side is on the decommissioning checklist.