Rewriting an app from scratch: Pros, cons & decision guide

This guide breaks down when a rewrite pays off, when it's a trap, and how to structure the decision so engineering and business leadership agree before code freeze starts.

Rewriting from scratch vs. Refactoring: The quick answer

Rewrite from scratch outperforms refactoring only when technical debt in the legacy codebase has compounded past the point where developers spend more time patching old code than shipping new product features. That threshold, not gut feel, should drive the decision.

In our work with production systems, including Moove's fintech MVP rebuild across nine African countries, we have found the sunk cost fallacy keeps development teams patching an old codebase long after rewriting legacy code would serve the business better. The average software project runs 189% over its original cost estimate and 222% over its original timeline (Standish Group CHAOS Report, 1994).

This piece maps the total cost of ownership math, the code freeze tradeoff, and the comparison between a strangler fig migration strategy and rewriting the app from scratch.

What does rewriting an app from scratch actually mean?

Rewriting an app from scratch means replacing the legacy codebase entirely, building new code that reproduces (and eventually exceeds) the old system's functionality rather than patching it piece by piece. The distinction that matters most upfront is how you replace it: big-bang or incremental.

A big-bang rewrite freezes the old application, builds the new one in parallel over months, and cuts over in a single release. It is faster to reason about but riskier: if the new system misses feature parity on launch day, developers and the business absorb the failure at once, in production, with no fallback.

An incremental rewrite avoids that cliff edge. Teams route traffic gradually from old to new components, often using the strangler fig pattern, until the legacy system has nothing left to serve and can be retired. This is slower, and it means running two systems side by side, but it lets developers validate each piece against real production traffic before the old code disappears.

Neither approach is refactoring. Refactoring improves the existing code's structure without changing what it does; rewriting from scratch is a rethink of the system itself, often because the old code's design can no longer support the product a business needs to ship. That difference in scope is what drives the cost and risk tradeoffs we cover next.

Pros of rewriting an app from scratch

The biggest argument for rewriting an app from scratch is that it clears technical debt in one move instead of paying it down for years. A legacy codebase built on a framework nobody wants to touch stops being a liability the moment you retire it.

Deciding when to make that move is rarely obvious, since the payoff has to outweigh the disruption of a full rebuild.

That clean break lets developers adopt a modern stack without working around old constraints. New language versions, current cloud-native patterns, and a regression suite designed for the actual product (not bolted onto a decade of workarounds) all become possible on day one.

That's what a clean break can look like in practice: a complex financial application rebuilt from scratch and launched across multiple markets, with a product structure built for the business the company had become rather than the one it started as.

A rewrite also forces discipline that refactoring rarely does. You can't incrementally patch your way to feature parity without a target, so teams end up defining one, which tends to surface assumptions the old system had been quietly carrying for years.

There's a total cost of ownership case here too. Gartner estimates that around 40% of the average IT department's spend gets lost to technical debt maintenance, which suggests carrying an aging system indefinitely isn't free, even when it looks stable.

Run that number against a realistic migration strategy and a rewrite sometimes wins on a five-year horizon, even with the higher upfront project cost. The catch, which the cons section covers, is that this only holds if the rewrite actually finishes on time.

Cons and risks of rewriting an app from scratch

Most teams underestimate how long a rewrite takes to reach feature parity with the legacy codebase it replaces, and that gap is where budgets and credibility both erode.

Among large software projects (over $10M), 56% run into serious challenges or overruns, averaging 230% over the original timeline and 178% over the original cost (Standish Group CHAOS Report, 1994), showing overruns are the norm, not the exception, and feature parity is usually the last milestone hit rather than the first.

A full rewrite typically forces a code freeze on the old system. Every feature request paused during that freeze piles up as backlog the new product has to absorb on day one, and the business unit waiting on those features inherits the delay.

Vendor lock-in is a second, quieter risk that many organizations want to avoid. Swapping one framework or cloud provider for another mid-rewrite can trade old technical debt for a new dependency that's just as hard to migrate off in five years.

McKinsey's CIO survey puts a number on why teams keep making this trade anyway: tech debt equals 20-40% of a company's entire technology estate value (McKinsey & Company, "Tech debt: Reclaiming tech equity," 2020), yet staying on the old stack still looks cheaper in the short term.

There's a psychological trap too. Once a rewrite is underway, sunk cost fallacy keeps developers and sponsors funding a project that a rational total cost of ownership model would have killed months earlier. A partial migration strategy using the strangler fig pattern avoids the all-or-nothing bet that refactoring in place doesn't force on you, but once a big-bang rewrite starts, that option is gone.

Rewrites also reset the regression suite to zero. Every edge case the old application quietly handled for years gets rediscovered, usually by a customer, not a developer.

Refactoring vs. Rewriting: How the tradeoffs compare

Refactoring versus rewriting presents a clear trade-off on total cost of ownership, with refactoring winning more often because it spreads risk across small, reversible changes instead of betting the roadmap on one big-bang release that requires a much larger upfront investment.

The strangler fig pattern lets teams route traffic to new modules piece by piece, keeping the legacy codebase live while pressure points get rebuilt underneath it.

Rewriting looks cleaner on a whiteboard for the user to visualize and iterate on. In practice, teams that have already sunk months into a rewrite tend to keep funding it past the point of sense, a textbook sunk cost fallacy that a phased refactor mostly avoids, since each increment either proves its value or gets cut.

Neither path is free. Refactoring a genuinely unworkable legacy system can cost more in developer hours than a disciplined rewrite would, particularly when the old code fights every new change. The right migration strategy depends on how much of the existing product is salvageable, not which approach sounds more modern.

Rewrite vs. Refactor: A decision framework

