LegacyLens

LegacyLens addresses a common challenge in legacy software modernization: translating an existing COBOL system into a modern language without accidentally changing the business behavior that the original system has accumulated over time. Legacy COBOL programs can contain important rules that are not obvious from a simple code translation. In this prototype, the legacy batch program processes fixed-width records, uses a specific decimal representation, performs weighted-average calculations with rounding, relies on control-break processing, preserves input ordering, and produces fixed-width historical and alert outputs. Runtime-specific details can also affect the observable output. Missing any of these contracts can produce a modern implementation that looks correct but behaves differently from the original system. LegacyLens uses a behavior-first modernization workflow. First, the legacy COBOL program is analyzed to identify its business rules, input/output contracts, data flow, and compatibility risks. A modern Python implementation is then created as a set of testable components for parsing, cost calculation, historical output, expiration processing, and batch orchestration. Both implementations are executed with equivalent deterministic inputs, and their observable outputs are compared automatically. The prototype uses an actual COBOL batch program as its behavioral baseline. The canonical fixture contains 10 cost records for five products and expiration records for three products. The modernization is also validated with a deterministic larger dataset containing 500 products, 54,088 cost records, and 250 expiration records. The validation suite contains 59 passing tests and includes byte-for-byte comparison of the legacy and modern output files. The target users are developers and teams responsible for maintaining or modernizing legacy batch systems, especially systems where undocumented behavior, data formats, and compatibility details make migration risky. A developer can inspect the legacy program, review the extracted behavior, run the modernization, and use the automated equivalence tests to verify whether the modern implementation preserves the original observable behavior. The creative aspect of LegacyLens is its emphasis on verification rather than direct translation. The project treats observable legacy behavior as the contract that the modern implementation must satisfy. This makes modernization measurable: instead of assuming that translated code is equivalent, the system executes both versions and checks the results. The result is a working prototype that demonstrates a practical path from legacy COBOL to modern Python while keeping the original behavior as the reference point. The prototype is intentionally focused on one concrete modernization workflow rather than attempting to replace an entire enterprise platform. Its purpose is to show how a team can make legacy behavior explicit, create a modern implementation, and continuously test that the migration has not introduced behavioral regressions. This approach is especially relevant when documentation is incomplete and the most reliable specification is the behavior of the running legacy system. LegacyLens therefore connects legacy understanding, modernization, execution, and verification in one repeatable workflow. The same validation principle can be extended to additional legacy programs and larger datasets. The project is presented as a prototype and does not claim to automate every aspect of enterprise migration. Instead, it demonstrates a concrete, reproducible method for reducing uncertainty and making behavioral compatibility visible during modernization work.