Legacy Software Modernization Cost in the USA: Rehost, Replatform, Refactor or Rebuild in 2027

Short answer

Modernizing one legacy business application in the USA typically costs $25,000 to $150,000 to rehost, $80,000 to $300,000 to replatform, $150,000 to $600,000 to refactor, and $300,000 to $1.5 million or more to rebuild. Those take roughly 1 to 4 months, 3 to 6 months, 6 to 12 months and 12 to 24 months or more. The cheapest path that fixes your real problem usually wins, and part of the work is deciding which systems you should leave alone.

Some deadlines have stopped being theoretical. Extended support for SQL Server 2016 ended on July 14, 2026. .NET 8 and .NET 9 lost support on November 10. Windows Server 2016 and .NET Framework 4.6.2 follow on January 12, 2027. Software keeps running after support ends, but it stops getting security fixes, and your customers' security questionnaires will notice.

This guide is for the person who has to decide what to do about an aging system: an owner, a COO, a CTO who inherited one. We cover what is ending and when, four paths and what each costs, where AI helps and where it does not, a payback model you can rerun with your own numbers, and how to modernize without betting the company on a big-bang rewrite.

We build and modernize software for a living, so we have a point of view. Where doing less, or doing nothing, is the right answer, we say so.

Why this is urgent right now: the 2026 and 2027 support calendar

What is ending and when

Microsoft's own notice says that after November 10, 2026, .NET 8 and .NET 9 receive no further security updates or technical support. A common trap is the stack under the application: SQL Server 2016, for example, is not supported on Windows Server 2022 or 2025, so the database and the operating system often have to be planned together.

What end of support really means

The software does not stop. It stops getting security patches, so every newly found vulnerability stays open. Attackers study the fixes for newer versions and check whether the old one has the same hole, which means the risk grows month by month. Paid extended security updates exist as a bridge, and they cost real money and buy you time, not a fix.

Why it matters beyond security

Unsupported software raises questions in security audits, enterprise customer questionnaires and cyber insurance renewals. It also limits hiring, because fewer people want to work on old stacks. Our guide to the best tech stack for scalable business software covers how to choose a stack that stays supportable.

Four paths and what each costs

Our planning bands, per application

These are our planning figures, built from the published ranges in the next section and sized for the US market. They are not a quote.

Why published prices disagree

The spread comes from three places. The guides count different things, so a single application and a multi-system program share one price list. They assume different team rates and different amounts of testing. And most are written by firms that want to attract a certain size of project. Use them to find the range, then test any quote against the hours and roles behind it, as we show in our custom software development cost guide.

Rehost: move it, do not change it

Choose this when the infrastructure is the problem and the software works. A data center exit or an aging server is the classic case. It is the cheapest and fastest path, and it leaves every flaw in the code intact. Some guides price the labor at $3,000 to $8,000 per workload.

Replatform: upgrade the foundation

Choose this when the code is sound and the platform underneath it is aging. Moving an application from an unsupported .NET version, or swapping a database engine, is replatforming. It is often the best value, because it removes the support-date problem without rewriting the logic.

Refactor: clean the code, keep the behavior

Choose this when the business logic is right but years of patches have made the code slow and risky to change. One 2026 guide puts refactoring at roughly 40% to 60% of the cost of a rewrite of the same system, since you never pay to rediscover what the system does. Treat that as a vendor estimate, not a rule.

Rebuild: replace it

Choose this when the system no longer encodes what the business actually does, or the architecture blocks everything you want to do next. It is the most expensive and riskiest path. Run it in phases and not as one big switch, as the section below explains.

Retire or retain

Two more options cost little. Retire an application nobody needs and archive its data. Retain one that works, is supported and is isolated, and spend the money elsewhere. A portfolio review often finds applications that need no change at all.

What drives modernization cost

• Size and code quality. More code and more tangled code take more effort to understand and to change safely.

• Documentation and knowledge. If the people who built it have left, you pay to rediscover how it works.

• Integrations. Every connection to another system is a place where behavior has to match, and a place for surprises.

• Data migration. Moving years of records, and cleaning them, is rarely a small line item.

• Testing. Without automated tests, you have to build them first, so you can prove the new system behaves like the old one.

• Downtime tolerance. A system that can go offline over a weekend is far cheaper to move than one that cannot stop.

• Compliance. Health, financial or payment data adds review and documentation.

Where AI helps and where it does not

