Mainframe modernization has long been treated as synonymous with migration. The logic seemed simple enough: the more applications moved out of the legacy environment, the more modern the architecture would become.
The market is beginning to rethink that assumption.
The State of Mainframe Modernization 2025, from Kyndryl, surveyed 500 business and technology leaders and found a far less linear picture: 80% of organizations changed their modernization strategy over the past 12 months.
At the same time, 56% increased their use of the mainframe, while the average share of applications planned to move off the platform fell from 36% in 2024 to 28% in 2025.
This does not mean companies have abandoned cloud, replatforming, or distributed architectures. It means something more interesting: modernization is becoming less about the technology destination and more about making the right decision for each workload.
Migration is one possible path to modernization, but it is not the definition of modernization.
A workload can remain on IBM Z and still be deeply modernized through APIs, new interfaces, automation, DevOps practices, cloud integration, and new ways of accessing data.
Likewise, an application can be moved to another platform while still carrying inefficient processes, legacy dependencies, and an architecture that is difficult to maintain.
Moving does not necessarily mean modernizing.
This distinction matters because a strategy based on migration volume tends to treat very different applications as if they shared the same problem. They do not.
Systems differ in terms of:
- business criticality;
- transaction volume;
- low-latency requirements;
- dependency on existing data and applications;
- regulatory requirements;
- frequency of change;
- operating costs;
- integration with other environments.
A workload supporting millions of financial transactions should not be evaluated using the same criteria as a low-volume peripheral application.
When the strategy starts with the target platform, these differences emerge late in the process. When it starts with the workload, they shape the decision from the beginning.
Staying can also be a modernization decision
The Kyndryl data is especially relevant because it reveals an apparent contradiction: while many organizations continue to migrate parts of their portfolios, 95% said their mainframe usage remained stable or increased over the past year.
The study also indicates that 56% of workloads considered mission-critical continue to run on the platform.
This helps dismantle a long-standing binary view: mainframe or cloud.
In practice, today’s enterprise architecture looks much more like mainframe and cloud and APIs and distributed data and digital applications.
The goal is not to choose a winner, but to determine where each component delivers the best combination of performance, risk, cost, availability, and ability to evolve.
In some cases, that means migrating. In others, integrating. In many, it means modernizing the workload where it already runs.
Kyndryl’s research itself reflects this movement, identifying hybrid models as predominant and showing that organizations are combining modernization on the mainframe, cloud integration, and selective application migration.
Every migration has an explicit business case. The problem lies in the costs that tend to appear after that business case has been approved.
Moving a critical application may require rebuilding:
- integrations;
- security controls;
- availability mechanisms;
- operational logic;
- recovery processes;
- monitoring;
- knowledge accumulated over decades of operation.
And applications rarely exist in isolation.
They access data, call other programs, participate in batch processes, respond to APIs, and depend on behaviors built up over time. The more tightly coupled they are, the greater the chance that an apparently localized decision will produce consequences elsewhere in the architecture.
That is why the true cost of modernization is not simply the cost of the target platform.
It must also account for the cost of rebuilding what already worked, operating through the transition, and maintaining the new dependencies afterward.
That calculation may still favor migration, but it needs to happen before migration becomes an objective in itself.
Stay, integrate, or move?
A more pragmatic strategy starts by classifying workloads before selecting technologies.
There are at least three paths.
1. Modernize on the mainframe
This makes sense when the workload depends heavily on the characteristics of the existing environment: high transaction volumes, proximity to critical data, availability, security, deep integration with other core systems, or specific performance requirements.
In this case, modernization may mean exposing APIs, improving the development lifecycle, automating testing, evolving interfaces, optimizing code, and making integration with the rest of the architecture easier.
The system stays. The way you work with it changes.
2. Integrate with new platforms
In many cases, the value lies precisely in the combination.
The mainframe continues to handle critical transaction processing while cloud, analytics, AI, or new digital applications consume services and information coming from that core.
The challenge then becomes interoperability, governance, observability, and the ability to make these environments operate as a single architecture from the business perspective.
3. Migrate selectively
Some workloads have a business case that clearly favors another platform.
Applications that are less tightly coupled to the core, systems with different scalability requirements, or components whose evolution is constrained by the existing architecture may justify replatforming, refactoring, or replacement.
In these cases, migration is modernization because the change solves a concrete problem.
The key word is selectively.
The right workload requires better questions
Before deciding where an application should run, some questions are more useful than debating technology.
Where is the data it depends on?
Moving processing while the data remains in another environment can introduce latency, additional integrations, and new costs.
What is the impact of downtime?
The higher the cost of an interruption, the greater the weight that resilience and predictability should carry in the decision.
How much does the application need to change?
A stable, highly critical workload may require a completely different strategy from an application that evolves continuously.
What problem are we trying to solve?
Cost? Time to market? Scalability? Skills? Integration? Developer experience?
Without an objective answer, modernization risks becoming a technology replacement exercise in search of a problem.
And what is the cost of staying?
That question also needs to be asked. Arguing for a more rigorous migration analysis does not mean automatically defending the status quo. Workloads that are inefficient, difficult to maintain, or unable to keep pace with the business also carry costs that need to be addressed.
The point is not to stay. It is to choose.
Hybrid architecture is not necessarily an intermediate stage
Hybrid architectures are often presented as a transitional phase: keeping part of the legacy estate while a complete migration is still underway. That view is also becoming outdated.
Kyndryl’s findings show organizations modernizing simultaneously on the mainframe, with the mainframe, and off the mainframe, while reporting ROI across all three approaches.
Depending on the approach, respondents reported returns ranging from 288% to 362% on their modernization initiatives.
This suggests there is no single end-state architecture.
For some organizations, a well-integrated hybrid environment is not an incomplete stage of modernization. It is the most rational end-state architecture.
The challenge shifts from eliminating different platforms to reducing friction between them.
Modernization means making better decisions about what already exists
The most interesting finding in Kyndryl’s research is not the increase in mainframe usage. It is the fact that 80% of organizations changed their strategy in just one year.
That points to a market that is less willing to follow rigid roadmaps defined five years ago and more willing to reassess decisions as technology, regulation, costs, and business needs change.
In mission-critical environments, that is maturity.
Modernization should not be a campaign to keep everything on the mainframe. Nor should it be a campaign to move everything off it.
It is an ongoing process of evaluating what stays, what integrates, what changes, and what genuinely needs to move.
Eccox’s experience in critical environments follows this logic. Before replacing an architecture, organizations need to understand dependencies, risks, costs, and the role each workload plays within the operation.
The most expensive modernization initiative is not always the one that requires the largest investment. Sometimes, it is the one that moves the wrong workload for the wrong reason.
If your organization still measures modernization progress by the number of applications that have left the mainframe, it may be time to change the metric.