DEV Community: somnath roy

Agentic AI for Mainframe Modernization: From COBOL Understanding to Automated Code Transformation

somnath roy — Sun, 27 Sep 2026 20:44:31 +0000

Agentic AI for Mainframe Modernization: From COBOL Understanding to Automated Code Transformation
Mainframe modernization has been discussed for many years. The technology around it keeps changing, but one problem remains the same: before we modernize a mainframe application, we need to understand what it actually does.
That sounds simple, but anyone who has worked with a large mainframe application knows that it is not.
A business application may have been running for 20, 30, or even 40 years. During that time, hundreds of developers may have changed it. New business rules were added. Old rules were modified. Programs started calling other programs. Batch jobs became connected to online transactions. New databases and interfaces were added.
After many years, the application is no longer just a collection of COBOL programs. It represents years of business knowledge.
This is where I think agentic AI can make a real difference in mainframe modernization.
The interesting part is not simply using AI to convert COBOL into Java or to an open-source language. Code conversion is only one piece of the problem. The bigger opportunity is using AI across the modernization process: understanding an application, finding dependencies, identifying business rules, analyzing the impact of a change, separating business functions, transforming selected code, generating tests and helping developers validate the results.
So the shift is bigger than code generation. AI can now help with several steps of the modernization work.
That is a much bigger change.

Why Mainframe Modernization Is Still Difficult
Mainframes continue to run critical workloads for banks, insurance companies, healthcare organizations, retailers, government agencies and many other large enterprises.
There is a reason these systems are still running.
They are reliable. They can process very large transaction volumes. They provide strong security and availability. More importantly, the applications running on them contain business logic that organizations have developed and refined over many years.
The technology may be old, but the business logic is extremely valuable.
Consider a COBOL application that processes customer payments. The application may contain rules for validating an account, calculating fees, handling exceptions, updating balances, generating accounting entries and creating downstream files.
Some of those rules may have been added 15 years ago because of a regulatory requirement. Others may have been added because of a specific business product.
The documentation may not explain every rule.
Sometimes the only place where the complete rule still exists is the code.
That makes a large modernization project risky.
If we translate the code without understanding why the code works the way it does, we may create a technically modern application that produces the wrong business result.
That is why, in my experience, understanding the application has to come before trying to modernize it.
Generative AI Was the First Step
Generative AI already gives mainframe developers some useful capabilities.
A developer can provide a section of COBOL and ask:
What does this program do?
The AI can summarize the logic.

The developer can then ask:

Explain this paragraph in simple English.
Or:
What happens when CUSTOMER-TYPE is equal to "P"?
Or:
Create a Java version of this logic.

These capabilities can save time, particularly when a developer is working with an unfamiliar application.
But there is a limitation.
The developer is still managing every step.
The developer asks a question. The AI answers it. The developer asks another question. The AI provides another answer.
Agentic AI changes this model.
Instead of asking the AI to complete one small task, we can give an agent a larger objective.

For example:
Analyze the customer fee-processing module and prepare it for modernization.

That objective may require several steps.

The agent may need to identify the relevant COBOL programs, understand which programs call each other, find the copybooks and database tables, explain the business logic, identify the fee-calculation rules, determine whether that logic can be separated from the larger application and create tests for the existing behavior.
That feels much closer to how developers work on a real modernization project.

What Makes Agentic AI Different?
I think the easiest way to understand the difference is to compare two workflows.
With a normal AI coding assistant, the process might look like this:

Developer -> Prompt -> AI Response -> Developer -> Next Prompt -> AI Response

With an agentic approach, it could look more like this:
Developer -> Objective -> AI Plans Tasks -> AI Uses Tools -> AI Analyzes Results -> AI Performs Next Task -> Developer Reviews

The important difference is the word objective.

An AI agent is not only answering a question. It is trying to complete a goal through multiple connected steps.
For mainframe modernization, that goal could be:
Identify and modernize the account fee calculation as an independent service.
To complete that objective, an agent may have to perform several different activities.

A possible flow could be:

Discover -> Understand -> Extract Rules -> Analyze Impact -> Refactor -> Transform -> Test -> Validate -> Deploy

This is where I see the real advantage of an agentic approach.

1. Start With Application Discovery
Before we ask AI to transform anything, we need to know what we have.
Imagine an enterprise application containing thousands of COBOL programs.
One program may call five other programs. Those programs may use several copybooks. They may read Db2 tables, update VSAM files, execute under CICS, exchange messages through MQ and participate in nightly batch jobs controlled by JCL.
Looking at one source file does not provide enough information.
For example:

Suppose we want to modernize FEE200.
Before changing it, we need answers to several questions.

Who calls FEE200?
Does FEE200 call another program?
Which copybooks does it use?
Which tables or files does it access?
Is it used by an online transaction, a batch process, or both?
Does another application depend on its output?

This is application discovery.
Tools such as IBM Application Discovery and Delivery Intelligence can help create this type of application inventory and dependency information. That information becomes even more useful when combined with AI.
Instead of giving an AI model only FEE200.cbl, we can give it the context around FEE200.
Now the AI is not simply reading a program.
It is beginning to understand where the program fits into the application.

2. Turn COBOL Into Something Developers Can Quickly Understand
Once we know the application structure, the next challenge is understanding the actual code.
Experienced COBOL developers can obviously read COBOL. But that does not mean they can instantly understand a 5,000-line program they have never seen before.
This is especially true when the application contains code written by many developers over several decades.
Imagine finding this logic:

IF WS-CUST-TYPE = 'P'
IF WS-BALANCE > 10000
COMPUTE WS-FEE =
WS-TRAN-AMT * 0.005
ELSE
COMPUTE WS-FEE =
WS-TRAN-AMT * 0.010
END-IF
ELSE
COMPUTE WS-FEE =
WS-TRAN-AMT * 0.015
END-IF.

