The Crisis Case for Platform Consolidation: Doing the Right Thing for the Wrong Reasons
A crisis will fund the consolidation a business case never could — and then tempt you to run it in exactly the way that guarantees it fails.
The line item that finally got approved
There is a particular business case that has been sitting in almost every large IT function for years. It proposes to collapse the tangle of overlapping systems the organisation has accumulated — the three general ledgers, the four customer databases, the six ways of doing substantially the same thing that arrived with as many acquisitions — into something smaller, cheaper and coherent. It is a good case. It has always been a good case. And it has been rejected, or quietly deferred, at every annual planning round, because the payback was long, the risk was real, and there was always something with a faster return to fund instead.
In the past few weeks, in boardrooms that six months ago would not hear of it, that same case has been approved on the nod. The credit markets seized, the cost mandate came down hard, and suddenly the rationalisation that could not be justified in five years of orderly growth is the first thing everyone reaches for in a crisis. This is the strange gift of the present moment, and also its trap. A crisis will fund the consolidation a business case never could — and then tempt you to run it in exactly the way that guarantees it fails.
The estate we built by accident
It is worth being honest about how we got here, because the honesty shapes what we should do about it. No one ever designed the sprawling application estates most large organisations now run. They accreted. Each acquisition brought its own systems, which it was cheaper, this year, to leave running than to integrate. Each urgent project bought its own tactical tool rather than wait for the strategic one. Each business unit, protective of its autonomy, kept its own instance of the thing three other units also ran. The result, across programme after programme, is an estate in which a genuinely large share of the systems duplicate one another, and in which the great majority of the technology budget — commonly two-thirds or more — is consumed simply keeping the accumulated tangle running, leaving only a thin slice for anything new.
This is the condition the crisis has walked into. And it is precisely because the estate is so obviously bloated that consolidation is such an easy sell in a panic. Everyone can see the duplication. Everyone knows the run cost is indefensible. The trouble is that seeing the waste and removing it safely are two entirely different disciplines, and a crisis sharpens the first while starving the second.
Two consolidations that look identical on the slide
Here is the argument I want to make plainly, because it is the whole of the matter. There are two things that both go by the name platform consolidation, and on a cost slide they are indistinguishable. One banks a permanent structural saving. The other books a temporary saving and hands back a larger bill later, with interest. Telling them apart is the single most valuable thing a technology leader can do this year.
The first — call it disciplined consolidation — treats the estate as a capability question. It asks which systems carry which business capabilities, where the genuine duplication lies, what depends on what, and in what sequence things can be safely retired. It decommissions deliberately, migrates data with care, and proves each retirement before booking its saving. It is slower than the panic wants, and it is the only version that actually works.
The second — call it panic consolidation — treats the estate as a list of costs to be struck through. It picks the systems with the largest visible run cost, mandates their removal against a date set by the finance target rather than by the dependencies, and books the saving the moment the line is cut, regardless of whether the capability the system carried has actually been rehomed. It is fast, it reports beautifully, and it is how organisations end up, eighteen months on, quietly rebuilding a capability they paid to destroy.
The difference between the consolidation that saves money and the one that only appears to is not the ambition on the slide. It is whether the saving is booked when the cost is cut or when the capability is proven to have survived the cut.
Where the panic version breaks
The failure is always in the same place, and it is worth naming the mechanism rather than merely warning against it. A system that looks like pure duplication almost never is. The redundant customer database also happens to be the one feeding a regulatory report no one remembered. The legacy platform everyone agreed to kill turns out to hold the only clean copy of a decade of reference data. The overlapping application carries a handful of business rules that were never written down anywhere but in its code. These are not exotic edge cases; they are the ordinary archaeology of any system that has been in production for years. Disciplined consolidation finds them before it pulls the plug, because finding them is the work. Panic consolidation finds them afterwards, in the form of a broken process and an emergency, because the work was skipped to hit the date.
Consider a composite that is entirely typical. An estate of roughly two hundred applications, perhaps a third genuinely redundant, is handed a mandate to cut run cost by a fixed percentage within two quarters. The disciplined path would decommission that redundant third over four or five quarters, proving each retirement, and bank a saving that stays banked. The panic path cuts to the two-quarter date, hits the number on the report, and then spends the following year — and a good deal more than it saved — restoring the three or four capabilities that turned out not to be redundant at all. Both programmes are called platform consolidation. Only one of them actually consolidated anything.
The honest case for doing nothing yet
The strongest objection to everything I have said is not that panic consolidation is bad — few would defend it — but that any consolidation is the wrong move in a cash crisis. The argument deserves its full weight: consolidation programmes are long, they consume capital and scarce senior attention up front, they carry real delivery risk, and they return their savings slowly. In a moment when the priority is survival and liquidity, the case runs, you should defer the whole endeavour, keep the lights on as cheaply as you can, and rationalise from a position of strength once the storm has passed.
I understand the pull of this, and there is a version of it that is simply correct: if an organisation lacks the delivery capability to run a consolidation well, then a badly run one is worse than none, and restraint is the wiser course. But as a general prescription the argument has a flaw. It assumes the storm passing restores the appetite to act, and experience says the opposite. The window in which consolidation is fundable is the window in which the pain is acute enough to override the political resistance that killed the case in every calmer year. Defer now and you do not consolidate later from strength; you return to the old equilibrium in which every business unit again defends its own instance and the case is unfundable once more. The choice is rarely now versus a better later. It is now, disciplined versus never.
How to tell which programme you are running
Because the two consolidations look identical on the slide, a leader needs a small number of hard tests to know which one they have actually authorised. Three questions separate them:
- When is the saving booked? If the plan recognises the saving the moment a system is switched off, you are running the panic version. If it recognises the saving only once the capability is proven to survive elsewhere, you are running the disciplined one.
- Who set the sequence? If the order of retirement follows the size of the run cost, that is finance driving an engineering decision. If it follows the map of dependencies, engineering is in charge, which is where it belongs.
- What happens when a system resists? If the answer to an unexpected dependency is cut anyway, we will deal with it, the programme has already chosen the date over the outcome. If the answer is pause this retirement and resequence, discipline is intact.
None of these tests slows a genuinely well-run programme, because a well-run programme passes them by construction. They only obstruct the version that was going to fail.
The right thing for the wrong reasons
What the crisis offers, then, is a genuine and unusual opportunity: the chance to do a thing that was always right and was never possible to fund. That the reason is panic rather than foresight does not make the opportunity less real. But the same panic that opens the window is what tempts us to climb through it recklessly, and the reckless version does not merely waste the opportunity — it discredits consolidation itself for a decade, because the next time someone proposes it, the organisation will remember the last one as the programme that broke everything to hit a number.
“The downturn hands you the mandate. It does not hand you the discipline. That you still have to supply yourself.”
So take the funding the crisis has finally released, and take it gladly. But run the disciplined programme, not the panic one — book the saving when the capability is proven, sequence by dependency and not by cost, and pause when a system resists rather than breaking it to hit a date. Do the right thing for the wrong reasons, by all means. Just make sure it remains the right thing once you are actually doing it.