Most legacy system modernization programs cost more than planned. The reason is usually visible in hindsight: the approach was chosen before anyone understood the system.
The research backs this up:
- 71% of organizations exceeded their original modernization budgets (Ensono, 2026 State of IT Modernization report, as covered by Channel Insider).
- 78% say legacy systems are more important to them than two years ago (Ensono).
- Just 9% fully understand their applications’ dependencies, and a quarter have large numbers of undocumented applications (Kyndryl, 2026 State of Modernization Report, 2,000 business and technology leaders).
This guide lists the seven legacy modernization approaches. Its real subject is how to choose between them: a five-step method that runs from discovery to delivery, so the approach becomes a conclusion drawn from evidence instead of a starting assumption.
Key takeaways
- The seven approaches, from least to most change, are encapsulate, rehost, replatform, refactor, rearchitect, rebuild and replace. They are the menu. The method decides what to order.
- The five steps are: discover the system, diagnose the constraint, decide the lightest approach that removes it, de-risk the business logic, and deliver incrementally.
- Discovery is where programs go wrong. Only 9% of organizations fully understand their application dependencies, so the surprises that blow budgets surface mid-project.
- Testing and knowledge are the hidden costs. AWS reports testing typically consumes more than half of a mainframe modernization project. In Ensono’s survey, 97% said talent shortages had increased modernization costs.
- Legacy is now a compliance item. DORA requires EU financial entities to risk-assess all legacy ICT systems at least yearly, and support deadlines for Windows 10, SAP Business Suite 7 and Java SE 17 are turning old systems into unsupported ones.
What counts as legacy, and why 2026 is the year it matters
A legacy system is one that still supports the business but is hard to change, hard to staff or no longer supported.
The EU’s Digital Operational Resilience Act (DORA), which has applied since January 2025, defines a legacy ICT system as one that “has reached the end of its lifecycle,” is “not suitable for upgrades or fixes” or “is no longer supported by its supplier,” but “is still in use and supports the functions of the financial entity.” That definition fits a lot of systems outside finance too.
Three pressures have moved these systems up the agenda:
- Support deadlines. Windows 10 reached end of support on October 14, 2025. SAP’s mainstream maintenance for SAP Business Suite 7 core applications runs to the end of 2027. Oracle’s roadmap puts Java SE 17 premier support at September 2026.
- Regulation. DORA’s Article 8(7) requires financial entities, other than microenterprises, to “on a regular basis, and at least yearly, conduct a specific ICT risk assessment on all legacy ICT systems.” Kyndryl’s 2025 mainframe survey found 94% of respondents say regulatory compliance highly influences their modernization plans.
- AI. BMC’s 2026 survey of more than 1,300 mainframe practitioners found implementing AI is a top priority for 45%. The US Government Accountability Office’s July 2025 review identified 11 critical federal systems, between 23 and 60 years old, most in need of modernization. Two had no plan at all.
The 7 legacy system modernization approaches in one table
Gartner’s framework ranks seven options from easiest to hardest to implement. The lighter the option, the lower the risk and the smaller the effect on the business processes around the system.
| Approach | What changes | Constraint it removes | Change and risk |
|---|---|---|---|
| 1. Encapsulate | Nothing inside. Data and functions are exposed as APIs. | Access: other systems and AI can’t reach the data | Lowest |
| 2. Rehost | Where it runs | Hardware, data center or hosting cost | Low |
| 3. Replatform | The OS, database or middleware, with minimal code change | Unsupported or expensive platform | Low to medium |
| 4. Refactor | The code, restructured without changing behavior | Agility: changes take too long and break things | Medium |
| 5. Rearchitect | The structure: monolith to services, batch to events | Scale and integration limits | Medium to high |
| 6. Rebuild | Everything, rewritten with the same scope | Code beyond repair, but requirements are stable | High |
| 7. Replace | The whole system, retired for a product or SaaS | Requirements have moved beyond the system | Highest |
Most programs combine several approaches, applied to different components of the same system. So the useful question is never “which approach for our legacy estate?” It is “which approach for this component, given what is wrong with it?” The five steps below answer that.
The five steps at a glance:
- Discover: map the system, its dependencies, its costs and the people who understand it.
- Diagnose: name the constraint for each system or component.
- Decide: pick the lightest approach that fully removes that constraint.
- De-risk: protect the business logic with characterization tests and business-rule recovery.
- Deliver: move one capability at a time, with the old system still running.
Step 1. Discover: map the system before you judge it
Discovery produces the evidence every later step depends on: what the system does, who uses it, what it talks to, what it costs and who understands it.
Build the inventory with discovery tooling as well as interviews, because the interfaces nobody remembers are the ones that fail at cutover. Capture:
- Inbound and outbound integrations
- Batch jobs and schedules
- Data flows and file transfers
- Reports that downstream teams depend on
- Support status and vendor end dates for every component. DORA’s technical standards require exactly that for financial entities, and it is good practice for everyone else.
Then capture the people. Kyndryl’s 2026 report points to “a shrinking pool of legacy systems expertise.” Its 2025 mainframe survey found 70% of organizations struggling to find the right multi-skilled talent and 74% relying on third-party providers. Identify who holds the knowledge of each system, and treat their time as a project resource, with a plan for capturing what they know.
Output of step 1: a dependency map, a cost baseline and a knowledge register. Without them, the budget overruns in the introduction are what happens next.
Step 2. Diagnose: name the constraint
Gartner’s April 2026 guidance is that modernization approaches “vary substantially based on the underlying problems they are intended to address,” and that the goal is to achieve the intended outcome “within acceptable cost, risk and impact constraints.”
So the second step is to name the problem for each system or component. The usual constraints are:
- Cost: licenses, hardware, maintenance
- Risk: unsupported, insecure, or nobody left who understands it
- Agility: changes take months
- Scale: it can’t handle growth
- Access: other systems and AI can’t reach its data and logic
- Skills: the platform can’t be staffed
Then check business fit. Gartner’s TIME model is a useful triage:
- Tolerate systems that fit the business but are technically weak and low priority.
- Invest in systems that fit well on both counts.
- Migrate the ones the business depends on but the technology can’t sustain.
- Eliminate the ones that fit on neither count.
A system in the “migrate” box needs a different diagnosis from one in the “tolerate” box, even if the code looks the same. The diagnosis is what the approach has to answer.
Step 3. Decide: the lightest approach that removes the constraint
With the constraint named, the table above becomes a lookup:
- Access constraint: encapsulate.
- Cost and support risk: rehost or replatform.
- Agility, when the design is sound: refactor.
- Scale and integration limits: rearchitect.
- A gap too wide to close in place: rebuild or replace. These remove everything, at the highest cost and risk.
Two rules keep the decision honest:
- Pick the lightest option that fully removes the constraint. Every step up the ladder adds cost, duration and risk. Ensono’s finding that 71% of programs overran is mostly a story of programs that chose too heavily.
- Decide per component. A core system can be encapsulated so new channels can use it now, replatformed to get off unsupported infrastructure next year, and rearchitected only in the one module where the business needs speed.
Price each option with its testing and knowledge costs included. That is where step four comes in.
Step 4. De-risk: protect the business logic before you touch it
Legacy systems carry business rules nobody has written down, and the cost of losing one usually appears after go-live. The protection is a characterization test suite.
As the Stack Overflow blog put it in October 2026, describing Michael Feathers’ term: “Before you touch code you don’t fully understand, you write tests that capture what it does right now. Not what it should do. What it actually does.” Build these tests against the legacy system first, with production-shaped data, so any replacement can be proved equivalent before it takes live traffic.
Budget for this properly. AWS reports that testing “typically consumes more than half of project timelines and resources” in mainframe modernization, which is why automated test generation is where AI tooling has the most effect. Alongside the test suite, plan for:
- Business-rule recovery for the modules being refactored, rearchitected or rebuilt. Extract the rules from code and from the people in the knowledge register, document them, and get the business to confirm them.
- A parallel run for anything that moves money, stock or patients. The old and new systems process the same inputs side by side until the results match.
- Budget contingency. Kyndryl’s data says most organizations have hidden dependencies. They are found here, or they are found in production.
Step 5. Deliver: incrementally, with the old system still running
Martin Fowler’s strangler fig pattern is the delivery model for legacy work. In his 2024 revision he describes “a gradual process of modernization” in which “we move bits of behavior from the legacy system into the new code base” until the legacy system can be switched off.
In practice that means:
- A facade in front of the old system
- One capability moved at a time
- Each cutover small enough to reverse
- The legacy system decommissioned component by component, not on a single weekend
Three things close the loop:
- Decommission deliberately. A legacy system that is 90% replaced still costs 100% of its license and still needs its yearly DORA assessment.
- Measure the return. Kyndryl’s 2025 survey found respondents reporting between 288% and 362% ROI on mainframe modernization initiatives. To claim that, you need the cost baseline from step one.
- Go back to step one for the next component. Discovery for the next piece is cheaper once the first piece has taught the team what to look for.
What AI changes for legacy work
AI tooling now does much of the reading, translating and testing that made legacy work slow. Vendor-reported results include:
- AWS: its agentic modernization service delivered a 70% reduction in modernization effort across 135,000 lines of code for one customer and a 40% reduction in developer effort at Experian. Its December 2025 mainframe testing automation targets the half of the project that testing consumes.
- GitHub: Copilot app modernization for Java and .NET, generally available since September 2025, handles assessment, code transformation, build fixes and containerization.
The survey data agrees, with a caveat:
- In Ensono’s 2026 report, 54% of organizations said AI had accelerated their modernization, up from 39% a year earlier.
- In Kyndryl’s, the 10% that have deployed agentic AI for modernization were more likely to be on track with their goals (67% against 51%).
- Gartner’s August 2026 Magic Quadrant guidance cautions that a great AI coding agent does not guarantee successful application modernization.
The bottom line: AI compresses steps four and five. Steps one to three, the discovery, the diagnosis and the decision, still belong to people who know the business.
How Compunnel Digital helps
Compunnel Digital runs the five steps as one engagement, from discovery through delivery, with accelerators for the migration and platform work and quality engineering to keep each cutover safe.
- Cloud migration and modernization covers the assessment and the rehost, replatform and rearchitect work through cloud-native engineering, migration automation and platform modernization frameworks.
- Cloud-native accelerators shorten steps three to five. CloudForge™ is a migration factory for application rationalization, wave planning and automated cutover testing. PlatformX™ provides microservices patterns, containerization templates and event-driven architecture blueprints for the move from monolith to cloud-native. Compunnel reports 40% faster migrations with these accelerators.
- Automation modernisation builds the test safety net that step four depends on, with self-healing automation and AI-driven test generation, and Compunnel reports an 80% reduction in automation maintenance.
- Cloud migration assurance validates functionality, integrations, performance, resilience and compliance before each go-live.
Three engagements show different approaches chosen for different constraints:
- Rebuild: For a wealth management platform, Compunnel rebuilt a legacy front end as a React ecosystem while keeping live trading running, with zero downtime during migration.
- Replace: For a financial institution, Compunnel replaced manual KYC and lending workflows with a Microsoft Power Platform solution, and reports a 70% reduction in KYC verification time and 60% faster compliance reporting.
- Replatform: For a global education organization, Compunnel replatformed a legacy Oracle data warehouse onto Snowflake, unifying data across institutions.
If a legacy system is holding back a project, talk to our team about a discovery and diagnosis engagement.
Frequently asked questions
What is legacy system modernization?
Legacy system modernization, also called legacy application modernization, is the process of updating or replacing older systems that still support the business but are hard to change, staff or support. It ranges from wrapping a system in APIs to replacing it outright, and the right option depends on what is wrong with the system and what the business needs from it.
What are the seven approaches to legacy modernization?
Encapsulate, rehost, replatform, refactor, rearchitect, rebuild and replace, ranked by how much changes. Lighter options change less and carry less risk; heavier options change more and cost more. Most programs combine several.
What is the difference between rehosting and replatforming?
Rehosting moves a system to new infrastructure, such as the cloud, without changing it. Replatforming also changes the operating system, database or middleware, with minimal code change, to get off an unsupported or expensive platform.
How do you choose between refactoring and rebuilding?
Refactor when the system does what the business needs and the design is sound, but the code has accumulated debt that makes change slow and risky. Rebuild when the code is beyond repair but the requirements are stable and well understood. If the requirements have moved on, consider replacing instead.
Why do legacy modernization projects go over budget?
Undocumented dependencies, business rules buried in old code, underestimated testing and talent shortages. Kyndryl found only 9% of organizations fully understand their application dependencies, AWS reports testing takes more than half of a mainframe project, and Ensono found 97% saying talent shortages had increased modernization costs.
Can AI modernize legacy code?
AI tools can now read, document, translate and generate tests for legacy code, and vendors report large reductions in effort. They work best under human direction: discovering the system, diagnosing the constraint, deciding the approach and confirming business rules remain people’s jobs.
What is the strangler fig pattern?
The strangler fig pattern, described by Martin Fowler, replaces a legacy system gradually. A facade sits in front of the old system, capabilities move to the new code base one at a time, and the legacy system is switched off once nothing depends on it.
Conclusion
Legacy system modernization goes wrong when the approach is chosen before the system is understood. Discover it, diagnose the constraint, decide the lightest approach that removes it, protect the business logic with characterization tests and business-rule recovery, and deliver incrementally with the old system still running. The seven approaches are the same for everyone. The method is what separates the programs that finish on budget from the 71% that didn’t.
Explore how our Cloud, Platforms and Engineering practice approaches modernization from discovery to operation.
Sources
- Ensono, 2026 State of IT Modernization Report, via Channel Insider, Ensono Finds 71% of IT Modernization Projects Over Budget, September 2026, and Intelligent CIO, Ensono research finds AI prompts IT leaders to rethink value of legacy systems, September 2026 (vendor research)
- Kyndryl, 2026 State of Modernization Report announcement, October 2026 (2,000 leaders; vendor research)
- Kyndryl, Mainframe modernization projects deliver 2-3X return on investment, September 2025 (500 leaders; vendor research)
- BMC Software, Trust Powers AI on the Mainframe, September 2026 (1,300+ practitioners; vendor research)
- Gartner, Guide Application Modernization Success by Diagnosing Root Causes, April 2026, and Use TIME to Engage the Business for Application and Product Portfolio Triage
- Gartner, Magic Quadrant for AI-Augmented Code Modernization Tools: Answering the Top 9 FAQs, August 2026
- US Government Accountability Office, Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems, July 2025
- Regulation (EU) 2022/2554 (DORA), Article 3 definitions and Article 8
- Microsoft Learn, Windows 10 lifecycle; SAP, SAP Business Suite 7 maintenance strategy; Oracle, Java SE Support Roadmap
- Stack Overflow Blog, The Regression Tests Nobody Writes: Capturing How Software Actually Behaves, October 2026
- Martin Fowler, Strangler Fig Application, revised August 2024
- AWS, Accelerating mainframe modernization testing with AWS Transform, December 2025, and Smash tech debt with AWS Transform, February 2026 (vendor-reported)
- GitHub, Copilot app modernization generally available for Java and .NET, September 2025 (vendor announcement)
