Three ways to migrate a datacenter (and how to pick one)

Most datacenter migrations don’t fail because the hardware is hard. Racking servers, running cables and configuring a BMC are all solved problems. Migrations fail on the things around the hardware: people who weren’t told what was moving, a cutover window that turned out to be too short, a dependency nobody mapped. The approach you pick up front decides how much of that risk you carry. It’s worth choosing deliberately rather than by default.

There are three common ways to do it. None of them is “the right one”. They fit different situations.

When downtime is not an option: parallel

In a parallel migration you build the new environment alongside the old one. You duplicate the infrastructure in the new datacenter, install and test everything there, sync the data across, and only cut over once the new side is genuinely ready. Until then, the old environment keeps running.

The advantage is obvious: you can verify the new setup completely before anything depends on it, and if something looks wrong you simply don’t cut over. The cost is just as obvious: you’re paying for a double footprint for as long as both sides are live. That’s the trade. Parallel fits revenue-critical platforms where an unplanned outage costs more than running two sets of racks for a few weeks.

When systems can move independently: phased

A phased migration moves the estate in stages instead of all at once. You group systems that can travel together, pick low-load windows for each group (evenings, weekends, whatever fits the workload) and move one stage at a time. After each stage you verify it works before scheduling the next.

This spreads the risk out. A problem in one stage affects that stage only, and you’ve still got the rest of the estate where it was. It fits heterogeneous estates: a mix of systems with different owners, different tolerances and different maintenance windows, where forcing everything to move on the same night would be the riskier choice.

When a clean cut beats a long tail: big bang

A big bang migration moves everything in one short, rehearsed window. You plan it down to the step, you practise the sequence, and you commit to a hard rollback plan in case the window runs out. When it works, it’s the cleanest of the three: there’s no period where half your systems live in one place and half in another.

It fits smaller estates where the whole thing genuinely fits inside one window, and it only works if the rollback plan is real and tested. The danger of a big bang is the long tail: if something goes wrong and you can’t roll back cleanly, a “short window” becomes a long night.

How to choose

The right approach depends on how your organisation depends on IT. A platform that loses money every minute it’s down points towards parallel. A spread of systems with different owners points towards phased. A small, well-understood estate with a solid rollback plan can take a big bang.

What matters most is that this gets decided in preparation, not on the night. The approach shapes the budget, the schedule, the access you need and who has to be available, so it belongs in the plan before anyone touches a rack.

What a full-package migration includes

Whichever approach you pick, the work on the floor is the same set of steps. A full-package migration covers all of them:

1. New rack design
2. Hardware transport to the new datacenter
3. Racking & stacking
4. Network & power cabling
5. BMC configuration (if needed)
6. Relabeling of cables and servers
7. Testing & troubleshooting

The point of doing it as a package is having one partner from plan to operational. The same people who designed the new layout are the ones racking it, cabling it and testing it, with everything documented in Netbox and photo proof per job. Nothing falls between two suppliers.

Planning a move and not sure which approach fits? Tell us what you’re working with and we’ll talk it through.