The slide had one number on it. Seventy per cent. A board member wanted to know why the legacy modernization programme was worth the risk if seven in ten fail. The CTO couldn't answer. Nobody in the room could name the study.
There isn't one. In 2011, a peer-reviewed review in the Journal of Change Management went looking. It examined five separate published instances of the 70 per cent organizational-change failure rate and reported "the absence of valid and reliable empirical evidence in support of the espoused 70 per cent failure rate" in each one [F1].
Fifteen years on, that number is still the opening move in most legacy modernization conversations. Which tells you what most of those arguments are made of.
Legacy modernization is the work of changing an old, business-critical software system so that it can keep being changed. There are three roads, and only three: refactor the system in place, replace it incrementally behind a facade, or rewrite it from scratch.
Key takeaways
Start with the provenance, because the provenance is the story. The home most often pointed to is a McKinsey piece from July 2019, Why do most transformations fail? A conversation with Harry Robinson. It says: "The academic research is really clear that when corporations launch transformations, roughly 70 percent fail." No study named, no sample size, no method, no footnote [F2]. The claim is that the academic research is clear, and the academic research is not cited. Hughes' verdict: "there is no valid and reliable empirical evidence to support such a narrative" [F1].
The modernization-specific variants are worse. Figures of 70 per cent, 68 per cent and a suspiciously precise "70–88%" circulate widely. Every traceable instance turns out to be uncited vendor content marketing. Most of it is attached to a company selling an AI modernization service, and none of it names a study, a sample or a method [F4]. There's no primary. Just the number, passed hand to hand, acquiring authority through repetition.
Here's what a real number looks like. In June 2019, the US Government Accountability Office reviewed 65 legacy systems that 24 federal agencies had flagged themselves, named the ten most critical, and reported them as 8 to 51 years old — one Department of Homeland Security system carrying 168 vulnerabilities rated high or critical [N4]. Those ten cost about $337 million a year to run [N5]. In the latest round, the 11 most critical systems across 10 agencies ranged from about 23 to 60 years old at roughly $754 million annually [N6]. As of February 2025, agencies had completed three of the ten modernizations identified in 2019 [N6].
That rate has named systems, a named auditor and a stated scope. It also doesn't generalise to your decision, which is the point: nobody knows the population failure rate. So what's left? The variables somebody actually measured.
The measurement that should govern this decision came out of Windows Vista, and it wasn't about code.
Nagappan, Murphy and Basili built defect-prediction models for Vista binaries from six families of metric and compared them head to head. Organizational structure metrics — how many engineers touched a component, where they sat in the org chart, how concentrated ownership was — hit precision of 86.2 per cent and recall of 84.0 per cent. Code churn came in at 78.6/79.9, complexity at 79.3/66.0, dependencies at 74.4/69.9, pre-release defects at 73.8/62.9. Coverage managed 83.8 precision but collapsed to 54.4 recall. The paper's conclusion is flat: "organizational structure metrics are significantly better predictors for identifying failure-prone binaries in terms of precision, and recall compared to models built using code churn, code complexity, code coverage, code dependencies and pre-release defect measures" [N8].
Read the losing list again. Churn, complexity, coverage, dependencies, prior bugs. That is the entire technical case for a rewrite, and the org chart beat all of it. If you're shortlisting engineering metrics that predict delivery, start there.
The second pillar is older and sharper. Herbsleb and Mockus ranked what drove change interval across two departments, 2,227 modification requests in one and 4,974 in the other. In Department A the order ran number of people, then diffusion, then size; in the replication department, size led and number of people came second. What holds across both is the weight of headcount: "the involvement of more people has a powerful influence on the MR interval" [V3]. And in both, once the other factors were controlled, being spread across sites stopped predicting anything: "Surprisingly, given all other factors, distributed MRs do not have significantly longer intervals than single-site MRs" [V3]. The thing everyone blames was a proxy for the thing nobody counts.
Thoughtworks got to the same place watching replacements fail in the field: "The poor outcomes they were seeing were largely a product of the organization; specifically it's leadership, structure and ways of working. They thought by just selecting newer technologies, but leaving everything else more or less unchanged, that they would get different outcomes from the past" [N3].
Two measurements and one practitioner diagnosis, all pointing at the same variable: the human path a change travels. Rewrite, refactor and replace are arguments about code. The evidence is about the org.
Before any of the three roads opens, there's a bill nobody puts in the business case: finding out what the system currently does.
A field study of 78 professional developers across seven real projects, logging 3,148 working hours, found they spend 58 per cent of their time on program comprehension. Navigation takes another 23.96 per cent, editing 5.02, everything else 13.40 [N7]. Five per cent of a developer's day is spent editing code; the rest is spent working out what's already there.
That's on a system somebody wrote recently. On a thirty-year-old one, comprehension isn't a tax on the work. It is the work.
And the documentation won't save you. The NaPiRE survey on what goes wrong in requirements engineering was completed by 228 companies across 10 countries. The most-reported problem was "incomplete and / or hidden requirements", cited by 109 of them [V4]. That is nearly half, on systems being built now, with the stakeholders still employed. The odds on a system whose authors left a decade ago are worse.
Which is why the incremental road has a precondition most teams skip. Thoughtworks: "Without crossing the boundary and uncovering how legacy systems support (or hinder) business process and activities it is challenging to find and extract thin slices to deliver" [N3b]. You can't carve a system into slices until you know where the joints are, and the joints are business behaviour, not package boundaries.
GAO found the same skip at scale: eight of those ten agencies had no modernization plan or only an incomplete one [N5], while running systems with known vulnerabilities, unsupported hardware, and a shrinking pool of people who could still read the code [N6b].
Three roads, then. Only one has measured support for its precondition.
Refactoring is the option nobody presents to the board, because it has no launch date. It's also the only one of the three whose precondition the evidence supports.
The mechanism has been documented since 2004. Michael Feathers' Working Effectively with Legacy Code is the canonical source for characterization tests: tests that pin down what the system currently does rather than what it should do. The publisher's description: it "teaches developers to write tests that can be used to ensure they are not unintentionally changing the application as they optimize it" [N16]. That's the comprehension bill from the last section, paid once and kept as an artefact.
Affordable at scale? At Meta, over 14 per cent of changes are explicitly devoted to code improvement, with "substantial improvements in quality and speed as well as a reduction in code complexity" [N10]. One change in seven, permanently, as a running cost.
Now the trap, because this is where the refactoring case oversells itself. Boehm and Basili's 2001 synthesis is the paper everyone reaches for: projects spend "about 40 to 50 percent of their effort on avoidable rework" [V1a], "about 80 percent of avoidable rework comes from 20 percent of the defects" [V1b], and — the famous one — "finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase" [V1c]. Left out is the revision in the same paper: "one insight shows the cost-escalation factor for small, noncritical software systems to be more like 5:1 than 100:1" [V1c]. Both numbers are Boehm's, and quoting the 100:1 alone inflates the case for heavyweight rigour on systems that don't warrant it.
Technical debt as a delivery predictor deserves the same caution. An industrial case study across six components found debt alone couldn't explain lead time: variance explained ranged from 5 to 41 per cent, and the effect was positive in two components, negligible in two, negative in two [N9]. The sign flipped. A case built on debt metrics rests on a coefficient that changes direction between modules.
One more signal, held loosely. GitClear's vendor telemetry over 2022–2026 reports block duplication up 81 per cent, from 40.3 to 73.0 per million changed lines; copy/paste up from 9.4 per cent in 2022 to 15.7 per cent in the first half of 2026; and moved code, their proxy for refactoring, down from 13 per cent of changed lines in 2023 to 3.8 per cent year to date in 2026 [V5]. That's a vendor measuring its own customer base, not a controlled study. As direction of travel: more duplication in, less restructuring out. (We've collected the rest of it in AI coding statistics for 2026.)
The strangler fig pattern has better provenance than almost anything else in this debate, and no outcome study at all.
Martin Fowler named it after a 2001 vacation in the Queensland rain forests, watching strangler figs grow around host trees; the pattern was later renamed from "Strangler Application" [N1]. His verdict on the alternative is worth having in front of you when someone proposes a clean cutover: "We've seen this simple-sounding plan go down in flames most of the time. Replacing a serious IT system takes a long time, and the users can't wait for new features" [N1b]. That's practice, not measurement. Thoughtworks names the failure mode more precisely: "Where they had taken a waterfall 'big bang' approach to the programme this meant abandoning the majority of the work" [N3c]. Big-bang programmes don't usually blow up. They get overtaken — needs move, and the half-finished replacement is solving a problem the company no longer has.
But the most useful thing written about the strangler fig isn't the case for it. It's Microsoft's Azure Architecture Center documentation, which spells out four conditions under which the pattern "might not be suitable": requests to the back-end system can't be intercepted; you can't access the legacy system's source code; you're migrating a small system where replacing the whole thing is simple; or you need to fully decommission the original solution quickly [N2].
That's vendor documentation, not research. It's also the sharpest decision tool here, because it's the only place anyone wrote down conditions that rule an option out — and three of the four you can establish in a week.
When the conditions hold, incremental re-architecture produces numbers. Bankdata, the co-operative IT provider for Danish banks, rebuilt a fragile Jenkins and COBOL CI/CD pipeline onto containers and reported an 82 per cent runtime reduction [N11]. One case, one pipeline — not a population result.
The case against rewriting from scratch is not that it has been disproven. It's that it has never been studied.
The canonical argument is Joel Spolsky's essay of 6 April 2000, which calls the decision to "rewrite the code from scratch" "the single worst strategic mistake that any software company can make". The durable part is the reasoning: "Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed" [N12]. Every unexplained conditional in a twenty-year-old function is a bug report someone once filed. A rewrite throws away the bug reports with the code.
That's an argued essay — a legitimate primary for the argument, not a finding. Its Netscape passage is the author's own reading, written while Netscape 6 was still in public beta, and no study establishing a causal link between a rewrite and a company's decline turned up anywhere in this research [N12]. Repeating the Netscape story as evidence means repeating a twenty-six-year-old opinion piece as data.
The other classical warning is Brooks' second-system effect, Chapter 5 of The Mythical Man-Month (originally 1975, anniversary edition 1995) [F5]. The argument — that the second system a designer builds is where they cram in everything the first couldn't afford — maps onto what a rewrite becomes: the old system plus every deferred ambition of the last decade. Brooks also held that product quality is strongly affected by organizational structure; Nagappan, Murphy and Basili open their paper by noting how little empirical evidence had ever been produced for it [N8]. The Vista study is that evidence, arriving thirty-odd years late.
What the literature offers instead is method. A 2026 paper proposing a four-stage model-driven migration for legacy .NET and ASP.NET [N18] tells you how to move a system, not whether moving it worked.
So the honest framing is narrow. A rewrite isn't reckless by default. It's the option with the least evidence in any direction, which makes choosing it a bet on your own judgement rather than anyone else's data. Make that bet consciously, or don't make it.
The finding I'd most like you to carry out of this post: no peer-reviewed or large-scale study comparing rewrite against incremental modernization outcomes appears to exist [F6]. Not one favouring rewrites, not one favouring incrementalism. The rewrite vs refactor debate consuming your steering committee runs, on both sides, without an outcome study.
That absence changes the decision. If there were a directional answer you'd apply it. There isn't. So your legacy system modernization strategy can't be directional. It has to be diagnostic: work out which conditions hold, and let them close roads.
Can you intercept requests to the back end, and modify the legacy source? If either answer is no, incremental replacement is ruled out by the pattern's own documentation [N2]. Not a preference — a mechanical constraint.
Is the system small enough that wholesale replacement is genuinely simple, or must it be decommissioned fast? Both are stated non-applicability conditions for the strangler fig [N2], and both describe the narrow ground where a rewrite is defensible. Boehm's 5:1 revision points the same way [V1c]: light systems don't warrant heavy process.
Does anyone still understand what the system does for the business? If not, no road is open yet, because you can't extract thin slices from behaviour you haven't uncovered [N3b]. Comprehension is 58 per cent of the work regardless [N7]; refusing to fund it doesn't remove it from the budget, it moves it somewhere you can't see.
How many people does a change pass through today? This predicted change interval [V3], and the same variable family predicted defects [N8]. If the answer is "nine, across four teams", no choice of language or architecture fixes delivery speed, because the constraint isn't in the code.
Refactoring in place is the default whenever the system is understood well enough to write characterization tests around what you need to change [N16], and you're willing to fund improvement as a running cost [N10].
One shortcut worth naming. DORA's 2025 work on AI-assisted development found that "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses" [N15]. Point a model at a codebase nobody understands, in an org where nine people touch every change, and you get more of what you already have. Faster. If you plan to lean on it, decide up front how you'll test AI-generated code before it lands in a system nobody can read.
The staffing prescription everyone quotes here comes from Herbsleb and Grinter's 1999 case study, and it's quoted at half length.
The famous clause: "assign work to different sites according to the greatest possible architectural separation in a design that is as modular as possible" [V2]. That sentence has justified splitting more or less anything into services and handing the pieces to separate teams.
The clause that gets dropped: split only "the development of well-understood products (or parts of products), where plans, processes, and interfaces are established and likely to be very stable" [V2].
Read together, the paper says the opposite of how it's used. A legacy system is by definition the case where plans aren't documented, processes have drifted, interfaces are undiscovered and the product is not well understood. Well-understood is precisely the condition the prescription requires, and precisely the one a modernization target fails. So the sequencing is fixed: understand first, split second, never the reverse. That constraint should drive which software development staffing model you pick for the work, not the other way round.
The rest follows from the change-interval data. The number of people involved had a powerful influence on how long a change took [V3], so the staffing move that helps is fewer hands per change, which is the same lever sitting underneath smaller batches and predictable delivery. A second team puts coordination on the critical path of every change, and coordination is the measured cost.
Which makes the first move a diagnosis, not a decision. Answer the four questions above before anyone argues rewrite versus refactor versus replace. That's a code audit, and it's cheap relative to being wrong about the road. Then keep the team small, and keep it the same team. The evidence doesn't say distance itself is what slows a team [V3]. It says the crowd that distance creates does.
If someone quotes you a 70 per cent failure rate in the next steering committee, ask them for the study. The answer will tell you more about the quality of the plan than the number ever could.
Legacy modernization is the work of changing an old, business-critical software system so that it can keep being changed. It has three roads: refactoring the system in place, replacing it incrementally behind a facade, or rewriting it from scratch. The choice between them is argued as a technical question, but the variables anyone actually measured are organizational — how many people a change passes through [V3], and whether anyone still understands what the system does [N7].
There is no credible source for that figure, and it should not be repeated as fact. A peer-reviewed review examined five separate published instances of the 70 per cent change-failure rate and reported "the absence of valid and reliable empirical evidence in support of the espoused 70 per cent failure rate" in each one [F1]. The modernization-specific variants — 70 per cent, 68 per cent, "70–88%" — trace back to uncited vendor content marketing, none of which names a study, a sample or a method [F4].
Refactoring changes the internal structure of the system you already run, with characterization tests pinning down its current behaviour first [N16]. Incremental replacement — the strangler fig pattern — puts a facade in front of the old system and moves functionality out of it slice by slice [N1]. A rewrite builds a new system from scratch and cuts over once. Joel Spolsky's 2000 essay calls that "the single worst strategic mistake that any software company can make", on the grounds that "old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed" [N12].
A rewrite is defensible on the narrow ground described by the strangler fig's own documented non-applicability conditions: the system is small enough that wholesale replacement is genuinely simple, or the original must be fully decommissioned quickly [N2]. Boehm and Basili point the same way. Their famous claim that fixing a problem after delivery is "often 100 times more expensive" than fixing it during requirements and design is revised in the same paper, which puts "the cost-escalation factor for small, noncritical software systems to be more like 5:1 than 100:1" [V1c]. Outside those conditions a rewrite is a bet on your own judgement, because no peer-reviewed or large-scale study comparing rewrite against incremental modernization outcomes appears to exist [F6].
Microsoft's Azure Architecture Center lists four conditions under which the pattern "might not be suitable": requests to the back-end system can't be intercepted; you can't access the legacy system's source code; you're migrating a small system where replacing the whole thing is simple; or you need to fully decommission the original solution quickly [N2]. That is vendor documentation rather than research. It is still the sharpest decision tool in this debate, because it is the only place anyone wrote down conditions that rule an option out.
