The first post-mortem I read thoroughly was for a wire transfer processing failure at a regional bank — not a client, a publicly documented case written up after the fact. The project had used a well-regarded AI translation tool. The code compiled. The unit tests passed. UAT crashed the database consistency check on the first transaction. The post-mortem ran 40 pages. I kept returning to one exhibit: a CA-7 job stream dependency printout showing a batch dependency chain the translation tool had never been given access to. The chart made the failure obvious. The code audit hadn't. That's when I stopped thinking about COBOL modernization as a translation problem.
What I kept seeing in the ones that failed
I read a lot of post-mortems before we built anything at Veriprajna — genuinely trying to understand why a $9B market had a 70-80% project failure rate that hadn't moved across a decade of improving AI tools.
The REDEFINES clause showed up in almost every technical failure. It's a COBOL construct that lets the same memory address be interpreted as two different data types depending on a flag set in a completely different module. An AI translation tool sees the variable name and the apparent type — it doesn't see the REDEFINES overlay in a copybook included thousands of lines earlier in the execution chain. So it translates the variable as a simple numeric field, when the mainframe was using that memory address as a packed decimal (COMP-3). The Java application writes corrupted binary data into the database column. The code is syntactically perfect. The outputs are wrong.
I described this to a VP Engineering at a regional bank whose team had just come out of an 18-month migration that ended in UAT failure. He stopped me midway through the REDEFINES explanation — his team had lived it, he didn't need the education. What he needed was authorization to restart the engagement the right way. The organizational authorization problem, in his framing, was the harder constraint.
I've come to think the COMP-3 problem is actually harder to catch in practice than the REDEFINES problem. There's no native Java equivalent for packed decimal arithmetic. The BigDecimal workaround works, but it requires explicit HALF_EVEN rounding mode configuration to match COBOL's ROUNDED clause. Miss that configuration and the error compounds across millions of settlement transactions without surfacing in unit tests — it surfaces in month-end reconciliation, which is when banks find out they've been running incorrect arithmetic.
What I looked for in every vendor's demo
I spent time with IBM's ADDI (Application Discovery and Delivery Intelligence) dependency report when Watsonx Code Assistant for Z reached its v2.8.20 multi-agent architecture — Z Orchestrate, Architect, and Code agents, with PL/I and IMS support. The analysis is serious work. But ADDI runs on z/OS, which means the team doing dependency analysis is doing it on IBM's infrastructure while trying to migrate off IBM's infrastructure. The lock-in is structural, not incidental. The ADDI dependency report PDF that validates a transformation plan can only be generated inside IBM's toolchain.
Anthropic published its COBOL modernization guide in February 2026 — alongside a $100M Claude Partner Network launch and a Code Modernization starter kit — and I read it the week it came out. IBM stock dropped 13.2% on the announcement day, which told me how much of the market had been waiting for an alternative to IBM's z/OS dependency. Anthropic's guide was candid about scope: strong on discovery, dependency mapping, API wrapper creation; explicit about what it didn't cover (JCL scheduling chains, behavioral equivalence testing in regulated environments, audit trails). Microsoft's COBOL Agentic Migration Factory runs COBOL Expert and Java Expert agents via Semantic Kernel, targeting Java Quarkus on Azure. DXC Technology has patented automatic code conversion; Accenture led the Commonwealth Bank of Australia's core banking migration at $749.9M USD over five years. Large SI engagements start at $500K and take 18-36 months.
What none of them had — the gap I kept finding in every demo I ran — was a product designed around the dependency map as the primary deliverable, before any translation begins. That's the gap Veriprajna's Legacy COBOL Modernization with Knowledge Graph Intelligence is built for.
The week we found the second map
We'd been building what I thought was a complete COBOL dependency surface — copybook inclusion chains, REDEFINES overlays, COMP-3 arithmetic paths, EBCDIC-to-ASCII conversion boundaries, dead code (typically 20-30% of a production codebase). I thought we were close to a complete picture. My team ran a scan on a sample mainframe environment and I looked at the CA-7 and TWS scheduling data alongside the source code graph.
There was a completely separate dependency topology living in the JCL. A production mainframe typically runs 2,000-5,000 JCL jobs with scheduling chains managed by CA-7 or TWS schedulers. Job A writes a dataset that Job B reads at 2 AM — the dependency is encoded in a JCL PROC member's DISP=SHR dataset allocation, and none of it exists in the COBOL source code we'd been mapping. We had one map. The JCL job network was a second map we hadn't started.
That wasn't a minor gap. Migrating COBOL without mapping the JCL chains doesn't introduce risk — it guarantees a specific failure mode: production breaks at midnight, in a batch window, on a job whose dependency on the changed module nobody knew about. We rebuilt the knowledge graph to cover both surfaces. The golden dataset transaction replay log we now use for behavioral equivalence testing — capturing mainframe inputs and outputs and replaying them against the Java equivalent — only works because the execution graph includes the full JCL topology.
The map isn't a better translation tool. It's what determines whether any translation can be trusted.
The compliance angle I hadn't accounted for
When DORA — the EU Digital Operational Resilience Act — took effect January 17, 2025, I'd been thinking about COBOL modernization as a code quality problem and a workforce problem. Ten percent of COBOL developers retire annually; 85%+ of universities dropped the curriculum; the average US COBOL developer is 55. A conversation with a client's compliance team reframed it for me as a documentation problem.
DORA requires operational resilience testing and threat-led penetration testing for financial institutions. My client's compliance team needed structured dependency documentation to build their DORA resilience-testing evidence pack — the kind of documentation that legacy mainframe environments almost never have in structured form. The OCC IT Examination Handbook's updated cybersecurity section had arrived at the same place from a different regulatory angle: legacy systems older than 10 years carry a 3x higher security breach probability, and that framing was shifting from advisory to examination pressure.
$1.52 trillion in US technical debt. Financial institutions spending 70-75% of their IT budgets on legacy maintenance — that figure kept coming up in every client budget conversation as the number that finally ended "maybe next year." What DORA added in 2025 was a date attached to the deferral.
Where I'm still uncertain
I still overestimate how much of the 70-80% failure rate is technical. The dependency map solves the contextual-blindness failure — the code that compiles and corrupts. It doesn't solve the organizational problem: getting hundreds of developers to change how they work, aligning migration sequencing with regulatory examination calendars, finding whoever has enough organizational credibility to tell a steering committee the prior approach needs to restart.
The post-mortems I read were roughly split between "wrong architecture from the start" and "right architecture, ran out of organizational momentum." Those two failure modes look different in post-mortems — and they require different interventions. The full technical architecture — how the knowledge graph maps copybook chains, how JCL dependencies get traced, what behavioral equivalence testing looks like at scale — is at https://veriprajna.com/solutions/legacy-cobol-modernization.
One question I keep returning to: how much of the COBOL institutional knowledge held by developers who retire in the next five years has ever been externalized into documentation? The dependency map is designed for a world where it wasn't. I'm not sure the field has fully reckoned with what happens when even the people who could describe the undocumented dependencies are gone.