The Diagnosis Nobody Wants to Sell
Why 99% of AI investment goes to replacing systems that were never understood in the first place.
There's something almost enigmatic about the way enterprises adopt AI.
Billions are being spent. Thousands of projects are in motion. Every consulting firm has a practice. Every vendor has a platform. Every CTO has a slide deck.
And 99% of the effort is pointed in the same direction: adding AI as a layer of automation. Replacing humans. Translating code. Generating from scratch. Building agents that do what people used to do.
Almost nobody is asking the question that should come first.
What if we used AI to understand what we already have — before we rush to replace it?
The sequence that keeps repeating
An organisation runs a platform that works. It has worked for years. Maybe decades. It processes millions of transactions, manages critical workflows, handles batch operations that the business depends on every morning.
The platform isn't glamorous. It doesn't photograph well for annual reports. But it works.
Then someone decides it needs to be modernised.
Not because it stopped working. Because it stopped looking modern.
A project is approved. A consulting firm is engaged. A slide deck is presented with words like transformation, agility, cloud-native, AI-enabled. The budget is approved. The timeline is ambitious.
And the very first thing that happens is: building the replacement.
Not understanding what exists. Not documenting the dependencies. Not mapping the knowledge that lives in the heads of the three people who've operated the system for twenty years. Not testing whether the recovery procedures still work with today's infrastructure.
Building the replacement.
The diagnosis is skipped. Every time.
Why?
This is the part that should trouble anyone who thinks about it carefully. The diagnosis isn't skipped because people are stupid. It's skipped because every force in the ecosystem pushes against it.
The consulting firm doesn't sell diagnosis. It sells transformation. A diagnostic assessment of existing systems is a small engagement — weeks, not years. Low margin. Hard to staff with junior consultants because it requires deep domain expertise. And worst of all, the diagnosis might conclude that the existing system doesn't need replacing — which eliminates the transformation project entirely. No consulting firm has an incentive to sell the engagement that might cancel the larger one.
The vendor doesn't sell improvement. It sells a new platform. Every vendor roadmap points forward: new features, new versions, new architectures. The conversation is always about what you should buy next, not about how to extract more value from what you already own. There's no revenue model for "help the customer realise they don't need to buy anything."
The CEO wants a narrative, not a diagnosis. "We're investing in AI-powered transformation" fits on a board slide. "We spent three months understanding what we have, and it turns out most of it works well — we just needed better documentation and governance" does not. Executive incentives reward visible change, not invisible improvement. A diagnostic that concludes "improve what exists" feels like a non-decision, even when it's the most valuable conclusion possible.
The fear factor is real. When AI is framed as a replacement technology, everyone downstream hears the same message: your job is at risk. This creates a perverse dynamic. The people who best understand the existing systems — the ones whose knowledge is most critical for any intelligent transition — are the least likely to contribute openly to a project that positions itself as their replacement. Knowledge gets hoarded, not shared. Cooperation becomes defensive. And the very expertise needed to make the right decisions goes underground.
The procurement machine can't process it. Enterprise procurement is designed for large, structured engagements with defined deliverables over 12–24 months. A three-week diagnostic assessment by a single senior specialist doesn't fit the template. It's too small for a formal RFP. Too specialised for a framework agreement. Too fast for a steering committee. The system is built for buying big, not buying smart.
These forces don't coordinate. They don't need to. They all push in the same direction independently — towards replacement, towards new, towards transformation. And away from the one thing that should happen first.
What gets lost
When the diagnosis is skipped, the consequences don't appear immediately. They accumulate.
Knowledge walks out the door. The specialists who built and maintained the existing systems are retiring. In every environment I've worked in over the past three decades, the same pattern repeats: three to five people carry 80% of the operational knowledge. That knowledge has never been documented — not because documentation was refused, but because operational knowledge is experiential, contextual, and embedded in decisions made years ago that nobody recorded. When those people leave, the knowledge leaves with them. Permanently.
AI is the first technology in history that could help capture this knowledge at scale — reading code, mapping dependencies, extracting business rules, documenting what exists. But instead of using AI for this urgent preservation work, we're using it to build replacements for the systems whose knowledge we haven't captured yet.
The irony is staggering.
Migrations add instead of replacing. When you don't understand what you have, you can't turn it off. The new platform goes live. The old platform stays. What was supposed to be a migration becomes an addition. Where there was one system, there are now two — or three, or four — each with its own failure modes, support model, and team of consultants trying to understand interfaces between components that were never designed to coexist.
I've watched this pattern consume hundreds of millions of euros across organisations. Not because the technology failed, but because no one diagnosed what needed to migrate, what could be improved in place, and what should simply be left alone.
Single points of failure multiply. Every undocumented dependency is a failure waiting to be discovered. Every business rule embedded in code that no one has analysed is a risk that no test plan covers. Every batch job running without a documented owner is a potential incident that no one will know how to resolve.
These aren't theoretical risks. They materialise at 3 AM, when a critical process fails and the only person who knew how it worked left the company eighteen months ago.
The right sequence
There is a different approach. It's not revolutionary. It's not exciting enough for a conference keynote. But it works.
Step one: diagnose. Before changing anything, understand what exists. Map the dependencies. Document the business rules. Identify the knowledge that lives in people's heads and hasn't been written down. Find the dead processes that consume resources without serving any business function. Classify every component by risk, criticality, and maintainability. This is the work that AI is extraordinary at accelerating — and the work that almost never gets funded.
Step two: improve. Fix what can be fixed without introducing new complexity. Optimise execution paths. Document recovery procedures and verify they actually work. Remove dead code, dead jobs, dead processes. Capture the knowledge of the specialists who are closest to retirement. This alone — without any platform change, without any migration, without any transformation — often delivers more measurable improvement than the first two years of a replacement programme.
Step three: decide. Now — with a complete picture of what exists, what works, what doesn't, and what's at risk — make the decision about what, if anything, needs to be replaced. The diagnosis might reveal that a migration is genuinely necessary. It might reveal that the existing platform, properly maintained and documented, has another decade of life. Or it might reveal a hybrid approach: modernise some components, preserve others, retire the rest.
The point is that the decision is made with evidence, not with slide decks.
Why this matters now
The pressure to act is real. Regulatory requirements like DORA and NIS2 are demanding operational resilience. The specialists who built critical systems are approaching retirement age across every sector. AI capabilities are advancing at a pace that creates genuine urgency.
But urgency without diagnosis is panic. And panic produces expensive mistakes.
The organisations that will navigate this transition successfully are not the ones that move fastest. They're the ones that understand what they have before they decide what to change.
That understanding — that diagnostic capability — is the most valuable and most undervalued service in enterprise IT today. Not because it's technically difficult, but because no one in the ecosystem has an incentive to sell it.
Except, perhaps, the specialists who've spent decades building the systems that everyone else is now rushing to replace.
The next time someone presents you with a transformation programme, ask one question: "What did the diagnostic find?"
If there was no diagnostic, you're not buying transformation. You're buying assumptions.