Table of Content
What is legacy system modernization?
Legacy system modernization is the process of updating outdated software, infrastructure and data. The goal is to keep the business logic you depend on without keeping the technology that traps it. In practice, you pick one of seven paths for each application: retire, retain, rehost, relocate, repurchase, replatform or refactor. You make that choice per system, not for the whole portfolio. Often the cheapest correct answer is to leave a system alone.
Key Takeaways
- The spending problem is bigger than the project cost. Federal agencies planned about $83 billion on operations and maintenance of existing systems in fiscal 2025. That is 79% of their total IT spending, according to the GAO. McKinsey’s CIO survey found another 10% to 20% of the new-product budget gets diverted to tech debt.
- There are seven strategies, and two of them mean doing nothing. AWS’s 7 Rs include retire and retain. A legacy modernization strategy that never recommends leaving a system alone is a sales plan, not an assessment.
- Refactoring during a migration is the expensive mistake. AWS advises against it. Rehost or replatform first, then modernize. Doing both at once is where timelines double.
- AI has moved the numbers, but not the way vendors imply. McKinsey reports 40% to 50% faster timelines and roughly 40% lower tech-debt costs with generative AI. It also warns that feeding old code into a translator just moves your tech debt into a modern language.
- Age is not the trigger. Risk is. Eight of the 11 most critical federal legacy systems run on outdated languages. Seven carry known cybersecurity vulnerabilities. Those are reasons to act. “It is 15 years old” is not.
- Commerce Pundit’s angle: our enterprise software development team starts with a portfolio assessment that is allowed to conclude “retain.” The systems worth rebuilding are usually a small fraction of the ones a vendor would quote you for.
What Is a Legacy System, Exactly?
Legacy System Definition
A legacy system is any software still in production that can no longer change at the speed the business needs.
That definition matters. The usual one, “old software,” leads to the wrong projects. Plenty of twenty-year-old code runs quietly, cheaply and safely. Plenty of five-year-old code is already a legacy application. The framework is unsupported, the developer left, and nobody dares touch it.
The practical test has four questions:
- Can you hire people who know it?
- Does the vendor still ship security patches?
- Can you get data out of it without a manual export?
- Can you add a feature in weeks rather than quarters?
Two “no” answers and you have a legacy system, whatever the build date says.
Scale is why this keeps reaching board agendas. McKinsey reports that as much as 70% of the software used by Fortune 500 companies was built 20 or more years ago. The public sector is sharper still. The US Government Accountability Office reviewed 69 systems across 24 federal agencies in July 2025. The 11 most critical ranged from 23 to 60 years old.
Legacy System Examples You Will Actually Recognize
| Legacy system type | What it looks like in practice | The usual constraint |
|---|---|---|
| Mainframe and COBOL | Core banking, claims processing, payroll, government benefits | The people who wrote it are retiring. Mainframe modernization is a talent problem before it is a technical one |
| IBM AS/400 (IBM i) | Manufacturing, distribution, order and inventory management | Very reliable, very closed. AS/400 modernization usually starts as an integration problem |
| Visual Basic 6 and classic ASP | Internal tools, shop-floor apps, quoting and pricing calculators | Unsupported runtime. A VB6 migration is usually forced by an OS upgrade, not chosen |
| .NET Framework applications | Line-of-business web apps and internal portals built between 2008 and 2018 | A .NET Framework to .NET migration unlocks Linux hosting and cuts licensing, but touches every dependency |
| Monolithic web applications | One deployable that contains the entire product | Every release is all-or-nothing, so releases get rarer and riskier |
| Client-server desktop software | Installed application talking straight to a database | No remote access, no API, and the database schema is the business logic |
| Heavily customized ERP | An ERP legacy system so modified it can no longer take a vendor upgrade | ERP modernization means unwinding customizations first. That is the part nobody budgets for |
| Undocumented custom applications | Built by one developer who has since left | Legacy software with no specification. Discovery costs more than the rebuild |
You will also hear these called heritage systems, incumbent systems, or just “the old system.” Vendor naming varies the same way. AS400 and AS/400 modernization describe identical work. So do software modernization, legacy software modernization and legacy application modernization.
The label does not change the decision. What changes the decision is what the system costs you. That is the part almost nobody measures.
One naming note before you take proposals. The market sells this work under two headings. Legacy system modernization services usually means assessment plus delivery for a defined estate. Application modernization services usually means per-application work, scoped after an assessment someone else ran. The second is riskier to buy blind, because you inherit whoever scoped it. Ask which one a quote actually is.
What Legacy Systems Actually Cost You
Most legacy system modernization business cases fail right here. They compare the price of a project against zero.
That is wrong, because the cost of maintaining legacy systems is already being paid. It just sits scattered across maintenance contracts, support tickets, integration workarounds and delayed launches. It is real money. It is simply nobody’s line item.
Three published anchors are worth knowing. All three measure the same thing from different angles: technical debt.
1. The maintenance trap. The GAO has reported for years that federal agencies spend roughly 80% of a $100 billion-plus annual IT budget just operating and maintaining what already exists. In fiscal 2025 that was about $83 billion, or 79% of planned spending. Private-sector ratios are rarely published, but the shape is the same. The more legacy you carry, the less budget is left for anything new.
2. The diversion tax. A July 2020 McKinsey survey asked 50 CIOs at companies with revenues over $1 billion. They reported that 10% to 20% of the budget meant for new products gets diverted to fixing tech-debt issues. The same CIOs valued their tech debt at 20% to 40% of their entire technology estate before depreciation. Sixty percent said it had grown over the previous three years. More recent McKinsey work puts the direct cost of technology debt at up to 40% to 50% of total investment spend.
3. The interest-only threshold. This is the most useful number in the literature, and it is a threshold rather than an average. McKinsey’s position is simple. A company spending more than half its IT project budget on integrations and legacy fixes is in a tech-debt spiral, paying interest only. If more than 50% of your project spend goes to keeping the lights on, you are not funding a roadmap. You are servicing a debt.
| Where the money goes | Why it is invisible | How to size it |
|---|---|---|
| Specialist contractors and retainers | Booked as support, not as legacy cost | Add up every contract that exists because one system is unusual |
| Extended-support and end-of-life licensing | Renews automatically, often at a premium | List every product past mainstream support and its price uplift |
| Integration workarounds | Charged to whichever project needed them | Count point-to-point integrations built because a system has no API |
| Manual process labor | Sits in operations headcount, not IT | Time the re-keying, reconciliations and exports people do weekly |
| Delayed revenue | Never measured at all | List features deferred last year because one system could not change |
| Risk and compliance exposure | Costs nothing until it costs everything | Count unpatched components and unsupported dependencies |
Run that table before you take a single vendor call. A legacy system audit that produces six real numbers gives you a business case. One that produces adjectives gives you a project nobody will approve.
The 7 Rs: Every Legacy Modernization Approach, and When Each One Wins
The industry has converged on the 7 Rs. They are documented most clearly in AWS Prescriptive Guidance: retire, retain, rehost, relocate, repurchase, replatform and refactor.
You will also see the older 6 Rs of migration, which leave out relocate. The names matter less than the discipline. Assign exactly one R to each application.
| Strategy | What you actually do | Choose it when | Cost and risk |
|---|---|---|---|
| Retire | Decommission or archive the application | No business value remains. AWS’s own signals: average CPU and memory below 5% (“zombie” apps), 5% to 20% over 90 days (“idle”), or no inbound connection for 90 days | Lowest, and it pays back immediately |
| Retain | Leave it alone and revisit later | Compliance requires it, dependencies must move first, you upgraded it recently, or it needs hardware with no cloud equivalent | None now, deferred |
| Rehost | Lift and shift, no code changes | You need out of a data center on a deadline and the application works | Low cost, low risk, no modernization benefit |
| Relocate | Move at hypervisor level. No new hardware, no rewrite | You are moving a large estate at once and want the fastest cutover | Lowest friction. Architecture unchanged |
| Repurchase | Drop and shop. Replace it with a SaaS product | The function is not a differentiator. Payroll, helpdesk, expenses, CRM | Moderate. Risk moves to data migration and change management |
| Replatform | Lift and reshape. Move it, and optimize a little | You want managed databases, containers or Linux without a redesign | Moderate. Usually the best cost-to-benefit ratio |
| Refactor or re-architect | Redesign the application around cloud-native patterns | The system genuinely blocks the business, nobody can maintain it, or the source code is gone | Highest. AWS calls it the most complex strategy |
The Advice Most Modernization Guides Leave Out
AWS’s guidance contains a recommendation that runs against most consulting pitches. Refactor is not recommended for large migrations.
The reasoning is that refactoring modernizes the application during the migration. That is the most complex strategy, and it is hard to manage across many applications at once. AWS recommends rehosting, relocating or replatforming first, then modernizing after the migration completes.
That one sequencing decision separates programs that land from programs that overrun. Move and rewrite at the same time and every bug has two possible causes. You also lose any clean rollback. This is why cloud development work is best scoped as its own phase, with modernization following it rather than riding along inside it.
Our AWS cloud migration guide covers the move itself: how to sequence a migration, and where production actually breaks. This article owns the question that comes first, which is which of the seven strategies each system deserves. Read that one once you have decided to move. Read this one to decide what to move and what to leave.
How to Choose the Right Legacy Modernization Strategy
Legacy application modernization strategies all reduce to one decision, repeated per system. Score each application on two axes and the answer usually presents itself.
Business value. Does this system do something that sets you apart? A pricing engine holding twenty years of commercial rules is not replaceable with a SaaS subscription. An expense approval workflow is.
Technical health. Is it supported, documented, staffable and integrable? This is where most of the risk lives.
| High technical health | Low technical health | |
|---|---|---|
| High business value | Retain or replatform. It works and it matters, so do not touch the logic | Refactor. This is the small set of systems that genuinely justify a rebuild |
| Low business value | Rehost or relocate. Move it cheaply and spend no design time on it | Retire or repurchase. Stop maintaining something that neither works well nor matters |
Then apply three constraints before you commit:
- Can you staff it? You need someone who understands the existing system, not only the target one.
- Is there a hard external date? An end-of-support deadline or an audit changes the sequence.
- What is the rollback plan for each step? Tested, not assumed.
An application portfolio assessment produces this grid for every system, with a named owner and a chosen R. That grid is what a legacy modernization roadmap is built from.
Most companies find that 60% to 80% of their estate belongs in the retire, retain or rehost rows. That is exactly why an honest assessment shrinks the project before it grows it.
Build vs Buy: Repurchase or Rebuild?
For every system in the “change it” half of that grid, one more question decides the budget: build vs buy. Repurchase means replacing the system with a SaaS product. Refactor or rebuild means keeping the logic and re-engineering around it.
The deciding test is not cost. It is differentiation.
If your competitors run the same process, buy it. Payroll, expenses, helpdesk and standard accounting all qualify. Accept that you will change your process to match the product.
If the process is the reason customers choose you, build it. Configuring a generic product into a bespoke one gives you the most expensive outcome available: SaaS licensing, plus custom development, plus an upgrade path you have just broken.
The trap is the middle. Systems that feel special but are not get rebuilt at custom prices for commodity value. Ask what would happen if you adopted the industry-standard process instead. If the answer is “nothing much,” that is a repurchase.
Legacy Modernization Approaches and Patterns That Reduce Risk
The Strangler Fig Pattern
Martin Fowler named this after a vine that grows around a tree until it can stand without it. The strangler fig pattern replaces a legacy application one capability at a time.
You put a routing layer in front of the old system. You build the first new capability behind it. You redirect that traffic, then repeat. The old system shrinks until nothing routes to it and you can switch it off.
The advantage is not elegance. It is that you can undo it. Every step ships on its own, and any step can be routed back.
For a monolith to microservices migration, that is the difference between two very different outcomes. One program delivers value in month two. The other delivers nothing until month twenty-four. It is also the clearest of the legacy modernization examples to show a skeptical board, because progress is visible every month rather than promised at the end.
Encapsulation and the API Wrapper
Sometimes a legacy system migration is not needed at all. The system is fine. The problem is that nothing can talk to it.
Wrapping it in an API leaves the core untouched while making its data and functions available to modern applications. This is the cheapest useful modernization move available. For legacy system integration it is often the whole answer, especially where a stable AS/400 or mainframe needs to feed a modern web or mobile front end.
It is also the honest first step before a bigger decision. Once a system has an API you can build around it, measure what actually uses it, and replace it later with far better information. Our guide to CRM and ERP integration walks through the connection methods and what each one costs.
Database Modernization
Data usually outlives applications. So database modernization is usually handled separately, and often first.
Moving to a managed database service removes patching and backup work immediately, without touching application code. Where the schema itself encodes business logic, expect this to be the longest part of the program rather than the quickest.
The Big Bang Rewrite
One pattern creates risk instead of reducing it, and it is the one everyone reaches for first. Stop, rebuild the whole thing, switch over on a date.
It fails for structural reasons, not for lack of effort:
- Requirements are discovered, not documented. The real specification is the running code, and nobody has read all of it.
- The target moves. The business keeps changing while you rebuild.
- Value arrives only at the end. The first eighteen months produce no evidence the approach is working.
- There is no partial rollback. On cutover day the choice is the new system or the old one, at full scale, under load.
Every low-risk pattern above exists to avoid that shape. If a proposal has a single go-live date eighteen months out and no delivery before it, that is the finding. Not the schedule.
Legacy Modernization With AI: What Has Genuinely Changed
This is the newest part of the field and the part most distorted by marketing. It is worth separating what is measured from what is claimed.
McKinsey’s December 2024 analysis reports real gains from generative AI. It finds 40% to 50% faster modernization timelines and roughly 40% lower costs from technology debt, with better output quality.
The illustration is concrete. A transaction-processing system for a financial institution would have cost well over $100 million to modernize three years earlier. Using generative AI, it now costs well under half that. Measured against McKinsey’s traditional baseline of hundreds of millions of dollars over five to seven years, that is a material shift. It makes projects viable that nobody could previously justify.
Where AI genuinely helps today is the part of modernization that was always most expensive and least visible: understanding the system you already have. Generative AI can turn impenetrable legacy artifacts into plain English process descriptions in minutes. That includes source code, thin documentation, observability data and call logs. On undocumented custom applications, it collapses a discovery phase that used to run for months.
The trap has a name. McKinsey calls it “code and load.” You feed legacy code into a generative AI tool, it translates the code into a modern language, and the output compiles. The project looks finished. In reality you have moved your tech debt from a legacy system into a modern one.
It is the same mistake as an early lift-and-shift to cloud that left every legacy problem intact. It is just faster and cheaper to make now. AI-assisted legacy code modernization is worth doing when you point it at comprehension and business outcomes. It is worth very little when you point it at line count.
What Legacy System Modernization Costs and How Long It Takes
Be skeptical of any published price range for this work, including ranges on competing pages.
Modernization cost is driven almost entirely by discovery risk. And you cannot know that risk until discovery is done. This is also why a legacy system modernization case study from another company tells you very little about your own number. The variable that decided their price was the state of their documentation, not the size of their system.
What can be stated honestly is the shape of the variables, plus the one public benchmark that exists.
That benchmark is McKinsey’s. Large-enterprise core system modernization has traditionally run to hundreds of millions of dollars over five to seven years, with generative AI now compressing both. Treat that as an enterprise figure for a core transaction system. It is not a guide for a mid-market application, and you cannot just scale it down.
| Cost driver | What makes it cheap | What makes it expensive |
|---|---|---|
| Documentation | Current specifications and tests exist | The running code is the only specification |
| Strategy chosen | Retire, retain, rehost, relocate | Refactor or full rebuild |
| Integrations | Few, documented, API-based | Many, undocumented, point-to-point, some to systems nobody owns |
| Data | Clean, one source, easy to migrate | Decades of accumulated exceptions and duplicate records |
| Compliance scope | No regulated data | Financial, health or personal data with audit requirements |
| Availability requirement | Planned downtime is acceptable | Zero-downtime cutover with parallel running |
| Knowledge | People who built it are still available | The original team has left |
Two practical rules follow from that table.
First, buy the assessment separately from the build. A fixed-price discovery is a small, bounded purchase. It gives you the portfolio grid, the chosen R per system, and an ordered roadmap. It is the only way to get a defensible number for the work that follows.
Second, insist that the assessment is allowed to recommend doing nothing. An assessment that cannot return “retain” was never an assessment.
Modernizing Specific Platforms
Mainframe and COBOL Modernization
Mainframe migration is constrained by people more than by technology. The applications are stable and well understood by a workforce that is retiring.
The GAO has repeatedly flagged outdated languages as a defining trait of the most critical federal legacy systems. Eight of the eleven it reviewed in 2025 run on them.
Generative AI has changed the economics here more than anywhere else, because reading the code was the bottleneck. The strategy is almost never a single rewrite. It is encapsulation first, then capability-by-capability replacement.
AS/400 and IBM i
AWS lists mid-range systems such as IBM AS/400 among the workloads needing careful assessment before migration. It often recommends retain in the short term.
The usual first win is not migration at all. It is an API layer that lets modern applications read and write to a system that otherwise works perfectly well.
.NET Framework and VB6
A .NET Framework to .NET Core migration, now just .NET, is one of the better-returning modernization projects available. It opens Linux hosting, removes Windows licensing cost and brings a supported runtime. It is also unusually predictable, because the tooling exists and the dependency graph is discoverable.
VB6 migration is a different story. It is nearly always forced by an operating system or hardware refresh. Because the applications are typically small and internal, repurchase or rebuild usually beats porting.
If you are rebuilding internal applications, our guide to multi-tenant .NET application development covers the architecture decisions that are expensive to reverse later.
ERP Modernization
An ERP legacy system is rarely old in the sense of unsupported. It is old in the sense of over-customized. It has been modified so heavily that it can no longer accept a vendor upgrade, so every year it drifts further from the supported product.
ERP modernization is therefore a customization-unwinding exercise first, and a platform decision second. Answer one question before you choose a target platform. Which customizations hold real competitive logic? And which ones just hold a process nobody has reviewed since go-live?
Why Modernization Programs Fail
The failure modes are consistent, and none of them is primarily technical. The legacy system problems that sink a program are almost always organizational. That is also why a digital transformation framing does not help. It raises the ambition without addressing any of the five constraints below.
1. No assessment, or an assessment that could only say yes. If the party that scoped the work would also win the build, the grid will be full of refactors.
2. Migration and modernization attempted together. Covered above, and worth repeating. It is the single most common overrun.
3. Nobody who understands the old system. Modernization needs people who can read the legacy code as well as people who can write the new system. That first group is scarce and getting scarcer. Our piece on the current IT hiring market describes the constraint. It is why knowledge capture belongs at the start of a program, not the end.
4. No plan for the people using it. A modernized system can work perfectly and still fail. If nobody has been trained on it, you get a support queue, a workaround culture, and a quiet campaign to keep the old system running in parallel.
5. Value deferred to the end. Programs that ship nothing for a year lose their sponsor before they lose their budget. Order the roadmap so something measurable lands in the first quarter, even if it is small.
The GAO finding is instructive. Of the 11 most critical federal legacy systems it reviewed in 2025, only three had modernization plans covering all the key practices for success. Modernization was already under way on seven of the eight that did not. Starting before planning is not a government-sector problem. It is the default everywhere.
Frequently Asked Questions
What is legacy system modernization?
Legacy system modernization updates outdated software, infrastructure and data so the business keeps the logic it depends on without keeping the technology that constrains it. It covers seven distinct strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. You apply them per application, not across a whole portfolio. A full rewrite is only one of those seven, and it is the most expensive and highest-risk of them.
Is replacing a legacy system worth it?
Only when the cost of keeping it exceeds the cost and risk of changing it. That comparison is rarely done properly. Add up specialist contractors, extended-support licensing, integration workarounds, manual process labor and deferred features before you compare. McKinsey offers a useful line: if more than half your IT project budget goes to integrations and legacy fixes, you are paying interest on debt rather than funding a roadmap.
Which is an example of legacy modernization?
A common low-risk example is wrapping a stable but closed system in an API. Modern web and mobile apps can then read and write to it, and the core is never touched. A mainframe or an IBM AS/400 both fit. A larger example is applying the strangler fig pattern to a monolith. You route one capability at a time to new services until nothing routes to the original and you can retire it.
Can you give me an example of a legacy system?
Common examples include mainframe COBOL applications running core banking or claims processing. Others are IBM AS/400 systems in manufacturing, Visual Basic 6 internal tools, and .NET Framework line-of-business web apps. Client-server desktop software that talks straight to a database counts too. So does a heavily customized ERP system that can no longer take a vendor upgrade. An undocumented custom application whose only developer has left also qualifies, whatever its age.
How many companies still use legacy systems?
Precise private-sector figures are scarce, but the available benchmarks are large. McKinsey reports that as much as 70% of the software used by Fortune 500 companies was built 20 or more years ago. In the US federal government, the GAO reviewed 69 legacy systems across 24 agencies in 2025. The 11 most critical ranged from 23 to 60 years old, and eight ran outdated programming languages.
Why do companies still use legacy systems?
Usually because the system works and the replacement risk is real. Legacy systems tend to hold business logic that exists nowhere else, including in the documentation. Replacing them means rediscovering rules the company has forgotten it depends on. Add regulated data, integrations nobody fully mapped, and the fact that a stable system creates no urgency, and deferral is the rational short-term choice. That holds right up until a security or staffing deadline removes the option.
How do you modernize legacy applications?
Start with a portfolio assessment that scores each application on business value and technical health, then assign exactly one of the 7 Rs to each. Order the roadmap so low-risk wins such as retire and rehost come first. They fund the harder work. Use reversible patterns such as the strangler fig or an API wrapper rather than a single cutover. Separate migration from modernization: move first, modernize afterwards.
What are the 7 Rs of modernization?
The seven are retire, retain, rehost, relocate, repurchase, replatform, and refactor. Retire means shut it down. Retain means leave it and revisit. Rehost is a lift and shift with no code changes. Relocate moves it at hypervisor level. Repurchase swaps it for a SaaS product. Replatform moves it with light tuning. Refactor redesigns it around cloud-native patterns. The older 6 Rs of migration are the same list without relocate. Refactor is the most complex and costly, and AWS recommends against attempting it during a large migration.
What is another name for a legacy system?
Heritage system, incumbent system and legacy application are the common alternatives. In technical contexts you will also see monolith or mainframe used as shorthand for specific kinds of legacy software. The terminology does not change the assessment. What matters is whether the system can be supported, staffed, integrated and changed at the pace the business requires.
How much does legacy system modernization cost?
It depends far more on discovery risk than on system size, which is why credible providers price assessment separately from build. The only widely published benchmark is McKinsey’s. It puts traditional large-enterprise core system modernization at hundreds of millions of dollars over five to seven years. Generative AI now cuts timelines by 40% to 50% and tech-debt costs by around 40%. Those are enterprise figures for core transaction systems. Do not simply scale them down for a mid-market application.
Bottom Line
Legacy system modernization goes wrong at the scoping stage far more often than at the engineering stage.
The companies that get it right do three dull things. They measure what the current system actually costs across contracts, licensing, workarounds and deferred revenue. They assign one of the seven strategies to each application, rather than treating the estate as a single project. And they separate moving from modernizing, so any step can be rolled back.
Do that and the program usually gets smaller. Most estates are mostly retire, retain and rehost, with a small number of systems that genuinely deserve a rebuild. Working out which is which is a small, bounded job. It is the right thing to buy first.
If you are at that stage, our enterprise software development and custom web development teams run portfolio assessments that are allowed to conclude “retain.” And if the outcome is a rebuild, our guide to modern web applications covers what replaces a client-server system, and why.
