The failure rate hasn't moved. IBM shipped Watsonx Code Assistant for Z — now at v2.8.20 with a multi-agent Z Orchestrate, Architect, and Code architecture — and the 70-80% mainframe modernization project failure rate stayed where it was. Anthropic published its COBOL modernization guide in February 2026 to enough market interest that IBM stock dropped 13.2% on announcement day, then launched a $100M Claude Partner Network and a Code Modernization starter kit. Microsoft released an open-source COBOL Agentic Migration Factory via Semantic Kernel. The tools got better. The failure rate didn't. That stability is the most important data point in the market: the problem isn't translation quality. It's that every major tool translates code without first building the map that determines whether any translation can succeed.
The Failure Pattern Is Well-Documented
Consider a wire transfer processing program. An AI coding assistant translates a COMPUTE statement that uses TRN-LIMIT into a Java BigDecimal operation. The code compiles. Unit tests pass. UAT crashes on the first transaction.
The root cause is legible to any mainframe architect who has spent time with a CA-7 job stream dependency printout: TRN-LIMIT wasn't defined in the source file being translated. It was defined in a copybook, included thousands of lines earlier in the execution chain. That copybook contained a REDEFINES clause — a COBOL construct that lets the same memory address be interpreted as two different data types based on a flag set in a completely separate module. The AI saw TRN-LIMIT as a simple numeric field. On the mainframe it held a packed decimal (COMP-3). The Java application wrote corrupted binary data into the database column.
The code was syntactically correct. The database corruption was contextual — the AI translated a variable without ever knowing what the variable was.
COBOL's COMP-3 packed decimal arithmetic has no native Java equivalent. The BigDecimal workaround requires explicit HALF_EVEN rounding mode configuration to match COBOL's ROUNDED clause; a single omission cascades across millions of settlement transactions. One wrong penny compounds. And a single COBOL program may reference 40+ copybooks, with variable definitions nested 5 levels deep in inclusion chains. Text-based translation tools see none of that structure.
What the Major Vendors Actually Cover
IBM's approach is the most architecturally complete: ADDI (Application Discovery and Delivery Intelligence) provides dependency analysis, and v2.8's agentic architecture handles PL/I, IMS, and COBOL-to-Java translation at statement level including inside copybooks. The structural constraint is that ADDI runs on z/OS, creating vendor lock-in during the migration itself — the ADDI dependency report PDF that validates a transformation plan can only be generated inside IBM's toolchain. JCL scheduling chains and behavioral equivalence testing remain outside scope.
Anthropic is targeting the discovery and documentation gap that IBM's ADDI toolchain fills only within its own ecosystem. Anthropic's February 2026 guide identifies the phases it handles well — dependency mapping, workflow documentation, API wrapper creation for incremental migration — and is explicit about what it doesn't cover: full program scope analysis, audit trails, behavioral equivalence testing in regulated environments. Microsoft's Azure COBOL Agentic Migration Factory runs COBOL Expert and Java Expert agents via Semantic Kernel, targeting Java Quarkus on Azure. It works well if Azure is the target platform; it isn't production-ready for regulated environments that require platform-neutral delivery.
The large SIs bring delivery infrastructure that the AI-only tools can't match: DXC Technology's patented automatic code conversion, Accenture's program management experience (it led the Commonwealth Bank of Australia's core banking migration, which ran at $749.9M USD over five years), TCS's MasterCraft and TransformPlus frameworks. Typical engagement range is $500K-$5M+ with 18-36 month timelines. The gap this creates — and the one that Veriprajna's Legacy COBOL Modernization with Knowledge Graph Intelligence is built for — sits at mid-tier banks and insurance carriers with $1-50B in assets, where the large-SI engagement model is too expensive and the AI-only tools lack regulatory-grade depth.
The Map Is the Product
JCL job networks are the most consistently overlooked failure vector. A production mainframe typically runs 2,000-5,000 JCL jobs with dependency chains managed by CA-7 or TWS schedulers. A JCL PROC member's DISP=SHR dataset allocation connects Job A's output dataset to Job B's input — and that dependency exists nowhere in the COBOL source code that every translation tool ingests. Migrate the COBOL without mapping those chains, and production breaks at midnight. That's not a hypothetical; it's a documented failure pattern in nearly every large migration post-mortem.
What a knowledge graph builds is the topology: copybook inclusion chains, REDEFINES overlays across modules, COMP-3 arithmetic paths requiring specific BigDecimal configuration, EBCDIC-to-ASCII conversion boundaries where encoding translation introduces its own class of silent errors, dead code (typically 20-30% of a production codebase), and the JCL scheduling chains that connect everything across batch windows. The graph answers the question that strangler-fig migration depends on: which modules have the lowest coupling and can be extracted safely first. Without that answer, extraction sequence is a guess, and the strangler-fig pattern produces invisible risk rather than incremental safety.
Knowing what to extract first — not just how to translate it — is where the 70-80% failure rate breaks.
Behavioral equivalence testing is the other gap the topology unlocks. Every edge case encoded in decades of production COBOL processing encodes regulatory logic that may exist nowhere else in the organization. A golden dataset transaction replay log — capturing inputs and outputs from the mainframe and replaying them against the Java equivalent — requires knowing what transactions to capture. That requires the execution graph. Without the map, the test harness is incomplete by definition, and the first edge case that surfaces in production was always going to.
The Compliance Timeline Is Compressing
Workforce attrition has been the headline risk — the average US COBOL developer is 55, with 10% of the workforce retiring annually and 85%+ of universities having dropped COBOL from their curriculum since the 1990s. But the regulatory timeline is less patient than the hiring market.
DORA (EU Digital Operational Resilience Act), effective January 17, 2025, requires operational resilience testing and threat-led penetration testing for financial institutions. The DORA resilience-testing evidence pack a compliance team must compile is genuinely hard to produce for legacy batch systems where dependency documentation doesn't exist as structured data. The OCC IT Examination Handbook's updated cybersecurity section flags legacy systems explicitly — systems older than 10 years carry a 3x higher security breach probability, and that framing is moving from advisory to examination pressure.
$1.52 trillion in US technical debt. Financial institutions spending 70-75% of their annual IT budgets on legacy maintenance — leaving roughly a quarter for anything new — means the cost-of-inaction math has become difficult to defend at the board level.
Where Migrations Actually Succeed
The programs that hit their objectives do discovery first — not as a justification phase before translation begins, but as the actual deliverable. The knowledge graph that comes out of a proper discovery phase is what every subsequent migration decision is based on: extraction order, REDEFINES remediation plan, COMP-3 arithmetic rewrites, JCL scheduling chain migration, test harness scope.
Honest caveat: technology is necessary but not sufficient. No tool — ours included — solves organizational buy-in, data quality problems, or the challenge of getting hundreds of developers to change how they work. Technology tells you what to do in what sequence. The program still needs someone to make that sequence happen inside a real organization with real political constraints.
For the technical architecture — how knowledge graph dependency mapping works in practice, how JCL chains get traced, what behavioral equivalence testing looks like at scale — the full approach is at https://veriprajna.com/solutions/legacy-cobol-modernization.
The question we keep returning to: how much of the 70-80% failure rate is genuinely architectural (the dependency map wasn't built before translation began) and how much is organizational (the sequencing was right but the program couldn't execute it against institutional resistance)? In post-mortems, those two failure modes look different — and they require different interventions. If your team has run a stalled modernization and has a diagnosis, we'd genuinely like to understand what the root cause looked like.