AI can help teams understand, modernize and extend mainframe applications, but it does not remove the need for application owners, business experts and rigorous testing. The practical starting point is to map what an application does, choose whether to preserve its behavior or redesign it, then validate each generated artifact against real requirements and tests.
What AI can—and cannot—do in mainframe modernization
Legacy source code often contains business rules and dependencies that are difficult to reconstruct from code alone. AI-assisted analysis can help inventory programs, visualize relationships and data flows, surface business functions, and turn findings into documentation or test cases. That assessment is useful even if the application is not immediately moved or rewritten.
As an Amazon Associate I earn from qualifying purchases.
From there, tools may assist with code restructuring, COBOL-to-Java translation, or drafting specifications for new services. These are not interchangeable outcomes: translating code is not automatically a redesign of the application, its data model or its business process. The capabilities described by Google Cloud, AWS and IBM are vendor descriptions, not independent proof that a particular transformation will be fast, less costly or correct for a given organization. See Google Cloud’s overview of AI for mainframe modernization, AWS Transform documentation and IBM’s discussion of generative AI for mainframes.
Use AI as an accelerator for discovery and implementation, not as the authority on what the system is supposed to do. People who own the application and business process must resolve ambiguous rules, approve changes and accept the resulting system.
#1 Best Overall
Choose the transformation path by workload
A portfolio rarely needs one modernization strategy for every application. First state the outcome you need: visibility, integration, behavior-preserving change, reduced platform coupling, or a redesigned business capability. “Move to the cloud” alone does not specify which problem the work should solve.
| Path | What changes | When it may fit | Questions to resolve |
|---|---|---|---|
| Assess and augment | Discover code, rules, dependencies and data; expose or integrate existing assets while retaining core systems. | You need to understand the estate, connect it to other capabilities or add functions without replacing the core. | What data is exposed or moved? What remains on the mainframe? How will encoding, security, latency and operational ownership be handled? |
| Deterministic refactor or replatform | Restructure or translate an application while targeting equivalent behavior; replatforming may leave much of the application intact. | The workload is stable and preserving external behavior is a priority. | Can outputs and interfaces be shown to match? Which runtime dependencies remain? What are the migration and ongoing operating costs? |
| Rewrite or reimagine | Extract and validate business rules, then design a new architecture and potentially new functionality. | Business differentiation or architectural change justifies deeper redesign. | Which rules have business-owner approval? How will data and transactions move? What test evidence and rollback plan are required? |
Terms vary across providers, so compare the work actually automated and the work left to your organization or implementation partner. Google distinguishes deterministic modernization from a reimagine path, and gives stable, high-volume batch processing as an example of a behavior-preserving case and a customer-facing loan platform as an example where reimagining may fit. AWS also describes distinct “Refactor” and “Reimagine” workflows. These are provider examples, not universal rules for classifying workloads. See Google Cloud’s explanation of the paths and AWS’s description of reimagining applications.
Rank #2
Where AI fits in the lifecycle
1. Discover the estate
Build an inventory of programs, data stores, interfaces, batch jobs and dependencies before selecting a target. AI-assisted tooling can help visualize flows and identify application boundaries or business functions. IBM describes inventory and flow diagrams; Google describes dependency visualization and business-function discovery. Treat these outputs as a map to review, not proof that every dependency or operational constraint has been found. See IBM’s overview and Google Cloud’s overview.
2. Recover and verify business rules
Use extracted rules, plain-language documentation and drafted requirements to make implicit behavior easier to discuss. Have knowledgeable business and application experts verify the rules, especially exceptions, timing dependencies and behavior that is poorly documented. AWS says expert validation of AI-generated specifications is essential before code generation; a plausible specification is not a substitute for that review. See AWS’s account of its reimagine workflow.
Rank #3
3. Transform to match the chosen outcome
For behavior-preserving work, AI may assist with code refactoring or translation, including COBOL-to-Java conversion. For a reimagine effort, extracted rules can inform specifications for new services and architecture. The second path is a design and business-validation exercise as well as a coding exercise; a translated program should not be described as a rearchitecture unless the architecture has actually changed.
4. Validate and operate
Compare the transformed system with the baseline, test integrations and data handling, and review generated specifications and code. Before production, also establish how security, compliance and operational behavior will be monitored. AWS describes testing and human verification; Google describes testing and pre-go-live risk reduction, including a “Dual Run” option. The right validation depth depends on the workload and the consequences of an error.
Rank #4
Reduce risk with a bounded pilot
- Select one application with a clear boundary. Map its upstream and downstream dependencies, interfaces, data stores, batch windows and operating requirements. Avoid choosing a pilot so small that it omits the system’s meaningful integration risks.
- Write down the target outcome. Specify whether the aim is visibility, integration, equivalent behavior on a different platform, less platform coupling, or new business functionality. Decide which behavior must remain unchanged and where change is allowed.
- Establish baseline acceptance tests. Before transformation, capture expected outputs and interfaces. Include integration, data, operational, security and user-acceptance checks that fit the application. Tests derived from AI-generated documentation still need review against business expectations.
- Review rules and generated artifacts. Have business owners validate extracted requirements and application experts inspect generated specifications and code. Resolve uncertainty before it becomes an assumed requirement.
- Test the whole operating model. Include migration of data and transactions, target runtime dependencies, required skills, support arrangements and the cost of running the destination—not just code conversion effort. Use the pilot to refine scope and the business case before scaling. AWS’s migration lifecycle likewise describes learning from pilots and planning the operating model: AWS Transform documentation.
- Plan recovery before cutover. For business-critical workloads, determine whether a rollback or parallel-run approach is warranted, define who can authorize it and set criteria for returning to the existing system. Google identifies Dual Run as one way to reduce go-live risk: Google Cloud’s mainframe modernization solutions.
How to judge claims and results
Ask providers what their tools generate, what they automate, what remains manual, and how their outputs are validated. Measure the pilot against your baseline: requirement coverage, behavioral equivalence where required, defects found, integration results, migration effort and the full operating model. A vendor timeline or savings estimate should be treated as a claim to test against your own workload and constraints.
The available provider materials describe capabilities and approaches, but do not establish typical project savings, transformation accuracy, time-to-production or success rates across organizations. IBM reported in an August 22, 2023 announcement that its 2023 Institute for Business Value research found organizations were “12x more likely” to leverage existing mainframe assets rather than rebuild application estates from scratch in the next two years. That is an IBM-reported finding from 2023, not a current forecast or an independently verified result. See IBM’s announcement.
Quick Recap
Best Value
- Murach's Mainframe COBOL
- Mike Murach & Associates
- ABIS BOOK
A practical decision rule
- Choose assessment and augmentation when the immediate gap is understanding, integration or access to existing capabilities.
- Choose behavior-preserving refactoring or replatforming when the application is stable and the priority is changing structure or runtime without changing its external behavior.
- Choose reimagining when a validated business case calls for new functionality or a different architecture and the organization can manage the resulting data, transaction and operating-model changes.
- In every case, let verified requirements and pilot evidence—not generated code volume or provider promises—determine whether to expand the effort.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
