Reverse-Engineering Undocumented Legacy Code: What Static and Dynamic Analysis Can Recover

The short answer

AI can reliably recover what the code states: structure, dependencies, data flows, and business rules that are written down in source, configuration or schemas. Applied to a legacy codebase, that produces a documentation baseline and a map of what the new system must do. AI cannot recover everything. Logic that only emerges when processes run in a particular order (dynamic behavior), rules that live in people's heads or in off-the-shelf systems you do not control, and the reason a rule exists at all all need other evidence.

The practical answer to "can AI reverse engineer legacy business rules" is yes for the static layer, partially for the runtime layer, and no for undocumented intent. A sound discovery phase combines static analysis, dynamic analysis and conversations with the people who still know the business, and it says plainly which parts of the dossier are confirmed and which are inferred.

The archaeology problem

Most legacy systems that reach a modernization decision share a history. The team that built them has moved on. One Sparq leader put the situation in a CTO's words: the people who built the system no longer work there, it was never documented, and so the CTO cannot assure the board that a replacement will reach feature parity with what exists today.

That is the archaeology tax: the time, budget and risk spent digging up business rules that nobody wrote down, paid before and during every modernization. It shows up in four places.

• Estimates. When no one knows what the system does, the estimate has to carry a large contingency. Or it carries none, and the project pays for it later in rework.
• Board confidence. Leaders can describe the value of modernizing and the cost of technical debt. What they cannot describe is the "cost of the unknown", meaning what will break when the old system is replaced.
• Adoption. Rebuild without understanding the old behavior and users notice. Sparq's team pointed to a modernization at one large client where franchise users rejected the new system, which turned the project into a fire drill. The risk of spending a long time building something people reject is the risk discovery is meant to reduce.
• Relevance. Discovery that drags into a long modernization can leave the target outdated before it ships. On one ExtJS to Angular 19 modernization that ran more than 1.5 years, Angular published three new versions along the way, so the upgrade was no longer current at delivery. Technology moved faster than the modernization. Long timelines also carry a running cost. On another engagement, because the modernization took two years, the client paid roughly $100,000 a year to the vendor for extended support of the old stack, since public support had ended for that technology. Every month spent rediscovering undocumented rules adds to that bill and shortens the useful life of the result.

Many organizations fund modernization only when a deadline forces it, such as an end-of-life date or a vendor cliff with six months left. Discovery done under that pressure is rushed. Doing it earlier, and doing it systematically, is the cheapest risk reduction available.

Static analysis: what AI reads from the code

Static analysis examines source code, configuration, database schemas and build files without running the system. AI changes the economics of this work because a model can read very large codebases, summarize them in plain language, and answer questions about them. A 15-year-old application written by an engineer who left a decade ago becomes readable again.

What static analysis recovers

• Structure. Modules, services, layers, entry points and the way components call each other.
• Dependencies. Internal coupling, shared databases, libraries, and integrations with other systems. This matters because, as one Sparq engagement lead described it, in a tangled legacy platform a fix in one place breaks something somewhere else.
• Documented and explicit rules. Validation logic, calculations, thresholds, status transitions and permissions that appear directly in code or configuration.
• Reverse-engineered documentation. Plain-language descriptions of what each part does, so engineers and business owners can review them.

What it produces

For a discovery phase, the useful outputs are an application dossier (a structured description of the system, its components, dependencies and rules), a parity map (a list of current behaviors the new system must reproduce, or consciously retire), and a gap and risk analysis that shows where understanding is thin. Sparq's Blueprint IQ is designed to deliver this kind of output for the discovery phase, ahead of any decision on the modernization path.

Where static analysis stops

Reading code tells you what the code could do. It does not always tell you what happens when the system runs in production.

Dynamic analysis: logic that only appears at runtime

A client of Sparq's raised exactly this objection when the team proposed using AI to document a legacy platform. Their reason for not trusting AI-based documentation was that the logic can only be seen at runtime.

They were pointing at a real distinction. Static analysis reads what is there. Dynamic analysis observes the system executing. Some behavior only exists in the second view:

• A process produces a result, and that result triggers another process, so the actual behavior is a chain that no single file describes.
• The outcome depends on which process is launched, and in what order.
• Behavior depends on data values, configuration state or scheduled jobs that are visible only while the system runs.

To discover that logic, an analyst has to know which exact code to execute and in which sequence, run it with representative inputs, and record what happens. That means test environments, sample or masked data, and people who know the real workflows well enough to design the scenarios.

