How AI Recovers Decades of Business Logic Hidden Inside Legacy Applications

By Sudha Devdas, Director of Technology, Opteamix 

In the first two articles of this series, our Chief Success Officer, Yashasvi Raykar, argued that legacy modernization is fundamentally a memory problem, not a technology problem [Part 1], and outlined A•D•A•P•T, the five-phase framework that Opteamix leverages to solve it [Part 2]. In both articles, he highlighted one phase as the heart of the approach: Decode, where AI reads your legacy code and recovers the business logic within it. My job in this article is to outline that phase in detail and show how it works.

Here’s the paradox at the center of it. The oldest systems in your organization are often the least understood, yet they remain the most trusted. They process millions of transactions, calculate premiums, settle positions, and run the business every day with remarkable reliability. Ask someone why a calculation works the way it does or where a rule is implemented, and the answers are surprisingly hard to find.

That’s the question I hear most often from engineering directors and architects when we present this capability: “I’ve seen AI write a to-do app. I’ve also seen our four-million-line COBOL estate. Are you seriously telling me the first can read the second?”

It’s the right question. The honest answer is yes, with important qualifications, and those qualifications are exactly where the engineering happens. So let’s walk through what AI can genuinely extract, how it works in practice, where it falls short, and why human validation isn’t a compliance checkbox but a structural part of the method.

The Knowledge Trapped Inside Aging Code

If legacy code were readable, the memory problem wouldn’t exist. Anyone who has worked in these systems knows why they aren’t. Business logic in legacy applications rarely lives in one tidy place with a comment above it. It’s distributed: validation here, a calculation in a shared routine there, an exception handled three layers away in a batch job that runs at midnight. Decades of maintenance have layered fix upon fix. Naming conventions drifted with each generation of developers. Dead code sits beside critical code, with nothing to tell you which is which. And the design intent, the “why” behind the “what,” was never written down at all.

That’s because these applications aren’t valuable for the language they were written in. They’re valuable because they encode thousands of business decisions accumulated over decades: lending policies and settlement rules in a banking platform, underwriting and claims logic in an insurance system, quality controls and supplier exceptions in a manufacturing plant. Most of that was never formally documented, and the software became the record.

A single transaction can pass through dozens of programs, invoke multiple databases, and apply different rules depending on customer type, geography, or jurisdiction. No individual developer holds all of it in their head, and in many organizations, no one ever has. That’s why understanding has historically consumed 30 to 50 percent of modernization effort. It isn’t the bottleneck because generating software is hard; it’s the bottleneck because understanding what already exists is hard. That’s the problem AI is now positioned to address.

What AI Actually Does With Legacy Code

When people hear “AI reads your code,” many picture a chatbot summarizing files one by one. That’s not what happens in a serious extraction effort. In the Decode phase, AI is systematically applied across the codebase to build layers of understanding:

• Structural analysis – Mapping the codebase itself: programs, modules, jobs, screens, data structures, and the dependencies among them. This produces the connective map no one has maintained, including unknown connections.
• Business rule extraction – Identifying the conditional logic, calculations, and validations that represent real business decisions: how a premium is calculated, when a claim routes for manual review, and why an order is held. Each rule is captured in plain language, not code.
• Workflow reconstruction – Assembling individual rules into end-to-end processes so you can see how a transaction actually moves through the system, including the paths that trigger only on exceptions.
• Documentation generation – Producing the artifacts that never existed: rule catalogs, process descriptions, data definitions, and interface documentation, each traceable to the source code it came from.

Take loan approval, for example. To a customer, it feels like a single, seamless request. Under the hood, it may involve customer validation across multiple databases, a credit check with an external service, lending- policy eligibility rules, risk calculations, regulatory checks, a pricing engine, and an approval workflow that routes differently based on loan value and geography. These components were built by different teams, on different technologies, over several decades. AI reconstructs how that information actually flows and where the real decisions are made, not just which function calls which.

Two practical notes on how we run this. First, it works across the legacy landscape you’d expect: mainframe environments like COBOL, RPG, and PL/I; client-server platforms like VB6, PowerBuilder, Delphi, and Oracle Forms; and legacy web stacks like Classic ASP, older .NET Framework, and J2EE. The techniques adapt; the approach holds. Second, we don’t rely on a single AI model for everything. Different models have different strengths, so we apply the right model to each task in the pipeline to optimize for accuracy, speed, and cost. Treating model selection as an engineering decision, not a matter of brand loyalty, is part of what separates a production-grade extraction from a demo.

From Extraction to Evidence: The Traceability Requirement

Here’s a rule we hold ourselves to, and one I’d encourage you to demand from anyone doing this work: every extracted rule must be traceable to the exact source code it came from.

This matters for a reason that becomes obvious the first time a stakeholder challenges a finding. When your compliance team asks, “Where does it say we do that?”, an extracted rule with no source reference is an opinion. The same rule, linked to the specific program and logic it was derived from, is evidence. Traceability is what makes recovered knowledge auditable, reviewable, and trustworthy enough to build a modernization on. It also means your subject-matter experts don’t have to take the AI’s word for anything; they can inspect exactly what the finding is based on.

