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.
Top comments (0)