COBOL migration
COBOL migration you can prove.
Move COBOL to Java, Python or C# one reviewed piece at a time, with every result checked against how the original program actually behaved.
004180* LATE FEE RULE. DO NOT CHANGE.004190 3200-CALC-INTEREST.004200 COMPUTE WS-DAILY-INT ROUNDED =004210 ACCT-BALANCE * ACCT-RATE / 365004220 ADD WS-DAILY-INT TO ACCT-ACCRUED004230 IF ACCT-DAYS-LATE > 5004240 MOVE 25.00 TO WS-LATE-FEE.
- Written
- 1987
- Last changed
- 2011
- Owner
- none on record
In short
- Montora is a COBOL migration workbench: it translates COBOL into a modern language and checks the result against recorded runs of the original program.
- Every difference is shown field by field, and nothing merges until a person on your team approves it.
- It is built for banks, insurers and other regulated teams, where a rounding difference is an incident, not a bug.
Why COBOL migrations go wrong
Translating COBOL syntax is the easy part. The risk sits in behaviour the syntax hides: fixed-point decimal arithmetic, implicit truncation, record layouts that overlay the same bytes, and control flow that falls from one paragraph into the next.
Code that compiles and reads well can still pay a customer the wrong amount. Our guide to the COBOL semantics that break in Java walks through the usual suspects.
- Packed decimal (COMP-3) and PIC scaling, where Java's double gives the wrong answer
- ROUNDED, ON SIZE ERROR and silent high-order truncation
- REDEFINES, OCCURS DEPENDING ON and group moves
- PERFORM THRU, GO TO and fall-through between paragraphs
- EBCDIC sort order and FILE STATUS codes programs branch on
How Montora migrates COBOL
Montora breaks a COBOL estate into units, scores each for risk and maps what depends on what, so the work runs in dependency order rather than all at once.
Each unit is translated, checked and then replayed: the new code runs against inputs recorded from the original system, and the outputs are compared field by field. A person approves, edits or rejects every change, and the result is sealed in a signed record your risk and audit teams can verify.
- Dependency map and risk score for every unit
- Translation into Java, Python or C# (TypeScript, Go and Rust in early access)
- Static analysis, generated tests and an AI review on every change
- Replay against recorded legacy behaviour, compared field by field
- Human approval on every change, and a signed evidence record
Proof, not promises
A migration is only as good as the evidence behind it. Montora's migration testing replays real recorded runs, flags every divergence with the field and the account it affected, and blocks the merge until someone resolves it.
That turns 'the new system should behave the same' into a record anyone can check.
Who it is for
Teams running COBOL they are afraid to touch: core banking, insurance policy administration, payments, pensions, government benefits and logistics. If the people who wrote it have gone and nobody dares change it, that is the problem Montora is built for.
Questions
Can COBOL be converted to Java automatically?
- The syntax can. The hard part is behaviour: decimal arithmetic, truncation, record layouts and control flow have to come across exactly. Montora automates the translation and then checks behaviour by replaying recorded runs of the original program, with a person approving every change.
Which languages can Montora migrate COBOL to?
- Java, Python and C# today, with TypeScript, Go and Rust in early access.
Do we have to migrate the whole system at once?
- No. Montora works one reviewed piece at a time in dependency order, so you can start with one application or one batch job and expand from there.
Will the migrated code be readable?
- Yes. The output is ordinary Java, Python or C# that your team reviews and edits before it merges, not a black-box runtime.
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.