COBOL Modernisation With AI: What It Cannot Fix

Q: Can AI actually translate COBOL to a modern language?

Yes, and it does that job genuinely well — which is precisely why so many programmes are now failing for the same reasons they always did. Modern models read COBOL competently, understand PERFORM structures and paragraph flow, recognise COPYBOOK layouts, and emit Java, C# or Go that compiles and broadly does the same thing. Work that once justified a large offshore team and eighteen months of effort is now substantially automated, and that is a real change worth acting on. The problem is that translation was never the binding constraint. Mainframe migrations fail because nobody can say which behaviours in the legacy system are intended business policy and which are defects the organisation has quietly adapted to over four decades. They fail because the batch schedule has timing dependencies and manual interventions that exist only in the knowledge of operators. They fail because there is no test suite, so there is no definition of correct other than what the old system currently does. And they fail because the system cannot be switched off for a weekend while you find out. An LLM translating a 12,000-line program produces code that compiles, passes tests you wrote by reading the same COBOL, and faithfully encodes every one of those forty years of accidents — including the ones the migration was supposed to eliminate. You have relocated the problem into a language with a larger hiring pool and discarded the single most valuable property the old system had: decades of production evidence that it behaves acceptably. The teams extracting real value use AI for comprehension — extracting candidate business rules, tracing data lineage, mapping the JCL dependency graph, generating documentation a business analyst can argue with — and treat translation as the final and least interesting step, performed against a specification humans have reviewed.

Q: Why can I not just generate tests from the existing COBOL?

Because tests derived from an implementation assert what the code does rather than what it should do, so they encode the defects as requirements. If a calculation has been rounding the wrong way since 1994, a generated test asserts the wrong rounding and passes. When your new system rounds correctly, that test fails — and the natural organisational reading of a failing test is that the new system is broken. The likely outcome is that someone "fixes" the new system to match the old bug, and you have spent a migration budget faithfully reproducing a defect. This is the same tautology trap that makes AI-generated unit tests unreliable in ordinary codebases, but the consequences are larger here because the legacy behaviour is the only specification anyone has. There is a legitimate version of this technique. Characterisation tests deliberately pin current behaviour as a safety net during refactoring, and they are useful in a migration — but only when everyone understands that they capture behaviour rather than intent, and that discrepancies against them are questions to investigate rather than failures to suppress. The distinction is one of framing and lifetime: a characterisation test is a temporary scaffold with a stated purpose, not the acceptance criteria for the new system. What actually substitutes for the missing test suite is parallel-run reconciliation. Run both systems against the same real production inputs and compare outputs field by field over weeks or months. Every discrepancy is either a bug in the new implementation or an undocumented rule in the old one, and you need to know about both. This is slower and less satisfying than generating a test suite in an afternoon, and it is the mechanism that actually finds the rules nobody remembered.

Q: What is the right sequence for an AI-assisted mainframe migration?

Comprehend, adjudicate, specify, build, reconcile, strangle — in that order, with translation appearing late rather than first. Phase one is comprehension, and this is where AI delivers most of its value. Point it at the codebase to extract candidate business rules, trace data lineage from screen field through program logic to database column, produce call graphs and the JCL batch dependency graph, and summarise each program in language a business analyst can challenge. Weeks of archaeology compress into days, and critically the output is a document a human reviews rather than code that silently ships. Phase two is adjudication, and it is the step most programmes skip. Every extracted rule needs an owner from the business who classifies it as intended policy, obsolete, or a bug the organisation has adapted to. Expect a meaningful proportion to have no living owner; that is itself information, and the correct response is a recorded decision to preserve or drop rather than a silent port. This phase is what converts a migration into a modernisation. Phase three is specification and build: the reviewed rules become written, testable requirements, and the new system is built against those requirements in the target platform idioms — not as a transliteration of COBOL structure into Java syntax, which produces code only a COBOL programmer can maintain. Phase four is parallel run: both systems process real production inputs and outputs are reconciled until every discrepancy is explained. Phase five is incremental cutover behind a facade, one bounded capability at a time, with the mainframe authoritative until each slice is proven. The property that matters across all of it is reversibility — you should be able to stop at any point without stranding the business between two systems.

Q: What are the biggest technical traps in COBOL migration?

Decimal arithmetic, overloaded data fields, and the batch dependency graph — in roughly that order of how expensive they are when missed. COBOL packed decimal, COMP-3, is exact fixed-point arithmetic. If a translation lands on a binary floating-point type, you have introduced rounding error into financial calculations. The failure mode is nasty because it is silent and delayed: discrepancies surface as one-cent reconciliation breaks months later, by which time nobody connects them to the migration. Exact decimal types are mandatory, and this belongs on the review checklist rather than in a style guide. Overloaded fields are the archaeology problem. A COPYBOOK field named FILLER-3 may have meant three different things since 1987 depending on a record type flag defined elsewhere. The layout tells you it is six bytes; nothing in the layout tells you what those bytes mean in each case, and an automated mapping will confidently produce a single wrong interpretation. These need human investigation against real data. The batch dependency graph is where schedule risk hides. JCL tells you which job runs after which, but not that job seven must finish before the 04:00 clearing window, that operators manually rerun step three on the last Friday of the quarter, or that a downstream partner expects a file by a particular hour. Those constraints live in runbooks and in people, and they are not in the source. Three more worth listing: EBCDIC to UTF-8 conversion with its collation and special-character edge cases; VSAM to relational modelling, where the flat file structure often encodes relationships implicitly; and CICS transaction semantics, whose consistency guarantees differ from those of a typical modern service and cannot simply be assumed equivalent.