What the 2026 claims say

AI tools are changing the economics of this work. McKinsey's research on AI in IT modernization, as reported by several 2026 guides, found that generative AI can speed up modernization timelines by 40% to 50% and cut technical-debt-related costs by about 40%. AWS says its Transform service modernized more than 40 million lines of COBOL to Java for Toyota with a 50% reduction in overall effort. Thoughtworks has reported cutting reverse-engineering time on a large COBOL system by about two thirds.

The warning that goes with them

Gartner's June 2026 prediction, summarized by the Open Mainframe Project, is that more than 70% of mainframe exit projects started in 2026 will fail to produce their intended benefits, largely because teams overestimate what generative AI can do on its own. Our own look at the code-quality side points the same way: Veracode's 2026 report found AI-generated code passed security tests about 56% of the time.

How to read it

AI helps most with understanding and documenting old code, generating tests, and mechanical upgrades such as moving a framework version forward. It helps least with deciding what the business needs. So do not cut an estimate in half on faith. Ask a vendor which tasks AI speeds up, by how much, and who reviews the output. If you are weighing partners, our guide to choosing an AI development partner has a scorecard that works for any vendor.

The payback math: the cost of standing still

Step 1: Price what the old system costs you now

Add the engineering time spent keeping it alive, the licenses and hosting, any paid extended security updates, and a figure for risk. For the engineering time, use the BLS median developer salary of $135,980 with a 1.3 to 1.5 employer-cost multiplier, which gives about $177,000 to $204,000 a year per engineer. The multiplier is our assumption, so swap in your own HR numbers.

Step 2: Estimate how much each path reduces that cost

A rehost changes little. A replatform trims upkeep. A refactor cuts it substantially. A rebuild can cut it most, and costs most to reach. Every percentage below is an assumption you should replace.

Step 3: A worked example

Take a mid-size line-of-business application, with these assumptions. One and a half engineers spend their time on upkeep, which is $265,000 to $306,000 a year, plus $40,000 a year in licenses and hosting. That is about $305,000 to $346,000 a year to stand still.

Two lessons come out of the table. Going deeper costs more and pays back more slowly unless the business value changes, so the shallowest path that solves your problem tends to win. And the table counts only upkeep savings. It leaves out faster feature delivery, lower security risk and easier hiring, which are often the real reasons to modernize.

When the payback is not there

If an application is stable, supported, isolated and rarely changed, the math may say leave it alone. If nobody uses it, retire it. If the savings only work at your best-case assumptions, do not start. The numbers should still clear the bar at half of what you expect.

How to modernize without a big-bang rewrite

Replace it piece by piece

The safest pattern for a large rebuild is to put a thin layer in front of the old system and move one function at a time to the new one, until the old system has nothing left to do. Each step ships, each step can be rolled back, and the business never waits two years for a switch to flip.

Start where the pain or the deadline is

Rank applications by risk and cost. An unsupported database facing an audit goes first. A stable, isolated tool goes last or never.

Write tests before you change anything

Tests that capture how the old system behaves are the safety net for everything that follows. They are boring and they are the difference between a controlled migration and a guess.

Plan the data and the cutover

Decide what data moves, what gets cleaned, and what gets archived. Run the old and new systems in parallel for a period, compare results, then cut over with a rollback plan.

Costs people forget

• Parallel running. You pay for both systems until the cutover is safe.

• Extended security updates. A bridge worth budgeting if your deadline is closer than your project.

• User retraining. New screens and workflows cost your team time.

• Re-certification. Compliance evidence often has to be redone for the new system.

• Ongoing upkeep. New software also needs yearly maintenance, which we plan at 15% to 25% of build cost as a convention rather than a measured benchmark.

Tax and accounting notes

Since 2025, US tax law lets companies deduct domestic software development costs right away, while research performed outside the United States is still spread over 15 years. Whether and how that applies to modernization work depends on the specifics, and your tax advisor should decide. We are an India-based engineering team with a US office in Jenks, Oklahoma, so we would rather you hear it from us. We cover the basics in our software cost guide.

How to choose a modernization partner

• Do you run a paid assessment of the application first, and what does it produce?

• How will you prove the new system behaves like the old one, and who writes the tests?

• Which tasks do you use AI for, and who reviews its output?

• How do you handle data migration and the cutover, and what is the rollback plan?

• Which roles and how many hours sit behind your quote, and what is excluded?