An experienced developer can understand this fairly quickly.
But an AI assistant could immediately explain it as:

Premium customers with a balance greater than $10,000 pay a 0.5% transaction fee. Premium customers with a lower balance pay 1%. Other customers pay 1.5%.

For a small example, the benefit may not seem significant.
Now imagine the same business logic spread across 30 programs, multiple copybooks, several database tables and thousands of lines of code.
That is where AI-assisted code understanding becomes valuable.
IBM's current mainframe AI tooling supports explanation of COBOL and other mainframe artifacts and its newer agentic direction expands this concept across broader development and modernization tasks.
For developers who are new to an application, this could significantly reduce the time needed to understand the system.

3. Find the Business Rules Hidden Inside the Code
I think this could be one of the most useful areas for AI in a mainframe environment.
Mainframe applications contain a huge amount of business knowledge.
The challenge is that the knowledge may be buried inside technical logic.
Look again at the previous COBOL example.
The code itself is technical.

The business rules are:
• Premium customers receive lower transaction fees.
• Premium customers with balances above $10,000 receive the lowest rate.
• Standard customers pay a higher transaction fee.

Those rules are much more important than the COBOL syntax.
If we decide to move the fee calculation to Java, the new application needs to preserve those rules.
An AI agent could potentially scan the related programs and produce something like this:
Business Rule: BR-FEE-001

Description:
Premium customers with account balances above
$10,000 are charged a 0.5% transaction fee.

Source:
FEE200.cbl

Paragraph:
CALCULATE-FEE

Inputs:
CUSTOMER-TYPE
ACCOUNT-BALANCE
TRANSACTION-AMOUNT

Output:
TRANSACTION-FEE
Now we have something useful for both developers and business analysts.
The business analyst can review the rule without reading COBOL.
The developer can see exactly where the rule came from.
The modernization team can later use the rule when validating the new implementation.
That gives the team much more value than simply converting one programming language into another.

4. Use AI for Impact Analysis
Impact analysis is part of everyday mainframe development.

Suppose someone asks:
Can we increase CUSTOMER-ID from 10 characters to 15?

The actual COBOL change might be very small:
05 CUSTOMER-ID PIC X(10).
becomes:
05 CUSTOMER-ID PIC X(15).

But experienced developers know that the real question is not how to change that line.

The real question is:
Where else is CUSTOMER-ID used?

It might exist in:
• copybooks
• Db2 tables
• VSAM records
• CICS screens
• input files
• output files
• JCL
• reports
• MQ messages
• downstream applications

An agent with access to dependency and application-analysis information could investigate these relationships and produce a report such as:

Proposed Change:
CUSTOMER-ID X(10) -> X(15)

Potential Impact:

COBOL Programs: 37
Copybooks: 4
Db2 Tables: 2
Batch Jobs: 6
CICS Transactions: 3
External Interfaces: 3

High-Risk Dependencies:

PAYMENT01
CUSTOMER-HISTORY-FILE
DAILY-SETTLEMENT-JOB

These numbers are only examples, but this is similar to the kind of impact analysis developers deal with regularly.
The AI does not make the final decision.
It gives the developer a much better starting point.
The developer can then investigate the high-risk areas rather than manually searching through the entire application.

5. Refactor Before Transforming
This is also where I have seen modernization discussions become too focused on code conversion.
Suppose we have a 7,000-line COBOL program.
We ask an AI tool to convert all 7,000 lines into Java (as an example).
The AI successfully generates Java.
Technically, we converted the application. But I would hesitate to call that modernization.
We may simply have created a 7,000-line Java application that has the same complicated structure as the COBOL application.
The language changed.
The architecture did not.
That is why refactoring should often happen before transformation.
Imagine that one large COBOL program handles:

Customer Validation |
Account Validation |
Fee Calculation |
Payment Processing |
Audit Processing |
Reporting

Instead of converting the entire application, we might identify Fee Calculation as an independent business capability.
The architecture could gradually move toward:
+----------------------+
| Existing COBOL Core |
+----------+-----------+
|
v
+----------------------+
| Fee Calculation API |
+----------+-----------+
|
v
+----------------------+
| Fee Service |
+----------------------+
The service could still run on the mainframe, or it could eventually be implemented using Java depending on the business and technical requirements.

To me, that is a better modernization approach because we are working with a business capability instead of blindly translating source files.
IBM's Z Refactoring Assistant follows this general idea by helping teams identify and isolate business logic from larger COBOL applications.
This allows modernization to happen incrementally.
That is much less risky than a "rewrite everything" project.

6. Transform COBOL to Java — But Do It for the Right Reason
Once we understand and isolate a business capability, code transformation becomes much more practical.
Suppose we isolate this COBOL logic:

IF CUSTOMER-TYPE = 'P'
IF ACCOUNT-BALANCE > 10000
COMPUTE TRANSACTION-FEE =
TRANSACTION-AMOUNT * 0.005
ELSE
COMPUTE TRANSACTION-FEE =
TRANSACTION-AMOUNT * 0.010
END-IF
ELSE
COMPUTE TRANSACTION-FEE =
TRANSACTION-AMOUNT * 0.015
END-IF.

An AI-assisted transformation might create Java similar to:

public BigDecimal calculateFee(
String customerType,
BigDecimal balance,
BigDecimal transactionAmount) {

BigDecimal rate;

if ("P".equals(customerType)) {
    if (balance.compareTo(
            new BigDecimal("10000")) > 0) {
        rate = new BigDecimal("0.005");
    } else {
        rate = new BigDecimal("0.010");
    }
} else {
    rate = new BigDecimal("0.015");
}

return transactionAmount.multiply(rate);

}

