Infrastructure relocation is almost always treated as a logistics task. The riggers show up, move everything carefully, switch it on, and leave. In practice, the transport itself is the shortest and most predictable part of the job. Everything interesting happens before it and after it.
In late August we had two relocations overlap. The first was moving a hardware-and-software appliance carrying Oracle database workloads from one server room to another. The second was an office move, where two racks from two different floors were consolidated into a single cabinet at the new site. The difference in equipment class is obvious. What’s far more interesting is something else: the relocation strategies turned out to be fundamentally different, and it wasn’t about budget.
Statement of the problem
Two sites, one week
The equipment classes were different, but in both cases the strategy came down to one question — what, here, can actually be duplicated in advance.
Let’s start with what was actually being moved — without that, the decisions that follow look arbitrary.
Site one. Two cabinets of a hardware-and-software appliance carrying Oracle database workloads, three separate smaller-form-factor appliances of the same class, and the network core. The source and target server rooms are in different buildings roughly 150 meters apart, within the same internal grounds. The customer provided the new cabinets; the original ones stayed in place — meaning the equipment didn’t travel “with the rack,” it was disassembled and reassembled from scratch.
Site two. The office: two racks that needed to be consolidated into a single 42U cabinet at the new site. Inside: the core router, three aggregation switches, access switches, a 10G switch, six patch panels, eight Wi-Fi access points, a telephony platform in a fault-tolerant pair plus a separate second one, and four servers: three nodes running office services on Proxmox and a backup server. Plus uninterruptible power supplies and power distribution units. The final layout used about 27 of the 42 units.
Both moves were handled by the same team a couple of days apart, and that turned into a useful experiment. Same engineers, same planning approach — yet opposite decisions at the end. Which means it wasn’t about the team’s preferences or the size of the budget, but about conditions that had already been set long before anyone even brought up the move.
The key difference isn’t size or price. Site one already had replication configured between the two appliances. Site two had neither a second site nor service duplication, but it did have the option of preparing the new site fully in advance. That’s what determined both strategies.
The database appliance
Moving a role, not hardware
Whichever appliance is standby at that moment goes first. The only thing users notice is the role switchover.
The two appliances at site one ran standard Oracle replication in Active/Standby mode. The plan was built around it.
The appliance acting as standby at the time of the work moves first: shutting it down has zero effect on users. It’s disassembled, transported, reassembled in the new cabinet, powered on, checked, catches up on the accumulated archive logs, and returns to service as standby. Then comes the role switchover. The former standby becomes primary, the former primary becomes standby — and now it’s the primary’s turn to move to the new room, following the same procedure.
Here’s how it played out in time. Moving the first appliance took 10 hours 55 minutes, done in a single pass with no shift breaks. The role switchover took 8 minutes. The second appliance moved the next day and came in at 9 hours: every hiccup from the first pass was already known and accounted for by then. Not once over those three days was the database fully unavailable — the only window users could have noticed was those eight minutes.
The smaller-form-factor appliances were moved differently. They have no replication, but they have another trait: they host test databases and development environments. A full shutdown is only possible on weekends — so developers can work normally on weekdays. So the window’s date was set not by the work schedule or crew availability, but by the development team’s calendar. The window itself was executed with discipline: standard shutdown, state capture, transport in two batches, reassembly, power-up in reverse order, and item-by-item verification. The batch order was chosen not for loading convenience but for what needed to come back online first.
Not everything went smoothly. During the role switchover, the redo stream failed to come up on one of the nodes — the log files had to be created manually and the node restarted. On top of that, a requirement surfaced mid-project that wasn’t in the original brief: clean and blow out the equipment before bringing it into the clean server room.
About people. A separate resource that has to be planned right alongside the hardware is engineers with hands-on experience of exactly this kind of appliance. Two remote Oracle engineers worked on this relocation: consulting and remote support at every stage. Importantly, earlier that same August they had done an identical move for another customer, relocating three appliances at once. Fresh experience is worth more than any procedure document: someone who went through this exact process three weeks ago knows where it usually trips up, and doesn’t burn the maintenance window figuring it out.
Preparation and timelines
The critical path wasn’t rigging
Procuring what’s missing and arranging site access take two orders of magnitude longer than the work itself.
Now, what actually ate up the schedule. Not a single risk that materialized had anything to do with transport.
The target room. Neither the customer nor we initially knew the state of outlets, cross-connects, ports, and cable lengths in the new server room. We had to add a separate survey stage to the plan, and, based on its findings, procure the missing cables, transceivers, adapters, and outlets. We got lucky here: everything was found and purchased within five days. But that’s luck, not the norm — the right transceiver or adapter can take a month to arrive, and then it’s the one thing that sets the moving date.
Completeness of the inputs. The work plan was recalculated four times, and it wasn’t about arithmetic. Every revision came after something new emerged: the makeup of the target room, the order of transport batches, exactly who was cleared for site access, what access regime the work operates under. The first version of any relocation plan is exactly as optimistic as its input data is incomplete, so its durations should be treated as a draft, not a commitment.
Personnel clearance. A separate line item that almost everyone trips over. The plan listed the rigging crew’s role as “in-house team or contracted subcontractor.” A restricted-access site doesn’t let outside movers in — meaning the heavy lifting falls to the same engineers who then assemble the appliance, and that has to be built into both the schedule and the crew roster.
Baseline and labeling
What to record before picking up a screwdriver
A condition report protects both sides, and your own labeling is the only thing you can trust during reassembly.
Before the work began, we pulled full diagnostic reports on both appliances. That gave us two things at once.
First — a list of defects that predated us. Online-installable kernel patches not applied, non-volatile memory on the storage cells misconfigured, a cache capacitor failed on one of the controllers, patches not registered within the database itself, flashback disabled, one server nearly out of space in its system volume group. The overall condition score was 92–93 out of 100, which is decent for an appliance of that age. But each cluster had three critical findings.
Second — protection against the conversation “it stopped working after your move.” If it wasn’t working before the move either, the dated report shows it. The customer also gets an honest picture of their appliance’s condition for free, before anything breaks. Pulling that same report after the work is done proves nothing anymore.
Now about labeling, and this is not a minor detail. The main rule: don’t trust the existing labels. You never know who reassembled or relocated this appliance before you, how many times, whether the actual wiring matches the port map in the documentation, or whether something was rerouted “temporarily” three years ago.
So the order is this. First, record the actual as-found state — photographs of the cabinet from both sides, a port diagram as it actually is, not as documented. Then relabel everything yourself, from scratch, and stick labels on everything: the equipment, the cables, the patch panels, the power outlets. Labeling has to be as simple and unambiguous as possible, so someone seeing this cabinet for the first time can understand it. Every cable is labeled on both ends, and the tag states exactly where it plugs in: unit, port, outlet, position. Not “uplink-2” — the actual destination.
You never know who reassembled this appliance before you, or how many times.
It’s tedious work that takes a few hours. It pays for itself exactly once — when something fails to come up at the new site and you need to work out, in a minute, whether the right cable is in the right port.
Consumables
Cables survive a move differently
What travels as-is, what gets inspected piece by piece, and what gets replaced with new stock without discussion.
A separate topic where people cut corners most often is consumables. A cable seems eternal right up until it starts failing under load.
100-gigabit copper DACs for the RoCE fabric handle a move and re-plugging fine: they’re short, rigid, and the connector is one solid piece. It’s enough to check the connector and the latch. 10- and 25-gigabit DACs, on the other hand, need individual inspection of every single one: they’re thinner, kink more easily, and the retention clips stretch out. Copper cat5e and cat6 patch cords belong in the same bucket: check for kinks, crushed insulation, and broken latches.
With OM3 and OM4 multimode fiber, the conversation is short: it gets replaced with new stock on every move. Microbends accumulate over years of service, adhesive and plastic dry out from the heat in the hot aisle, and disassembly and re-routing add their own share of damage. The other problem is that a patch cord like this doesn’t fail cleanly and immediately — it produces a growing error count under load, and people will look for the cause everywhere except the cable itself.
Better to throw out a cheap consumable than to go chasing intermittent degradation on a critical system later.
Better to throw out a cheap consumable than to go chasing intermittent degradation on a critical system later. This is probably the one place in a relocation where there’s nothing worth saving money on.
The office move
The office: one pass onto a prepared site
No replica, no rollback. Which means all the insurance goes into site preparation — and that takes longer than the move itself.
Now, site two. There’s no second site here and no service replication. There’s one role; nothing to switch over.
We considered a swap-fund approach: temporarily put spare switches in the old location while moving the actual units ahead and bringing them up at the new site in advance. We dropped the idea. We didn’t want to smear the working configuration across two sets of hardware, configure everything twice, and still have to move the real hardware afterward. We decided to move the actual, current configuration all at once, in a single pass.
That means there’s no rollback. The move is irreversible: in a single day, the equipment comes down at the old site, gets transported, mounted, and started up at the new one. Since there’s no rollback, all the insurance shifts into preparation — and here, preparation takes longer than the move itself.
The main work was the cabling system. The new structured cabling at the site was built out in advance, completely, down to the outlets at the desks, by an installation crew. A separate storyline was dismantling the raised floor, under which the old wiring ran. The entire new system was consolidated into six 24-port patch panels in a single cabinet — and honestly, that’s the main outcome of the move: cross-connects used to be smeared across two racks, now they’re in one place and legible.
By the time the equipment arrived, the desk outlets were already live, the runs had been tested and labeled, and all that was left in the cabinet was to install the active gear and plug in the cross-connects per the finished diagram. That’s why the move fit into a single day.
Two racks into one is a rebuild, not addition. Everything had to be recalculated from scratch: units, ports, power draw, weight, heat output, and patch cord lengths. The layout is assembled from zero and by the rules: patch panels at the top, active network equipment below them, telephony under that, servers in the bottom third, uninterruptible power supplies at the base — two units, two of them.
Separately, about free space. A continuous block of roughly 13 units was deliberately left in the middle of the cabinet. Not because things didn’t fit, but because new servers will go in there in a year to a year and a half, and we didn’t want to scatter them across leftover scraps of space. Empty units in a new cabinet aren’t wasted capacity — they’re the only cheap way to buy yourself the next upgrade without another move.
And about connectivity. There were four carrier services, and each one is migrated separately: internet for office services and users; a dedicated Wi-Fi channel; primary telephony in a fault-tolerant configuration; and a second phone line for secondary calls. The scheme is workable and predictable if the requests are filed in advance: the carrier runs fiber to the new site ahead of the move, and does the actual service cutover on the day of the work. The key word is “in advance.” The requests go out first, before a date is even set, and acceptance isn’t based on the wording “service activated,” but on the fact that “the call went through, the channel holds the load.”
Checklist
What to ask before setting a date
Eleven questions that turn a moving date from a wish into a grounded plan.
Conclusion
In place of a conclusion
The strategies look different, but both come down to one rule: the risky moment has to be covered by something set up in advance. The only thing that differs is what, exactly. In the first case, it was replication configured long before we got involved. In the second, it was site preparation: a cabling system built out down to the desk outlets before the first rack ever arrived.
Which leads to an uncomfortable conclusion for planning: the ability to move calmly isn’t built in at the moment of the move. If there’s no replica and the site isn’t ready, no crew can make the move seamless — you can only shrink the window and decide in advance what you’re risking.
And in both projects, the critical path lay outside transport: on one side, procuring cables and transceivers; on the other, installing the cabling system and filing carrier requests. Both items are measured in weeks, while the work itself is measured in hours. That’s why the right way to start a conversation about a move isn’t “when does the truck arrive,” but “what do we still not know about the target site.”