# Understand what the legacy system knows before changing it.

A legacy system may contain the most complete record of how a business actually works. Modernization should recover and validate that knowledge before changing the implementation.

Canonical: https://peakroai.com/insights/recovering-legacy-business-rules/
Updated: 2026-10-26


## Begin with a bounded business capability

“Document the legacy system” is usually too broad to guide useful work. Start with a business capability affected by a planned change: calculating a charge, processing a return, applying an entitlement or exchanging data with another system.

Define its boundary, inputs, outputs and owners. Identify the users who rely on it and the consequences of getting it wrong. This creates a manageable discovery task and a reason to distinguish important behavior from incidental implementation detail.

## Collect more than code

Code shows what the current implementation does under particular conditions. It may not explain why an exception exists, whether a workaround is still needed or which behavior the business considers a defect.

Useful evidence includes automated tests, interface contracts, operating procedures, user guides, production incidents and interviews with experienced users. Where permitted, representative data and observed workflows can reveal cases that documentation omits.

Record the source of each finding. A rule supported by a test and a business owner has a different confidence level from a rule inferred from a single branch of unfamiliar code.

## Use AI to organize hypotheses

Agents can help map code paths, summarize behavior, identify duplicated logic and propose candidate requirements. They can also suggest boundary cases and tests that make an inferred rule concrete.

Treat those outputs as hypotheses. Ask for traceable references to the relevant code or documents, and keep uncertain findings visible. A fluent explanation is not proof that the agent has understood the business rule correctly.

Review especially carefully where behavior depends on time, rounding, permissions, external systems or historical data. Small details in those areas can have large effects.

## Separate observed behavior from intended behavior

Bring candidate rules to the people accountable for the business capability. For each one, decide whether to preserve it, change it, retire it or investigate further.

For example, a system may accept an expired entitlement because of an old exception. Discovery should not silently convert that behavior into a permanent requirement. Equally, an unusual exception should not be removed merely because its purpose is unclear to an engineer.

Record the decision and its rationale. The approved requirement becomes the reference for modernization; the old implementation remains evidence, not the sole authority.

## Design validation before replacement

Translate the agreed rules into acceptance criteria and a validation strategy. Include ordinary cases, boundaries and exceptions. Establish how outputs will be compared and which differences are intentional.

Depending on the system, validation may use regression tests, sample-data reconciliation, contract tests or controlled comparison runs. Also plan migration, rollback and operational ownership. A correct replacement still needs a reliable route into use.

## Leave behind a reusable knowledge asset

The discovery should produce more than a report that ages immediately. Keep requirements connected to decisions, tests and the parts of the system they describe. Assign ownership for updating them when future changes occur.

This makes modernization cumulative. Each completed slice reduces dependence on undocumented knowledge and gives the next team a clearer starting point.

[Discuss a modernization opportunity](/services/legacy-modernization/) or [see how requirements remain useful across changes](/methodology/requirements-driven-engineering/).