Case Studies · BraivIQ AI Engineering Playbook

The Mainframe Problem: What A Bank's Dev Team Must Learn To Modernise COBOL With AI Agents - Without A TSB-Style Meltdown

Behind the sleek apps of most banks and trading firms sits a fact the industry does not advertise: the ledgers, settlement and core processing still run on decades-old COBOL on mainframes, maintained by a shrinking pool of specialists, expensive to license and nearly impossible to change quickly. For thirty years modernisation was too risky to attempt at scale. In 2026 AI coding agents changed the calculus - Morgan Stanley has modernised more than 17 million lines of COBOL, Natural and Perl using an in-house generative-AI platform, saving developers over a million hours, and tools like IBM watsonx Code Assistant for Z and Sourcegraph Cody now specialise in exactly this. But the counter-example every dev team must study is TSB's 2018 single-event migration, which locked roughly 1.9 million customers out of their accounts and cost on the order of £330 million. This playbook, from a team that builds financial systems, is a practical, code-side account of what a bank's dev team must learn: recovering intent from undocumented code with agents that explain before they translate, building a behavioural test harness and golden datasets before touching anything, verifying equivalence with data-level reconciliation, migrating by the strangler-fig pattern with dual-running - and never, ever doing the big-bang cutover.

September 21, 2026 · 14 min read · By BraivIQ Engineering

17M+ lines - COBOL, Natural and Perl modernised by Morgan Stanley with an in-house generative-AI platform, saving over a million developer hours · £330M - Approximate cost of TSB's 2018 single-event migration, which locked roughly 1.9 million customers out of their accounts · Shrinking pool - Banks modernise to reduce dependence on a dwindling COBOL specialist workforce and cut platform and licensing cost · Never big-bang - The most expensive way to modernise COBOL is to replace an entire system in one cutover event

Behind the polished mobile apps and real-time dashboards of most banks and trading firms sits a fact the industry does not advertise: the systems of record - ledgers, settlement, positions, core account processing - still run on COBOL written decades ago, on mainframes, maintained by a specialist workforce that shrinks every year, expensive to license and nearly impossible to change at the speed the business now demands. For thirty years everyone knew this had to be fixed and almost nobody attempted it at scale, because the risk of getting it wrong was existential. In 2026 the calculus changed, because AI coding agents made the impossible tractable: Morgan Stanley has modernised more than 17 million lines of COBOL, Natural and Perl using an in-house generative-AI platform, saving its developers over a million hours of manual work, and purpose-built tooling - IBM watsonx Code Assistant for Z for COBOL-to-Java, Sourcegraph Cody for codebase-scale understanding - now specialises in exactly this problem. But there is a counter-example every dev team must study before touching a line: in April 2018, TSB attempted a single-event migration of around 5.2 million customers onto a new platform, roughly 1.9 million were locked out of their accounts, and the episode cost the bank on the order of £330 million. The lesson is not that modernisation is too dangerous; it is that how you do it is everything. As a team that builds financial systems, we think mainframe modernisation with AI is the defining pain point of bank technology this decade, and this playbook is a practical, code-side account of what a dev team must actually learn.

Lesson One: Understand Before You Translate

The seductive promise of AI modernisation is the translation step - point an agent at COBOL, get Java out - and it is the least important part. The genuine difficulty of a decades-old codebase is that nobody fully knows what it does: the original authors are gone, the documentation describes a system three rewrites ago, business rules are buried in copybooks and job-control scripts, and undocumented edge cases - the special handling for a product discontinued in 1998 that some account still depends on - are load-bearing. Translating code you do not understand produces new code you do not understand, faster. So the first thing a dev team must learn is to use agents for intent recovery before generation: agents that read the COBOL, the copybooks, the JCL and the database schemas, and produce explanations, call graphs, data-flow maps and candidate business rules that humans then verify. This is where codebase-scale tools earn their place - they can hold an entire program family in context and answer 'what touches this field and why' in a way no human can at 17 million lines. The output of this phase is not code; it is a verified specification of behaviour, including the edge cases, that becomes the contract every later step is tested against. Teams that skip it and go straight to translation are the ones who discover in production that the modern system handles the discontinued 1998 product differently.

Lesson Two: Build The Harness And The Golden Data First

The second lesson is that you cannot safely change a system whose behaviour you cannot measure, so before any migration the team builds two assets. The first is a behavioural test harness around the legacy system as it stands: a way to feed it defined inputs - transactions, batch files, account states - and capture its exact outputs, at the level of data and not just return codes, so that its current behaviour, warts and all, is pinned down. This is characterisation testing, and AI agents are excellent at generating the breadth of cases it needs from the recovered specification, including the edge cases humans would forget. The second asset is golden data: curated, representative datasets (anonymised or synthetic where regulation requires) that exercise the real distribution of accounts, products and transactions, together with the legacy system's recorded outputs for them. Golden data is the oracle for everything that follows: any candidate modern implementation must reproduce the legacy outputs on it, field by field. Building these assets before writing a line of new code feels slow and is the single biggest determinant of a safe migration, because it turns 'we think the new system is equivalent' into 'we have proven the new system is equivalent on this data', which is the only claim a bank can responsibly act on.

