Guide

How to test a COBOL migration.

A practical, vendor-neutral checklist for proving a migrated system behaves like the one it replaces.

In this guide7 parts
  1. 01Capture representative inputs
  2. 02Decide what you compare
  3. 03Build a golden master or replay suite
  4. 04Add boundary values for numeric fields
  5. 05Measure coverage, and say what it is
  6. 06Finish with a parallel run
  7. 07Keep evidence and sign off

In short

  • Testing is where most COBOL migration effort goes, because the new system has to match the old one exactly, not approximately.
  • A sound approach captures real inputs, compares outputs, files and database state with exact decimals, adds boundary values, measures coverage, and finishes with a parallel run.
  • Every result should be traceable to its inputs and signed off by an accountable person.

1. Capture representative inputs

Start from real behaviour, not specifications. Record the inputs the legacy programs actually receive, including month-end, year-end and rare paths. Production data usually needs masking first; masking must keep formats, lengths, signs and the links between files, or the recording stops being representative.

2. Decide what you compare

Outputs alone are not enough. Decide up front which effects count as behaviour:

  • Returned values and records, compared with exact decimals
  • Files written, including record order
  • Database state after the run (before and after images)
  • Messages, status codes and FILE STATUS handling

3. Build a golden master or replay suite

Store legacy inputs with their expected outputs and re-run them against the new code on every change. Replay-style testing catches a regression at the change that caused it rather than at cutover, which is when it is cheapest to fix.

4. Add boundary values for numeric fields

Recorded traffic rarely covers every edge. For each numeric field, add cases at its maximum digits, at zero, negative values for signed fields, and amounts that round in both directions. These are where COBOL and modern languages disagree most often; see the semantics that break in Java.

5. Measure coverage, and say what it is

A replay proves behaviour only for the paths it exercised. Measure which paragraphs and branches the test data reached, fill the gaps deliberately, and report coverage alongside the pass rate. A 100% match on 40% coverage is a different result from a 100% match on 95%.

6. Finish with a parallel run

Before switching off the legacy system, run old and new side by side on live inputs through at least one period-end and reconcile the results. If every change has already been replayed against recorded behaviour, the parallel run becomes a confirmation rather than the moment you find out.

7. Keep evidence and sign off

Every comparison should be reproducible and tied to its inputs, every override recorded with a reason, and the final decision made by an accountable person. That record is what auditors and regulators ask for. Montora's migration testing is built around this flow.

Questions

What is the best way to test a COBOL migration?

Combine methods: replay or golden-master tests against recorded legacy runs on every change, boundary values for numeric fields, measured coverage, and a parallel run on live inputs before cutover.

Why can't I use floating point to compare COBOL results?

COBOL uses fixed-point decimal arithmetic. Floating point cannot represent many decimal values exactly, so comparisons must use exact decimal types such as Java's BigDecimal or Python's Decimal.

How long should a parallel run last?

Long enough to cover the cycles that matter to the business, typically including at least one period-end such as a month-end or year-end close.

Sources

Keep reading

See it on your own code.

Montora is taking on a small number of design partners: banks, insurers and other teams with COBOL they can't afford to get wrong.