Generating the Java itself is actually the less interesting part.
Many tools can convert simple logic.
The real value is everything that happened before the transformation.

We already know:
• where the COBOL logic came from
• which applications depend on it
• what the business rules are
• what data it requires
• what output it produces
• what needs to be tested

Having that context gives the developer a much better chance of getting the transformation right.
There is also research supporting this idea.
IBM researchers published work in 2026 on improving LLM-based COBOL-to-Java transformation by providing natural-language summaries of the original COBOL programs. Their results showed improvements in difficult transformation cases.
I found this research interesting because it supports something that makes sense in practice: the better we understand the COBOL application, the better chance we have of transforming it correctly.

7. AI-Generated Code Needs AI-Assisted Testing — and Human Validation
Code generation gets a lot of attention.
In a real modernization project, I would give testing just as much attention as code generation.
Imagine that our original COBOL program produces this result:

Customer Type: P
Balance: $15,000
Transaction: $1,000
Fee: $5.00

The transformed Java service should produce exactly the same business result.

We can build tests around this behavior.
For example:

@test
void premiumCustomerHighBalance() {

BigDecimal fee =
    feeService.calculateFee(
        "P",
        new BigDecimal("15000"),
        new BigDecimal("1000"));

assertEquals(
    new BigDecimal("5.000"),
    fee);

}

But we should not test only the obvious case.
The AI agent could inspect the original COBOL branches and identify test s

Scenarios:

Test 1:
Premium customer
Balance > $10,000

Test 2:
Premium customer
Balance = $10,000

Test 3:
Premium customer
Balance < $10,000

Test 4:
Standard customer

Test 5:
Zero transaction amount

Test 6:
Maximum transaction amount

Test 7:
Invalid customer type

At this point, AI is doing something more useful than simply producing code.

It is helping us prove that the new code behaves like the old code.
IBM watsonx Code Assistant for Z includes capabilities around Java generation and JUnit generation for this type of validation.
For a business-critical application, however, unit tests are only the beginning.
We may still need:
• integration testing
• regression testing
• performance testing
• security testing
• user acceptance testing
• production validation
A successful AI transformation is not one where Java compiles.
It is one where the business behavior remains correct.

8. Put Agentic AI Inside the DevOps Pipeline
The next step is connecting these capabilities with the development process we already use.
Modern mainframe development is increasingly connected to Git, automated builds, testing tools, code scanning, CI/CD pipelines and enterprise approval processes.

Agentic AI can become another participant in this pipeline.
Imagine a developer receives the following requirement:
Add a new validation rule for international payment transactions above $25,000.

Instead of manually starting from scratch, an agent could:

Search the application for international
payment processing.
Identify the relevant COBOL programs.
Find the existing transaction-limit rules.
Identify related copybooks and Db2 tables.
Perform impact analysis.
Explain the existing business logic.
Suggest the required code change.
Generate the proposed code.
Generate unit tests.
Run approved automated validations.
Update technical documentation.
Prepare the change for code review.

The developer reviews the results.
If everything looks correct, the change continues through the organization's normal approval and deployment process.
The AI agent does not have to replace DevOps.
It can work inside DevOps.

9. Mainframe Modernization Does Not Mean Moving Everything to the Cloud
For years, modernization conversations often started with one question:
How do we move this application off the mainframe?
I do not think that should always be the first question.
A better question is:
Where should each part of this application run?
For some workloads, the answer may still be the mainframe.
For others, Java, containers, APIs, or cloud services may make more sense.
A hybrid architecture could look like this:
+----------------------------------+
| Cloud |
| |
| Web / Mobile / Analytics / AI |
+----------------+-----------------+
|
| APIs / Events
|
+----------------v-----------------+
| Integration Layer |
+----------------+-----------------+
|
+----------------v-----------------+
| IBM Z |
| |
| COBOL | CICS | Db2 | IMS | MQ |
| |
| Core Transaction Processing |
+----------------------------------+

This architecture lets the organization continue using the strengths of the mainframe while also using modern cloud capabilities.
Agentic AI can help connect these environments.
For example, an agent could understand a COBOL transaction, document the interface, help expose the business capability through an API, generate a Java consumer, create tests and update the deployment pipeline.
I think the practical answer for many companies will be a mix of both: keep the right workloads on the mainframe and use cloud services where they make sense.

10. Human Approval Still Matters
When discussing agentic AI, it is easy to imagine a completely autonomous system.
For a production mainframe environment, I would be very careful with that idea.
These systems may process payments, customer accounts, healthcare claims, insurance policies, or other critical transactions.
An AI-generated change should not move directly into production simply because the AI says the change is correct.

A safer workflow would include human approval points.

                 AI Application Analysis
                         |
                         v
                 Mainframe Developer Review
                         |
                         v
                 AI Business Rule Extraction
                         |
                         v
                 Developer / Business Review
                         |
                         v
                 AI Refactoring Recommendation
                         |
                         v
                 Architecture Review
                         |
                         v
                 AI Code Transformation
                         |
                         v
                 Code Review
                         |
                         v
                 Automated Testing
                         |
                         v
                 Human Approval
                         |
                         v
                 Deployment

AI can certainly help developers move faster, but I would not use that as a reason to bypass normal engineering reviews and controls.
This becomes even more important when agents have access to development tools.

Organizations need to control:
• what source code an agent can access
• what data it can read
• which tools it can execute
• whether it can modify code
• whether it can create pull requests
• whether it can deploy anything
• what actions require human approval

The principle of least privilege should apply to AI agents just as it applies to people.

11. What Happens to the Mainframe Developer?
This may be the most important question for people currently working with COBOL and mainframe systems.
If AI can explain COBOL, generate Java, create tests and analyze dependencies, what happens to the developer?
I do not think the mainframe developer suddenly becomes unnecessary.
What I think will change is the type of work the developer spends time on.
Today, a developer may spend hours searching through programs to understand where a field is used.

