“AI will rewrite COBOL.” The slogan has been circulating for a couple of years and, like all slogans, it is half true. The core systems of banks and insurers still rest on z/OS applications written decades ago — PL/I, COBOL CICS, ASSEMBLER — and the two classic approaches to modernisation both have a well-known flaw. Manual rewriting is slow, expensive and dependent on skills that are heading into retirement. Automatic transpilation produces what is jargonically called “Java that speaks COBOL”: code that is formally modern and substantially unmaintainable.

Lately a third way to fail has been added, a subtler one: handing the sources to a language model and expecting a system to come out. It does not work, but not for the reason one might think. The model does write the code, and often writes it well. The problem is everything that comes afterwards.

Verification is the real bottleneck

Generating code with AI has become fast and cheap. Verifying it has not. In a portfolio of hundreds of banking programs, if every migrated program requires a full human review, AI has not changed the economics of the project: it has merely shifted the cost from writing to reading.

That is why a serious method invests more in verification than in generation. In our approach, every migrated program goes through a chain of automated gates: it compiles in the target stack, complies with the standards under static analysis, passes the generated tests with coverage thresholds, and — the decisive gate — produces the same outputs as the original program for the same inputs. For online programs, the consistency of the video maps and full coverage of the transaction catalogue are added.

The conceptual point is this: migrated code is not judged, it is compared. Functional equivalence with the existing system is not the opinion of the reviewer, it is measured evidence. Human review remains, but it intervenes by exception — high-complexity programs, failed gates — and this changes the time per program by an order of magnitude. It is the automated QA, not the model, that is the throughput multiplier.

The question to ask before writing a single line

There is a single question that weighs more than any other in a feasibility assessment: how standardised is this codebase?

Almost every large mainframe installation has internal libraries, built up over the years, that standardise data access and transaction handling. When they exist and are pervasive, the apparent idiosyncrasy of hundreds of programs reveals itself for what it is: a finite number of repeated patterns. And a pattern-driven migration is a radically different problem — in risk, time and cost — from a program-by-program architectural redesign.

The study phase serves precisely to measure this coverage, layer by layer: data access, screen flow, transaction orchestration. It is work done before committing to any number, because everything else depends on that answer.

Knowledge goes into conventions, not into heads

Once the patterns are identified, the temptation is to document them and entrust them to the team’s experience. We do something different: we codify them into parametric conventions that the pipeline consumes. All context-specific knowledge — the client’s standards, their libraries, the technology mappings — lives in configuration files; the pipeline that applies them stays identical from one client to the next.

The practical consequences are three. Quality variance between programs collapses, because the translation is not reinvented each time. The process scales horizontally: more AI instances in parallel on the same patterns, on separate streams for batch and online. And the know-how accumulates in a reusable artefact instead of dispersing at the end of the project.

Legacy bugs are a deliverable

A valuable side effect of systematic reverse engineering: the latent bugs of the original code surface. Out-of-bounds array accesses, swapped fields, critical lines commented out fifteen years ago and never touched again. Systems that “have always worked” also work thanks to errors that everything downstream has adapted to.

That is why every anomaly found enters a formal inventory, and for each one an explicit decision is taken: preserve the behaviour or fix it. The decision is then propagated consistently across migrated code, test scenarios and documentation. It looks like bureaucracy; it is what prevents acceptance testing from discovering “mysterious” divergences between old and new.

Honesty about scope is part of the method

A final lesson, the least technical one. In banking, the production release belongs to the client’s processes and responsibilities: the honest contractual boundary for a migration is acceptance testing, not go-live. Likewise, a serious study phase may conclude that parts of the portfolio are not worth migrating at all. A method that promises everything, in this domain, is promising badly.

---

The full principles of the method — the agent pipeline, the six QA gates, the convention-based approach — are described in detail in the public modernLegacy repository. The implementation is proprietary, but we are happy to talk about the method: if you have a legacy portfolio and you are asking yourself “where to start”, the short answer is: from an assessment of your internal libraries. For the long one, contact us.