Moving a Server Room: Planning a Rack Relocation

Moving a rack looks like a logistics job and is mostly a documentation job. The equipment usually survives the journey; what causes the long outage is nobody knowing exactly how it was connected.

Document before you touch anything

The step that determines how long the outage lasts.

Photograph everything — front and rear of each rack, both power and data cabling, from several angles. Photographs are faster than notes and considerably more reliable, and they capture things nobody thought to write down.

Label both ends of every cable before disconnecting, with what it connects and to which port. Cables that looked obvious in place become anonymous in a bundle.

Record rack positions. Which unit each device occupies, in which rack. Reassembling in a different order breaks your documentation and any cable lengths cut to fit.

Capture configuration. Switch and firewall configurations, management controller settings and credentials, RAID controller settings, and IP addressing. If anything fails to come back, this is what lets you rebuild rather than reconstruct.

Two hours of documentation regularly saves a day at the other end.

Verify backups first

Non-negotiable, and it needs to be a verified restore rather than a successful job.

A move is a period of concentrated physical risk to equipment that has been running undisturbed for years. Drives that have spun continuously for a long time are more likely to fail on being powered down and restarted than at any other moment — the shutdown, not the journey, is frequently what kills them.

That is worth stating plainly: expect some hardware not to come back up. On ageing equipment it is normal rather than exceptional.

Which means arriving with spares, and knowing that your backups restore, are the two things that turn a failure into an inconvenience.

Check the destination before moving

Four things measured in advance, because discovering them on the day is expensive.

Power. Enough circuits, of the right type, with capacity for the load — and in a redundant design, each path able to carry the whole load alone. Confirm connector types match. Our PDU guide covers the arithmetic.

Cooling. Adequate for the load, with a path for hot air to leave. Check the room, not just the capacity figure. Our airflow guide covers what to look at.

Physical access. Doors, lifts, floor loading, and the route from the vehicle. A rack is heavy, and floor loading limits in older buildings are real.

Network connectivity. Uplinks, addressing, and whether anything depends on the old location’s addressing. Cable lengths too — runs that fit in one room may not in another.

Shutdown order

Reverse of the startup order, and worth writing down before starting.

Generally: applications, then virtual machines, then hosts, then storage, then network, then power infrastructure. The principle is that things depending on something else go first.

Do a clean shutdown rather than pulling power. Storage systems in particular need to flush caches, and an unclean shutdown of a storage array can leave it doing a lengthy consistency check on startup — time you will not have.

Note anything that does not shut down cleanly. A system that hung during shutdown may need attention before it starts again.

Moving the equipment

Remove servers from racks rather than moving racks loaded, unless the rack is designed and rated for it. A loaded rack is top-heavy and racks have tipped during moves.

Handle drives carefully. Mechanical drives are most vulnerable to shock, and a drive that has been running for years is not a new drive. Where practical, remove and transport them separately, labelled by bay — because RAID arrays care which drive goes in which position on some controllers.

Antistatic handling for anything removed and transported loose.

Keep rails, screws and small parts together and labelled. Missing rail hardware is a common cause of a rack that cannot be reassembled on the day.

Bringing it back up

Reverse of the shutdown, and slower than you expect.

Power infrastructure first, then network, then storage, then hosts, then virtual machines and applications. Let each layer come up fully and verify it before starting the next. Starting hosts before storage is available produces failures that look like data loss and are not.

Verify storage arrays are healthy before mounting anything. If a drive failed during the move, you want to know before the array is under load, and a rebuild is the hardest work the surviving drives will do.

Expect the first startup to be slow — consistency checks, filesystem checks and rebuilds all run at once.

Take spares

Given that some hardware will not survive the restart, arrive prepared.

At minimum: drives matching what is fitted, a power supply for each server type, and the cables you might need. Our spares guide covers holding these generally, and a move is exactly when the holding proves its value.

Also take the tools, the labels and the documentation in printed form. A runbook stored only on a system you have just powered down is unavailable.

Common questions

Planning a move? Tell us your platform and we will advise which spares to have on hand for the day.