• Who owns the code, the documentation and the test suite from day one?

• Which named people will work on it, and does the contract keep them there?

• What happens if we pause after the first phase?

If you need to add engineers to a team that already runs the system, see our staff augmentation for US companies page, and our guide to hiring software developers in the USA.

How Akoode approaches modernization

When we are the right choice, and when we are not

We are a good fit when you have a business application on an aging stack, a clear problem and the need for a partner who will plan in phases and test as they go. If your system is a mainframe program that needs COBOL specialists, we will tell you honestly whether we are the right fit before you spend anything. And if SaaS covers what the old system does, buying may beat modernizing. Our guide to custom software vs SaaS has the five-year math.

How we scope and price

We do not publish a rate card. A quote starts with a one-to-two-week discovery that settles which applications to touch, which path fits each, the integrations and the risks. It produces a roadmap and a scoped estimate tied to roles and hours. We work on a fixed-cost, dedicated-team or staff augmentation basis, depending on how settled your scope is. Our engineers are in-house, and you own the IP.

Start with our custom software development company in the USA page, our software development services and our enterprise application development work. For AI-assisted work, see AI development for US businesses.

Proof from delivered projects

None of these is a mainframe migration, and we will not dress them up as one. They are examples of replacing fragmented or manual work with one connected system.

• We built one connected system that runs three retail repair locations and a nationwide mail-in repair operation from a shared backbone. Read the case study.

• For Qualis Construction Ltd., we built an AI quantity takeoff application that replaced manual blueprint counting. Read the case study.

• We built a subscription-based property and lead platform with a web dashboard for the office and a Flutter app for agents in the field. Read the case study.

Our Google rating is 4.9 from 126 reviews, and we have delivered 180+ projects across 15+ industries.

Frequently asked questions

How much does legacy software modernization cost?

Per application in the US market, plan on $25,000 to $150,000 to rehost, $80,000 to $300,000 to replatform, $150,000 to $600,000 to refactor, and $300,000 to $1.5 million or more to rebuild. Published guides range even wider, from about $25,000 to $2 million or more. A paid assessment of the application is the most reliable way to narrow your number.

What is the difference between rehosting, replatforming, refactoring and rebuilding?

Rehosting moves the application to new infrastructure without changing code. Replatforming makes selective changes to the runtime, database or deployment, such as upgrading .NET. Refactoring restructures the code to remove technical debt while behavior stays the same. Rebuilding replaces the system with a new one on a modern stack. Each step costs more and changes more.

Is it cheaper to refactor or rewrite a legacy system?

Usually refactoring. One 2026 guide puts it at roughly 40% to 60% of the cost of a rewrite of the same system, because you do not pay to rediscover what the system does. That is a vendor estimate, not a rule. Rewrite when the code no longer reflects what the business does or the architecture blocks your plans.

How long does legacy modernization take?

Planning figures: a rehost takes about 1 to 4 months, a replatform 3 to 6 months, a refactor 6 to 12 months, and a rebuild or phased replacement 12 to 24 months or more. Integrations, data migration, testing and how long the system can be offline set the pace more than coding does.

What happens when software reaches end of support?

It keeps running, but it stops receiving security patches, so new vulnerabilities stay open and the risk grows over time. Paid extended security updates can bridge the gap. SQL Server 2016 ended extended support on July 14, 2026, .NET 8 and 9 on November 10, 2026, and Windows Server 2016 and .NET Framework 4.6.2 end on January 12, 2027.

Can AI make legacy modernization cheaper?

In parts. Reported 2026 results include McKinsey's 40% to 50% faster timelines and AWS's 50% effort reduction on a large COBOL project. But Gartner predicts that more than 70% of mainframe exit projects started in 2026 will fail to deliver their intended benefits, largely from overestimating AI. Ask vendors which tasks AI speeds up and who reviews the output.

When should I retire or keep a legacy system instead of modernizing it?

Retire an application nobody uses and archive its data. Keep one that is supported, stable, isolated and rarely changed. Modernize when the system is out of support, blocks business changes, costs too much to run or fails audits. If the payback only works at your best-case assumptions, do not start.

Get a modernization assessment

If you have a system approaching an end-of-support date, book a technical consultation. Bring what you have: a list of applications, the versions underneath them and the deadline that worries you. We will tell you what we would ask in discovery, which path we think fits, and where the risk sits, whether or not you end up working with us.