When to Rewrite vs. Maintain: The 2026 Decision Framework

Ask “should we rewrite or maintain this system?” and you will get a bad answer, because the rewrite vs maintain question misstates the problem. Both poles carry documented failure records. Consequently, a question whose only two answers both fail reliably is not one you should try to answer. The real issue is the unit of decision: you can route a component, never a whole system. This article gives you the classifier we use instead — six gates, dated thresholds, and a breach rule for every route.

Why the rewrite vs maintain binary survives

The binary persists because procurement creates it. Notably, the UK National Audit Office found that essential non-functional requirements are routinely stripped out of digital contracts by commercial teams as “savings,” and stated plainly that this has contributed to the deterioration of many legacy systems over time.

That mechanism matters. Specifically, commercial teams delete maintainability at contract signature, years before anyone notices. Therefore, by the time a team asks the rewrite question, the system has already hardened into something that resists incremental change — and the binary looks like the only available choice. It is not.

What both poles actually cost

The maintain pole. The UK government’s own review found that maintaining legacy systems often costs three to four times that of modern alternatives, citing HMRC’s COBOL maintenance contracts as the demonstrating example. Furthermore, that review recorded UK public-sector organisations spending as much as 70–85% of technology budgets on upkeep rather than modernisation, against roughly 60% among digital leaders.

The replace pole. Across five UK government digital change programmes, cost increases exceeded £3 billion — at least 26% above original forecast — with delays totalling at least 29 years. Meanwhile in the US, an independent 2022 Institute for Defense Analyses estimate put the VA’s electronic health record modernisation life cycle cost at $49.8 billion, and GAO reported in December 2025 that the programme now aims to complete roughly 170 sites by 2031.

Both poles are expensive. Accordingly, the useful work is not picking one but avoiding the choice.

Step 0: score the risk before you choose a strategy

The UK Government’s Legacy IT Risk Assessment Framework assesses systems against 7 likelihood criteria (scored 1–6) and 6 impact criteria (scored 1–5). Aggregated likelihood multiplied by aggregated impact produces a score out of 30, where 16 or above makes a system formally “red-rated.”

Borrow the structure, but understand what the score does. Critically, it answers exactly one question: am I allowed to do nothing this cycle? It does not name a route. Below 16, with no dated external deadline inside 24 months, the correct output is “no decision required — re-score in 12 months.”

That stand-down output matters more than it looks. Otherwise, a classifier that can never say “not now” becomes a machine for generating rewrites. In our experience, stand-down is the single most common correct answer.

Step 1: the unit of decision is the component

This is the shortest section and the most important one. List components, not systems. Subsequently, score and route each component separately.

A single application routinely produces four or five different answers. Indeed, the vendor frameworks already concede this implicitly: Microsoft’s Cloud Adoption Framework, AWS’s seven migration strategies, and ISO/IEC/IEEE 14764:2022 all describe portfolios of approaches rather than one verdict per system. However, none of them tells you which approach a given component gets. That routing is the gap this framework fills.

The six bounded routes

Every route below stays bounded — each carries a fact that makes it finite. Unbounded work is how modernisation programmes die.

• Retire / repurchase. The component is no longer needed as-is, or a commodity equivalent costs less than a year of current run cost. Bound: a decommission date.
• Extend. Buy the dated vendor extension, freeze feature work, and price the exit immediately. Bound: the purchased support end date plus a written no-new-features rule.
• Re-platform. Same code, new runtime, host, or major version. Bound: the end-of-life date that triggered it.
• Build the seam. You hold the source but have no interception boundary yet. Fund the boundary as its own workstream — event interception or branch-by-abstraction — before attempting displacement. Bound: one boundary, one release.
• Carve. Replace one nameable subsystem behind an existing seam while everything else stays on maintenance. Bound: one subsystem, one seam, one quarter.
• Strangle. Sequenced displacement across a large estate, with a published module burn-down. Bound: the burn-down plus a named finish owner and a finish date.

Whole replacement is deliberately absent. Rather than a route the classifier selects, it remains the residual after all six others fail.

The classifier: six gates, first match wins

Run each component down this list and stop at the first gate that fires.

1. Demand. Still needed substantially as-is in three years? Is a commodity equivalent available for under a year of run cost? → Retire / repurchase.
2. Clock. Months to the nearest dated external deadline. Under 12 → extend. Twelve to 24 → re-platform. Over 24 → continue.
3. Source. Do you hold the source code? If not, displacement is impossible and only retire, repurchase, or extend remain.
4. Seam. Can you intercept requests at a boundary today? If not → build the seam first.
5. Blast radius. Is the failing behaviour confined to one nameable subsystem? Yes → carve. No, across a large estate → strangle.
6. Residual. Whole replacement, reachable only when three preconditions hold together: the component is genuinely small, the team can write an accurate behaviour specification without the original authors, and a parallel-run comparison harness is budgeted as a line item. Miss one and the honest output is extend until it exists.

Gate 4 is the fix for the most common failure we see. Teams that hold the source but lack a boundary conclude they must rewrite everything, when in fact they need to fund one seam first.

The threshold table: dated numbers that set the gates