Q: How long does a parallel run need to be?

Long enough to exercise every cycle the business actually has, which in practice means at least one full quarterly cycle for most financial systems and often a year for anything with annual processing. The principle is straightforward: rules you never exercise are rules you never validate. A month of parallel running covers daily and weekly patterns and will find the majority of discrepancies by volume. It will not touch quarter-end, year-end, statutory reporting, annual interest or dividend calculations, leap-year handling, or the special processing that fires on the last business day of a period — and those are precisely the paths with the most accumulated special-case logic and the least frequent human review. Practical guidance by system type: transactional systems with daily cycles need one to three months. Anything with month-end or quarter-end processing needs to cover at least one full instance of each, with the strong preference being two so you can distinguish a genuine rule from a one-off data condition. Systems with annual processing need a year, or an explicit accepted risk with a documented fallback for the first annual run. Two practices make the wait productive rather than idle. Reconcile automatically and continuously rather than in periodic manual batches, so discrepancies surface in hours and the team stays in a debugging rhythm. And triage every discrepancy to a cause — new-system bug, undocumented old-system rule, or acceptable difference — rather than letting a tolerance threshold absorb them. A parallel run where discrepancies are counted but not explained provides false assurance, which is worse than no parallel run because it justifies a cutover decision on evidence that was never examined.

Q: Should we rewrite, re-platform, or re-host?

They are three different decisions with different risk and value profiles, and the common mistake is choosing on cost per line rather than on what you actually need to change. Re-hosting, sometimes called lift-and-shift, moves the same COBOL onto emulated or cloud infrastructure with minimal code change. It is the lowest risk and fastest option, it removes hardware and licensing dependency, and it buys time. What it does not do is address the underlying problem: the code remains COBOL, the expertise shortage remains, the business rules remain undocumented, and change velocity remains what it was. It is a legitimate first step when the immediate driver is infrastructure risk rather than agility. Re-platforming converts the code to a modern language while preserving structure, often with automated tooling. It is the option most improved by AI, and it is also the one that most reliably produces the outcome nobody wants: 4,000-line procedures and GOTO-shaped control flow rendered in Java, maintainable only by people who understand the original COBOL. If you re-platform, budget explicitly for restructuring afterwards, or you have exchanged one legacy system for another with a better hiring pool. Rewriting rebuilds the capability against reviewed requirements in target-platform idioms. It is the highest cost and highest risk, and the only route that genuinely addresses undocumented rules, poor structure, and change velocity together. The pragmatic answer for most organisations is a hybrid sequenced by business value: re-host to remove immediate infrastructure risk, then rewrite the capabilities where change velocity actually matters, strangling them out one slice at a time while the rest stays where it is. Choosing by capability rather than by system is what makes the programme affordable and reversible.

Q: How much does AI actually reduce the cost of a modernisation programme?

It substantially reduces some phases and does essentially nothing for others, and the ones it does not touch were always the majority of the risk — so treat any headline claim of a large total-programme reduction with scepticism. Genuinely and significantly cheaper: code comprehension and documentation, which was previously slow manual archaeology; business-rule candidate extraction; data lineage tracing; dependency graph construction; test scaffolding; and the mechanical translation itself. These are real savings on real work, and they are why programmes shelved five years ago are worth reassessing now. Essentially unchanged: business-rule adjudication, which requires humans with organisational authority to decide what is policy and what is a bug; parallel-run reconciliation, which is bounded by real business cycles and cannot be compressed by faster tooling; data migration correctness, where the hard part is semantic ambiguity rather than mechanical conversion; cutover risk and the operational choreography around it; regulatory approval and audit evidence; and organisational change, training, and the reality that people must learn a new system while running the old one. Note the pattern: AI compresses the phases involving reading and writing code, and leaves untouched the phases involving deciding, verifying, and coordinating. Since the second group was always where programmes actually failed, the honest framing for a board is that AI improves the odds of success by making comprehension affordable enough to do properly — which is a genuine and important benefit — rather than that it makes the programme dramatically cheaper overall. A vendor quoting a large total reduction on the strength of translation automation is pricing the half that was never the problem.

Q: What if nobody knows why a rule exists?

Treat it as a decision to be made and recorded, never as a detail to be silently ported — because rules with no living owner are disproportionately likely to be load-bearing. There is a survivorship effect at work: rules that were obviously wrong got removed years ago, so what remains without documentation has usually been quietly correct for long enough that everyone stopped thinking about it. The productive sequence starts with investigation rather than a decision. Check version control and change records if any survive; a commit message or change ticket from 1998 sometimes still exists and often names a regulation or an incident. Look for correlation with external events — a rule introduced in a particular quarter frequently maps to a regulatory change or a customer dispute you can identify from other records. Query production data to establish how often the rule actually fires, which separates a genuine edge case from dead code. And ask retirees and long-tenured staff in adjacent functions; the operations team frequently knows why a rule exists even when engineering does not. When investigation genuinely fails, the default should be to preserve the behaviour and document it explicitly as unexplained, with the frequency it fires and the affected population recorded. Preserving an unexplained rule costs you a small amount of complexity in the new system. Removing a load-bearing rule you did not understand costs you a production incident, possibly a regulatory one, and a loss of confidence in the whole programme. Two safeguards make this manageable: implement unexplained rules behind a feature flag so they can be disabled quickly if they later prove obsolete, and maintain the register of them as a deliberate backlog for the business to revisit once the migration is stable — which is a far better outcome than the pre-migration state where nobody knew the rules existed at all.