Migration testing
Migration testing that shows its working.
Replay recorded legacy runs against the new code, compare every field, and keep the evidence.
In short
- Migration testing checks that a modernised system produces the same results as the legacy system it replaces, also called functional equivalence testing.
- Montora records real inputs and outputs from the legacy system, replays them against the migrated code and compares the results field by field.
- Divergences are flagged with the field and record they affected, and the merge is blocked until a person resolves them.
What functional equivalence testing means
Functional equivalence means that, for the same inputs, the new system produces the same outputs and side effects as the old one: the same values, written in the same order, leaving the same state behind.
For COBOL this is stricter than it sounds. A one-penny rounding difference on a single account is a failed migration in a bank.
Golden master, parallel run and replay
There are three common ways to test a migration, and serious programmes use more than one. Our guide on how to test a COBOL migration goes deeper.
- Golden master: capture outputs from the legacy system for a fixed set of inputs, then check the new code reproduces them.
- Parallel run: run old and new side by side on live traffic, often through a period-end, and reconcile the results.
- Replay: record real legacy runs and re-run them against each migrated change during development, so problems surface long before cutover.
How Montora replay works
Montora records the inputs and outputs of the legacy program, replays the same inputs against the migrated code, and compares results field by field using exact decimal arithmetic.
Each divergence is attributed: which field, which record, and whether it comes from the migration or from the reference itself. The result is signed, so it can be verified later without trusting the run.
- Recorded legacy runs as the source of truth
- Field-by-field comparison with exact decimals, not floating point
- Divergences flagged and attributed, then routed to a reviewer
- Signed, reproducible results tied to their exact inputs
- Merge blocked until critical divergences are resolved
Coverage on the record, not silent green ticks
A replay is only as strong as the runs it replays, so Montora reports exactly what each one covered alongside what it found, and adds boundary values for every numeric field to close the gaps. You always know how much of the system the evidence speaks for.
A parallel run is still the last step before cutover. With replay checking every change for months beforehand, it confirms what you already know instead of discovering problems at the most expensive moment.
From evidence to sign-off
Every change ends at a person: approve, edit or reject, with any override recorded with a reason. The evidence trail is what a risk committee, auditor or regulator asks for when they want to know how you know the new system is right.
Questions
What is functional equivalence testing?
- Functional equivalence testing checks that a migrated system produces the same outputs and side effects as the original system for the same inputs. In COBOL migrations it must match exact decimal values, record order and final state.
What is a parallel run in a mainframe migration?
- A parallel run operates the legacy system and the new system side by side on the same live inputs, usually across at least one period-end, and reconciles their results before the old system is switched off.
Does replay replace a parallel run?
- No. Replay checks every change during development against recorded legacy behaviour, so problems are caught early. A parallel run is still the final check on live traffic before cutover.
How do you test COBOL rounding in a migration?
- Compare outputs with exact decimal arithmetic, never floating point, and include boundary values for each numeric field: maximum digits, negative values, and amounts that round in both directions.
Related
Bring one system. We'll show you the proof.
Montora is taking on a small number of design partners: banks, insurers and other teams with COBOL they can't afford to get wrong.