A data centre exit is not a moving job

The logistics are the easy part. The risk lives in what you find, what you’re not allowed to do, and the judgement calls no tool can make for you.

By Joe Henderson, TXP Head of Application Modernisation.

Ask most people what a data centre exit involves and they’ll describe a moving job. Get everything out of one building and into another, or into the cloud, safely. Cut the old link, done. Plan the lifts, book the window, hold your breath over the weekend.

I’ve spent more than twenty years doing this in banks, insurers and government, and the moving is rarely the hard part. The hard part is everything around it: what you find when you look properly, what the rules won’t let you do, and the decisions no piece of software will make for you. Here’s what I mean.

What the move surfaces

Every estate of any age has applications that have sat quietly behind a firewall for years. Nobody’s touched them because nobody’s had to. They work, they’re out of the way, and they’ve drifted out of everyone’s mind.

Then you run discovery ahead of a migration and the picture changes. Some of those applications haven’t been patched in two years, they’re out of support, there are known vulnerabilities against the exact versions running, and the only thing protecting them has been their obscurity and the firewall sitting in front of them. The move doesn’t create that risk, it reveals it, and it forces you to deal with it, because the moment you touch the network boundary that quiet protection is gone.

Then there’s the software nobody in IT knows about at all. A service the finance team put on a company credit card, a tool marketing bought and quietly built a whole process around. It’s in no asset register and it never came up in any architecture review, but it’s load-bearing for someone, and on cutover weekend it becomes your problem whether you knew about it or not.

In financial services and central government, this isn’t a tidy-up job you can leave for later. It’s a live security and compliance exposure that was invisible until someone went looking. Finding it is the work, the move is the easy bit.

What the rules won’t let you do

The second thing that catches people out is that in regulated environments you often can’t move the way you’d like to.

Picture the data that isn’t allowed anywhere near the public internet. Too sensitive, and the rules genuinely don’t bend. In theory you could stand up an encrypted tunnel between the sites and push it across. In practice you don’t have the time in the outage window to build one and prove it. So the fastest secure route between two data centres turns out to be a physical one: a snapshot, a secure courier, and a very carefully controlled hand-off at the other end. I’ve moved a live system on the back of a truck, escorted, because on that particular day it was genuinely the safest and quickest option available. It works, if you’ve planned every minute of it.

And that’s the real point. The technology choice is almost secondary to the questions around it. When do you take the snapshot? At what exact moment is that system declared unavailable? How small can you make the window it’s down? What is your point of no return, the moment after which rolling back is no longer an option and you’d better be certain?

For an organisation whose services run around the clock and can’t simply go dark overnight, those questions aren’t footnotes. They’re the plan. Get the transition states and the recovery points right and the actual move is almost boring, which is exactly how it should be. Get them wrong and you find out in production, in front of the public.

The bit in the middle nobody enjoys

There’s also a stretch in every migration where the old world and the new world are both live at once. Legacy still serving, target coming up, both real for a period that can run for weeks. It’s the state most plans design for least, because it’s messy and temporary and doesn’t feel like progress.

It’s also where a lot of the operational risk sits. Monitoring has to watch both estates. When something breaks, the first question is which world it even belongs to, and if that isn’t obvious, you’ve got an accountability problem as much as a technical one. Somebody has to own the service while it’s living in two places, and everyone involved has to know who that is. Coexistence isn’t a gap to rush through. It’s a phase to design.

Why none of this is a tooling problem

You’ll have noticed that none of what I’ve described is solved by buying better software.

There are excellent tools, and we use them. Discovery tooling, dependency mapping, and increasingly AI, which is genuinely good at the scenario planning people find too cumbersome to do by hand: generating candidate transition states, stress-testing a cut-over sequence, modelling what happens if step nine fails at two in the morning. I’m all for it, but it accelerates the thinking, it doesn’t replace it. You still need someone who knows whether the answer the model gives back is right, and whether the question was framed correctly in the first place. The expert always stays in the lead.

Because in the end this work is held in people. It’s held in the person who recognises the shape of a problem because they’ve seen it before, who knows which question to ask next when the plan finally meets reality, and who’s prepared to own the outcome rather than just supply the hands.

That’s the difference between a data centre exit that’s almost boring and one that makes the news for the wrong reasons.

The move is the easy bit, everything else is judgement. So be sure to choose the people accordingly.