The clock gate only works if you can look up real deadlines and real containment prices. Accordingly, the table below lists verified anchors as of publication.

Notice the cost shapes. Extend is recurring and frequently escalating, whereas re-platform is one-off. Consequently, an extension that looks cheap in year one rarely stays cheap.

Worked example: one platform, five different routes

Consider a 2015-vintage regional claims-and-disbursement platform operated from Singapore: roughly 180,000 lines of PHP 8.2, a SQL Server 2016 backend, an HTTP boundary in front of the claims UI, a batch reconciliation service whose vendor contract ended in 2021 with no source handed over, and a small internal reporting module.

Risk scoring lands around 20 out of 30 — red-rated. Doing nothing is therefore disallowed. That is the only thing the score establishes.

• Database → extend. ESUs run out on 17 July 2029, so the exit has to fit inside that window.
• Runtime → re-platform. PHP 8.2 security support ends 31 December 2026, inside the 12-month band. Move the runtime; keep the code.
• Reconciliation service → repurchase. No source means gate 3 fails outright. Buy the replacement instead of attempting to displace what nobody can read.
• Disbursement subsystem → carve. The boundary already exists, the failing behaviour sits in one place, and the runway exceeds 24 months.
• Internal reporting module → whole replacement. Here the residual legitimately fires: it is genuinely small, eleven report definitions specify its behaviour completely, and a parallel-run harness fits in a sprint. All three preconditions hold, so rewriting it is correct.

One eleven-year-old payments platform, five components, five different routes — and exactly one rewrite, on the smallest piece.

Every route needs a breach rule

A bound without a trip-wire is a wish. Accordingly, decide now what happens when a route misses its bound.

Will Larson’s migration model — “derisk, enable, and then finish” — identifies the finish phase as where migrations die, and he argues stalled migrations are rarely a staffing problem. Similarly, Thoughtworks has named the same pathology directly: displacement can stall before completion, leaving a hybrid harder to maintain than either endpoint. Zalando quantified the scaffolding cost, documenting that a parallel run potentially doubles load across all components, and that tearing it down meant deleting roughly 700 lines of production code and 1,300 lines of test code.

Our rule is simple. When a carve overruns its quarter, or a strangle burn-down stalls two quarters running, the route does not silently continue. Instead, it reverts to extend, and the component is re-scored from gate 1. Furthermore, cap concurrency: one strangle per team at a time, because routes that contend for the same engineers all miss their dates together.

What AI changes in 2026 — and what it doesn’t

AI moves one gate, not the framework. Comprehension has always been the expensive precondition: a 2018 IEEE field study instrumenting 78 professional developers across 3,148 working hours found they spend roughly 58% of their time on program comprehension rather than writing code.

That is precisely where the measured gains sit. Thoughtworks reported reverse-engineering a 10,000-line legacy module dropping from about six weeks to roughly two. Meanwhile Google’s own case study of LLM-assisted migration recorded 39 migrations producing 595 code changes, of which the model generated 74% — though its widely-quoted “50% time reduction” is a developer estimate rather than a measurement.

Be careful about the other direction. Veracode’s Spring 2026 study across 150+ models found only 55% of code-generation tasks produced secure code, with Java worst at a 29% pass rate. Additionally, METR’s February 2026 follow-up found a point estimate of −4% speedup with a confidence interval spanning −15% to +9%, and said openly that the data gives an unreliable signal. In short, AI shortens gate 4 and gate 6’s specification work. It does not make whole replacement safe.

How this maps to our earlier articles

Terminology should stay consistent across the series, so here is the mapping. Refresh-in-place is re-platform. Targeted rewrite is carve. One caution: contain-and-freeze in our deferred-maintenance article is an exit decision for systems retiring anyway, whereas extend here buys dated runway for a system you intend to keep. They are different routes despite similar names.

Our earlier guidance that full rewrites should stay at 10% of the estate at most remains an upper bound. In practice, running this classifier drives the number lower, because gates 4 and 6 catch components that would otherwise be misrouted.

Claims we deliberately did not cite

Two widely-repeated figures failed verification, so they appear nowhere above. First, “rewrites cost four to ten times the original build” traces to no primary source we could find. Second, “strangler fig migrations have a 3× higher success rate than big-bang rewrites” circulates constantly yet cites nothing.

We are equally explicit about our own judgement calls. Specifically, the gate order, the 12- and 24-month bands, and the one-year-of-run-cost test in gate 1 are Pegotec operational conventions, not published research. Adjust them to your risk posture.

How Pegotec helps

We run this classifier as a discrete engagement: a component inventory, a risk score per component, a route with its boundedness condition, a named owner, and a finish date. The deliverable is a one-line-per-component decision record you can take to a board — including which routes failed, and why.

If you are staring at a system that feels like it needs a rewrite, talk to us before you scope one.

Read next

• How Long Does Software Actually Last? Lifespan Benchmarks by Software Type in 2026 — the full end-of-life calendar that feeds the clock gate.
• The True Cost of Deferred Software Maintenance: 2026 Failure Benchmarks — what inaction costs before you reach this decision.
• Still Running CodeIgniter 3? Your Options in 2026 — the same decision worked through on one specific stack.