The Data Centre Exit and the Myth of Someone Else’s Problem
The exit transfers the racks; it does not transfer the accountability, the architecture, or the judgement.
The morning the racks went quiet
There is a particular silence that settles over a machine room once the last workload has been cut across. The cooling spins down, the amber lights stop their blinking, and a hall that drew a serious share of the whole site’s power becomes, almost overnight, an expensive empty room. The programme board records it as a milestone: primary data centre exited, on plan. For the people who ran that room, the moment is meant to feel like release. More often, it is the beginning of a problem they have not yet learned to name.
We have spent the past two or three years telling ourselves a comfortable story about that room. The story runs like this: infrastructure is undifferentiated heavy lifting — racks, power, cooling, the three-in-the-morning call-outs — and the sensible thing is to hand it to a provider who does it at a scale we could never reach, then get on with the work that actually distinguishes us. Put the estate in someone else’s building, or better still onto someone else’s balance sheet, and infrastructure becomes, in the phrase that has quietly hardened into policy in more than one boardroom this year, someone else’s problem.
I want to argue that this phrase is the single most expensive assumption in the current transformation business case. Not because the move to public cloud is wrong — in most cases it is right, and overdue — but because “someone else’s problem” describes what happens to the cost and almost nothing of what happens to the responsibility. The exit transfers the racks; it does not transfer the accountability, the architecture, or the judgement. Organisations that grasped that distinction are, as this year closes, quietly pulling ahead. Those that did not are discovering their savings on a slide and their overspend on an invoice.
What the business case promised
The business case for leaving is, on paper, one of the cleanest a transformation director will ever sign. It usually carries three numbers and a mood. The first number is capital avoided: the refresh that falls due when a data hall reaches the end of its life, the seven-figure cheque for new storage and network kit that nobody enjoys signing. The second is the run cost removed: the power, the cooling, the facilities contract, the maintenance renewals, the small standing army of people whose working lives are the estate. The third is a softer figure dressed as a hard one — agility — the promise that teams which once waited eleven weeks for a server will, in the new world, stand one up before lunch.
The mood is relief. For a decade the data centre has been the part of the balance sheet that only ever grew, the cost that could be deferred but never removed, the 2 a.m. risk that sat under every board pack without ever quite making it onto one. The chance to be rid of it feels less like a technology decision and more like a liberation. And that mood, not the arithmetic, is where the trouble starts — because relief is a poor auditor.
The strongest version of the case for leaving
Let me put the case for exit at its strongest, because it deserves that respect and because the weak version is too easy to knock down.
The economics of hyperscale are not marketing. A large provider runs its fleet at a utilisation the average enterprise data centre never approaches; our own halls have long sat at fifteen or twenty per cent of capacity because we sized them for a peak that arrives twice a year. The provider buys power, land and silicon at a scale that bends the unit cost in a direction we simply cannot follow. Turning capital expenditure into a metered operating cost is genuinely valuable to a finance function that would rather not tie up cash in depreciating tin. And the security argument, which sceptics still wave away, has quietly inverted: the leading providers now spend more on protecting their platforms in a quarter than most of our organisations will spend on security in a decade, and they employ specialists we could never recruit or retain. When someone says the estate is undifferentiated and should be handed to those who do it best, they are, at that level, correct.
The case for leaving the data centre is strong on its own terms. The error is not in accepting it — it is in believing that accepting it settles the matter, when in truth it only changes the shape of the work that remains.
So this is not an argument for staying. It is an argument about what the word “someone” is quietly asked to carry — and about everything the business case leaves out because relief did the sums.
Where the responsibility refused to move
Here is the pattern that recurs, almost without variation, across organisations that have made the move. What leaves the building is precisely the part that was already commoditised. What stays behind is everything that required judgement — and the leaving does not make it any easier.
| What the exit actually transferred | What stayed exactly where it was |
|---|---|
| The racks, the power draw, the cooling, the facilities contract | Accountability to the regulator and the board for availability and data |
| The refresh cheque and the depreciation schedule | The architecture — what runs where, and why |
| The night-shift call-out to swap a failed disk | The decision about what is worth re-engineering and what is merely moved |
| The provider’s platform security | The security of everything you build and configure on top of it |
Consider a composite that is true to life. A mid-sized general insurer sets out to exit its two data centres. The case is sound: around £6.4m a year in combined run cost, a projected thirty per cent reduction, and a £3m hardware refresh avoided. The board approves it in an afternoon. The delivery team, under pressure to hit the exit milestone rather than the savings, does the pragmatic thing and lifts the estate across broadly as it stands. Virtual machines are sized to match the physical servers they replaced — servers that were themselves specified for a decade of headroom. Everything runs on demand, because reserving capacity requires a forecast nobody has had time to build. Data replicated between regions for resilience quietly starts drawing a charge for every gigabyte that crosses. And a long tail of some forty systems — a mainframe interface, a licence tethered to specific hardware, three applications whose original vendors have vanished — cannot move at all, so one of the two data centres stays open on a short, humiliatingly expensive lease.
The year-one run cost lands near £5.8m. That is a nine per cent reduction, not thirty. The saving is real, but it arrives eighteen months late and only after a right-sizing and reservation programme that nobody had scoped, staffed or funded — the very engineering discipline the phrase “someone else’s problem” had assumed away. I have watched more than one capable team live exactly this sequence, and the lesson each drew was the same: the money was never in the moving. It was in the re-engineering that the moving was supposed to make unnecessary, and never did.
“Lift-and-shift moves your inefficiency to a place where it is metered by the hour.”
Then there is the part of the responsibility that no invoice captures. This year of all years has made it plain. The old Safe Harbour arrangement for moving personal data across the Atlantic was struck down just over a year ago; its replacement is new, contested, and trusted by nobody’s legal team without a caveat. The June referendum has opened a question, unanswerable for now, about where the United Kingdom will stand on data adequacy once it leaves. And the new European data protection regulation, adopted this spring, is already casting its shadow forward to the compliance deadline everyone can see coming. Put those together and “where does the workload physically run” stops being a facilities detail and becomes a board-level question about jurisdiction, residency and lawful transfer. That question did not leave with the racks. If anything, handing the estate to a provider with regions scattered across the map made it sharper, because now the location of your data is a configuration choice your engineers make on a Tuesday — and a choice your regulator is entitled to ask about.
Why the assumption persists
If the flaw in “someone else’s problem” is this visible in hindsight, why does the assumption keep being made? Three forces sustain it, and they are structural rather than foolish.
- The exit is framed as a property decision, not an engineering one. When the driving logic is vacating buildings and shedding facilities cost, the programme naturally lands with those who think in leases and square footage. The people who understand what actually runs in the hall — and what it would take to run it well somewhere else — are consulted late, as implementers rather than as authors. The architecture question is never asked at the altitude where it could still change the plan.
- The incentive rewards the milestone, not the run-rate. The exit is a date on a plan; the overspend is a slow leak discovered two budget cycles later, often by different people. A programme is celebrated and closed the moment the last workload lands, long before anyone can see whether the promised economics materialised. We reward the move and rarely audit the arrival.
- The phrase is genuinely seductive. “Someone else’s problem” offers a tired organisation permission to stop worrying about something it has worried about for years. That is a powerful thing to offer, and powerful things are rarely examined closely. The relief is real; it is simply not the same as the responsibility being gone.
None of these is a failure of intelligence. They are what happens when a decision with deep engineering consequences is owned by a part of the organisation that reasonably thinks in different terms — and when the reward structure closes the book before the story has finished.
Moving on, not merely moving out
The distinction I would press on any leader facing this decision is between moving out of the data centre and moving on from it. The first is a logistics exercise with a date. The second is an operating-model change with no fixed end, and it is the only one that pays.
Moving on means owning the architecture as a first-class decision rather than a consequence of the move. Every workload deserves a deliberate verdict — re-engineer it to work with the grain of the platform, move it as-is with eyes open and a dated plan to fix it later, or retire it honestly rather than paying to host a system nobody should still be running. The lift-and-shift default is not wrong as a tactic; it is only dangerous as a destination.
Moving on means putting cloud financial governance in place before the first workload lands, not eighteen months after the invoices start to sting. Someone must own the run-rate the way a facilities manager once owned the power bill — watching utilisation, matching commitment to demand, treating an idle over-provisioned instance as the waste it is. The meter never sleeps, and in a metered world, financial discipline is an engineering discipline.
And moving on means keeping the accountability firmly on your own side of the contract. The provider is responsible for the resilience and security of the platform; you remain wholly responsible for what you build and configure on it, and for where your data comes to rest. The board cannot outsource its answer to the regulator, and the regulator has shown no sign of accepting that it can.
The organisations that will look prescient in a few years are not the ones that left the data centre fastest. They are the ones that treated the exit as the beginning of an engineering commitment rather than the end of one — and never let themselves believe the responsibility had gone to live in someone else’s building.
The empty machine room is a genuine achievement, and the silence in it is earned. But it is worth being clear-eyed about what that silence means. It is not the sound of a problem solved. It is the sound of a problem changing address — and keeping your name on the door.