What dynamic analysis recovers

• Actual execution paths and the order of processing.
• Runtime dependencies and triggered side effects.
• Observed inputs and outputs for important scenarios, which become the basis for parity tests.
• Differences between what the code appears to do and what the system does in practice.

Where it stops

Dynamic analysis only sees the scenarios that someone runs. Paths that are rare, seasonal or never exercised in test stay hidden, so coverage depends on the quality of the scenarios and the data.

How static and dynamic analysis combine in a discovery phase

The two methods answer different questions, and each makes the other more reliable. Static analysis shows where to look. Dynamic analysis confirms what actually happens there. A typical sequence:

1. Scope the system and its boundaries. Identify the codebase, environments, integrations and the people who can answer questions.
2. Run static analysis. Map structure, dependencies and explicit business rules, and generate first-pass documentation.
3. Identify what code alone cannot explain. Flag batch jobs, event chains, configuration-driven behavior and rules that appear to depend on order or data.
4. Design runtime scenarios. Choose which processes to launch, in what order, with what data, drawing on the people who know the business.
5. Run and observe. Capture the results and the processes they trigger, and compare them with the static picture.
6. Validate with the business. Have owners review the rules, resolve conflicts, and record the reason behind rules that exist for regulatory or commercial reasons.
7. Verify against compliance documentation. In highly regulated industries, check the recovered rules against the compliance standards the organization is already held to, which include but not limited to Quality Management System (QMS). For many companies in these industries alignment with these requirements carry compliance risk, so a rule that the legacy code enforces according to QMS should be fully replicated by the modernized system to satisfy compliance certification, or initiate re-assessment instead of a full certification cycle when the logic is changed in its entirety. Record the result in the parity map.
8. Assemble the outputs. Produce the application dossier, the parity map, a list of open uncertainties, and a phased roadmap.

Typical outputs

Sparq's view is that a precise discovery tells you the exact pain points, the exact evidence to collect and the exact uncertainties to resolve first, rather than a long open-ended study. That precision is what allows firmer commitments afterward. It also lets teams tackle the hardest problems early and leave easier work for later.

Limits and failure modes

A discovery that overstates its confidence is worse than none. These are the limits to expect.

• Runtime logic is not automatic. Reading code is the strong point of AI today. Executing the right processes in the right order requires an environment, data and scenario design. Not every tool or engagement covers this layer, so ask whether yours does.
• Intent is not in the code. AI can describe what a rule does. It often cannot tell you why it exists, whether it is still needed, or whether it encodes an old workaround. Business owners must decide what to keep.
• Third-party and off-the-shelf systems are out of reach. Platforms such as an ERP or CRM are controlled by their vendors, may restrict where AI agents can be deployed, and often have their own AI tooling. Analysis of your custom code does not explain how those systems behave. The integration points between the two need separate work.
• Coverage gaps. Dead and/or duplicated code, rarely used paths and seasonal logic can be missed or misread. Treat the output as a hypothesis set to verify, not a certified specification.
• Missing environments and data. If there is no working test environment or safe data, dynamic analysis is limited or impossible.
• Plausible but wrong summaries. Model-generated descriptions can read confidently and still be incorrect. Every important rule needs a source reference in the code and a human reviewer.
• Parity is not the same as improvement. A parity map tells you what the old system did, including behavior that should not be carried forward.
• Discovery does not replace testing. The dossier lowers the risk of building the wrong thing. System integration and regression testing still decide whether the new system is correct, and acceptance testing decides whether it's right.

Checklist: what to ask a vendor claiming AI-driven discovery

1. Does your approach cover static analysis only, or also dynamic analysis at runtime? Which parts are in your product today, and which are planned?
2. How do you decide which processes to execute, and in what order?
3. What do you need from us: environments, data, access, subject matter experts?
4. Can every rule in the output be traced to a source location or an observed runtime result?
5. How do you mark confirmed, inferred and unknown findings?
6. How do you handle third-party and off-the-shelf systems we do not control?
7. What are the deliverables, and can we see a sample dossier and parity map?
8. How do business owners review and approve the rules?
9. How do you make sure that the new platform is still compliant with regulations, and how do you understand when to file for a new compliance assessment?
10. What timeline have you achieved on a comparable system, and can you name the engagement or share a measured range?
11. What does your output tell us about the modernization path before we commit budget?