Why Now
For decades, mainframe modernization meant either rewriting from scratch (expensive and risky) or using vendor tools that produced output locked to proprietary runtimes. Neither approach solved the core problem: nobody could read a 5,000-line COBOL program and tell you in under an hour what it actually did. That is changing, and the shift is specific. LLMs can now produce plain-English summaries of mainframe program intent at the function and module level — whether the estate is written in COBOL (the most common), PL/I, Assembler, or NATURAL. For programs in the 2,000-10,000 line range, this reduces comprehension time from days to hours. The key enabler is structured parsing. Tree-sitter and ANTLR parsers now produce ASTs from COBOL that LLMs can reason over, rather than requiring the model to parse raw COBOL text. Raw COBOL has ambiguous structure; AST nodes have typed fields that constrain interpretation. The difference in output quality is significant. The market has recognized this shift. Anthropic published a post specifically covering Claude Code being used for COBOL modernization. IBM built watsonx Code Assistant for Z as their own AI-assisted migration product. AWS launched BluAge. Astadia, IBM ModernSystems, and LzLabs are all actively competing in this space. The industry describes mainframe as "the last frontier" for LLM-assisted migration, and the emerging consensus is that mechanical transformation first (AST parsing, dependency analysis) followed by LLM-assisted translation produces better results than feeding raw code to a model. The open-source approach differs from vendor tools in one important way: the output is portable. AWS Transform produces Java files, but those files require the BluAge runtime to execute. You have not escaped the mainframe; you have traded one proprietary dependency for another. The tree-sitter grammar and translation pipeline described here produce code in whatever stack the client already runs (TypeScript on Node.js, Java/Spring, Python, or Go) and runs on standard runtimes without a proprietary dependency.
The tools available for mainframe modernization have changed materially in the last three years. The bottleneck was never compute or translation speed; it was always comprehension. A COBOL estate that has accumulated 50 years of undocumented changes cannot be migrated by brute-force translation. Before any code can be rewritten, someone has to understand what it does. That used to take months of manual analysis by developers with mainframe expertise. It no longer does.
What changed
LLM-assisted code comprehension has crossed a practical threshold. A large language model given a structured AST (Abstract Syntax Tree) of a COBOL program can generate accurate plain-English descriptions of what each function does, what data it reads and writes, and what would break if it changed. For programs in the 2,000 to 10,000 line range, this reduces comprehension time from days to hours. The accuracy is not perfect, and human review is required, but the ratio of human effort to coverage has shifted decisively in favor of AI assistance. Structured parsing has improved. Tree-sitter grammars and ANTLR parsers now exist for COBOL and other mainframe languages that produce full, queryable ASTs rather than ad-hoc tokenizations. This means LLMs receive structured input rather than raw text, which substantially improves the quality of analysis and translation output. Anthropic's Code Modernization Playbook describes this combination of mechanical transformation and LLM analysis as the pattern that "preserves critical business logic during migrations and generates comprehensive documentation where none previously existed." Agentic coding tools operate at codebase scale. Tools like Claude Code can reason across an entire mainframe estate simultaneously, maintaining context across thousands of files and surfacing patterns and dependencies that no single developer could track manually. This is qualitatively different from using an LLM as a single-file translator.
What this enables
These three capabilities together enable an approach that was not practical before: front-loading the comprehension work before any code is changed.
The traditional approach was to assign developers to study individual programs, write specifications, then rewrite. The per-program cost was high and the institutional knowledge transfer was lossy. The result was either years of effort or a big-bang migration that inevitably missed undocumented behavior.
The AI-assisted approach runs comprehension at estate scale first. The entire codebase is parsed, inventoried, and documented before a single program is translated. Dead code is identified and removed from scope. Programs are complexity-scored and sequenced. By the time translation begins, the team has a comprehensive picture of the estate that no one had before, including the client's own team. IBM's watsonx Code Assistant for Z and AWS Transform for mainframe both validate that the market has converged on this framing. Both products front-load analysis and documentation before translation. The difference is in the output: both major commercial offerings produce code that requires their proprietary runtimes, which creates new vendor dependencies rather than eliminating old ones. An open-source approach targeting whatever stack the client already runs in production produces portable, maintainable code that the client's existing engineering team can own.
The validation
We ran this approach against the AWS CardDemo application, a publicly available reference COBOL corpus for IBM z/OS with 44 programs, 30 copybooks, 46 JCL jobs, and 57,268 lines of code. Results from the comprehension phase: 179 files inventoried in under a minute, dependency graph built across all 44 programs, 14 dead programs and 33 dead paragraphs identified (32% dead code rate), complexity scoring completed across all 44 programs. The hardest program in the corpus scored 4.1 out of 5 on the composite complexity index: 3,368 lines, 17 CICS commands, 51 GO TO statements. That program requires a human specialist. The rest do not. We also ran AWS Transform against the same corpus as a benchmark. It produced 1,213 Java files. Those files require AWS's proprietary BluAge runtime and cannot be deployed without it. AWS Transform produces output. This approach produces understanding. The translation branch is open source at https://github.com/Spantree/aws-mainframe-modernization-carddemo/tree/migration/typescript. It includes 34 translated programs, 4 stubs ready to implement, and 4 human-specialist stubs. Each stub explains exactly why automated translation was not attempted and what the specialist work involves.
A note on GitHub Copilot
Many enterprises have existing GitHub Copilot or Microsoft 365 Copilot subscriptions. Copilot is optimized for IDE-integrated developer productivity: inline completions, PR assistance, and single-file code generation. Claude Code is built as an agentic, terminal-first engine with very large context windows and explicit memory systems, optimized for repository-scale comprehension and orchestrated multi-file analysis. These are different tools for different jobs. For Microsoft-aligned organizations: GitHub Copilot Business and Enterprise now expose Anthropic Claude models as a selectable option. Claude access for estate-scale analysis may already be available through an existing Copilot subscription, without separate procurement. The practical framing is not "switch from Copilot to Claude" but rather "Claude Code handles the migration analysis pipeline; existing Copilot entitlements cover Claude access for day-to-day developer productivity alongside it." One important caveat: independent evaluations show that LLMs including Claude can produce false negatives when extracting business rules from COBOL, such as omitted conditions and missed edge cases. Human review of all LLM-generated documentation is required before it is treated as authoritative. The methodology is designed around this constraint: comprehension outputs are reviewed and confirmed before they feed the wave plan.