Modernization Failure Rate Statistics

Part 2 explained why rewrites fail. This part turns to how often, and it has to be the most disciplined in the series — because a statistics article is only as valuable as it is honest, and “modernization failure rate” is a phrase that attracts loose numbers. Several figures get quoted as if they were a measured failure rate for modernization programs. Most are not. What follows is the small set that is genuinely sourced, what each one does and does not prove, and how to use them without the overreach that gets a business case dismissed by the first person who checks.

The headline figure, read correctly

The number you will see most often is Boston Consulting Group’s: up to 70% of digital transformations fail to deliver on their objectives (BCG, 2023). It is the strongest single data point in this series, and the most misused.

Here is what it is not. It is not a measured failure rate of legacy-modernization programs specifically, and it is not “70% of modernizations fail regardless of how you run them.” It comes from BCG’s work on digital transformations broadly — large, all-at-once change programs of which modernization rewrites are one species. Quoting it as a blanket modernization failure rate overstates what the source actually says.

Here is what it is. It is the base rate for the big, all-at-once shape — programs defined entirely upfront and proven only at a distant finish line. Read that way, it is the most important number in the case for a different shape. The figure does not say modernization fails; it says betting everything on one cutover fails most of the time. That distinction is the whole argument: incremental, slice-by-slice delivery exists precisely to change which side of this number a program lands on, by replacing one large untested bet with a sequence of small, validated ones.

Is there a single authoritative “failure rate”?

Honestly, no — and that honesty matters more than a tidy number would. There is no widely accepted study that isolates legacy-modernization programs, segments them by approach, and reports a clean failure percentage for each. The 70% figure is the closest credible anchor, and it measures transformations broadly rather than modernizations narrowly.

So treat any precise “X% of modernization projects fail” claim with suspicion unless it names three things: its source, its date, and the population it measured. A number without those is decoration, and decoration is exactly what erodes credibility in front of a skeptical committee. The defensible statement is partly qualitative: large, all-at-once programs fail at a high rate, the failures cluster around the structural causes Part 2 laid out, and outcomes improve markedly when risk is distributed rather than concentrated. That is more useful than a false-precise percentage, because it is true and it points at the lever.

The cost of the status quo, sourced

A failure-rate conversation is incomplete without the other side: the cost of not acting, which is what the failure rate is being weighed against. Two sourced figures carry it.

• Roughly 55–57% of enterprise IT budgets go to running existing systems rather than building new capability (Deloitte CIO surveys, 2016–2020). Most of the budget keeps yesterday alive, and for an aging system that share tends to climb. This is the spend the business is already making to stand still.
• Technical debt represents 20–40% of a technology estate’s value, and managing it down can free up to 50% more engineering time (McKinsey & Company, October 6, 2020). That is the capacity locked behind the condition of the systems — recoverable, but only by reducing the burden itself.

A note on a figure you should stop quoting: the often-repeated “Gartner says 70% of IT spend goes to maintenance” claim is not cleanly traceable to a primary Gartner report. Use the Deloitte run-the-business share (~55–57%) instead — it makes the same point and it can be sourced.

These are not failure rates, and presenting them as such would be the exact dishonesty this article warns against. They size the cost of the status quo, which is the other half of any honest risk comparison.

Figures to handle with caution

Part of sourcing numbers honestly is naming the ones that circulate without a traceable source, because a borrowed statistic that turns out to be unattributable does more damage to a business case than no statistic at all — it hands a skeptic a reason to discount everything else you said. A few patterns to watch for in modernization writing:

• The “Gartner 70% maintenance” figure. The claim that “70% of IT spend goes to maintenance” is repeated everywhere and attributed to Gartner, but it does not trace cleanly to a primary Gartner report. Use the Deloitte run-the-business share (~55–57%, 2016–2020) instead — it makes the same point and it can be defended.
• Precise “X% of modernizations fail” claims. As above, treat any clean single percentage for modernization failure specifically as suspect unless it names source, date, and population. The honest anchor is BCG’s transformation figure, read as a base rate.
• Round numbers with no date. A statistic without a year attached cannot be defended when someone asks whether it still holds. If a figure circulates without a date, that absence is itself a reason to handle it carefully.

The point is not pedantry. It is that the discipline which makes a number citable — a named source, a date, a defined population — is the same discipline that makes a business case survive scrutiny. A figure that fails those tests is a liability, not an asset.

How to use these numbers without overreaching

Three disciplines separate a credible case from a dismissible one.

1. Establish scale, don’t claim local fact. Industry figures show the problem is real and well-documented across the industry. They do not show it exists in your system. A case that leans only on borrowed numbers is one a skeptic rightly discounts as “other companies, not us.” The figures anchor; your own operating data convicts. Use both, in that order.
2. Always carry the date and the source. Every figure ages. A number cited without its date is a number you cannot defend when someone asks “is that still true?” Name the source, show the year.
3. Show the range when sources disagree, and don’t invent precision. Where credible sources differ, the range is the truth and collapsing it to one number is a distortion. And where no real source exists for a claim, say so qualitatively rather than manufacture a statistic — the absence of a clean number is itself a finding worth stating plainly.

The figure that actually convicts is never one of these. It is your own: the share of engineering time your teams spend keeping the system running versus building, your change-failure rate, your incident hours, the features you couldn’t ship because the system couldn’t take them. Track those for a few sprints and you have a number a committee cannot wave away as someone else’s problem. The legacy cost calculator helps turn that operating reality into a figure; the maintained statistics hub keeps the sourced industry figures current.

The honest bottom line

The data supports a narrow, defensible claim, and only that claim. Large, all-at-once modernization programs fail at a high rate — BCG’s up-to-70% is the best anchor for it — and they fail for the structural reasons Part 2 named, not because the goal is impossible. Distributing risk slice by slice does not guarantee success and is not free, but it removes the structural causes that account for most of those failures. Anyone who tells you incremental modernization has a precise, study-backed success rate is doing the thing this article exists to warn against.

Where this leads

The numbers so far measure the downside — what the big-bang shape risks. The rest of the series turns to the upside and the mechanics: how the incremental shape actually controls risk in practice. It starts with the benefit a rewrite can never offer, the one a frozen-roadmap big-bang puts most at risk. Part 4, Business Continuity During Modernization, shows how replacing a system slice by slice keeps the business running and the roadmap alive throughout — and names the real operational cost of doing it that way.