Rebuild vs refactor: when to modernize legacy software

When software gets old and painful, the instinct is to want a clean slate: tear it down, build it right this time. It's an emotionally satisfying plan and, most of the time, the wrong one. The reason is simple. Working software, however ugly, is worth more than you think, and a rewrite throws that value away on day one in exchange for a version that, at launch, does less than what you already had.

So the real question isn't "is the code bad?" It almost always is; that's what technical debt looks like up close. The question is why it hurts. If the system still does what the business needs and the pain is maintenance cost, slow changes, or fragility, that's a refactoring problem, and you fix it in place. If the pain is a hard ceiling, the architecture can't scale, the platform is unsupportable, you can't hire anyone to touch the stack, then and only then is the architecture itself the constraint, and a rebuild earns its risk.

Getting that distinction right is worth a lot, because the wrong call is expensive in both directions: refactor something that genuinely needed rebuilding and you pour money into a dead end; rebuild something that only needed cleaning up and you take on the single riskiest project in software. Here's the vocabulary this guide uses, in plain English:

Legacy system

Software that still runs the business but is old enough that it's hard to change safely: an unsupported framework, a language few people want to touch, or an architecture built for a smaller, simpler version of the company. Legacy doesn't mean broken. It usually means expensive to maintain and slow to extend.

Technical debt

The accumulated cost of shortcuts, aging dependencies, and decisions that made sense at the time but now slow every change down. Like financial debt, a little is normal and useful; too much means you pay interest on every new feature in the form of extra time and risk.

Refactor

Restructuring and cleaning up existing code without changing what it does for users, so it's cheaper to maintain and safer to extend. It's the lowest-risk way to make a deep change, because the system keeps working the whole time and every hard-won fix stays in place.

Rebuild

Rewriting the software from scratch, keeping the same scope but starting from an empty file. Also called a rewrite. It's the most disruptive deep-change option, because you re-earn every edge-case fix the old system already learned, and users get nothing new until the new version catches up.

Strangler Fig pattern

A way to modernize incrementally: build new components alongside the running legacy system and migrate behavior piece by piece, so the old system is gradually replaced rather than switched off in one risky cutover. Named by Martin Fowler, and published as a standard pattern by both AWS and Microsoft.

Big-bang migration

Replacing the whole system at once, then flipping everyone over on a single go-live date. Conceptually simple and operationally dangerous: the new system has to match years of accumulated behavior on day one, and there's no partial fallback if it doesn't.

Technical debt isn't a metaphor for "bad code." It's the accumulated cost of past shortcuts and aging dependencies, and you pay interest on it in real time, as extra hours and extra risk on every change. Three numbers frame how large that interest bill gets:

Stripe's survey of developers and executives found the average developer loses about 17 hours a week to maintenance and dealing with bad code, and pegged the global drag from bad code at roughly $85 billion a year¹¹⁶. McKinsey's survey of CIOs put technical debt at 20 to 40 percent of the value of their entire technology estate, with a further 10 to 20 percent of new-product budgets quietly diverted to servicing it, and 60 percent of CIOs saying the debt had grown noticeably over the prior three years².

The government number is the hardest anchor of all, because it's audited rather than self-reported: the US Government Accountability Office found that around 80 percent of the federal IT budget goes to operating and maintaining existing systems, out of more than $100 billion in annual spend³. A small business isn't the federal government, and your exact split will differ, but the shape holds everywhere: left unaddressed, keeping the lights on eats the budget that should be funding new capability. That's the pressure that puts rebuild-versus-refactor on the table in the first place.

In 2000, Joel Spolsky wrote what remains the definitive warning on this. Rewriting code from scratch, he argued, is "the single worst strategic mistake that any software company can make." His example was Netscape, which decided to rewrite its browser and then shipped no major release for roughly three years, handing the market to Internet Explorer while it rebuilt⁴. The company effectively took itself off the field to redo work it had already done.

Spolsky's deeper point is the one that catches teams out. That old, ugly code you want to throw away looks ugly precisely because it works. "Each of these bugs took weeks of real-world usage before they were found," he wrote; the messy conditionals and odd special cases are years of hard-won fixes for edge cases you've long since forgotten. A rewrite silently discards every one of them, then rediscovers each as a brand-new bug in production. You don't start from zero; you start from below zero.

