Modernization quotes stop being mysterious once you see the multiplier system underneath them. Rehosting (moving an application onto new infrastructure mostly as-is) is the 1x baseline. Replatforming, where you swap one layer (the database, the OS, the runtime) but keep the core, runs 1.5 to 2x that baseline, and a full refactor lands at 2 to 3x. Same application, three invoices. The spread between strategies is usually wider than the spread between vendors.
In dollars: a simple database migration starts around $25K while an enterprise portfolio runs $2M+, and a single departmental app typically lands near $200K, with mainframe-scale programs reaching $60M. Wide ranges. They narrow fast once you fix scope and pick a strategy, which is what this guide is for.
We’re gmware, a software development firm in Austin, TX with delivery centers in Bangalore and Mohali, India, and legacy modernization is the busiest corner of our practice this year. 2026’s end-of-support calendar is forcing decisions that got deferred for a decade. Below: what each strategy costs, the double-pay trap that quietly breaks budgets, and the sequencing we’d actually recommend.
| Scope | Typical 2026 cost |
|---|---|
| Simple database migration | from about $25K |
| Single departmental application | around $200K |
| Multi-app enterprise portfolio | $2M+ |
| Mainframe-scale program | up to $60M |
2026 cost at a glance
What legacy application modernization costs in 2026
Expect $25K at the floor (one database, schema and data moved, application retargeted) and $2M+ for a portfolio program, with a single departmental application near $200K as the most common mid-market anchor. Three variables set where you land: the app’s surface area (integrations, data volume, user count), the strategy multiplier, and team rates. Surface area is a fact you inherit. The other two are choices, and they’re where quotes diverge. The same departmental app can cost two to three times more refactored than rehosted, and that’s the multiplier doing the work, not vendor greed.
There’s also a demand effect on price. The legacy modernization market sits at $21.9B to $30B in 2026 and is projected to reach roughly $92B by 2034. Teams that do this work well are booked through the year. Booked teams don’t discount, so a vague RFP in October costs more than a scoped one in June.
Rehost vs replatform vs refactor
Match the strategy to what’s actually broken: the hosting, one layer, or the architecture itself.
| Strategy | Cost vs rehost | Best for | Pros | Cons |
|---|---|---|---|---|
| Rehost (lift-and-shift) | 1x baseline | EOL deadlines, datacenter exits, stable apps | Fastest, cheapest, lowest execution risk | The code’s problems move with it; cloud bills creep if nobody optimizes |
| Replatform | 1.5 to 2x | Apps held back by one layer (DB, OS, runtime) | Real performance and cost gains without a rebuild | Invites “while we’re in here” scope creep |
| Refactor / re-architect | 2 to 3x | Systems your roadmap will live in for a decade | Modern architecture, faster shipping, easier hiring | Longest timeline, plus the double-pay window below |
The strategy multiplier
Most teams over-buy. If the application is stable and the pain is purely the hosting, rehost it, bank the difference, and revisit in a year. We priced that path separately in our cloud migration cost breakdown for small business. Refactor when the application is where your product roadmap actually lives, because that’s the only case where the 2-to-3x multiplier buys something you’ll use.
The double-pay trap
The double-pay trap is the budget line that never makes the kickoff deck: during a long refactor, you pay for the legacy system and its replacement at the same time. A 12-to-18-month refactor runs legacy infrastructure and the rebuild payroll simultaneously, inflating total cost 37% to 75% before the new system delivers any value. Old hosting keeps billing. Old licenses keep renewing. The maintenance contract on the system you’re replacing doesn’t pause because you started replacing it.
The double-pay window
We’ve sat with modernization budgets where this line was simply absent, and the CFO met it for the first time around month nine. Two mitigations actually work: shorten the overlap window, and retire legacy pieces as their replacements ship instead of waiting for one big cutover. The second one is the strangler-fig pattern, and it earns its own section below.
Rewrite or refactor, and which pays back first
Incremental wins on time-to-value, and it isn’t close: incremental modernization typically reaches payback in 12 to 18 months, while a full rewrite takes 36 to 48 months.
| Approach | First shipped value | Typical payback | Risk shape |
|---|---|---|---|
| Incremental refactor | First slice in production within months | 12 to 18 months | Many small, reversible bets |
| Full rewrite | Mostly at final cutover | 36 to 48 months | One large bet, feedback arrives late |
Refactor vs rewrite
If you’re asking which one we’d fund with our own money: incremental, almost every time. The rewrite case is real but narrow: a genuinely dead platform (VB6, classic ASP, an abandoned vendor framework) with no incremental path worth taking. A rewrite should be argued into, never defaulted into. In our experience, most “we need a rewrite” conversations are actually “nobody left understands the old code” conversations, and an assessment is a lot cheaper than finding that out from a rebuild.
How the strangler-fig pattern de-risks the spend
The strangler-fig pattern puts a routing facade in front of the legacy system, then moves one capability at a time onto new services (orders this quarter, invoicing next), retiring the legacy piece behind each slice as it goes live. Every slice gets its own budget, its own rollback plan, and its own proof that the program works.
How strangler-fig de-risks the spend
That structure attacks both failure modes above. There’s no big-bang cutover, so no single night where everything has to go right. And the double-pay window shrinks continuously, because legacy upkeep (software maintenance typically runs 15% to 25% of the original build cost per year) falls away slice by slice instead of at one distant cliff. The honest caveat: strangler-fig needs seams. Applications with tangled data models resist slicing, and finding out whether yours has usable seams is precisely what a two-week assessment is for.
Why 2026 is forcing the decision
Because the support clocks all expire together. SQL Server 2016 leaves extended support on July 14, 2026, and Microsoft’s extended security updates cost 75%, then 150%, then 300% of license price across three years, pricing designed to push you off the platform, not keep you on it. .NET 8 and .NET 9 both end support on November 10, 2026. Windows 10 stragglers are already paying ESU at $61, then $122, then $244 per device per year.
2026's converging deadlines
If any of those dates touch your stack, the sequencing changes: clear the deadline assets first at 1x cost, then refactor what earns it. We’ve written the specific playbooks, SQL Server 2016 end of support: your four options, costed and the .NET 8/9 upgrade plan, because “modernize everything” is not a plan when the clock runs out in weeks.
How offshore delivery and AI tooling change the math
Rates first. US senior engineers bill $125 to $250+ per hour; Indian engineering talent runs $20 to $45 per hour, averaging about $32. On a multi-quarter modernization program, that gap compounds into the difference between affording a rehost and affording the refactor you actually wanted.
Rate per hour
AI tooling is the newer lever. Grid Dynamics halved a Fortune 500 insurer’s modernization timeline and cut 90% of manual code review with an AI-native approach, and Gartner now tracks AI-augmented code modernization tools as its own category. Our read from using these tools daily: they’re genuinely good at code translation and test generation. What they can’t do is decide which code deserves to survive. The judgment work stays human, which is why the multiplier system above hasn’t collapsed even as the tooling improved.
When modernization is the wrong spend
Three cases where we’d tell you to keep your money. If the application is being replaced by a SaaS product inside two years, rehost for the deadline and stop. Refactor spend never pays back before retirement. If nobody can say what the system must do (no tests, no docs, original team long gone), fund a specification-recovery phase first; modernizing an unspecified system reproduces its bugs on newer infrastructure, just faster. And if the business process the app serves is itself about to change, fix the process before you pour concrete around it in code.
None of those are arguments for doing nothing. They’re arguments for spending the 1x money now and holding the 3x money until the target is stable.
How gmware scopes modernization work
We start with a two-to-three-week assessment: inventory the portfolio, risk-rank it by end-of-support exposure and business value, and assign each application its own strategy. One strategy for the whole portfolio is a tell. It means the vendor is selling a motion, not an outcome. Architecture and client-facing leadership sit in Austin; build capacity runs from Bangalore and Mohali with overlapping US hours. Where the destination is cloud, our cloud consulting team owns the landing zone, and a broader digital transformation program wraps around the rebuild when process change rides along with the code change.
“Every portfolio has one app everyone’s scared to touch. The assessment exists to find out whether the fear is earned.” (one of our modernization leads, on most kickoff calls)
Tell us what you’re running and what’s expiring, and we’ll give you a straight answer on strategy, cost, and sequencing within 48 hours. Start the conversation.