IT Equipment Relocation: Planning a Move That Works
Moving hardware between sites is where estates lose equipment and discover undocumented dependencies. This covers planning a relocation that works.
Plan the destination before touching the source
Five things ready before anything moves.
Rack space, with positions assigned for each item. Deciding where things go while holding them is how racks end up badly arranged.
Power capacity and outlets, including two feeds for redundant supplies. Our PDU guide covers counting them.
Cooling capacity for the load arriving. Our cooling guide covers working it out.
Network in place and tested, including the addressing plan if it changes.
Rails fitted where possible, so installation is lifting rather than assembly.
Document before you disconnect
The step that determines how the rebuild goes.
Photograph everything β rack fronts, rack rears, cable routing, every port. Far more useful than notes, and it takes minutes.
Label both ends of every cable before unplugging any of them. A rack of unlabelled cables at the destination is hours of work.
Record the current configuration β addressing, VLANs, port assignments, anything that lives in a device rather than in documentation.
Our network documentation guide covers doing this properly, and a relocation is the best opportunity you will get.
The dependency check
Before shutting anything down, establish what depends on it.
Systems accumulate dependencies nobody documented β scheduled jobs, licence servers, integrations, DNS entries, a service pointing at an IP address rather than a name. Our undocumented estate guide covers finding them.
The relocation-specific version: anything hard-coded to an address that will change. If addressing changes at the destination, every hard-coded reference breaks, and those are found by testing rather than by looking.
Shut down in the right order
Dependencies first, infrastructure last.
Virtual machines, then hosts, then shared storage, then network, then power. Reverse it at the destination. Starting storage after the hosts that need it produces a confusing set of failures.
And take a backup first, verified. A relocation is a period where the equipment is in a van rather than in a rack, and that is exactly when you want a copy elsewhere. Our backup guide covers verifying it.
Packing for transport
Four points, and equipment in a van needs the same care as equipment in a courier network.
Remove drives from servers where practical, packed separately and labelled by machine and bay. Drives are the most shock-sensitive part and the most valuable.
Remove or secure anything that can move β power supplies, loose cards, cable arms.
Original packaging where available, double-boxing where not. Our packing guide covers the standard.
Do not stack unpacked equipment. A server resting on another server in a van moves, and the damage is invisible until it is under load.
Condensation: the one people miss
Equipment moved between very different temperatures can form condensation internally.
The rule: let equipment reach room temperature before powering it on. Several hours for a cold server brought into a warm room. Powering on wet electronics is how a relocation turns into a replacement.
This matters most in winter and with long transport times. Our humidity guide covers the wider environmental picture.
At the destination
Five steps.
Acclimatise, per above.
Inspect before installing. Damage found now is damage you can act on.
Rack, cable and power up in dependency order. Our racking guide covers the physical side.
Verify each machine before moving to the next. Configuration matches, health clean, no new errors. A machine that lost a drive in transit is easier to identify now than after everything is on.
Test the workloads, not just that machines are up. Our acceptance testing guide covers what to check.
Frequently asked questions
What should I do before disconnecting anything?
Photograph rack fronts, rears, cable routing and every port; label both ends of every cable; and record configuration that lives in devices rather than documentation. A relocation is the best documentation opportunity you will get.
Should I remove drives before moving a server?
Where practical, yes, packed separately and labelled by machine and bay. Drives are the most shock-sensitive part and the most valuable, and a loose drive inside a chassis damages everything it hits.
Can I power equipment on as soon as it arrives?
Not if it has moved between very different temperatures. Condensation can form internally, and powering on wet electronics turns a relocation into a replacement. Allow several hours to reach room temperature.
What order should I shut down and start up in?
Shut down dependencies first: virtual machines, then hosts, then shared storage, then network, then power. Reverse it at the destination. Starting storage after the hosts that need it produces confusing failures.
What breaks most often after a relocation?
Anything hard-coded to an address that changed. Those are found by testing the workloads rather than by looking at documentation, which is why testing workloads matters more than confirming machines are up.
Should I verify each machine as I install it?
Yes. Configuration matches, health clean, no new errors, before moving to the next. A machine that lost a drive in transit is far easier to identify now than after everything is powered on.
Tell us what is moving and we will list the spares worth having on site for the day, because relocations surface failures.