Reading Isn’t Understanding: Where Humans Are Structural

Understanding software requires answering two questions. The first is what the application does, and modern AI has become genuinely good at answering it. The second is why it does it, and whether it still requires human judgment. That distinction is where vendors tend to go quiet, and it’s where we design explicitly for three failure modes.

• AI can misread. Language models can misinterpret convoluted logic or, worse, state a plausible- sounding rule that doesn’t quite match the code. In a business rule, “not quite” can mean a mispriced product or a misrouted claim
• AI reads implementation, not intent. The model can accurately tell you that the system applies a special discount path to a specific customer category. It cannot tell you whether that path is a contractual obligation, a regulatory requirement, or a workaround from 2009 that should have been removed years ago.
• AI can’t decide what deserves to survive. Extraction tells you what the system does. It cannot tell you what the modernized system should do. Separating the business’s real requirements from decades of accumulated behavior is a human task.

None of these limitations argues against using AI. They argue for a method in which AI does the reading at scale, and humans do the judging with context. In practice, that means three roles working together on every finding:

• AI extracts: It examines source code, execution paths, schemas, batch jobs, and interfaces to surface candidate rules, workflows, and dependencies consistently across the entire landscape, not module by module.
• Engineers interpret: Engineers validate technical accuracy, distinguish intentional design from historical accident, and synthesize thousands of technical observations into a coherent architecture.
• Subject-matter experts validate: SMEs determine whether a rule still reflects current policy, complies with a regulation, or is a workaround that was never removed, and classify it as: keep, change, or retire.

That’s the working definition of human-led, AI-powered, and it’s why validation checkpoints are built into Decode rather than bolted on afterward. Functional equivalence is later proven by testing, not asserted by the model.

What the Process Looks Like in Practice

For the technical leaders who want the operational picture, a Decode engagement operates as a disciplined loop rather than a single pass:

• Ingest and map. The codebase is inventoried and structurally analyzed, and dependency and data-flow maps are produced.
• Extract. AI extracts candidate business rules, workflows, and validations, each linked to its source.
• Validate. Engineers verify technical accuracy against the code; your SMEs review business meaning and classify each rule.
• Document. Validated rules become structured, traceable requirements and living documentation, the foundation for everything A•D•A•P•T does next.

We’ve watched this loop play out on a 25-year-old order management platform for a retailer, where AI surfaced dozens of pricing rules, promotion exceptions, and fulfillment workflows in days rather than months. But discovery was only half the story: engineers found that several order-routing paths, introduced years apart after separate acquisitions, did nearly the same things and could be consolidated. SMEs identified customer-specific discount rules tied to loyalty programs the company had retired years earlier. The tax and compliance team confirmed that other controls such as sales tax handling and regulated-product restrictions that looked similar were still mandatory and had to be preserved exactly. AI found what existed. People decided what deserved to continue.

Why This Matters Even Before You Modernize

Here’s the point I’d underline for any engineering director weighing this: the output of Decode is valuable even if you never modernize a single line.

Think about what most enterprises pay today in what I call the “knowledge tax.” A regulator asks why a calculation exists, and someone searches for documentation that may not exist. A production issue hits, and engineers spend days tracing execution paths by hand. A new developer joins and spends months learning systems built over decades. Each of those is the organization re-paying for knowledge it already owns but can’t access.

Documented, validated, source-traceable business logic breaks the cycle. It reduces key-person risk, shortens onboarding, accelerates audits, and provides a map for every future change, regardless of whether a modernization program follows. It’s also the foundation for the next wave of enterprise AI: copilots, automation, and knowledge graphs perform better against validated business rules than against fragmented documentation. Several organizations begin here for exactly that reason. Recovery first; transformation when ready.

The Questions to Take Back to Your Team

If you’re evaluating AI-powered extraction, from us or anyone else, here are the questions I’d ask in your position:

• Can every extracted rule be traced to its source code (program, logic, etc.)?
• Can the AI explain how it concluded, or is it a black box?
• Who validates the findings: engineers for technical accuracy, SMEs for business meaning, and at what points in the process?
• How is obsolete logic identified, so you’re not faithfully rebuilding a workaround from 2009?
• How is functional equivalence proven: by testing against real behavior, or asserted?

The answers will tell you quickly whether you’re looking at a proven methodology or marketing collateral.

Closing Thoughts

Understanding your legacy systems is only half the journey. Recovering business knowledge gives you clarity; what you do with it (what to preserve, what to simplify, and what to retire) determines whether modernization creates lasting value. That’s engineering and business judgment, not a technology question, and it’s exactly where AI, done right, should be accelerating your people rather than replacing them.

Want to see what’s inside your legacy applications?

A Business Logic Discovery Workshop guides your team through the extraction approach in your actual environment: what can be recovered, how validation works, and what the documented output looks like.