An AI agent may reduce that work to minutes.
A developer may spend hours creating basic documentation.
AI can create a first draft.
A developer may manually create many repetitive unit tests.
AI can help generate them.

But someone still needs to answer harder questions.

Does this business rule make sense?
Is the AI missing an important dependency?
Should this function become a service?
Should this workload remain on IBM Z?
Is the generated Java maintainable?
Does the new application have the same performance characteristics?
Are the tests sufficient?
Is this change safe for production?

These are the areas where an experienced developer still adds a lot of value.
In fact, experienced mainframe developers may become extremely important in AI-driven modernization because they understand both the technology and the business behavior behind it.

The developer's role gradually moves from:
Write every line manually
toward:
Understand -> Direct -> Review -> Validate -> Approve
So I see the mainframe developer role changing, not disappearing.

A Practical Agentic Mainframe Modernization Architecture
Putting everything together, a future modernization platform could look something like this:
+----------------------+
| Developer / SME |
+----------+-----------+
|
v
+----------------------+
| AI Orchestrator |
| / Agent |
+----------+-----------+
|
+----------------+----------------+
| | |
v v v
+----------------+ +---------------+ +---------------+
| Application | | Source Code | | Documentation |
| Discovery | | Repository | | / Business |
| | | | | Rules |
+-------+--------+ +-------+-------+ +-------+-------+
| | |
+------------------+-----------------+
|
v
+----------------------+
| Application |
| Understanding |
+----------+-----------+
|
v
+----------------------+
| Business Rule |
| Extraction |
+----------+-----------+
|
v
+----------------------+
| Impact Analysis |
+----------+-----------+
|
v
+----------------------+
| Refactoring |
+----------+-----------+
|
v
+----------------------+
| COBOL -> Java / API |
| Transformation |
+----------+-----------+
|
v
+----------------------+
| Automated Testing |
+----------+-----------+
|
v
+----------------------+
| Human Review |
+----------+-----------+
|
v
+----------------------+
| CI/CD Pipeline |
+----------+-----------+
|
v
+----------------------+
| IBM Z / Hybrid Cloud |
+----------------------+

The language model is only one part of this architecture. What matters just as much is how it connects to the tools, application context, testing and approval process.
The agent needs access to the right tools and the right context. It also needs boundaries.

Without application discovery, the AI may not understand dependencies.
Without business context, it may misunderstand a rule.
Without automated testing, we cannot confidently validate transformation.
Without human review, we may accept a change that looks technically correct but is wrong for the business.

That is why agentic modernization should be viewed as an engineering workflow rather than simply an AI feature.

A Better Way to Start
Organizations do not need to begin by giving an AI agent millions of lines of COBOL and asking it to modernize everything.
If I were starting a project like this, I would begin with something small and manageable.
Choose one application that the organization understands well.
Map its dependencies.
Use AI to explain the programs.
Compare those explanations with what experienced developers know.
Ask AI to extract business rules.
Have business and technical teams validate them.
Then identify one small business capability.
Maybe it is:
• fee calculation
• account validation
• customer eligibility
• transaction routing
• interest calculation
Refactor that capability.
If there is a good business reason to transform it, generate the new implementation.
Create automated tests.
Compare the results with the existing COBOL application.
Then measure what happened.
Did developers save time?
Were the business rules identified correctly?
How much AI-generated code required correction?
Did test coverage improve?
Were any dependencies missed?
Did performance change?
Those results would give the organization something practical to evaluate instead of relying on an impressive AI demo.

Final Thoughts
For me, the most interesting part of agentic AI for mainframe modernization is not COBOL-to-Java or to a open source conversion.
We have had code-conversion tools for years.
The bigger opportunity is everything that happens around the conversion.
Can AI help us understand a 30-year-old application?
Can it show us how thousands of programs are connected?
Can it identify business rules that are buried inside COBOL?
Can it tell us what might break if we change a copybook?
Can it identify a business capability that can be separated from a monolithic application?
Can it generate tests that prove the new implementation behaves like the old one?
Can it work with our Git and DevOps processes while still keeping developers in control?
If the answer to these questions continues moving toward yes, agentic AI could change the way we approach mainframe modernization.
The modernization process may eventually look like this:
Discover -> Understand -> Extract -> Analyze -> Refactor -> Transform -> Test -> Validate -> Deploy
The important word in that sequence is still understood.
We should not modernize a system simply because AI can rewrite the code.
We should first understand what the system does, why it does it and what other systems depend on it.
Then we can decide what should remain in COBOL, what should be refactored, what should become an API, what should move to Java and what should integrate with cloud services.
That also changes the role of the mainframe developer.
Instead of spending most of the day searching through thousands of lines of code, developers can spend more time understanding business problems, reviewing architecture, validating AI-generated changes and making sure critical systems remain reliable.
The future of mainframe modernization, in my view, is not AI replacing COBOL developers.
It is also not cloud replacing the mainframe.
It is much more likely to be:
Mainframe + Cloud + DevOps + Agentic AI + Human Expertise
That combination gives organizations something they have been looking for a long time: a way to modernize critical mainframe applications without throwing away the business knowledge and reliability those systems have built over decades.
And that may be where agentic AI provides its greatest value.
Not by simply rewriting old code, but by helping us understand it well enough to decide what should happen next.

References and Further Reading
IBM. (2026). Announcing the IBM Bob Premium Package for Z: Accelerating enterprise mainframe application modernization.
IBM. (2026). IBM watsonx Code Assistant for Z.
IBM. (2026). Code explanation with IBM watsonx Code Assistant for Z.
IBM. (2026). Z Refactoring Assistant.
IBM. (2026). Modernize mainframe applications for hybrid cloud with IBM and AWS.
Bhardwaj, A., Arya, V., & Sabharwal, Y. (2026). Refining LLM-Based COBOL-to-Java Translation via Natural Language Summary Augmentation. IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER 2026). IBM Research.
Parziale, L., et al. (2023). Mainframe Application Modernization Patterns for Hybrid Cloud. IBM Redbooks, SG24-8532-00.