Recover intent first - use agents to explain code, map data flow and extract candidate business rules; humans verify them into a behavioural specification.
Characterise the legacy system - a harness that pins down exact current outputs for defined inputs, edge cases included.
Curate golden data - representative, regulation-safe datasets with the legacy system's recorded outputs as the oracle.
Translate with agents, then verify equivalence - generated code must reproduce legacy outputs field by field on golden data before it goes anywhere.
Migrate strangler-fig with dual-running - one capability at a time, old and new running side by side, cut over only when reconciliation is clean.

Lesson Three: Translate, Verify Equivalence, Then Strangle - Never Cut Over

With a specification, a harness and golden data in hand, translation becomes the well-bounded task it should be. Agents - whether an in-house platform or tools like watsonx Code Assistant for Z - generate the modern implementation module by module, and the team's job shifts from writing code to verifying it: every generated module is run against the golden data and its outputs reconciled against the legacy outputs at the data level, with any difference treated as a defect to be understood, never waved through as 'probably fine'. Equivalence verification is where AI acceleration is safest, because the oracle is mechanical. Then comes the step that separates the Morgan Stanley outcome from the TSB one: how the new system reaches production. The strangler-fig pattern migrates one capability at a time - a single batch job, one product's processing, one reporting flow - routing that capability to the modern implementation while everything else stays on the mainframe, and running the two in parallel with continuous reconciliation of their outputs until the new path has proven itself on live traffic, at which point the legacy path for that capability is retired. Each increment is small enough to reverse, and the mainframe remains the safety net throughout. This is slower and less dramatic than a single cutover weekend, and it is the only approach that reliably ships without an outage that makes the national news. The TSB failure was, at root, a decision to make one irreversible change to everything at once; the strangler-fig is the decision never to be in that position.

The pain point, stated plainly: The reason mainframe modernisation is a genuine, expensive, career-defining pain point is that it combines the hardest properties of enterprise engineering: a system nobody fully understands, that cannot be switched off, that must never produce a wrong number, under regulatory scrutiny, on a platform consuming most of the budget, with a workforce that is retiring. AI agents have removed the labour bottleneck - reading, explaining, translating and generating tests at a scale that was previously impossible - but they have not removed the need for discipline, and a team that treats acceleration as permission to skip the harness, the golden data, the equivalence verification or the incremental migration is a team that will modernise faster into an outage. Respecting the curve means learning that the translation is the easy part, that the assets built before translation are what make it safe, and that the cutover strategy is the difference between a million hours saved and £330 million lost.

The Bottom Line

The mainframe problem - core banking and trading systems on decades-old COBOL, maintained by a shrinking specialist pool, too risky to change for thirty years - became tractable in 2026 because AI coding agents removed the labour bottleneck, as Morgan Stanley's modernisation of more than 17 million lines with over a million developer hours saved demonstrates and as purpose-built tools now enable. But TSB's 2018 single-event migration - 1.9 million customers locked out, on the order of £330 million lost - is the permanent reminder that the method is everything. What a bank's dev team must learn is a discipline, not a tool: use agents to recover intent and produce a verified behavioural specification before generating anything; build a characterisation harness and curated golden data so equivalence can be proven rather than assumed; translate with agents but verify every module by data-level reconciliation against the legacy oracle; and migrate by the strangler-fig pattern - one capability at a time, dual-running with continuous reconciliation, the mainframe as the safety net, each step reversible - and never attempt the big-bang cutover. AI has made modernisation fast; the harness, the golden data, the equivalence verification and the incremental migration are what make it safe, and treating speed as a reason to skip them is how a bank modernises faster into a meltdown. Building financial systems that change without ever breaking is exactly the correctness-critical engineering we specialise in.

References & Further Reading

Domain-b - the mainframe moment: how AI-driven modernization is reshaping the COBOL economy (Morgan Stanley's 17M lines): https://www.domain-b.com/technology/information-technology/ai-cobol-mainframe-modernization-2026
Hakuna Matata Tech - COBOL modernization in 2026: cost, risk and the AI path (the TSB single-event migration): https://www.hakunamatatatech.com/our-resources/blog/cobol-modernization
Microsoft All Things Azure - how we use AI agents for COBOL migration and mainframe modernization: https://devblogs.microsoft.com/all-things-azure/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization/
Ascendion - mainframe and COBOL modernization with agentic AI: what's actually possible in 2026: https://ascendion.com/ai-basic/mainframe-and-cobol-modernization-with-agentic-ai-whats-actually-possible-in-2026/
IBM - watsonx Code Assistant for Z (COBOL-to-Java modernization): https://www.ibm.com/products/watsonx-code-assistant-z