McKinsey and the University of Oxford, studying more than 5,400 large IT projects, found an average 45 percent budget overrun, a 7 percent time overrun, and 56 percent less value than predicted, with one in six turning into a "black swan" that threatened the company's existence⁵. A ground-up rebuild is exactly the kind of long, all-or-nothing project that produces those numbers. That doesn't make rebuilding always wrong. It makes it a decision that has to clear a high bar, not a default you drift into because the code offends you.

Martin Fowler named the pattern after a vine that grows around a host tree and gradually replaces it. Applied to software, you build new components "on top of, yet separate to" the legacy system, then move functionality across a piece at a time, so "investment and returns occur gradually and visibly" instead of arriving, or failing to arrive, in one enormous cutover⁷. The old system keeps running and shrinking until, eventually, there's nothing left to strangle.

This is the opposite of a big-bang migration, and it's preferred for a concrete reason. As Thoughtworks puts it, replacing a serious system all at once is "disruptive, fraught with risk, and an immense strain," because the replacement has to match years of accumulated behavior on day one and users can't wait months with nothing⁸. Incremental migration spreads that risk out and delivers value the whole way through. It's not a fringe idea, either: both AWS and Microsoft publish the Strangler Fig as a standard, low-risk modernization pattern in their official architecture guidance⁹¹⁰.

Gartner's analysts lay out seven options for modernizing a legacy system, in rising order of risk, cost, and disruption¹¹. Seeing them as a ladder rather than a yes/no choice is most of the battle, because it forces the question "what's the cheapest rung that fixes my actual problem?" before anyone reaches for the most drastic one:

1. Encapsulate (lowest risk)

   Leave the legacy system running and wrap it behind an API so new services can reach it without touching the old code. Nothing inside changes; you just make the old system reusable. It buys time but doesn't reduce the underlying technical debt.

2. Rehost

   Lift and shift the same application onto new infrastructure, usually cloud, with no code changes. It cuts hardware risk and hosting cost quickly, but every line of legacy logic and every bit of technical debt comes along untouched.

3. Replatform

   Move to a new runtime or platform with small, targeted code changes, like a supported language version or a managed database, while keeping the architecture and features the same. Modest risk for a real operational upgrade.

4. Refactor

   Restructure and clean up the existing code without changing what it does for users, so it's cheaper to maintain and safer to extend. The lowest-risk way to make a deep change, and the right call when the software still fits the business but the code has decayed.

5. Rearchitect

   Materially change the code to shift it onto a better-fitting architecture, for example breaking a monolith into services. Higher effort and risk than refactoring, reserved for when the current structure genuinely blocks where you need to go.

6. Rebuild

   Rewrite the component from scratch, keeping its scope and specifications. High risk and high cost: you re-earn every edge-case fix the old system already learned, and users get nothing new until the rebuild catches up.

7. Replace (highest risk)

   Retire the system entirely and swap in something new, often off-the-shelf, accounting for new requirements. The most disruptive option and rarely reversible once the old system is gone.

The pivot in the middle of that ladder is the one that matters most for owners. Refactor is the lowest-risk way to make a deep change, and it's the right call whenever the software still fits the business but the code has decayed. Rebuild and replace sit at the far, high-risk end, reserved for when the current architecture genuinely can't meet future needs. Put the two options side by side and the trade-off is stark:

Underneath the ladder sit the signals that tell you which rung you're actually on. These are the criteria we use when we audit an existing codebase and have to give a client a straight answer:

1. Refactor when the software still fits the business

   If the system does what the business needs and the pain is maintenance cost or slow changes, not a hard capability ceiling, refactor in place. Working code carries years of quiet bug fixes you'd otherwise throw away and rediscover.

2. Refactor when downtime or migration risk is high

   When the system is business-critical and can't go dark, incremental change beats a cutover. Refactoring and the Strangler Fig pattern keep the software running the whole time, so a mistake is contained instead of company-threatening.

