Moving a server room over one weekend: a realistic runbook

The plan usually sounds simple: switch everything off on Friday evening, move it on Saturday, have it running by Monday. Then Sunday night arrives. The file server will not mount its storage, the firewall still has the old site's public IP addresses, and nobody remembers which patch cord went into which switch port. Moving a server room over one weekend is entirely achievable — but only if most of the work is done before the weekend starts.

Below is a realistic runbook for a small server room: a few racks, a handful of physical servers or virtualization hosts, storage, core switching, a firewall and an internet connection. It is the sequence we use as a baseline in infrastructure relocation projects, adapted to each site.

Two weeks before: what must be true by Friday

The weekend is for execution, not discovery. If any of the items below is still open on Thursday, treat the move as at risk.

• The new room is finished: power circuits, rack positions, cooling and physical access are ready and checked.
• Internet and WAN links at the new site are installed and tested — not just ordered. If public IP addresses change, DNS records, VPN peers and firewall rules are prepared in advance.
• Structured cabling between the server room and the floors is installed, labeled and tested.
• There is a current inventory: every device, its role, its rack position, its power and network connections.
• Every cable is labeled at both ends, and the port map is photographed and stored outside the systems being moved.
• System owners have signed off the downtime window and know who makes the go/no-go call.
• Spares are on hand: patch cords, power cables, rack fixings, a spare switch if one is critical, and vendor support contacts.

Friday evening: freeze, verify, shut down

Work starts once users are off the systems. Announce a change freeze, confirm that the final backup jobs have completed, and only then begin a controlled shutdown. The order matters: shut down from the top of the stack to the bottom — applications first, infrastructure last — so that databases close cleanly and storage is not pulled out from under running workloads.

1. Stop applications and services, then databases.
2. Shut down virtual machines, then the virtualization hosts.
3. Shut down storage systems according to the vendor's procedure.
4. Power off network equipment last — you may need remote access until the very end.
5. Photograph each rack front and back, then disconnect and dismantle according to the labels.

Saturday: transport and rebuild

Servers and storage should travel in their original packaging or in padded transport cases — never stacked loose in a van. Disks from storage arrays are sometimes removed and transported separately with their slot positions recorded; whether to do this depends on the hardware and the vendor's guidance. At the destination, equipment is checked against the inventory before anything is mounted.

• Mount racks and equipment to the prepared layout — not to the old one out of habit.
• Connect power first and verify which UPS and circuit each power supply is on.
• Re-patch strictly from the port map; any deviation is recorded immediately.
• Check that airflow direction matches the hot-aisle and cold-aisle arrangement.

Saturday night: bring-up in reverse order

Bring-up is the shutdown sequence reversed: infrastructure first, applications last. Confirm that each step works before moving to the next. A fault found in the core switch is cheap at ten o'clock on Saturday night and expensive once forty services depend on it.

1. Power and UPS: load, alarms, correct circuits.
2. Core network and firewall: internal routing, internet access, VPN tunnels.
3. Storage: health status, no degraded volumes, paths visible from the hosts.
4. Virtualization hosts and directory services (domain controllers, DNS, DHCP).
5. Databases, then business applications, then everything else.

Sunday: test like a user, not like an administrator

A server that answers ping is not the same as a working business. Prepare a short test script with the system owners in advance and run it on Sunday afternoon from an ordinary workstation, with an ordinary user account.

• Log in, open shared folders, print to a network printer.
• Open the accounting or ERP system and post a test transaction where that is safe.
• Send and receive external email; check remote access and VPN from outside the office.
• Check telephony, video surveillance recording and access control, if they depend on the server room.
• Confirm that backup jobs run at the new location too.

Go or no-go: the decision point and a real rollback plan

Agree in advance a specific time on Sunday — early afternoon, for example — by which the core systems must be working. If they are not, the team either escalates with a clear estimate of the remaining work or executes the rollback plan. A rollback plan that says only 'we will move it back' is not a plan; it needs the same level of detail as the move itself.

In practice, a full physical rollback is rare. More often the fallback is partial: run a critical service temporarily in the cloud or a temporary environment, or accept a reduced service level on Monday morning while a specific fault is fixed. Decide what is acceptable before the weekend, not at two in the morning.

Monday morning: hypercare

Have technicians on site when people arrive. The first hour surfaces issues that no test caught: a forgotten desk phone, a mapped drive pointing to an old server name, a scanner configured with a static IP. Log every issue, fix it and close it, and finish the week with updated documentation: rack layouts, port maps and network diagrams that reflect the new reality. If the new site also needed network and cabling work, its as-built records belong in the same handover pack.

Planning a server room move and want a second pair of eyes on the runbook? Get in touch — we can review the plan with you and agree the scope and sequence.