Mainframe Modernization: Why Mainframe and Cloud Technology Should Work Together

somnath roy — Mon, 14 Sep 2026 04:30:03 +0000

Executive Summary
For many years, companies have discussed whether mainframe systems should be replaced by newer technology. As cloud adoption has increased, the question of whether companies still need mainframes has become more important. Cloud technology gives companies many useful options. It can help teams build new applications faster, connect systems more easily and use modern tools for reporting, data analysis and artificial intelligence. For most companies, these advantages are now too important to ignore.
However, I do not see complete mainframe replacement as the right answer in every situation. Mainframes are still very good at what they were built to do. They can process a very large number of transactions in a short period of time and they can do it in a stable and controlled way. This is especially important in banking, payment processing, insurance and other businesses where even a small delay or processing mistake can create a serious problem. Earlier, many companies tried to move everything away from the mainframe. The idea was usually to reduce cost and move to a more modern platform. In practice, these projects were often harder than expected. The new system did not always match every function of the old system. Some business rules were missed. Performance was sometimes different. In other cases, the new system worked for normal transactions but was not trusted enough for unusual or high-volume situations. Because of that, the old mainframe had to stay in production along with the new system.
When both systems have to run in parallel, the expected savings can disappear. The company must support two environments, two sets of technology and sometimes two development and support teams. Instead of reducing cost, the company may end up spending more money and carrying more operational risk. For that reason, a more practical approach is to keep the mainframe for the work it does best and use cloud technology for the areas where cloud gives a clear advantage. For a transaction-processing business, this is usually a more realistic approach because it reduces the amount of change and risk taken at one time.

Introduction
Modernization discussions usually start because the business wants faster delivery, lower operating costs, or easier integration with newer applications. The challenge is deciding how much of the existing system actually needs to change. New tools come into the market every year and cloud computing has become one of the biggest changes in the technology industry. Because of this, older systems are often questioned. Mainframe systems are one of the first areas that companies look at because many of these applications have been running for decades.
It is easy to understand why management may want to replace a mainframe. The technology may look old compared with newer cloud platforms. Some programs may be written in older languages and the company may be worried about finding people with the right mainframe skills. Mainframe software and support can also be expensive. These are valid concerns. However, replacing a mainframe should not be treated as a simple technology upgrade. It can affect the core of the business. A mainframe application may contain many years of business rules and processing knowledge. Some of these rules are well documented, but many are not. Changes may have been added over time for certain customers, products, regulations, or special cases. The system may look complicated, but much of that complexity exists because the business itself is complicated. A new platform has to understand and reproduce all of that behavior before the old system can safely be removed.
This supports a balanced approach to modernization. The mainframe should stay where high transaction volume, speed, reliability and accuracy are most important. Cloud technology should be used where it can make the company more flexible and help teams deliver new services faster. The more useful question is not which technology is newer, but which platform is better suited to a particular workload. The goal should be to use each one where it makes the most sense.

Why Mainframes Still Matter
Mainframes are certainly older than most cloud technologies, but age alone is not a good reason to replace a system that is still doing its job well. In many large companies, the mainframe still supports the most important business functions. The reason is simple: these systems have been built to handle very large workloads for a long time and they are known for stable transaction processing.
Performance during peak transaction periods can be very different from performance under normal load. A system that looks successful during regular testing may behave differently when transaction volume increases significantly. A payment platform may receive transactions from many merchants, banks, networks and customers at the same time. The system needs to respond quickly, but speed is only one part of the requirement. The transaction also needs to be accurate. It must not be lost, duplicated, or posted to the wrong account. The system must also stay available when transaction volume suddenly increases. Mainframes have handled this type of work for many years. They are designed to process a high number of transactions at the same time while keeping data consistent. This matters in financial systems because a small error can have a large effect when the volume is high. A system that works well for normal traffic but slows down during peak traffic may not be good enough for a payment processor or a large bank.
What makes replacement especially difficult is the amount of business knowledge accumulated in these systems. A mature mainframe application is more than just code. It is the result of years of fixes, improvements, production issues, customer requests and business changes. Every time a problem was found, someone may have added a rule or control to prevent it from happening again. Over time, the system became very stable because it learned from real business situations.
A new system does not get this history automatically. Even if the new design is technically better, it still has to prove that it can handle the same real-world situations. That can take time. This is one of the main reasons companies become uncomfortable when they try to turn off the old system too early.

Cloud Technology Cannot Be Ignored
Keeping the mainframe does not mean a company should stay with old technology everywhere. One major advantage of cloud technology is the speed at which teams can build and test new services. This is particularly useful for customer-facing applications, where changes may be needed much more frequently than in the core transaction-processing system. Companies can create new environments quickly, increase or reduce computing capacity when needed and use many services without buying and managing all the hardware themselves.
Cloud platforms are also very useful for software development. Teams can automate testing and deployment, build smaller services and release changes more often. This can help a company respond faster to customer needs. For customer-facing applications, this speed can be very important because customers now expect frequent improvements in mobile apps, websites, alerts and online services.
Cloud platforms also make modern data tools easier to use. Reporting, analytics, machine learning and artificial intelligence can be added without changing the core transaction engine. A company can move data to a cloud platform for analysis while keeping the actual financial transaction on the mainframe. In many cases, this gives the company the benefit of modern technology without putting the core processing at unnecessary risk.
Integration is another strong area for cloud technology. Modern applications usually need to connect with many systems. APIs and messaging services can create a cleaner way for these systems to communicate. A mobile application does not need to know how the mainframe works internally. It only needs a reliable interface to request information or submit a transaction. APIs make this combination practical. A customer-facing application can change without requiring the team to redesign the transaction-processing system behind it.

