Mainframe modernization is one of the few disciplines where the case studies that matter most are the ones nobody publishes. Programs that succeed get a press release. Programs that fail get a settlement, a leadership change, and a line in an annual report about revised delivery timelines. So the industry keeps relearning the same lessons at nine-figure tuition.
This page is a working library of post-mortems, organized so the patterns are visible. One note of humility before the autopsies begin: none of these programs failed because the people running them were careless. They were run by capable teams under real constraints. They failed on structure, not talent — which is exactly why the failures are predictable, and why controls work.
Use the entries however they earn their keep — as steering-committee pre-reads, as seeds for a risk register, as an uncomfortable appendix to a vendor’s proposal. Each one ends the same way, with the control that would have caught it, because a post-mortem that changes nothing is just an anecdote.
The library
pm-01 · public record · uk retail banking · 2018
The weekend everything moved at once
what was attempted
In April 2018, a UK retail bank migrated its entire customer base — reported at around five million customers and over a billion records — from the legacy platform of its former parent to a new core banking platform built with its new owner, over a single cutover weekend.
where it died
Immediately. Customers were locked out of online and mobile banking, disruption ran for weeks, fraud teams were overwhelmed, and the chief executive left within months. Regulators later fined the bank £48.65 million for operational-resilience failures. The independent post-incident review found, broadly, that the platform went live before testing was complete and without a fully rehearsed, fully proven fallback.
the pattern
big-bang cutover · secondary: target-first thinking
the control that would have caught it
A phased migration with a parallel run: cohorts of customers moved in waves, old and new platforms reconciled daily, rollback rehearsed until it was boring. Phasing feels slower. It is only slower when nothing goes wrong on the one weekend you bet everything on.
pm-02 · public record · us federal tax administration · 1960s–present
The master file that outlived its modernizers
what was attempted
The US tax authority has worked for decades to replace its Individual Master File — the assembly-language system of record for individual taxpayer accounts, first built in the 1960s — across a series of successive programs under successive names. Each generation of the effort was scoped, funded, and partially delivered.
where it died
Nowhere, and that is the point: it has never finished. Replacement dates have been announced and revised repeatedly, oversight bodies have documented the schedule slips for years, and the original system remains in production roughly six decades after it was written. Every year of delay compounds the problem it was meant to solve — the engineers who can read the code are retiring faster than the code is.
the pattern
missing rules provenance · secondary: dead code inflating scope · sme attrition mid-program
the control that would have caught it
Deterministic extraction of the rule base — decades of tax law encoded as logic — with lineage back to source, captured while the people who can validate it still work there. A replacement designed from a verified rules inventory can be delivered in slices. A replacement designed from the code itself inherits all of it, including the parts nobody can explain.
pm-03 · public record · canadian federal payroll · 2016
The payroll that underestimated its own rules
what was attempted
In 2016, the Government of Canada consolidated federal pay onto a heavily customized commercial payroll package — the Phoenix pay system — replacing a roughly 40-year-old predecessor and rolling out in two waves to nearly 300,000 employees.
where it died
Within months of go-live. Public inquiries documented hundreds of thousands of pay errors — employees underpaid, overpaid, and unpaid — and a case backlog that took years to work down. The reported causes read like this library’s index: the complexity of roughly 80,000 pay rules spread across dozens of collective agreements was underestimated; experienced compensation advisors were released before cutover as a projected saving; a planned pilot and testing phases were compressed to protect the schedule. Cost estimates grew from an initial budget of about $310 million to well over $2 billion.
the pattern
missing rules provenance · secondary: big-bang cutover · sme attrition mid-program
the control that would have caught it
A rules inventory with provenance, reconciled line by line against the collective agreements it encodes — and a parallel pay run against the legacy system until the delta held at zero for consecutive cycles. Payroll is the easiest domain in the world to verify: the correct answer is already being computed every two weeks.
pm-04 · public record · us state government · multiple programs
The restart that bought the destination twice
what was attempted
A US state motor-vehicles modernization — one of several broadly reported cases in which a state DMV or labor department halted a legacy replacement mid-program, wrote off years of spend, and restarted with a new vendor. The program had a chosen platform, a signed integrator, and a multi-year roadmap before anyone had produced a verified account of what the legacy system actually did.
where it died
Mid-program, in the gap between delivered increments and undocumented legacy behavior. Each release surfaced business rules nobody had specified because nobody knew they existed. Each surprise became a change order; the change orders consumed the contingency; the program was halted and later restarted around a different target. The state paid for the destination twice and for the understanding zero times.
the pattern
target-first thinking · secondary: missing rules provenance
the control that would have caught it
Per-application disposition from an estate map, and vendor gates tied to evidence — a rules inventory, a reconciliation report — rather than milestones tied to the target platform. If the first deliverable a vendor proposes is an architecture diagram of the destination, the second deliverable will be a change order.
pm-05 · anonymized composite · insurance · 30-month program
The rewrite that transcribed the screens
what was attempted
A mid-size insurer commissioned a full rewrite of its policy administration core — roughly 2.4 million lines of COBOL — into Java. The functional specifications were written the way they usually are: by reading screens, interviewing users, and sampling reports. The target date was fixed before the specifications were finished.
where it died
Month 22, in user acceptance testing. Claims adjudication in the new system disagreed with legacy on the edge cases — grandfathered policy terms, rounding behavior, date logic added during a 1999 remediation — because the specifications described what users saw, not what the code did. The team fell back to reverse-engineering COBOL by hand at rewrite prices. The program was paused for re-planning, then quietly cancelled. The legacy system still runs. Part of the budget, it later emerged, had gone to faithfully rewriting batch jobs that had not executed since 2009.
the pattern
missing rules provenance · secondary: big-bang cutover · dead code inflating scope
the control that would have caught it
Rule extraction with source lineage before the first line of Java — so the gap between what the specifications said and what the code did surfaces in month two as a diff report, not in month 22 as a UAT crisis. And a dead-code report before estimation, so nobody pays rewrite rates for jobs the scheduler retired years ago.
pm-06 · anonymized composite · regional banking · 3-year horizon
The lift-and-shift that arrived unopened
what was attempted
A regional bank rehosted its mainframe estate onto an emulation layer in the cloud to meet a datacenter exit deadline. The move itself went well: applications came up, batch windows held, the deadline was met. The program was declared a modernization success.
where it died
Quietly, in year two. The COBOL was still COBOL, now running on rented infrastructure plus emulator licensing. Change requests still took the same nine months, because the code was no more understandable after the move than before it — and the SME bench was two retirements shorter. When analysis was finally run, roughly a third of what had been carefully migrated turned out to be dead or duplicative: the bank had paid to relocate code that nothing executed. The second program — the actual modernization — now had to be sold to a board that believed it had already funded one.
the pattern
target-first thinking · secondary: dead code inflating scope
the control that would have caught it
Honesty about what a rehost is, and rationalization before the move. Rehosting under deadline physics is sometimes the right call — but it is relocation, not modernization, and it should ship with a manifest: a dead-code report to cut the freight, and a rules inventory so the new address is a waypoint instead of a dead end.
pm-07 · anonymized composite · cards & payments · 12-week pilot
The AI conversion that could not answer the auditor
what was attempted
A card issuer piloted an LLM-based COBOL-to-Java conversion on a portfolio of interest-calculation programs. The demo was genuinely impressive: readable Java, fast turnaround, most converted files compiled, and a sampled few passed unit tests. The pilot moved toward a production recommendation.
where it died
In risk review. Two runs of the same program through the same pipeline produced structurally different Java — plausible both times, identical neither time. When internal audit asked which business rules the translation had preserved, there was no rules inventory to point to. When they asked for the evidence chain from a specific interest calculation back to its source, the honest answer was a probability. The pilot was reclassified as research. The estate stayed where it was.
the pattern
unverifiable ai translation · secondary: missing rules provenance
the control that would have caught it
Determinism as an acceptance criterion, written into the pilot before it starts: run the pipeline twice and diff the outputs; require every extracted rule to carry its exact source paragraphs; let the audit team score the evidence, not the demo. The question was never whether AI can write Java. It is whether anyone can prove what the Java means — we take that question apart in Can AI convert COBOL?