Data centre relocation: how to plan and execute a server move without surprises

Why documentation is not enough: the physical audit is step one

Most data centre documentation drifts from physical reality within weeks of being produced. Cables are added without being recorded, devices are swapped without the CMDB being updated, and power circuits are redistributed without the elevation diagrams reflecting the change. A relocation project planned from unverified documentation will encounter those discrepancies on the move day, when there is no time to resolve them without delaying the window.

The physical audit should capture: every device in every rack with its make, model and serial number, every cable with its source port, destination port and type, the power draw of each device from each PDU circuit, and any undocumented equipment that appears on the floor but not in the records. The audit output becomes the basis of the move plan, not the documentation that preceded it.

Dependency mapping: the step that determines the sequence

Dependency mapping identifies which systems break when a given device is powered off. A server may have dependencies on a storage array, a firewall, a load balancer and a database server, and those dependencies may run in both directions. Moving the storage array before the server requires the server to be offline first; moving the server first requires the storage array to remain available. Getting the sequence wrong causes an outage that was not planned.

The dependency map is produced by combining the physical audit with the application stack documentation (if it exists and is current) and a live network scan showing active connections. Where documentation is absent or questionable, a period of network monitoring before the move window allows connections to be observed rather than assumed.

Sizing move waves: the two failure modes

Move waves group devices that can be moved together within a single change window without creating a prolonged outage for any critical system. Too many devices in a wave and the window runs long; too few and the number of windows becomes unmanageable. Most relocation projects fail in one of two ways: waves are sized against how many devices fit on the transport vehicle rather than how long reinstallation and verification takes, or waves include devices that have unresolved dependencies on systems staying at the source site.

Rollback: what it actually means and when to call it

A rollback plan is a decision to stop the move and return devices to the source site. To be executable, it must specify the trigger conditions (what state of the move window prompts the rollback decision), the roles with authority to call it (not just the project manager but the technical leads who can assess the impact), and the physical steps to reverse the work done so far. A rollback plan that exists only as a document is less useful than one that the engineers have rehearsed.

Rollback becomes harder as the move progresses: a device that has been unracked and transported can be returned, but a device that has been reinstalled and is already carrying production traffic cannot be returned without a second outage. Establish the rollback threshold early in the window and assign a named person to make the call.

Destination readiness: the long-lead items

The destination data centre must be ready before the first device arrives. Long-lead items that are regularly overlooked include cross-connects (the physical circuit connecting your cabinet to the facility's network interconnect, which can take four to eight weeks to provision), power circuits (the A and B feeds to each new cabinet, which must be commissioned and tested before the first device is racked), and the cabinets themselves (many facilities require cabinets to be installed and access-listed before equipment can be placed in them).

• Cross-connects ordered and confirmed: typical lead time four to eight weeks at most UK colocation facilities
• A and B power circuits commissioned and load-tested in each new cabinet
• Cabinets installed, access authorisation confirmed for all attending engineers
• Out-of-band management connectivity (console server, IPMI) configured and tested before hardware arrives
• Staging area confirmed for unboxing and inspection of hardware arriving from transport
• Handover from transport to data centre team agreed: who signs for each device and where

Verification: the three levels to reach before sign-off

Move sign-off should require three levels of verification. Physical verification confirms that every device is racked in the correct position, cabled correctly and powered from the correct A and B feeds. Infrastructure verification confirms that every device is network-reachable, that storage is accessible and that out-of-band management responds. Application verification confirms that the applications and services running on the moved infrastructure are healthy and handling requests correctly. Without all three, sign-off is premature.

After the move: the tasks most teams defer and later regret

• Update all CMDB records to reflect the new facility, rack positions and cable schedule
• Update monitoring and alerting with the new infrastructure identifiers and thresholds
• Decommission the old cabinet space formally, including power-down, unrack and removal
• Cancel or re-order cross-connects at the source facility that are no longer needed
• Produce an as-built document for the new facility that matches the physical state after the move
• Close the access lists at the source facility for engineers who no longer need access