Why Complete Mainframe Replacement Is So Difficult
A complete mainframe replacement sounds simple when it is described in a presentation. The company has an old system, so it builds a new system and moves the business to it. The real work is very different. A large mainframe environment may contain thousands of programs, many databases, files, interfaces, batch jobs, online transactions and links to other internal and external systems.
The programming language itself is usually not the hardest part of modernization. The harder part is understanding years of business rules, exceptions and dependencies that have become part of the existing system. A program may have changed hundreds of times over many years. Some changes may support one customer. Others may support a legal requirement or a product that is used only in a certain country. Some logic may run every day, while other logic may run only at month end or year end.
These less common cases are easy to miss when a new system is being designed. During normal testing, the new system may look correct. The problem may appear later when a rare transaction enters production. At that point, the team may discover that the old mainframe handled a condition that was never included in the new design.
Documentation does not always solve the problem. In older systems, documents can be incomplete or out of date. Sometimes the only place where the real rule exists is in the working program itself. This means the replacement team has to study the current behavior very carefully. That work takes time and depends heavily on people who know the business as well as the technology.
Much of the unexpected time in modernization can be spent understanding existing business rules rather than writing the new code. A rule that looks unimportant may support a particular customer or transaction condition, so the team has to understand it before deciding whether it can be removed. The team is not just moving code. It is trying to rebuild years of business behavior on a new platform while the current business continues to change.

The Performance Challenge
Performance is another area where companies need to be careful. Mainframes are made for high-volume transaction processing. They can handle many requests at the same time and are designed to keep processing stable even when the workload is heavy.
A cloud or distributed system can also process very large volumes. The problem is that the design may be much more spread out. One business transaction can move through several services, databases, networks and message queues before it is complete. Each step may add a small amount of time. For one transaction, the delay may not matter. For millions of transactions, it can become important.
The new platform may need additional servers, caching, database tuning, message processing, monitoring and other controls just to reach the same response time as the current system. I am not suggesting that cloud platforms cannot handle large transaction volumes. They clearly can. My point is that performance should be proven using the complete architecture and realistic transaction volumes rather than assumed simply because the platform is newer.
If the mainframe already meets the business requirement and handles peak periods reliably, the company should ask what business value will come from moving that workload. If the answer is only that the new technology looks more modern, the cost and risk may not be worth it.

What Earlier Replacement Efforts Can Teach Us
Many companies have already tried large mainframe replacement programs. Some have succeeded, but others have faced delays, higher costs, or problems with the new system. A common situation is that the old system has to stay active during the entire replacement project. The business cannot stop processing transactions while a new platform is being built.
This means the company starts paying for both environments. The mainframe still needs support because it is running the business. At the same time, the company is paying for the new platform, new development work, testing, infrastructure and training. This may continue for several years.
The real difficulty comes near the end of the migration. Building the new platform is one challenge; becoming confident enough to switch off a system that has reliably processed transactions for years is another. Maybe some functions are still missing. Maybe performance is not the same during peak periods. Maybe certain customer cases work differently. Management then has to decide whether it is safe to shut down the old platform.
If management is not confident enough to retire the mainframe, the company can end up in an uncomfortable middle state: the new platform is running, but the old platform cannot be switched off.. This is where the project can create the opposite result from what was planned. The company wanted to reduce cost and complexity, but now it has two systems to maintain. Some products may run on one system and other products on another. Teams may need to investigate problems across both platforms. Business changes may also need to be made twice.
Success should be measured by whether the change actually reduces operating complexity, improves reliability, or provides a clear business benefit. Simply moving a large percentage of applications to a new platform does not necessarily mean the program was successful. It should be measured by whether the business becomes simpler, safer and more efficient after the change.

The Cost of Keeping Two Systems in Parallel
Running two complete systems for the same business function can become very expensive. Both systems need people, monitoring, security, testing, software and production support. The company may also need to keep data synchronized between them. If the same business rule exists in two places, it may need to be maintained in two places as well.
Testing becomes more complicated because the company may need to compare results from the new system with results from the mainframe. Any difference has to be studied. Sometimes the new system is wrong, but sometimes the difference is caused by an old rule that nobody knew about until the comparison was done.
The cost is not only technical. Employees also need to understand which system is used for which customer or product. Support teams may have different procedures. Operations teams may need different tools. This makes the whole environment harder to manage.
For this reason, I do not think a company should build a full duplicate platform unless there is a very clear and realistic plan to remove the old one. If the new system cannot fully replace the mainframe, the company may be better off building new services around the existing mainframe instead of creating a second complete copy of it.

A Better Approach: Mainframe and Cloud Together
For these reasons, a hybrid modernization strategy is more practical than a complete replacement strategy. Proven high-volume transaction processing can remain on the mainframe while services that benefit from cloud flexibility are moved gradually. The mainframe can continue to handle the work where it is already strong, especially critical and high-volume transaction processing. Cloud technology can then be used for new digital services, reporting, analytics, customer applications, artificial intelligence and other areas that need more flexibility.
This approach changes the goal. Instead of asking, 'How do we remove the mainframe?' the company asks, 'Which part should stay on the mainframe and which part will benefit from cloud technology?' That is a much more practical question.
For example, a mobile application can run in the cloud and still use the mainframe to complete a payment or update an account. The customer sees a modern application, but the core transaction is handled by the trusted system. If reporting needs more flexibility, data can be moved to a cloud platform for analysis without moving the full transaction engine.
This also gives the company more choices in the future. If a certain mainframe function becomes easy and safe to move later, it can be moved. If another function continues to perform well on the mainframe, there is no need to force it to move. The architecture can change step by step instead of through one very large replacement project.

