A 14-month data centre exit, finished with six weeks to spare.

The situation

Two co-location contracts were expiring within a month of each other. The board had already announced the exit, which meant the deadline was not negotiable and the timeline had been set before anyone confirmed a dependency map existed.

It did not. The estate was documented mostly in the heads of three long-serving engineers, two of whom were within a few years of retirement. There was a CMDB; it had last been reconciled in 2019 and was missing roughly a fifth of the running hosts.

A previous attempt with another provider had produced a migration strategy deck and an eight-figure indicative cost, but no inventory. That is the artefact that matters, and it is the one most often skipped because it is unglamorous and takes three weeks.

What we did

Discovery before anything else

We ran thirty days of network flow capture alongside agent-based discovery, and reconciled the result against the CMDB, the virtualisation inventory and the backup catalogue. Four sources, because each one lies differently.

That produced an application inventory in three weeks and, more importantly, a dependency graph built from observed traffic rather than from recollection. It found forty-one integrations nobody had listed, including a nightly file transfer to a customer that had been running unattended since 2016.

Waves ordered by blast radius

Eleven waves, sequenced by dependency depth and failure consequence rather than by application name. Development and internal tooling first, so the team could make its mistakes where nobody would notice. Core ERP last, by which point the runbook format, the rollback procedure and the cutover command structure had been exercised ten times.

Every production cutover was rehearsed in a matching non-production wave first. The rehearsals found a hard-coded IP address in a warehouse management integration, an expired certificate with no documented renewal path, and a batch job that assumed it was the only thing writing to a shared filesystem.

Two workloads we did not force

Two legacy applications could not be moved economically — one had a licence tied to physical hardware, the other a vendor who had gone out of business. Rather than force a bad rehost, we landed them on a small managed VMware footprint with a defined retirement date. That decision was unpopular at the time and correct in hindsight.

Where it landed

All eleven waves completed six weeks before the first lease expiry. One wave — the customer portal — was rolled back mid-cutover when a database replication lag exceeded the trigger we had agreed in advance. It was re-run successfully nine days later. The rollback took forty minutes because it had been tested.

Infrastructure run-rate fell 31% against the co-location baseline once decommission completed. That figure is measured after decommission deliberately: the number during the migration was worse, because you run both environments, and any provider quoting savings before decommission is quoting a number that has not happened yet.

The customer moved onto our Managed plan at go-live and has not had a P1 in the eight months since.

“The wave plan was the first artefact that made the whole estate feel knowable. After that it was just execution.”

IT Director, national logistics operator

What we would tell the next customer

• Budget three weeks for discovery and do not compress it. Every week saved there costs three later, usually at 2am.
• Rehearse every production cutover. The rehearsal is where you find the things nobody could have told you.
• Agree the rollback trigger before the night. A pre-agreed number removes the 3am debate about whether to push on.
• Track decommission as rigorously as migration. Otherwise you run two estates for a year and the business case never materialises.