Why decades of undocumented business knowledge are the biggest obstacle to enterprise transformation
Part 1 of 5: The Executive Guide to AI-Powered Legacy Modernization – An Opteamix series on AI-powered legacy modernization
There’s a scene I’ve watched play out, in some form, with most of the clients I’ve worked with over my 25-plus years.
There’s a farewell party with cake and a card signed by everyone. Someone gives a heartfelt speech about the engineer who spent thirty years at the company, the person everyone called when the batch cycle failed at 2 a.m., the one who remembered why the pricing module had that odd exception for a product line dropped in 2003. When he retires, the company loses more enterprise architecture knowledge that Friday than it has created in the last five years.
If that sounds a bit abstract, think about how it shows up later, as it always does. Every legacy modernization project starts with optimism. The business case gets approved, the target architecture is set, and cloud platforms are reviewed. Meanwhile, engineering teams start talking about microservices, APIs, and AI-assisted development. Then someone asks what seems like a simple question: “Why does this business rule exist?”
Why does the claims system handle one exception differently from another? Why does the payment platform treat a certain customer group differently? Why does a manufacturing process need a series of approvals that no one remembers setting up? In many organizations, the answer is uncomfortable – nobody knows.
The people who knew the answers have left, retired, been moved to other roles, or are long gone after several acquisitions. The documentation was never updated and might not have existed at all. Now, the only source of truth is the code. People often call this a “talent shortage.” I think that misses the real issue. Across corporate America, something more muted and more serious is happening; enterprises are losing their memory. Most modernization efforts fail because they treat this memory loss like a construction problem.
The Code Was Never the Asset
Many leadership teams are surprised to learn that the millions of lines of COBOL, VB6, or legacy Java that run their business are not true assets. These systems are more like vaults, and the real value lies in what they contain. We often call these systems “technical debt,” but that term captures only the cost of the code and overlooks the value they hold. These systems store years of business decisions, unusual situations, and solutions to rare problems that might arise only once every ten years.
Your insurance platform holds underwriting logic developed over generations. Your banking system encodes settlement rules and compliance controls that have evolved over decades of regulatory change. Your manufacturing systems capture workflows refined through years of trial and error on the plant floor.
In many companies, those rules are not written down anywhere, not in a document, not in a wiki, and not even in anyone’s memory, since the people who knew them have left. The irony is that the systems you most want to retire are often the only ones your business still knows how to use.
That knowledge is huge, but almost none of it is organized. McKinsey reports that nearly 70% of the software used by Fortune 500 companies is more than 20 years old. Industry research says that 30 to 50 percent of all modernization work goes into just understanding the legacy code before making any changes.
Read that again – “Enterprises routinely spend half their modernization budget paying people to rediscover what the organization once knew about itself.”
That’s why modernization is more than just a technology project. It’s also about preserving what your company knows. For this reason, the memory problem should be on the executive agenda, not just the CIO’s. When business logic isn’t documented, it’s not just a technical issue; it’s a hidden liability that won’t show up on your balance sheet or in any risk register. This problem grows quietly each year. Every time someone leaves, the gap gets bigger. Every workaround adds to it. Every decision you put off increases the future cost of recovering your company’s memory.
Why the Standard Playbooks Fail
When you view legacy application modernization as a memory problem, it becomes clear why the usual approaches often let people down. There are three main strategies, and most executives have likely tried at least one.
- The Lift-and-shift approach involves moving your existing code to a new infrastructure without looking inside it. This approach is quick and gives the impression of progress. However, the technical debt stays with you, along with a lack of understanding. In the end, you pay cloud prices without really knowing how your business logic works.
- The big-bang rewrite approach discards the old code and tries to rebuild it based on what people remember. While it looks promising on paper, it often leads to budget overruns, delivery risks, and business disruptions. When your systems handle important tasks like moving money, paying claims, or fulfilling orders, relying on people’s memory for continuity is not a real strategy. It is more like guessing.
- The slow incremental rewrite approach at least acknowledges the memory problem, but it does not actually fix it. Each module still requires people to investigate and understand the old code. This process can take years; momentum often fades, and the project may lose support before it delivers real value.
These three approaches are very different, but they share a common flaw: they prioritize technology over understanding. None of them makes recovering the organization’s knowledge the primary goal. They try to rebuild systems but ignore the memory problem.
This is why the cost of understanding has always been the biggest obstacle to modernization. That is beginning to change.
What Actually Changed: We Can Finally Read Our Own Memory
For years, only one thing could read an enterprise’s embedded memory: rare, costly, and aging human expertise. Consider how much that single limitation has shaped your timelines, budgets, and risk tolerance. Every CIO inherits a backlog of stalled projects. It all comes down to one bottleneck: understanding systems took too long and relied on too few people.
Today’s AI technologies, including large language models and agent-based systems, can read millions of lines of legacy code and surface what’s inside, such as business rules, workflows, dependencies, validations, and even missing documentation. It operates at speeds and scales no human team can match. Now, teams can begin modernization with real insight into what their applications do, rather than spending months on manual analysis.
This leads to faster planning, stronger business cases, and much lower risk before any new code is written. This is the real breakthrough of AI for legacy systems, and it’s important to be clear about what that means. AI didn’t make code generation the breakthrough; it made understanding the breakthrough. For the first time, we can speed up how we understand systems, not just how we write code. The real bottleneck for legacy modernization has always been understanding hidden business logic, not code generation.
But precision cuts both ways, so here’s the caution I offer in the same breath: an AI reading your legacy code without expert judgment is a fluent translator with no idea what it’s translating. It will faithfully extract that 2003 pricing exception. Still, AI cannot tell you whether it’s a regulatory requirement, a workaround for a bug fixed in 2011, or a decision the business would never make again. Only your subject-matter experts can. Nothing should reach production on AI’s word alone.
That’s why the operative phrase for this new era is “Human-led, AI-powered”. AI brings the scale to read your systems, but experienced engineers and domain experts bring the judgment to decide what matters and what should stay. This is precisely why we believe the future belongs to human-led, AI-powered modernization rather than AI-only transformation approaches.
How to put that combination to work in a structured, low-risk, five-phase framework we call A • D • A • P • T. That’s what I will try to explain in detail in the next article in this series.
How to Know If You Have a Memory Problem
Five questions to ask your leadership team this quarter:
- The bus-factor test: How many mission-critical systems depend on one or two individuals for deep understanding, and what happens when they retire?
- The documentation test: If a regulator or auditor asked you to explain, end to end, how a core system calculates a price, payment, or claim, could anyone produce that explanation without reading the code?
- The change-velocity test: How long does a “simple” change to a legacy system actually take, and how much of that time is spent figuring out what the system currently does?
- The AI-readiness test: Could your AI initiatives access the business logic and data in these systems today? Or is your AI strategy waiting for systems it can’t read?
- The exit-cost test: If you had to replace a core legacy system tomorrow, how much of the effort would be rediscovery rather than rebuilding?
If two or more of these answers make you uncomfortable, you don’t have a technology problem. You have a memory problem, and it is compounding.
The Forward View: Amnesiac Enterprises Can't Do AI
Let me leave you with one last thought, given the direction things are moving. No matter what kind of enterprise AI strategy you choose, whether it’s intelligent automation, AI-powered workflows, or decision support systems, they all rely on the same basics: your data, your logic, and your processes, all in a format AI can actually use. Legacy systems don’t meet this requirement. Their logic isn’t documented, their data is trapped in closed systems, and their integrations are fragile.
So, the challenge of remembering what your organization knows and the chance to use AI are really the same thing. Companies that recover and put their knowledge back into use will be able to build on it with AI over the next five years. Those that don’t will keep investing in AI projects that never get off the ground.
Your systems still hold everything your organization has forgotten. Now is the time to reclaim that knowledge.
Next in this series → Inside A • D • A • P • T: The Five-Phase Framework for Low-Risk AI-Powered Legacy Modernization. Read how a structured, human-led, AI-powered framework turns memory recovery into a repeatable, low-risk delivery discipline. [Continue to Part 2]
Want a concise overview of how enterprises are modernizing legacy applications with AI?
Download our AI-Powered Legacy Modernization Services Brochure to explore the challenges, business impact, and the A • D • A • P • T framework in more detail.