The Role of APIs
APIs are very important in this type of combined environment. They allow modern applications to use mainframe functions without needing to understand the mainframe itself. A cloud application can send a request through an API and the API can pass the request to the mainframe and return the result.
This creates a useful separation between the old and new technology. A developer working on a mobile application does not need to know every detail of the mainframe program. The developer only needs to understand the API. At the same time, the mainframe team can continue to manage the core processing behind that interface.
APIs can also help a company modernize gradually. Instead of rewriting a large application all at once, the company can expose useful business functions one at a time. New cloud-based services can then use those functions. Over time, the company can decide whether any of the underlying services should move to another platform.
This approach allows the team to modernize one business function, test it under real conditions and learn from the result before moving the next function. This limits the impact if something does not work as expected.

Lower Investment and Shorter Migration Time
A full replacement usually requires a large amount of money before the company sees the final result. Applications have to be rebuilt, data has to be moved, interfaces have to be changed, security has to be redesigned and employees have to be trained. Large testing programs are also needed because the new system has to prove that it can handle the same work as the old one.
A combined approach can spread the investment over smaller projects. The company can first modernize an area where the benefit is clear. It may move reporting or analytics. Later, it may redesign a customer portal or add a new cloud service. The mainframe can continue to process the core transactions during these changes.
With a smaller migration, the team has fewer changes to test at one time and can identify problems more easily. If the result is not what was expected, correcting or rolling back that change is also more manageable. If one change does not work as expected, the problem is limited. The company can learn from it before starting the next change. This can also make budgeting easier because the company is not depending on one very large project to succeed after several years of work.
Migration time is also reduced for each part of the business. The company does not have to wait for the complete replacement before users see any improvement. New functions can be delivered while the existing core continues to run. This helps the business receive value earlier and lowers the pressure on the replacement team.

Reducing Business and Operational Risk
Risk is one of the biggest reasons to avoid a big-bang replacement. Moving a large number of customers, transactions and interfaces to a new system at the same time can create a serious business impact if something goes wrong. Even a small issue can become large when the transaction volume is high.
A gradual approach makes each change smaller. A new service can first be tested with limited traffic. The team can watch response time, errors and customer impact. If the result is good, more traffic can be moved. If there is a problem, the team can fix it without affecting the full business.
This approach also gives operations teams time to learn the new environment. Monitoring, support, incident handling and recovery procedures can be tested as the new technology is introduced. These operational details are sometimes overlooked in a large replacement program because so much attention is placed on development.
For a transaction-processing system, introducing changes in smaller steps and observing how they behave in production can reduce risk. When millions of transactions may be involved, even a small problem can quickly become a much larger operational issue. A controlled change is usually easier to understand and manage than a full replacement of a system that is already critical to daily operations.

Protecting Business Knowledge
One of the most valuable parts of a mature mainframe application is the business knowledge inside it. A company may think of the system as old code, but that code may contain years of rules and lessons from real production experience.
Some rules exist because of customer agreements. Others may exist because of regulations. Some may have been added after a production problem many years ago. The people who created those rules may no longer work for the company and the documentation may not explain all of them clearly. If the system is rewritten too quickly, some of that knowledge can be lost. The new team may understand the major business flow but miss a small condition that is important only in a rare case. The problem may not appear during testing because the rare case does not happen often.
Keeping the mainframe for core processing gives the company more time to understand and document these rules. Functions can then be moved later when the team is confident that the business behavior is fully understood. This is safer than assuming every detail can be discovered at the start of a large replacement program.

Security, Compliance and Skills
Security and compliance are important in any technology environment, especially in financial services and payment processing. Mainframes have strong security controls and have been used for sensitive processing for many years. Cloud platforms also provide strong security tools, but they have to be designed and configured correctly. Moving an application to the cloud does not automatically make it more secure. The company still has to manage identity, access, encryption, networks, logging and data protection. In a distributed design, there may also be more connections between services and each connection needs to be protected.
A combined architecture can give the company flexibility. Sensitive transaction processing can remain on the mainframe while cloud services are used for functions that need easier scaling or faster development. Security then becomes part of the complete design instead of a reason to force all workloads onto one platform.
Mainframe skills are another concern. Many experienced mainframe employees are getting closer to retirement and younger developers often have more experience with cloud technology. This is a real issue, but removing the mainframe is not the only answer. Companies can improve documentation, train new people and use APIs so that fewer developers need deep mainframe knowledge. At the same time, experienced employees can transfer important business knowledge before they leave.

A Practical Modernization Roadmap
A practical modernization program should start by understanding the current environment. Before deciding what to move, the company needs to know which applications are critical, how many transactions they process, what systems they connect to and what business rules they support.
The next step is to group workloads based on what they really need. Workloads that require very high transaction volume, low response time, strong consistency and high availability may be good candidates to stay on the mainframe. Workloads that need rapid development, flexible scaling, modern analytics, or frequent customer changes may be good candidates for the cloud. After that, the company can create a clean integration layer using APIs and messaging. This allows cloud applications and mainframe applications to work together in a controlled way. The company can then modernize one area at a time instead of changing everything at once.
Reporting, analytics, customer portals, alerts and new digital services may be good early areas because they can show business value without changing the core transaction engine. More critical workloads can be reviewed later. They should move only when the new platform has clearly proved that it can meet the required performance, reliability, security and cost targets.
This type of roadmap is slower than making a bold announcement that the mainframe will be gone by a certain date, but it is usually more realistic. It allows the company to make decisions based on results instead of assumptions.

