Data center to cloud migration: the hardware side nobody puts in the plan

A move to the cloud is planned as a software project: workloads assessed, dependencies mapped, services rebuilt or lifted, traffic cut over. Every artefact of that plan is about the destination. The source is a building full of hardware, and the plan usually contains one line about it, near the end, that says decommission. This article is about that line and only that line. It offers no opinion on the cloud.

What is physically left when the workloads are gone

Everything. A cloud migration removes nothing from the room. When the last cutover completes, every server, every drive, every switch, the storage arrays, the tape library, the power distribution, the cabling and the racks are still exactly where they were, and every drive still holds the data that was just copied elsewhere. The difference from a move between two data centers is that none of it is going anywhere in particular. There is no destination rack. Each asset needs a decision, resell, redeploy elsewhere in the organization, or retire, and each one needs its data dealt with regardless.

The resale window closes while the migration runs

Cloud migrations take time, and hardware loses value continuously through that time. Equipment that would have sold well at the start of the project is worth less at the end, and the end is when most organizations first ask what it is worth. Two decisions reduce the loss. The first is to identify, at the start, the equipment that will be released earliest, and to plan its exit as its own event rather than holding everything for a single final clearance. The second is to settle who keeps the proceeds before any vendor is engaged, because the answer changes the commercial shape of the whole exit, as argued in the resale upside article.

Data on hardware the cloud never touched

The migration copied the data that mattered to the new platform. It did not touch the backup tapes, the retired test environment in the corner, the drives replaced under warranty and kept in a drawer, or the configuration on the network equipment. All of it is still in the building and none of it was on the migration team’s list, because their list was of workloads. The exit inventory has to be built from the room, not from the migration plan, and the two lists are then reconciled. The unresolved lines are the risk.

The exit sequence, for a cloud move specifically

The physical sequence is the same as for any exit: inventory, data classification, sanitization or destruction per device, removal, resale and recycling, reinstatement, certificate pack. What differs is the trigger. In a move between data centers, each system is released when it is running at the new site. In a cloud move, the release comes when the migration team declares the workload stable and the rollback window closed, and that declaration is often informal. Make it formal: a written release per system or per rack, signed by whoever owns the workload, is the document that lets us start. How the two projects interlock in general is covered in the migration article, and the cloud case is simply the version where nothing comes back.

The lease and the landlord do not know about the cloud

The colocation contract or the property lease has an end date and reinstatement terms that were written with no reference to where the workloads went. A cloud move that finishes on time still leaves a hall to empty and a floor to hand back. Read the reinstatement clause early, because it decides whether the exit ends at the loading dock or at a swept floor with the cabling removed and the tiles relaid.

What we need from the migration team

A register of every asset in the room, not just the migrated systems. The data classification per device. A release process with a named signatory. The lease end date and the reinstatement terms. With those, we plan the physical exit alongside the migration, remove equipment as it is released rather than at the end, and preserve whatever resale value remains. What that engagement covers, rack by rack, is on the server and rack removal page.

No cloud advice here

Which platform, which architecture, which migration method: not our field and not this article. Our field begins when the workload is gone and the hardware is still there, and it ends when the room is empty and every serial number has a documented fate. The overlap with the migration itself is described on the data center migration page.