Application modernization is the process of updating older software so it runs on current languages, frameworks, and platforms. The process itself can be compared to remodelling a house in order to make it safer, stronger, better in line with the present, and ready to last a long time. The modernization process is best suited for legacy applications as it extends the life of organizations’ solutions while taking advantage of technical innovation. The hard part is picking the right strategy for each application. In 2026, two forces shape that choice: AI tools now handle a large share of routine upgrade work, and new EU rules have put firm dates on security obligations.
Why application modernization matters in 2026
Application modernization allows a company to update a piece of software with fewer resources than developing a new one would cost. It also lets a team adopt newer tools and languages gradually instead of betting everything on a rewrite. A well-chosen application modernization strategy can reduce the resources required to run an application, increase the frequency and reliability of deployments, and improve uptime and resiliency.
To avoid sounding unfounded, let’s look at some numbers. Worldwide spending on digital transformation is forecast to reach almost $4 trillion in 2027, according to IDC, with AI and generative AI driving much of the growth. Yet inside most organizations, legacy tech acts as an anchor on that investment.
For context, U.S. federal agencies typically spend about 80% of their IT budgets on operating and maintaining existing systems, according to the US Government Accountability Office.
Inside most enterprises, though, legacy systems drive that spending up. In a Pega survey of more than 500 IT decision makers, 68% said legacy systems keep their organization from operating as effectively as possible. Almost half (48%) would like to stop supporting their legacy applications but can’t, because the business still depends on them. Moreover, the study found that this technical debt now slows down AI adoption as well.
That trap has a price. Pega also estimates that the average global enterprise wastes more than $370 million a year because it can’t modernize legacy systems efficiently, and 78% of respondents agreed that the money spent maintaining legacy applications could go to more productive projects.
For a breakdown of the direct and hidden costs of legacy systems, from lost productivity to security exposure, plus typical modernization budgets, see our guide on how legacy system modernization helps reduce hidden costs.
The timing matters, because modernization itself has become much cheaper. Projects used to be shelved because they took years and cost hundreds of millions. Based on its project experience, McKinsey reports that generative AI can speed up modernization timelines by 40 to 50% and cut the costs that come from technology debt by 40%.
Later research points the same way, with an important condition attached. BCG finds that matching the right AI to the right task can cut modernization costs by 25 to 35% and speed up delivery by 30 to 40%. The gains come from modernizing selectively, on systems that matter to the business, rather than from a blanket technical upgrade.
Analysts expect this way of working to become the norm. Gartner projects that by 2029, organizations will complete 90% of software modernization with AI-augmented tools, up from less than 15% at the time of the research, and that GenAI will cut modernization labor costs by 50% compared with 2025 levels.
In short, the cost of keeping legacy systems keeps rising, while the cost of modernizing them is falling. Below, we examine in more detail the two main forces – technological and regulatory – that shape how teams execute these updates in 2026.
Two forces shaping application modernization in 2026
AI tools now do much of the upgrade work
The biggest shift in recent years is in who, or what, does the mechanical part of modernization.
A good example is Amazon’s internal Java upgrade program. CEO Andy Jassy reported that Amazon Q turned Java 17 upgrades from a multiweek chore into a task of a few hours per application. Amazon estimates the program saved about 4,500 developer-years of work.
Beyond Java, the tooling now covers whole platforms. In May 2025, AWS made AWS Transform generally available, with AI agents for .NET, mainframe, and VMware workloads. For mainframes, the service breaks monolithic COBOL applications into smaller components that teams can modernize one at a time.
The catch is that these tools move the bottleneck instead of removing it. Code changes get cheaper, while test coverage, review capacity, and knowledge of old business rules become the limiting factors. In planning terms, this means budgeting more time for testing and less for editing code by hand.
Compliance deadlines shape the schedule
In the EU, regulation has turned some modernization work from optional into time-bound. The Digital Operational Resilience Act (DORA) has applied to financial entities since January 17, 2025, and it sets rules for ICT risk management and for the third-party ICT providers those entities rely on.
Meanwhile, the Cyber Resilience Act reaches deep into the software industry. Since September 11, 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents, and the first notice is due within 24 hours.
Legacy components that nobody can patch quickly make that deadline hard to meet, which gives teams a practical reason to modernize them first.
Application modernization strategies to consider in 2026
So let’s take a look at some of the most innovative legacy application modernization strategies your company can use in the upcoming year.
TIME Chart prioritization
When choosing which application modernization strategy is right for you, you need to prioritize them based on the business value and functionality of each one. In turn, this helps manage application modernization in the most efficient and cost-effective way. By tracking the workload characteristics of each application, it is possible to gain a better understanding of which apps are more critical for the business, what parts of them can be migrated and how.
Gartner’s Portfolio Triage Process is widely used as part of one of the best application modernization strategies.
In short, it scores each application on two axes. Technical fit covers code quality, maintainability, and security posture. Business value, on the other hand, measures how well the application supports what the company needs. Together, the two scores place the application in one of four quadrants.
- Tolerate. The application is technically sound but adds limited business value. Keep it running with minimal investment.
- Invest. The application is both technically strong and highly valuable to the business. Keep investing to extend and improve it.
- Migrate. The application is valuable to the business but built on weak or outdated technology, such as unsupported software or knowledge held by a few people. Move it to a modern platform.
- Eliminate. The application offers little business value and has poor technical fit. Retire it or consolidate it into other systems.
Once the TIME chart has been drawn up, the place of each application in the company’s processes becomes clear. The actions that need to be taken to increase the apps’ efficiency and value also become apparent.
Bendigo Bank shows what the Eliminate quadrant can deliver at scale. Back in 2019, the Australian bank ran eight core banking systems. Over a six-year simplification project, it consolidated them into one and moved all 2.9 million customers onto a single platform, finishing with the migration of more than 180,000 Adelaide Bank accounts in December 2025. With the duplicate systems gone, the bank’s teams no longer repeat the same work across platforms.
Gartner’s seven modernization options
As a first step, build your IT capabilities around your business goals. For example, if a retailer needs to achieve better customer segmentation, the best solution would be to develop advanced analytics capabilities and a centralized database. After identifying the application that needs modernization, it’s time to move on to choosing an approach from Gartner’s list of application modernization strategies. Here they are, roughly from least to most invasive:
Encapsulate
The application stays as it is, and its data and functions become available to other systems through APIs. It is the fastest way to connect a stable legacy core to mobile apps, partners, or new analytics, although the old code still needs the same people and patches.
BNP Paribas took this route to open up its mainframe without rewriting it. The bank exposes services running on its IBM Z systems as REST APIs through IBM z/OS Connect, so newer applications can call core functions directly. Since October 2025, the same API layer can also publish those services as Model Context Protocol tools, which makes an encapsulated mainframe reachable for AI agents as well.
Rehost
As part of this approach, a separate application component is redeployed into another infrastructure (physical, virtual, or cloud) without recompiling, changing the code, or modifying any features or functions.
Shutterfly Business Solutions recently used exactly this approach. Their on-premises VMware environment of about 2,000 virtual machines kept running into capacity limits, so the team first rehosted it on VMware Cloud on AWS as a bridge. From there, it moved around 800 systems to native AWS services and carried workloads on operating systems near end of life over as is. The migration finished in March 2025, six months ahead of plan, and cut operating costs by about 25% through license avoidance and right-sizing.
Replatform
The component moves to a new runtime platform with minimal code changes, such as a newer language version, a managed database, or containers.
One of the best examples here is Amazon. The company replatformed tens of thousands of its own production applications from Java 8 or 11 to Java 17 with the help of Amazon Q Developer. The move to a current runtime paid off twice. The company estimates it saved more than 4,500 years of development work, and performance gains on Java 17 let it remove servers worth about $260 million a year.
Refactor
This approach restructures and optimizes the existing code without making significant changes to the work in order to eliminate technical debts and improve the structure and function of the component.
For example, Alpitour World, Italy’s leading tourism group, ran its core B2C and B2B applications in COBOL on an on-premises mainframe that was expensive and hard to change. The company refactored thousands of COBOL programs into Java, moved them to AWS, and replaced the legacy tooling around them with cloud-native and open-source tools. The cutover took place in October 2025 with no disruption to the business, and early results include 25 to 30% cost savings.
Rearchitect
This approach implies changing the application code to port it to a new architecture and using the new and expanded capabilities of the application platform to the optimal level.
This strategy was recently used by Axel Springer. Their 500,000-line monolith had become so tightly coupled that it blocked framework upgrades. The team first tried to carve out services through code-first refactoring, which failed because of tangled data dependencies. It then rearchitected from the data up, with a parallel data store, event-driven syncing from the legacy database, and a gradual shift of traffic to the new services. The whole migration ran with zero downtime.
Rebuild
In this approach, a certain code component is rewritten from scratch, keeping its scope and specification.
Thus, Morgan Stanley has been rebuilding legacy systems written in outdated programming languages. The hardest part of such a rebuild is understanding what the old code actually does, so the bank built DevGen.AI, an in-house tool that turns legacy code into plain-English specifications. Developers then rewrite the systems in modern languages from those specs. By June 2025, the bank said the tool had saved more than 280,000 developer hours.
Replace
This approach involves completely removing a particular component and replacing it with a new one in accordance with the new requirements.
For example, BancoEstado, Chile’s largest bank by customer base, replaced its core banking system this way. The mainframe core was reliable but kept getting more expensive as transaction volumes grew, so the bank moved to Mambu, a cloud-native core platform. It migrated 14 million customers in phases between 2020 and 2025, with both systems running in parallel the whole time. The bank is now on track to cut its reliance on the mainframe by 90% by 2027.
7 strategies at a glance
| Strategy | What changes | Effort | Risk | Best for |
|---|---|---|---|---|
| Encapsulate | Nothing inside; an API layer is added | Low | Low | Stable systems that must connect to new apps |
| Rehost | Infrastructure only | Low | Low | Fast exits from a data center or platform |
| Replatform | Runtime platform, minimal code | Low to medium | Low to medium | Apps that work but cost too much to run |
| Refactor | Code structure, not behavior | Medium | Medium | Valuable apps slowed by technical debt |
| Rearchitect | Architecture and code | High | High | Core systems that must scale or change faster |
| Rebuild | Everything, same scope | High | High | Valuable functions on a dead-end stack |
| Replace | The product itself | Medium | Medium | Commodity functions a product already covers |
If you plan a cloud move, you will also run into the AWS 7 Rs. Unlike Gartner’s, that list focuses on migration rather than code changes, so it includes options such as retire, retain, and relocate. Notably, AWS describes its list as an extension of the Rs that Gartner identified. In other words, the two lists work well together: Gartner’s helps you decide what to do with the code, and the AWS version helps you plan where each workload goes.
Tips for choosing the proper application modernization strategy
As in any other area, there are many tips to help you succeed in app modernization. Now, let’s have a look at them.
Do not forget about elimination
Sometimes upgrading does not mean updating, but eliminating the application. Sometimes the right upgrade is to remove an application altogether. At times, a company may find itself using different applications that have nearly the same functionality. This situation can arise for a number of reasons, such as a merger or teams buying tools independently. In that case, compare the overlapping applications carefully and decide which ones the company can do without. This will prevent the unnecessary burning of resources that could be spent on upgrading other applications and company processes.
Do not bet all on microservices
When implementing one of application modernization strategies, companies often turn to microservices too quickly, believing that this approach is a panacea. Many companies turn to replatforming to microservices too quickly because they see the approach as a cure-all. In practice, this is not the case. Microservices work well in many situations, but under certain circumstances, they can create more problems and complications than benefits.
Typically, microservices require a complex runtime environment and mature DevOps practices. Microservices are most useful when they are shared by overlapping functions. Splitting an application into multiple microservices when it isn’t needed can lead to unnecessary complexity, as well as management and scaling difficulties.
A telling example comes from Amazon’s own Prime Video team. Its audio and video quality monitoring service started as a distributed design built on serverless components, and consolidating it into a monolith cut infrastructure cost by over 90%. So split an application only where independent scaling or deployment brings a clear benefit.
Planning to split your monolith?
See how we moved a cloud HRM platform to microservices step by step, and what it gained.
Set small and achievable goals
Creating a global schedule and timeline and choosing one of the application modernization strategies allows you to effectively structure the process and plan for modernization budget. However, the schedule for specific actions should be made for a short period of time. The reason is simple: everything changes quickly, endlessly, and inevitably. Reducing cycle time and instead focusing on iterating to achieve smaller goals will have a much higher probability of success. Within these iterations, the adaptation, feedback, and completion of projects occur in a much shorter time frame than with long-term ambitious plans. It also allows you to be more flexible and make decisions successfully based on the feedback received. That way you’re more likely to finish the project while reducing risks.
Protect yourself from data loss
One of the key priorities when choosing among application modernization strategies should be to preserve and prevent the loss of data processed, moved, and stored. The most convenient approach to this is to assign a category to the data, such as “high-medium-low” or “red-yellow-green”. However, it is imperative that the upgrade team clearly understands these categories and makes sure that specific security measures are applied for each one.
Keep the gaps closed
There are a myriad of languages, technologies, tools, methodologies, systems, and application modernization strategies that an application developer needs to know. Therefore, they need to update their knowledge quickly and continuously, as well as think of ways to implement this knowledge into work. So it’s highly important to keep teams in the loop on all the changes and dedicate resources to making sure they understand how to navigate the new workflow. This practice should be long-term if the company wants to achieve greater success. After all, the tools are only as good as the people who use them.
How Bamboo Agile approaches modernization
Our team follows the same logic as this article: diagnose the problem first, then choose the least invasive strategy that solves it. Two of our projects show how different that answer can look.
MediaGun: a rebuild for cross-platform reach
- Starting point: a professional media player first developed in the late 1990s. It supported over 50 file formats but ran only on Windows.
- Strategy: Rebuild. We remade the application from scratch on Qt (C++), with C#, Microsoft Azure, and MySQL behind it.
- Result: the beta runs on Windows, macOS, and Linux and displays Microsoft Office files on machines without Office installed. Cloud sync, shareable portfolios, and Android support are provided as well.
HR Software: rearchitecture in increments
- Starting point: a cloud HR and payroll platform used by companies across Europe and the GCC, running on a monolithic backend.
- Strategy: Rearchitect step by step. We moved parts of the monolith to microservices with separate databases and replaced the REST API with GraphQL, while new HR and payroll features kept shipping. For the mobile app, a full rewrite made more sense.
- Result: a much faster web version, automated QA, a new mobile self-service app, and payroll for multiple salary types across Europe and the GCC.
So, you know your software needs modernization? Here is what to do next
Modernization projects go wrong in two opposite ways: teams either wait until a legacy system fails, or they jump straight to a rewrite. The approach in this article sits between those extremes. In short, it comes down to five steps, and each one builds on the result of the one before.
- Pinpoint where it hurts most. You may already know that legacy software is slowing you down, but not every system is equally to blame. Use the warning signs above to find the application where they cluster, and start there.
- Put a price on waiting. Compare that application with the benchmarks in the cost table, and add any regulatory deadline that applies to you, such as CRA reporting or DORA. At this point, a technical concern becomes a business case that leadership can act on.
- Triage the whole portfolio. Place your applications on the TIME chart. The Migrate quadrant shows where modernization pays off, and the Eliminate quadrant shows where you can save money first.
- Match each application to a strategy. For every Migrate candidate, pick the least invasive of the seven strategies that solves the actual problem. For large systems, plan the delivery in increments.
- Prove it with a pilot, then scale. Run one bounded pilot, with AI-assisted tools where they fit, and compare the real effort with your estimate. Those results become the plan for the next wave, and a regular review keeps the portfolio from drifting back.
In sequence, these steps turn modernization from a one-off crisis project into a steady habit.
Your own team can take the first three steps. Steps four and five are where an outside view pays off, because engineers who have already modernized similar systems know which strategy fits, where estimates slip, and which shortcuts backfire later. That is the kind of help Bamboo Agile offers.