Cost and Business Value
Cost is often one of the main reasons companies consider moving away from a mainframe. Mainframe software and support can be expensive. However, cloud cost can also become high when a system runs all the time and processes very large volumes. The cost model is different, but it is not automatically cheaper.
The company should look at the full cost of ownership. That includes infrastructure, software, cloud usage, storage, network traffic, employees, testing, monitoring, security, training, migration work and ongoing support. It should also include the cost of keeping the old platform if the new one cannot fully replace it. Business value is even more important than the technical cost comparison. If moving a workload improves customer service, helps the company release products faster, or reduces a real business risk, then the move may be worth the investment. If the main reason is only to say that the company no longer uses a mainframe, the value is much less clear.
The first question in modernization should be what business problem the change is intended to solve. Moving to a newer platform may sound attractive, but if it does not improve cost, reliability, delivery time, or customer experience, then it is difficult to justify the change.

Customer Experience Should Come First
Customers usually do not care which computer system processes their transaction. They care about whether the service works. They expect the transaction to be fast, correct, secure and available when they need it.
For a payment customer, there is no extra value in knowing that a transaction moved from a mainframe to the cloud. If the change makes the transaction slower or less reliable, the customer may actually have a worse experience. On the other hand, the customer may notice a better mobile application, faster alerts, easier reporting, or a more useful website. These are areas where cloud technology can provide a clear benefit.
This is why the architecture should be built around the customer and the business requirement. The core transaction should run on the platform that provides the best result. The customer-facing service should use the technology that helps the company improve the experience quickly. There is no rule that both parts have to run on the same platform.

Recommendations
Based on these points, companies should avoid treating mainframe replacement as the only path to modernization. The mainframe should continue to support important, high-volume transaction processing as long as it remains reliable, secure and cost effective. Cloud technology should be used where it clearly improves flexibility, development speed, integration, analytics, or customer experience. Companies should also avoid creating a second complete platform unless they are very confident that the original platform can be retired. Running two full systems for a long period can increase cost and make operations more difficult. A better plan is to connect modern services to the mainframe and move functions gradually when there is a clear reason to do so.
APIs, good documentation, automated testing, monitoring and knowledge transfer should be part of the modernization plan. These are practical investments that make the current environment easier to manage and make future changes safer.
Before moving a workload, the business problem being solved should be clearly understood. If the move improves customer experience, reduces a measurable cost, speeds up product delivery, or reduces operational risk, then there is a clear reason to consider the migration. New technology is valuable, but newer does not always mean better for every workload. The company should choose the platform that gives the best mix of performance, reliability, cost and flexibility.

Conclusion
Mainframes continue to play an important role in companies that process a very large number of transactions in a short period of time. Their strength is not that they are old or familiar. Their strength is that they have proved that they can process critical workloads with high reliability and stable performance.
Cloud technology is also important and should be part of the future. It gives companies faster development, easier access to modern tools, flexible computing, better integration options and strong support for data and analytics. A company that ignores these advantages will have a hard time keeping up with changing customer needs. The mistake is to think that modernization requires one technology to completely replace the other. In many cases, that creates more risk than value. Earlier replacement efforts have shown that if the new system cannot fully match the old system, both platforms may end up running together anyway. When that happens, cost and complexity can increase instead of decrease.
A combined mainframe and cloud approach is more practical. The mainframe can continue to handle the transaction workloads where it is strongest. Cloud technology can support modern applications, data services, customer tools and new business capabilities. APIs can connect the two environments so they work as one overall system. This approach can reduce the amount of money that has to be spent at the beginning, shorten the time needed for each migration step and lower the chance of a major failure. It also protects the business knowledge already built into the mainframe and gives the company time to move functions only when it is safe and useful to do so.
In the end, modernization should not be measured by how much old technology a company removes. It should be measured by whether the company becomes more reliable, flexible and efficient. For high-volume transaction processing, the mainframe may continue to be the right platform for many years. Cloud technology can still play a major role around it. Using both technologies where they provide the most value is a more practical strategy than replacing a proven system simply because a newer technology is available.

References
• Parziale, L., et al. (2023). Mainframe Application Modernization Patterns for Hybrid Cloud. IBM Redbooks, SG24-8532-00.
• Loomis, S., et al. (2023). Accelerate Mainframe Application Modernization with Hybrid Cloud. IBM Redbooks, REDP-5705-00.
• IBM. (2026). What is Mainframe Modernization? IBM Think.
• IBM. Mainframe Application Modernization with IBM Cloud and IBM zSystems. IBM.
• Amazon Web Services. AWS Mainframe Modernization – User Guide. AWS Documentation.
• Amazon Web Services. Modernization Approach – AWS Mainframe Modernization. AWS Documentation.

Mainframe Modernization with Python for High-Volume Transaction Processing

somnath roy — Mon, 20 Jul 2026 00:42:17 +0000

I have worked as a mainframe programmer for more than 15 years, so I understand how important speed, stability, and transaction volume are. Mainframe modernization should not be treated as a simple technology replacement. The new Python-based system must be designed to process large volumes of data within a very short time. Python can support this goal when it is combined with efficient frameworks, parallel processing, and strong database design. The modernization should begin by separating the mainframe functions into smaller and manageable services. Each service should be tested with actual transaction volumes before moving it into production.

The migration should be completed in phases so that business operations are not disrupted. Historical data should be cleaned, validated, and moved before the final cutover. Real-time transaction data should then be transferred through controlled and secure migration processes. The mainframe and the new system should not continue running together for a long period because it can create duplicate processing, extra cost, and data differences. After a short and controlled validation period, the mainframe application should be stopped once the Python system is confirmed to be stable. Strong monitoring, automatic alerts, rollback planning, and support teams should be ready during the cutover. This approach can reduce processing time, handle high transaction volumes, avoid unnecessary redundancy, and complete modernization with minimum business disruption.