Batch Twin: parity proof for COBOL that models have migrated

Recording batch inputs, replaying them and diffing outputs is the standard way to prove a mainframe migration works, and the hyperscalers already ship it. AWS has Application Testing and the testing automation in AWS Transform, and Google has Dual Run. Both compare at the record level, read EBCDIC, and support equivalence rules. Integrators such as Astadia and Mechanical Orchard build the same check into their delivery work. A general parity harness would be up against free or bundled features from the companies doing the migrations. What looks open is a neutral harness that doesn't belong to any cloud. It would run on-premises or in a bank's own cloud account, and it would work whatever produced the new code, whether that is Java, C# or Python from an LLM or from rewriting by hand. The buyers would be regional banks and credit unions whose migration targets are Micro Focus/Rocket, Azure or private infrastructure, plus integrators who want an independent pass/fail report that compliance teams, auditors or regulators will accept. AWS and Google can't credibly grade their own migrations. The trap library is less crowded commercially, but open-source tools (verify-cbl, cobol-equiv) and research (IRONPROOF, SEDCoT, IBM's symbolic test generation) are already working on it. On its own it is probably best as a feature that wins customers for the harness, or as a reference dataset, rather than a product. To win, a new entrant would need to cover the hard cases the existing tools skip: REDEFINES, COMP-3 and number fields that get cut off or overflow, sort order and record ordering that differ between EBCDIC and ASCII, the program's own date and time, and VSAM key behaviour. It would also need to produce audit-ready parity reports, and charge per program or per migration so it can sit alongside any integrator.

• AWS Mainframe Modernization Application Testing

  Generally available since June 2024. You capture mainframe datasets and DB2 change journals as a baseline, replay batch jobs on the target, and it labels each record identical, equivalent, different or missing. It handles run-relative dates and lets you write custom equivalence rules. This is very close to the parity harness, but it only works if you are moving onto AWS.

• AWS Transform for mainframe (testing automation)

  Added in December 2025. It generates JCL scripts that collect inputs and outputs from sequential files, VSAM and DB2, plus scripts that run the test cases and check results. AWS pitches it as functional equivalence testing for code it migrated with AI.

• Google Cloud Mainframe Dual Run

  Runs the mainframe and Google Cloud side by side and compares batch outputs. It supports EBCDIC files and DB2 UNLOAD output and reports full match, partial match or missing records. It is tied to Google Cloud.

• Mechanical Orchard

  A funded modernization firm. It uses captured production data as ground truth and checks that the regenerated code behaves the same. It sells this as part of its delivery work, not as a standalone tool.

• vdf.ai

  Offers a verification agent that turns recorded legacy inputs and outputs into tests, then replays them and compares outputs field by field after a COBOL-to-Java migration.

• Astadia

  A migration integrator. It records inputs and outputs for each screen and batch job and replays them on the migrated system, treating any difference as a failure. This is offered as part of its migration services.

• IBM watsonx Code Assistant for Z (testing)

  IBM research that uses symbolic execution to generate COBOL unit tests and turns them into JUnit tests to check that the Java translation behaves the same. It overlaps with the idea of generating edge-case tests.

• Tech4biz differential equivalence verifier

  An early product. It uses an SMT solver to check that COBOL and the migrated Java give the same outputs, and returns a counterexample when they don't. Version 1 only covers arithmetic and branching. It says outright that it does not handle PERFORM loops, file I/O, REDEFINES or string handling.

• verify-cbl (open source)

  Uses Z3 plus Monte Carlo fuzzing to find rounding differences of a cent or so between COBOL and Java financial calculations. It is an early version of the trap library idea, limited to rounding.

• cobol-equiv (open source)

  A differential testing harness with a Python runtime for COBOL number handling (COMP-3, ROUNDED, ON SIZE ERROR), checked byte for byte against GnuCOBOL. It overlaps directly with a COBOL-aware semantics trap catalogue.

• IRONPROOF and SEDCoT (research)

  Two 2026 papers on checking COBOL translations. IRONPROOF uses SMT and finds that values getting cut off when stored into a field are the most common source of mismatches. SEDCoT (arXiv 2607.04092) uses GnuCOBOL as the reference across 500 changed inputs per program and found that no LLM-translated program passed every test. Academic groups are actively building the trap catalogue idea.

Checked 2026-10-20