Technical Debt Statistics

A statistic is only as good as its attribution. An unsourced number in a business case is a liability. The first person who asks “where’s that from?” can dismiss the whole argument when the answer is a shrug. So this final part does one thing well: it collects the technical-debt statistics worth citing, each named, dated, and attributed exactly as its source stated it, with one line of interpretation. It is the reference Part 11’s business case draws on, and the bookend to a series that opened by insisting one sourced figure beats three superlatives.

A discipline note before the numbers. Every figure below is reproduced as its source published it. We do not round, restate, or invent. Where we lack a credible, dated source for a number this article’s title might invite, we leave it out rather than fill the gap with something unsourced. These are the figures we can stand behind, and the maintained, quarterly-refreshed version lives on the statistics hub.

The figures at a glance

Every statistic in this article, with its exact source and date, and the argument it actually supports. Nothing in this table is rounded or restated. If you are assembling a business case, this is the row you cite from, and the sections below give each figure its full interpretation.

Statistic (as the source stated it)	Source (date)	What it establishes	Use it to argue
Developers lose roughly 42% of their time to technical debt and bad code	Stripe, “The Developer Coefficient” (2018)	Nearly half of paid engineering capacity fights the codebase	Recover capacity you already pay for
Technical debt is 20 to 40% of a technology estate’s value, and managing it frees up to 50% more engineering time	McKinsey & Company (Oct 6, 2020)	Debt is a balance-sheet-scale drag, not a backlog item	Paydown is a capacity investment, not a cost
Roughly 55 to 57% of enterprise IT spend goes to running existing systems	Deloitte, Global CIO surveys (2016 to 2020)	Most of the budget keeps yesterday running	Modernization redirects spend to the roadmap
Up to 70% of digital transformations fail to deliver on their objectives	Boston Consulting Group (Sep 13, 2023)	Big-bang change fails at a high base rate	Pay debt down incrementally, not all at once
Average COBOL developer is roughly 58, and about 10% of the COBOL workforce retires each year	IBM, reported via Fujitsu (2020)	The people holding the rules are leaving on a schedule	Capture knowledge now, delay has a clock
An estimated 220 billion to 800 billion+ lines of COBOL in production worldwide	Reuters via IEEE Spectrum (≈220B, 2017), Micro Focus (800B+, by 2022)	The most debt-laden systems are load-bearing infrastructure	The problem is large and real, not a relic
Mainframe modernization market $8.39B (2025) to $13.34B (2030), 9.7% CAGR	MarketsandMarkets (Aug 21, 2025)	The response is now budgeted at scale	Modernization has moved from optional to funded

The time cost of technical debt

Developers lose roughly 42% of their time to technical debt and bad code. Source: Stripe, “The Developer Coefficient,” 2018

This is the most-cited figure for the time cost of debt, and the most useful for a business case, because it translates directly into capacity. Read it as an interest rate on the entire engineering organization: close to half of paid engineering time, across the firms Stripe surveyed, went to working around the codebase rather than extending it. It is the empirical anchor for the “recover capacity you already pay for” reframe in Part 11. The spend on debt is not hypothetical, it is already happening, measured here at nearly half of capacity.

Technical debt as a share of the estate

Technical debt amounts to 20 to 40% of an entire technology estate’s value. Actively managing it can free up to 50% more engineering time. Source: McKinsey & Company, October 6, 2020

McKinsey approaches debt from the asset side and arrives at the same order of magnitude as Stripe from a different direction. The 20 to 40% figure reframes debt from a code-quality nuisance into a material drag on a large fraction of the organization’s technical capability, a balance-sheet-scale problem, not a backlog item. The companion figure, up to 50% more engineering time from managing it down, is the recoverable upside: the capacity sitting locked behind the debt, the mirror image of the cost. It is the statistic that turns debt repayment from a defensive cost into a capacity investment.

The cost of maintaining what already exists

Roughly 55 to 57% of enterprise IT spend goes to running existing systems. Source: Deloitte (Global CIO surveys, 2016 to 2020)

The endpoint of debt left to compound. When debt is never managed, an ever-larger share of the budget goes to keeping the existing system alive rather than building new capability. Deloitte’s CIO surveys put that at roughly 55 to 57% of enterprise IT spend. It is the macro view of what Part 4’s interest looks like at the scale of a whole IT budget: most of the money keeping yesterday running. Modernization is, in large part, the work of pointing that spend back at the roadmap.

One caution when you cite it. A rounder-sounding “70%” version of this statistic circulates widely, usually attributed to Gartner, but it is not traceable to a primary Gartner report. Use the Deloitte figure with its range and date. The precise, sourced number survives scrutiny in a way the tidy, unsourced one does not.

The base rate for big-bang change