A rewrite makes sense when technical debt has compounded past the point where the legacy codebase can absorb new features without breaking old ones. Refactoring wins everywhere else. The decision framework below scores five signals rather than relying on gut feel or how frustrated the team is with the old code.

Run this scoring exercise before the sunk cost fallacy runs it for you. Teams rarely say "we're rewriting because we're emotionally invested in this old code" out loud, but "we've already spent two years on this system, we can't throw it away" is the same reasoning in different words. The framework forces the conversation onto architecture and total cost of ownership instead.

According to the Standish Group CHAOS Report, large software projects with big-bang delivery models overrun budget and timeline far more often than those shipped incrementally, which is the strongest empirical argument for scoring refactor first and rewrite only when the table above says otherwise.

When is rewriting from scratch the wrong call?

A rewrite from scratch is the wrong call when the legacy codebase still ships revenue-generating features faster than a green-field team could rebuild them. If the old system handles 80% of production traffic without incident, the argument for scratch work is emotional, not economic.

Teams reach for a rewrite when they're tired of the code, not when the total cost of ownership math actually favors one.

The riskier failure mode shows up mid-project: sunk cost fallacy keeps a doomed rewrite alive long after the data says stop. A team six months into a twelve-month rewrite, watching the MVP slip and feature parity stay out of reach, will often push forward rather than admit the spend was wasted.

The original Standish Group CHAOS survey backs this pattern up across large software projects generally: 52.7% of projects ran 189% over the original cost estimate (Standish Group CHAOS Report, 1994).

Our view: set a kill criterion before the code freeze starts, not after. If the MVP hasn't reached feature parity on core workflows by a fixed date, revert to incremental migration on the old system rather than funding another quarter of scratch development.

How to rewrite without a big-bang cutover: The strangler fig pattern

The strangler fig pattern avoids a big-bang cutover by routing traffic to new code one feature at a time, while the legacy codebase keeps running underneath until nothing depends on it. You migrate a checkout flow, verify it against production traffic, then move to the next module. No six-month code freeze, no single go-live date where the whole system either works or doesn't.

Mechanically, this means standing up a routing layer (an API gateway or reverse proxy) that decides per-request whether to hit old or new code, plus a regression testing suite that runs against both paths to confirm feature parity before you flip traffic. Skip that suite and you're rewriting on faith.

The tradeoff is calendar time. A migration strategy built on strangler fig increments can take longer end-to-end than a rewrite from scratch, because developers maintain two systems in parallel for months. In practice, this is why total cost of ownership models favor the pattern for revenue-critical systems: partial failure costs a broken feature, not a broken product.

Refactoring in place is a lighter version of the same idea, for teams not ready to commit to a full rewrite yet.

How much does a rewrite cost, and how long does it take?

A full rewrite from scratch typically runs 12 to 24 months and costs two to five times more than the equivalent refactoring effort, though the range depends heavily on legacy codebase size and how many integrations need rebuilding (Kunalganglani.com - Software Rewrite from Scratch).

According to the Standish Group CHAOS Report, a large share of large software projects run over budget or over schedule, and rewrites carry that risk more than incremental work because there is no working system to fall back on mid-project.

Build your total cost of ownership model before you commit, not after. A TCO comparison should stack the rewrite's build cost, migration strategy overhead, and parallel-running expenses against the ongoing cost of carrying technical debt in the old system. Industry estimates that put technical debt at 21% to 40% of IT spending give a rough anchor for the second side of that equation.

Timing depends on when you start your migration strategy. A strangler fig approach spreads cost over many small releases and lets a team keep shipping product features during the transition. Big-bang rewrites concentrate cost into a single code freeze window, which is faster to plan but riskier to execute, since developers can't validate feature parity until the very end.

That large IT and software projects run 45% over budget on average (McKinsey & Company / University of Oxford, 2023) is worth pulling into your board conversation early. Once a rewrite passes 18 months without shipping, sunk cost fallacy starts influencing decisions more than the original business case did.

Case study: Rebuilding a fintech app under time pressure

Rebuilding a fintech app from scratch under a hard launch deadline forces a different calculus than a rewrite done at leisure. Netguru's engagement with Moove, a fintech app already live and processing real transactions, is a case in point.

The migration strategy could not be a slow strangler fig rollout. Nine markets, each with distinct payment rails, regulatory checks, and mobile network conditions, meant the new system had to launch close to a big-bang cutover rather than an incremental one.

Feature parity was the non-negotiable constraint: drivers and fleet owners already depended on the old app daily, so the rebuild had to match every workflow before a single legacy instance went dark.

What this case shows is that rewrite discipline matters more, not less, under time pressure. A regression suite covering the full transaction surface ran before code freeze, and the team treated feature parity as the release gate rather than a nice-to-have.

Mobile money transaction volumes across African instant payment systems grow at double-digit rates year-on-year (World Bank - Scaling Instant Payments in Africa), and the global mobile payment market overall is projected to reach $12.06 trillion by 2027, per our analysis of the future of payments.

That growth underscores why a fintech app serving multiple African countries cannot afford launch instability: the addressable market moves fast, and downtime carries a real revenue cost.

FAQ: Rewriting vs. Refactoring an app

Making the call: Rewrite, refactor, or wait

The decision to rewrite from scratch comes down to one model: total cost of ownership over three to five years, not the sprint cost of the next release. Run the numbers against refactoring, sunset legacy patches into a migration strategy, and treat a code freeze as a last resort, not a default.

We've seen this calculation done right on complex, regulated rebuilds. That played out at FairMoney: new provider integration completed in under 3 months, NPS score of 9.

If your team is weighing a rewrite, a refactor, or a strangler fig migration for an aging application, talk to our team before committing engineering quarters to the wrong one.