3. Rebuild when the architecture is the constraint

   When the current design literally can't meet future needs, it won't scale, or the assumptions it was built on no longer hold, a rebuild or rearchitect may be the only path. The trigger is the architecture, not the mess in the code.

4. Rebuild when the platform is unsupportable or unhireable

   If the framework is end-of-life and can't be upgraded in place, or the stack is so obscure you can't hire anyone to maintain it, a rebuild onto a supportable platform can be justified. Weigh it against replatforming first.

5. Take the smallest step that clears the blocker

   Most owners jump to rebuild or replace when encapsulate, rehost, replatform, or refactor would solve the actual problem for a fraction of the risk. Pick the lowest-risk option on the ladder that removes the real constraint.

6. Never rewrite just to escape ugly code

   Ugly is not the same as broken. A messy codebase can almost always be cleaned up incrementally, at far lower risk than a rewrite. Reserve the full rebuild for when a cheaper option genuinely can't clear the constraint.

Both halves of the story are real, which is why the honest picture is a tension rather than a slogan. Here are the three measured results people actually cite:

From roughly 2018 to 2024, the mood was optimistic. A controlled GitHub trial found developers completed a greenfield task about 55 percent faster with Copilot, and a much-repeated figure attributed to Gartner claimed AI could cut modernization costs by 70 percent by 2027¹³. Treat that second number with care: the primary source for the "70 percent cost cut" claim isn't confirmed, so it's best read as an unverified, widely-copied assertion rather than a finding you can bank on.

The 2025 to 2026 evidence points the other way, and it's better sourced. METR ran a controlled study of experienced developers working on their own mature repositories and found they were 19 percent slower with early-2025 AI tools, even though they believed they were about 20 percent faster¹². Then in June 2026 Gartner predicted that more than 70 percent of mainframe-exit projects started that year will fail to deliver their intended benefits, specifically because organizations overestimated what generative AI could do on complex legacy systems⁶¹⁵. The app-modernization services market is still forecast to grow from about $28 billion in 2026 toward $52 billion by 2030, so the spending isn't slowing; the expectations are just being reset¹⁴.

The pattern underneath the whiplash is consistent. AI compresses effort most on fresh, well-scoped work and on modernizing in place, using a model to explain unfamiliar code, translate a module, or accelerate a refactor a senior is reviewing. It helps least, and sometimes hurts, on the exact thing the hype promised: a full, one-shot migration off a gnarly legacy system. Which is another way of saying AI strengthens the case for incremental modernization over the big-bang rewrite, rather than finally making the rewrite safe.

Inheriting someone else's codebase is normal work for us, not a special case. The order of operations is what keeps it honest. Before we recommend anything, we audit: we read the code, map the behavior, and locate where the debt and fragility actually live. Only then do we give a recommendation, and it's a genuine one, because the audit comes first and the answer isn't predetermined by which path bills more. Sometimes the honest call is "this still has business value, we'll refactor and strangle it incrementally." Sometimes it's "the architecture is the ceiling, here's the case for rebuilding this part." Our bias, backed by everything above, is toward incremental modernization wherever the code still earns its keep.

Whatever the call, the commercial terms are the same as any of our builds. You get a written scope, a fixed quote against it, and milestone billing tied to working software, so you're never paying ahead of what's been delivered. And you own the result outright: the code, the repositories, the infrastructure, and the IP, in your own name, with no license and no lock-in. We work on your platform and hand it back; we never own it. Our custom software development services page covers how we build, and our custom software build methodology walks through how a written scope becomes a milestone plan.

If you already have software that's become painful to run, a free codebase audit is the fastest way to a straight answer on whether to refactor or rebuild, with a fixed quote for whichever the audit recommends.

If you want to understand how we build before you hand anything over, our custom software development services page and our custom software build methodology cover the written-scope, fixed-quote, milestone-billing approach, and if you know it's a web or mobile product, the web app development and mobile app development pages go deeper on each. When you're ready to scope the actual work, that's what our build process is for.

And if the open question is really about budget, our guide on how much custom software costs breaks down the 2026 numbers, or browse the rest of our guides for the surrounding decisions.