Up to 70% of digital transformations fail to deliver on their objectives. Source: Boston Consulting Group (BCG), September 13, 2023

Not a debt statistic directly, but the one that governs how you pay debt down once it has grown into a transformation. The base rate for large, all-at-once change programs is failure, which is the empirical case for the incremental, reversible repayment that Parts 9 and 11 argued for. Slice-by-slice delivery exists to change which side of this number a debt-paydown program lands on.

The human side: aging skills

The average COBOL developer is roughly 58, and about 10% of the COBOL workforce retires each year. Source: IBM, reported via Fujitsu, 2020

The statistic behind knowledge debt. The people who hold the undocumented rules of the oldest, most debt-laden systems are leaving on a schedule, and each departure converts living knowledge into archaeological debt. It is the figure that gives the cost of delay its clock: capturing that understanding before it walks out the door is a race against the calendar, not a task that can wait for a quieter quarter.

The scale of the systems involved

An estimated 220 billion to 800 billion+ lines of COBOL are in production worldwide. Source: Reuters, via IEEE Spectrum (≈220B, 2017). Upper bound, Micro Focus (800B+, by 2022)

The mainframe modernization market is projected to grow from $8.39B in 2025 to $13.34B by 2030, a 9.7% CAGR. Source: MarketsandMarkets, August 21, 2025

These two frame the scope of the problem the technical-debt discipline ultimately serves. The COBOL figure, a wide range because credible sources disagree, which is exactly why we show the range rather than pick a side, establishes that the most debt-laden systems are not relics but load-bearing infrastructure. The market figure shows the response is now budgeted at scale: modernization has moved from optional to funded across the enterprise.

How the figures reinforce each other

No single number here proves the case. What makes them persuasive is that they were measured independently, from different angles, and still point the same direction. Reading them together is what turns a list into an argument.

• Two independent measurements converge. Stripe measured the time side and found roughly 42% of engineering capacity lost. McKinsey measured the asset side and found debt at 20 to 40% of estate value. Different methods, different years, same order of magnitude. When two unrelated studies triangulate a number, it is much harder to dismiss than either one alone.
• The cost has an endpoint. Deloitte’s 55 to 57% shows where unmanaged debt lands at the scale of a whole budget: the majority of spend keeping the existing system alive. That is the compounded version of the capacity Stripe and McKinsey found leaking today.
• The method is not optional. BCG’s up-to-70% failure rate for large transformations is the reason you cannot simply spend your way out in one program. It is the empirical case for paying debt down in slices rather than betting the year.
• The clock is external. The COBOL demographics figures mean the most debt-laden systems have a deadline you do not control. Knowledge leaves on a retirement schedule whether or not the paydown is funded.

Used this way, the figures make the general case that the problem is real, large, expensive, and time-bound. They do not make the case for your system. That is the next distinction, and the most important one.

How to cite these well

The figures only do their job if they are presented as honestly as they are sourced. Three rules, carried from the business case:

• Always pair the number with its source and date. “42% (Stripe, 2018)” is citable. “studies show almost half” is not, and invites the dismissal the number was meant to prevent.
• Use them for scale, not as your measurement. These describe patterns across many organizations. They establish that the problem is real and large. They do not measure your system, and presenting them as if they did is the overreach that loses a skeptical room.
• Show ranges where sources disagree. The COBOL figure spans 220B to 800B+ because credible sources differ. Reporting the range is more credible than picking the number that flatters your case.

The line these figures can’t cross

Statistics persuade, and that is exactly why they have to be handled with care. The temptation in any business case is to stack favorable numbers into something that sounds overwhelming. But a figure quoted without its source, stripped of its date, or stretched past what it actually measured is worse than no figure at all, because it hands a skeptic the thread that unravels the whole argument. Aggregate industry data, however good, is never a substitute for measuring your own system. It makes the general case while your own delivery metrics make the specific one. Cite these to establish that the problem is real and well-documented. Then measure your own debt to say what it costs you. The two together are persuasive. Either one stretched to do the other’s job is not.

Where this series leads

That completes the arc this series set out to walk: measure it, price it, pay it down. We began by defining technical debt as the compounding cost of rework, broke it into its types and causes, made its cost concrete, built the methods to measure and calculate it, assembled a framework to manage it, detailed how to reduce it in a running system, traced its impact on velocity, and turned all of it into a business case, anchored, finally, by the sourced figures above.

If you want to read it in order, the Technical Debt series hub starts at Part 1. And if your debt has compounded into a system that is genuinely hard to change, past refactoring, knowledge thinning, the cost of delay mounting, the next step is not another spreadsheet but a conversation. ModernLift pays down debt that has grown into a modernization problem: incrementally, with validated behavior parity, and with the business running the entire time. Book a 30-minute discovery call, no deck, and we will scope what paying it down would actually take.