01 / The stakesWhy migration is the riskiest project you will run
A migration concentrates years of accumulated complexity into a handful of maintenance windows. Everything that has ever been plugged in, patched, scripted or forgotten has to come back up, correctly and on time, with the business watching.
One window, no undo
The cutover happens in hours, usually over a weekend. If the plan is wrong there is no clean rollback, which is exactly why everything before the move matters more than the move itself.
A web, not a list
Hundreds of devices and thousands of connections, with dependencies nobody fully remembers. Miss one and a service that “wasn’t in scope” goes dark at 02:00.
As built is not as documented
The real environment rarely matches the diagram. Migrating from a guess is how kit comes back up wrong, or not at all. You can only move safely what you have actually mapped.
A migration is won or lost in the weeks before anyone touches a screwdriver. The move itself is only the visible part.
02 / The processThe end-to-end migration process
Seven stages, one accountable owner from first survey to final handover. Step through each: most of the work, and most of the risk reduction, happens long before the move weekend.
03 / The moveHow the physical move actually runs
Depending on the estate, the dependencies and the window available, a migration runs either as a single big-bang cutover or as phased waves. Destination racks are pre-patched and waiting; devices move in planned, dependency-led groups; excess and end-of-life kit is decommissioned rather than carried over, so two racks of sprawl can land as one clean, denser rack. Here is a phased example.
Pre-migration: environment mapped
Illustrative. 20 racks of sprawl consolidate into 12 denser racks, with excess and end-of-life kit retired on the way: a smaller footprint and lower energy use.
A big-bang cutover moves everything in one window: faster, and often the right call for smaller or self-contained estates. Phasing splits a larger estate into waves that each complete and verify inside their window, with the previous wave proven before the next begins. Which one fits depends on the estate, its dependencies and its tolerance for downtime; the discipline around it is the same either way.
04 / The differenceWhat separates a clean migration from an outage
The kit moves the same way for everyone. What decides whether Monday morning is uneventful is the discipline around the move.
- 01
Tested where it counts
Where the risk warrants it, a test migration on non-production devices proves the process, the documentation and the timings, so risks are found on a Tuesday, not on the night.
- 02
Runbook and change control
A device-by-device runbook with assigned ownership, twice-weekly stakeholder meetings and a structured RFC process under a dedicated project manager. Nothing moves that is not written down and approved.
- 03
Transform, do not just lift and shift
A destination designed to decommission excess and reduce footprint, with lower power, lower cost and a cleaner estate, instead of carrying the old mess into a new room.
- 04
Secure, insured, tracked logistics
SC-cleared engineers, computer-specification vehicles, device and vehicle tracking and full goods-in-transit insurance. Your hardware is accounted for every metre of the way.
- 05
Proven hands
Engineers who have done this in live, high-stakes and hyperscale environments, so the unexpected on the night is handled calmly.
- 06
A documented handover
A closure pack with updated rack layouts, patching schedules and test results, loaded into your DCIM, so the new site is better documented than the old one ever was.
05 / The triggersWhen a migration makes sense
Most migrations are forced by a deadline or opened up by an opportunity, and a single migration often delivers several of these at once. Select the drivers behind your move to see how each is met.
Choosing where to land is its own decision: see how to choose a data centre. If you are moving a virtualisation platform rather than physical kit, read VMware to Nutanix.
06 / How Optronix helpsOne accountable partner, audit to handover
We run physical data centre migrations and relocations as a single accountable partner, from audit to handover, across Europe, North America, the Middle East and APAC, built to understand your environment, control the risk and keep the downtime window as short as possible.
Where to land
If the move is about cutting cost, we help you find and compare a cheaper facility, contract or service before you commit, vendor-neutral and against the criteria that matter.
End to end
One partner from site survey to closure pack: audit, design, preparation, test, migration and handover, not a relay of vendors pointing at each other when something slips.
De-risked before it moves
A device-level runbook and RFC change control under a dedicated PM, and where the risk warrants it a test migration, so the cutover windows are uneventful by design.
Transformed, not relocated
A destination design that decommissions excess and reduces footprint, power and cost, so you arrive with a cleaner, denser estate rather than the same sprawl in a new room.
Accountable logistics
SC-cleared engineers, tracked vehicles, full goods-in-transit insurance and ownership of every device in motion, with post-migration support on the other side.
And then we can run it
Once you are live we can keep it running, with managed operations, smart hands and support. One partner for the whole lifecycle.
Related services
Migrations
Tell us what you run and where it needs to go.
We will plan and deliver the migration: audited, dependency-mapped, change-controlled and insured, big-bang or phased to fit the estate.
Sources and notes
- Process and method based on Optronix data centre migration delivery practice: audit, design, preparation, test, review, migrate and handover.
- General industry practice for phased migration, runbooks, RFC change control, test migrations and DCIM handover.
- Related guides: choosing the destination, building it out and platform migration.
General guidance, not a project plan. Every migration differs by estate, dependencies, risk appetite and timeline; scope, sequencing and the achievable downtime window are confirmed per project. The rack animation is illustrative.