For decades, mainframe modernization has been the project every CIO knew they needed and few wanted to own. Core banking, insurance claims, airline reservations and government benefits still run on COBOL, PL/I, JCL, CICS, IMS and Db2, often written by people who retired long ago. Previous waves of modernization stumbled on the same obstacles: undocumented business rules, enormous codebases, scarce skills and the terrifying risk of changing systems that process money and entitlements. Since 2025, a new generation of generative and agentic AI tools has changed the economics of the hardest parts of the problem, especially discovery, documentation and code transformation. This article explains what these tools actually do, where they still fall short and how to structure a modernization program that uses AI to reduce risk rather than create new kinds of it.
Why Mainframe Modernization Is Back on the Agenda
Three pressures have converged. First, skills: the engineers who understand legacy mainframe applications are a shrinking pool, and every year the institutional knowledge embedded in their heads becomes harder to recover. Second, agility: business teams want real-time APIs, cloud analytics and AI features that are difficult to bolt onto batch-oriented systems. Third, cost and lock-in: software licensing and capacity charges on proprietary platforms keep rising, while cloud and open-source alternatives have matured.
What is new is that the tools have caught up with the ambition. Over the past two years, major vendors have shipped or substantially expanded AI services aimed squarely at legacy code. AWS describes AWS Transform for mainframe as an agentic AI service for modernizing COBOL, JCL, CICS, Db2 and VSAM workloads. IBM’s watsonx Code Assistant for Z uses a model tuned for IBM Z to explain COBOL, help refactor it into modular services and transform selected components into Java. Ecosystem vendors are integrating on top: in June 2026, Pegasystems announced that its Blueprint application design agent is available inside AWS Transform, using AI-extracted documentation of COBOL business rules to generate designs for new cloud applications. Modernization is shifting from a craft performed by small teams of specialists to an industrialized process with AI doing much of the analytical heavy lifting.
What GenAI Actually Does in a Modernization Program
It is tempting to imagine an AI that ingests a mainframe and emits a cloud-native application. That is not how successful programs work. AI contributes across several distinct activities, each with different maturity and risk.
Discovery and Analysis
The first and most reliable gains come from understanding the estate. AWS’s refactor guidance describes automated code analysis that measures complexity and maps dependencies, data lineage that shows which programs read and write which datasets, and activity analysis that parses SMF records to identify inactive jobs and heavy workloads. Finding dead code and unused batch jobs alone can remove a meaningful share of scope before any conversion starts. This kind of analysis existed before generative AI, but AI makes the results explorable through natural-language questions.
Documentation and Business Rule Extraction
Generating readable explanations of what a program does, extracting business rules and producing data dictionaries are where large language models shine. AWS Transform groups code into business domains at several levels of abstraction, and IBM positions explanation and business logic documentation as core capabilities of watsonx Code Assistant for Z. For many organizations, high-quality documentation is valuable even if they never convert a line of code, because it de-risks maintenance and supports regulatory and audit needs.
Decomposition and Planning
Monolithic mainframe applications need to be broken into domains that can be migrated in waves. AI agents can propose decompositions based on code structure and shared data, and generate wave plans. These proposals are a starting point; architects still need to validate boundaries against business ownership, transaction integrity and data coupling.
Code Transformation
Conversion is where expectations need the most care. Deterministic, rules-based refactoring engines have converted COBOL to Java for years, often producing functionally equivalent but hard-to-maintain code. AI now adds two things: smarter, more idiomatic output, and post-processing. AWS describes an optional Reforge step that adds comments, applies modern practices and generates unit tests. IBM’s approach emphasizes selectively transforming COBOL into object-oriented Java services with generated unit tests to compare behavior against the original program.
Testing and Equivalence
The hardest question in any modernization is whether the new system behaves exactly like the old one. AI helps generate test plans, data capture scripts and automated functional tests, but the ground truth remains production behavior. Capturing real inputs and outputs, replaying them against the new system and comparing results at the record level is still the gold standard.
Choosing a Modernization Pattern
AI does not remove the need to choose a pattern; it changes the cost of each. AWS’s 2026 guidance organizes mainframe options into several approaches, which map well to decisions most organizations face:
- Replatform: keep COBOL or PL/I but move to a modern runtime on cloud or distributed infrastructure. Lowest code risk, but skills and language constraints remain.
- Refactor: automatically convert COBOL and JCL into Java and modern scripting while preserving functional equivalence. Faster than rewriting, and AI improves readability of the output.
- Reimagine: use AI-extracted business rules and documentation to design and build new applications, often with different architecture and user experience. Highest potential value and highest delivery risk.
- Replicate or augment: keep the core on the mainframe but replicate data to cloud platforms for analytics, APIs and AI use cases. Often the right first step for organizations not ready to move transaction processing.
Most large estates end up with a mix. Stable, rarely changed batch processing may be refactored or replatformed; customer-facing processes that the business wants to redesign are reimagined; and some components are retired altogether once analysis shows they are unused. Vendor landscapes also shift: AWS notes, for example, that its managed runtime for Mainframe Modernization is no longer open to new customers, while self-managed options and AWS Transform remain available, so tool choices should be revalidated at program start.
Use AI first to understand and document the estate, then to transform it. The organizations that skip straight to code conversion usually rediscover their business rules in production.
Risks and Limitations to Manage
Generative AI introduces new failure modes alongside its benefits. Program leaders should plan explicitly for the following:
- Plausible but wrong explanations. Language models can describe code fluently while misreading edge cases such as packed decimal arithmetic, REDEFINES clauses or implicit file status handling. Subject-matter experts must review extracted rules for critical domains.
- Numerical and data semantics. COBOL fixed-point decimal behavior, EBCDIC encoding, collation sequences and date handling must be reproduced precisely. Small differences in rounding can create regulatory and financial errors.
- Non-functional behavior. Batch windows, throughput, locking and restart and recovery semantics are rarely visible in code and must be engineered deliberately in the target architecture.
- Maintainability of output. Converted code that mirrors COBOL structure in Java syntax can be harder to maintain than the original. Budget for refinement and for training teams on the new codebase.
- Data and IP governance. Source code for core systems is sensitive. Confirm where models run, how code and data are stored and who can access generated artifacts.
- Organizational change. Operations, security, audit and business users all depend on current behavior. Communication and parallel running are as important as technology.
A Phased Roadmap for AI-Assisted Modernization
A pragmatic program typically runs in five phases, with explicit decision gates between them:
- Portfolio assessment (6–10 weeks). Inventory applications, run automated code and activity analysis, identify dead code and unused jobs, and estimate complexity. Interview business owners about pain points and change frequency.
- Knowledge recovery. Use AI to generate technical and business documentation, data dictionaries and domain maps. Have subject-matter experts validate critical rules and store the results in a searchable knowledge base.
- Pattern selection and wave planning. Assign each domain a pattern, define target architecture and data strategy, and plan migration waves that start with lower-risk, high-learning domains.
- Pilot and prove equivalence. Transform one bounded domain end to end, including data migration, testing with captured production data, performance benchmarking and operational runbooks. Use the results to calibrate estimates.
- Industrialize and decommission. Scale to remaining waves with a factory model, run old and new systems in parallel where needed, and retire mainframe components as each wave stabilizes.
Decision gates matter. If the pilot shows that converted code is not maintainable enough or that equivalence testing is too expensive, adjust the pattern for later waves rather than pushing forward on the original plan.
Worked Example: A Regional Insurer’s Policy Administration
Consider a hypothetical regional insurer whose policy administration runs as several million lines of COBOL with CICS online transactions, nightly JCL batch and VSAM and Db2 data. Only a handful of engineers understand the rating logic, and the business wants to launch new products faster and expose policy data through APIs.
The program starts with AI-driven analysis, which reveals that a significant portion of batch jobs have not run in over a year and can be retired after confirmation with operations. AI-generated documentation of rating and endorsement logic is reviewed by actuaries and senior developers, who correct several misunderstood rules around mid-term adjustments. The insurer then splits the estate into domains. Billing and document generation, which change rarely, are refactored to Java with equivalence testing against months of captured production runs. Product rating, the area where the business wants the most agility, is reimagined as a rules-driven service designed from the validated business rules. Meanwhile, policy data is replicated to a cloud data platform so new digital channels can read it immediately, long before the core is fully migrated.
The result is not a single cutover but a sequence of smaller, verifiable moves. Each wave reduces mainframe dependency and builds team confidence, and AI’s main contribution is compressing the discovery and documentation work that historically consumed the first year of such programs.
Evaluating Tools and Partners
The tooling market is moving quickly, and vendor demonstrations on small sample programs say little about performance on your estate. Before committing, run a structured proof of value on a representative slice of your own code, including the awkward parts: dynamic CALLs, copybooks with many REDEFINES, assembler routines, unusual CICS patterns and batch jobs with complex restart logic. Ask each vendor or partner the same questions:
- Which source languages, runtimes and data stores are supported natively, and which require partner tools or manual work?
- How is functional equivalence demonstrated, and can tests be driven by captured production data?
- Can transformation be rerun incrementally as the legacy code continues to change during the program?
- What does the generated target code look like, and how will your developers maintain it in five years?
- Where do models run, how is source code isolated and retained, and what audit evidence is produced?
- What licensing or runtime dependencies remain after migration, and how portable is the result across clouds?
Team Structure and Operating Model
Successful programs pair three kinds of expertise. Legacy specialists understand COBOL semantics, CICS behavior, batch scheduling and the history behind odd design choices. Modern engineers design target architectures, cloud infrastructure, APIs and data platforms. Business domain experts validate extracted rules and own acceptance decisions. AI tools sit in the middle, accelerating the handoffs between these groups, but they do not replace any of them. A common structure is a central modernization factory that owns tooling, standards, equivalence testing and knowledge management, with domain squads that execute each wave. Distributed delivery can work well here: much of the analysis review, conversion refinement and test automation is well suited to dedicated offshore teams working alongside onshore architects and business experts, provided governance over source code access is clear. Plan knowledge transfer deliberately so that the people who will run the modernized systems are involved from the pilot onward, rather than receiving a finished codebase at the end.
Measuring Success
Define success metrics up front so the program is judged on outcomes rather than lines of code converted. Useful indicators include mainframe capacity and licensing consumption retired, percentage of business rules documented and validated, defect rates in equivalence testing, lead time for changes in modernized domains compared with the legacy baseline, and the number of engineers able to work confidently on each domain. Track operational stability through incident rates after each cutover, and report cost against plan at every gate.
Outlook
Expect continued rapid progress in agentic modernization tooling: tighter integration between analysis, design and IDE-based development; better support for less common languages such as Assembler and PL/I; and more automated test generation from production data. Expect also a growing emphasis on reimagining rather than translating, as tools increasingly connect extracted business rules to new application design. Human expertise will remain central for validating rules, designing target architecture and managing the business change that comes with replacing core systems.
Conclusion
Generative and agentic AI have made mainframe modernization more feasible than at any point in the last two decades, mainly by compressing analysis, documentation and transformation work. They have not eliminated the need for careful pattern selection, rigorous equivalence testing and strong program governance. Start with understanding, use AI to recover knowledge before converting code, prove equivalence on a bounded pilot and scale in waves with clear decision gates. Done this way, AI turns a high-risk leap into a series of manageable, measurable steps.
How Hanoi Technology Can Help
Hanoi Technology helps enterprises plan and execute AI-assisted mainframe modernization, from code analysis and business rule documentation to refactoring, equivalence testing and cloud deployment.