Modernization isn't one project. It's a decision.
Every legacy system conversation eventually collapses into 'we need to modernize this.' That phrase hides four or five very different projects with wildly different price tags, timelines, and failure modes. Picking the wrong one is one of the most expensive mistakes a technical org can make, and it happens constantly because teams jump to a solution before they've named the actual problem.
The numbers explain the urgency. A 2022 study from the Consortium for IT Software Quality (CISQ) put the cost of poor software quality in the US at $2.41 trillion a year, with $1.52 trillion of that tied directly to accumulated technical debt. Separate industry surveys from 2025 put the figure at roughly 40% of IT budgets going toward servicing technical debt rather than building anything new, and McKinsey's research on technical debt estimates it represents 20 to 40 percent of the total value of a company's technology estate before a dollar is spent paying it down. Stripe's Developer Coefficient research, still the most-cited data point on this, found developers spend around 41 percent of their time on maintenance and bad code, and projected that software engineering inefficiency would cost the global economy roughly $3 trillion in lost GDP over a decade.
None of that gets fixed by 'modernizing.' It gets fixed by choosing the right approach for the system you actually have.
The framework: six ways to deal with a legacy system
The standard vocabulary here started as Gartner's '5 Rs' and was extended by AWS into what's now commonly taught as six or seven Rs. Three of them are about whether to touch the system at all:
- Retire — decommission it. If nobody depends on it, killing it is the highest-ROI modernization move available, and it's the one teams skip most often because nobody owns the decision.
- Retain — leave it exactly as it is, on purpose, and revisit later. Not every system needs to be touched this year.
- Repurchase — replace custom code with a SaaS or COTS product. Common for commoditized functions like payroll, HR, or CRM, where maintaining a bespoke build has stopped making sense.
The other four are the engineering-heavy paths, and they're the subject of this article: Rehost, Replatform, Refactor, and Rebuild (sometimes split further into Refactor and Re-architect). These are the options you reach for when the system is staying, in some form, and the question is how much of it gets rewritten.
| Approach | What it means | Typical cost | Typical timeline | Best for |
|---|---|---|---|---|
| Rehost | 'Lift and shift' — move the app to new infrastructure with no code changes | $25K–$150K | Weeks to 6 months | Stable systems where the problem is hosting cost or a data center exit, not the code |
| Replatform | 'Lift, tinker, and shift' — move to a new runtime or managed services with minor code changes | $75K–$270K | 3–12 months | Systems that need a real infrastructure upgrade but don't need an architecture change |
| Refactor | Restructure code and architecture incrementally while preserving behavior | $180K–$9M+ | 6–36 months | Core systems actively slowing down feature delivery, where a full rewrite is too risky |
| Rebuild | Full rewrite from scratch on modern, often cloud-native, architecture | $500K and up | 12–18+ months | Systems too small to justify incremental work, or too broken to save |
Rehost: the cheapest option, and the one that fixes the least
Rehosting moves an application to new infrastructure — usually the cloud — without touching a line of code. It's the fastest path to a lower hosting bill, and industry benchmarks put the infrastructure savings at 20 to 40 percent once the move is done. For a straightforward system, that's a small-scope engagement: roughly $25K to $150K and anywhere from a few weeks to six months, depending on how tangled the deployment story already is.
The catch is obvious once you say it out loud: your COBOL app, or your undocumented monolith, is now running on modern infrastructure and is still a COBOL app or an undocumented monolith. Rehosting solves a hosting problem. It does nothing for a code problem. Teams that rehost expecting it to fix delivery speed or reliability are usually disappointed within a year.
Replatform: the middle ground that's easy to underscope
Replatforming goes further than a straight lift-and-shift — swapping a self-managed database for a managed one, upgrading a runtime, containerizing a service — without a full architectural redesign. It sits in the $75K to $270K range and typically takes 3 to 12 months, and it's genuinely the right call for a lot of systems: you get real operational improvement without paying for a redesign you don't need.
The risk with replatforming is scope creep in the other direction. It's tempting to bundle in 'just one more' architectural change once you're already in the code, and that's how a replatform project quietly turns into an underfunded refactor with a replatform budget.
Refactor: the highest-leverage option, and the widest cost range
Refactoring restructures the code and internal architecture while keeping external behavior intact. This is where most incremental modernization work happens, including the strangler fig pattern — running the old and new systems side by side and migrating traffic piece by piece rather than in one cutover. We've written a full deep-dive on that specific technique in Legacy System Modernization Without a Rewrite; this article is about deciding whether refactoring is the right approach at all, not how to execute it.
Cost here spans an enormous range because 'refactor' covers everything from a mid-size service ($180K–$270K, 6–12 months) to a core financial or claims platform. For systems at that scale, traditional refactor and re-architecture work has historically run $4M to $9M over 18 to 36 months. AI-assisted delivery is compressing that: 2025 benchmarks put comparable projects closer to $7.2M over 8 to 14 months, roughly a fifth cheaper and close to half the timeline of the traditional path — a real shift, but not the 10x claims some vendors market.
Rebuild: full control, full risk
Rebuilding means starting over — a genuine rewrite on modern architecture, typically cloud-native from the start. It's justified when the cost of continuing to patch the existing system exceeds the cost of replacing it, or when the system is small enough that the full scope can be reasonably estimated up front. Benchmarks put enterprise-scale rebuilds at $500K and up, running 12 to 18 months traditionally (AI-assisted delivery can bring that closer to $250K and 6 to 12 months for comparable scope).
Rebuild is also the riskiest of the four by a wide margin. You're replacing the system your business runs on with something unproven, usually on a single cutover date, while the team that understands the old system's quirks is busy building its replacement instead of maintaining it. Budget for a parallel-run period, and don't let anyone tell you the old system can be switched off the day the new one ships.
One widely cited industry estimate puts the typical modernization initiative at $1.5M and 16 months — and finds that as many as 79% fail to fully meet their original objectives. Separate research on enterprise software projects broadly puts the failure rate at 58%. In both cases, the leading cause isn't bad engineering. It's picking the wrong approach for the system: rebuilding something that only needed a refactor, or replatforming something that actually needed to be rebuilt. The framework above exists to prevent exactly that mistake, before a single dollar is spent.
What actually moves the price inside each band
Within any of these four approaches, the same handful of factors decide whether you land at the low end or the high end of the range:
- Data migration complexity — volume, quality, and the number of source systems involved. Dirty or duplicated data adds cost regardless of which approach you pick.
- Compliance and regulatory load — healthcare and financial systems carry validation and audit requirements that add real time. It's not a coincidence that a large share of hospitals are still running end-of-life systems: the cost of touching them is genuinely higher.
- Integration surface area — every upstream API, batch job, and downstream consumer is a thing that can't break during the transition, and each one adds testing and coordination cost.
- Parallel-run costs — if the old and new systems run side by side during migration, budget for double infrastructure and support costs for the overlap period, not just the build cost.
- Team availability — whether the work is done by engineers who also keep the legacy system running, or by a dedicated team brought in specifically for the migration, changes both the timeline and the risk of burnout-driven mistakes.
How to actually decide
A rough but reliable heuristic: if the system is stable and the only real problem is where it's hosted, rehost or replatform. If it's core to the business, actively slowing down feature delivery, and can be broken into pieces, refactor incrementally rather than betting everything on one cutover. If the function is commoditized and buying beats building, repurchase. If it's small enough to scope completely, or too broken to be worth saving, rebuild. And if it works and nobody's complaining, retain it and revisit the question in twelve months — that's a legitimate decision, not a failure to act.
When we scope a legacy modernization engagement, this is the first conversation we have, before any code gets discussed: what does this system need to do for the next three years, and which of these four paths gets it there for the least risk. The cheapest option on paper is rarely the cheapest option once you count what happens if it doesn't work.
Not sure which approach fits your system?
We have run rehosts that took three weeks and refactors that took eighteen months, for companies the same size. Send us your system and we will tell you honestly which path fits, what it will cost, and what we would do differently.
Frequently asked questions
How do I know if I need a rehost or a full rebuild?
Start with what's actually broken. If the problem is hosting cost or a data center exit and the code itself works fine, rehost. If the code is the problem, but the system can be decomposed and migrated piece by piece, refactor. Rebuild is for systems that are either small enough to fully rescope or too fundamentally broken to extend. Most systems land in the replatform or refactor middle ground, not at either extreme.
Is refactoring always cheaper than rebuilding?
Not always, but it's usually lower-risk. Refactor and re-architect projects for large systems can run $4M to $9M, which can approach rebuild territory at scale. What tends to differ is payback speed: incremental approaches typically show payback in 12 to 14 months, versus 18 to 36 months for a big-bang rebuild, because you start capturing value from the pieces you've already migrated instead of waiting for one final cutover.
How long does a typical modernization project actually take?
Based on 2025 benchmarking across project sizes, small engagements run 3 to 6 months, mid-size projects run 6 to 12 months, and enterprise-scale work runs 12 to 18 months or more using traditional delivery. AI-assisted delivery is compressing these timelines by roughly 40 to 50 percent on comparable scope, though that gain shows up mainly in code-heavy refactor and rebuild work, not in migration-heavy rehost projects.
What's the biggest reason modernization projects fail?
Choosing the wrong approach for the system, not bad engineering. Industry estimates put enterprise software project failure rates as high as 58%, and one widely cited study found 79% of modernization initiatives fall short of their original objectives. The common thread is scope mismatch: teams rebuild what only needed a refactor, or replatform what actually needed a rebuild, and discover the mismatch six months and a lot of budget later.