Technology Debt vs Technical Debt: The Whole Iceberg

If you searched for “technology debt” and landed on a page about “technical debt,” you were not confused — the industry is. Almost every reference treats the two as synonyms and moves on. They are not the same thing, and the difference is the whole reason this page exists. Technical debt is code-scoped. Technology debt is the broader surface that the code sits inside. Most organizations meter the first and never see the second, which is why the second is usually the one that hurts.

This article draws the distinction, maps the full surface, and puts real numbers and named incidents against it. If you want the deep treatment of the code-scoped part, we cover that in a full series starting with what technical debt is — this page will not re-explain it. This page is about the rest of the iceberg.

Technology debt vs technical debt: the distinction

Here is the crisp version. Technical debt is the implied future cost of rework created by expedient choices in the codebase — shortcuts, aging dependencies, structure that resists change. Technology debt is that same idea applied to the entire technology estate: not just the code, but the infrastructure it runs on, the cloud resources around it, the licenses that entitle it, the vendors it is locked to, the platforms underneath it, the data it carries, and the processes that keep it alive.

Technical debt is one slice of technology debt. A team can have a clean, well-tested, beautifully refactored codebase and still be deep in technology debt because that pristine code runs on a database version that lost support last year, depends on a cloud account no one has audited since 2021, and can only be deployed by one engineer who is retiring in spring. None of that is technical debt in the strict sense — the code is fine. All of it is technology debt, and all of it will eventually cost you.

The reason the distinction matters in practice is measurement. The tools and metrics the industry has built — static analysis, the technical-debt ratio, code-quality scores — all point inside the codebase. They are good at the slice and blind to the rest. So the debt that gets tracked is the debt that gets tooled, and the far larger surface stays off the ledger until it arrives as an outage, an audit finding, or a renewal invoice nobody budgeted for.

The iceberg: what lives below the code

Picture technical debt as the tip above the waterline — visible, discussed, the thing everyone means when they say “we have a lot of tech debt.” Below it sits the mass that determines whether the whole system stays afloat.

The full technology-debt surface breaks into eight categories. The first is the familiar code slice; the other seven are what “technical” quietly leaves out.

Category	What it is	How it shows up
Code debt	Shortcuts and aging structure inside the codebase	Duplicated logic, missing tests, tangled modules — the six types of technical debt
Infrastructure debt	Aging servers, networks, and on-prem hardware past their useful life	Machines nobody will patch, a data center on a lease no one wants to renew, capacity you cannot scale
Cloud debt	Accreted, unoptimized, or unowned cloud resources	Orphaned instances, over-provisioned services, “do not delete — not sure what it does” tags, a bill rising faster than usage
Licensing debt	Software entitlements that no longer match reality	Seats you pay for and don’t use, license terms you’ve drifted out of compliance with, renewals that quietly assume lock-in
Vendor lock-in	Dependence on a proprietary platform you cannot leave cheaply	A database or middleware whose exit cost is a rewrite — the subject of our vendor lock-in work
Platform / EOL debt	Operating systems, databases, and runtimes past end of support	An unsupported Windows Server or SQL Server, a deprecated API a partner is about to switch off
Data debt	Schemas, pipelines, and stores that resist change	Undocumented schemas, ETL sprawl, data models load-bearing for reports nobody can reproduce
Process / org debt	The human and procedural machinery around the system	A deploy only one person can run, no runbook, knowledge that lives in one head and leaves when they do

Each row is a real cost with its own interest rate, and only the first shows up in a code scanner. This is the practical payoff of the distinction: the moment you accept that technology debt is broader than technical debt, you start looking in the seven places your existing tooling never pointed.

What the broader surface costs

The most useful number here is deliberately an estate-level one, because the estate is the right unit for technology debt.

McKinsey estimated, in an October 2020 analysis, that technical debt amounts to 20–40% of an entire technology estate’s value — and that actively managing it down can free up to 50% more engineering time. Read against the iceberg, that figure lands differently than it does in a conversation about code alone. An estate is not just a codebase; it is the infrastructure, the licenses, the cloud footprint, and the platforms too. A fifth to two-fifths of all of that is drag. That is the size of the surface most teams are not measuring.

From the engineering-capacity side, Stripe’s 2018 report “The Developer Coefficient” found developers lose roughly 42% of their time to technical debt and bad code. That one is code-scoped by construction — it measures developer time — which is exactly why it is only half the story. It captures the tip. It says nothing about the cloud bill, the license true-up, or the EOL migration that lands as a capital project. We treat the code-scoped cost in full in the true cost of technical debt; the point here is that the code number, large as it is, sits on top of an infrastructure-and-vendor cost the code metrics never see.

Two honest cautions on these figures. They are aggregate patterns across many organizations, excellent for establishing scale and useless as a measurement of your specific estate — your number could be higher or lower. And not every renewal or migration is “debt”; some spend is simply the cost of running a real business at real scale. The discipline is to use the benchmarks to argue that the surface is large, then measure your own.

When technology debt bites: named examples

Technology debt is easiest to see in the moments it stops being theoretical. Three public cases, described only as far as the public record supports, show the debt living outside the code as often as inside it.

Knight Capital, 2012. A deployment left dormant, years-old code on one of eight servers and reused a feature flag that had once triggered it. When trading opened, that one server began firing runaway orders. In roughly 45 minutes the firm took on about $440 million in losses and never recovered as an independent company. The proximate cause was dead code, but the debt that killed it was process — a deployment procedure with no safeguard against a partial rollout. That is technology debt, not a bug in a function.

Southwest Airlines, December 2022. A winter storm cascaded into an operational collapse when the airline’s aging crew-scheduling system could not re-solve the schedule at the scale the disruption demanded, forcing days of manual rework. Southwest cancelled roughly 16,700 flights and took a hit it disclosed in the hundreds of millions of dollars; regulators later imposed a $140 million penalty. The codebase was not the story. Aging operational software plus the infrastructure and process around it — that is the broader surface, and it grounded a national carrier.

Healthcare.gov, 2013. The launch buckled under integration failures across many contractors and rushed architecture — debt in how the system was assembled and coordinated, not in any single component. It became the canonical example of what accreted structural and organizational shortcuts cost at go-live.

The everyday version is quieter and far more common: the bank running core ledgers on COBOL mainframes maintained by a shrinking, aging workforce; the manufacturer whose line depends on an application that only runs on an operating system that lost support two versions ago. No incident, no headline — just a widening gap between what the estate is and what the business now needs from it.

Is AI creating technical debt?

Yes — and it is worth answering directly, because it is the question everyone is now asking and almost no reference page addresses. AI coding assistants like GitHub Copilot, Cursor, and Claude Code are genuinely useful and genuinely change the debt equation, in three specific ways.

Un-owned code. The core risk is not that AI writes bad code — often it writes fine code. It is that AI writes a lot of code that no human on the team fully understands. Code you did not reason your way into is knowledge debt from the first commit: it works until it doesn’t, and when it doesn’t, there is no author to ask. Volume of output and ownership of output are different things, and assistants inflate the first without the second.

Hallucinated dependencies. Models sometimes suggest importing packages that do not exist. Left unchecked, that is a broken build at best — and a genuine supply-chain risk at worst, because attackers have begun registering the plausible-sounding package names models tend to invent, so that a hallucinated import can resolve to hostile code. This is a novel debt pattern with no pre-AI analogue.

Prompt-brittle systems. As teams build features around LLMs — not just with them — behavior comes to depend on prompts, model versions, and outputs that are not deterministic. A system whose correctness rests on a particular model behaving a particular way is carrying a new kind of dependency debt: the vendor can change the model under you, and your prompts silently stop working.

None of this is unprecedented in kind. Google’s 2015 paper “Hidden Technical Debt in Machine Learning Systems” (Sculley et al.) named most of these patterns — glue code, pipeline jungles, and systems where changing anything changes everything — a decade before LLM-assisted coding made them a daily concern for ordinary teams. Independent analysis of large code corpora has since reported that as assistants spread, the share of duplicated and churned code has risen rather than fallen. The tools raise the floor on speed and the ceiling on how fast debt can accumulate at the same time. Used with review and ownership, they are a gain; used as a firehose, they are a debt engine. We go deeper in AI legacy-code modernization.

Why measuring only code debt is the trap

The failure mode is now easy to name. Teams adopt the tooling that exists — static analysis, code-quality gates, a debt ratio — and those tools measure the one category they can see. The dashboard turns green. Meanwhile the platform slides past end of support, the cloud footprint accretes, the vendor’s renewal terms harden, and the one person who can deploy the system updates their LinkedIn. Every one of those is technology debt, and none of it moved the code metric.

Green code metrics on a red estate is the most common way this bites well-run engineering organizations. They are not negligent; they are measuring exactly what their tools were built to measure. The fix is not a better scanner. It is widening the lens from technical debt to technology debt, and then looking deliberately at the seven categories a scanner cannot reach — starting with the end-of-life exposure that carries the sharpest tail risk.

Paying it down: the broader surface is a modernization program

Here is where the distinction stops being semantic and becomes a plan. The reason technology debt is worth separating from technical debt is that the broader surface — end-of-life platforms, vendor lock-in, aging infrastructure, the undocumented process that keeps it all running — is precisely what an incremental modernization program pays down. A refactoring sprint fixes code debt. It does nothing for a database you cannot leave or a server you cannot patch. Those need a different instrument.

That instrument is not a big-bang rewrite. Trying to clear technology debt in a single cutover mostly converts old, understood risk into new, unproven risk. The durable approach is the same one that works for code: incremental, reversible, and validated. A strangler facade lets the legacy estate and the modern path run side by side; one slice of behavior moves at a time; and before any slice carries live work, it is proven to behave identically to the original — same results, same state, reconciled record by record. The platform, the license, the vendor dependency each retire only once nothing depends on them anymore. The figures behind all of this — the estate-level cost, the EOL timelines, the workforce demographics — are collected, sourced, and dated in our modernization statistics.

If the part of your technology debt that keeps you up at night is the part your code metrics never showed you — the EOL platform, the vendor you cannot leave, the system only one person understands — that is exactly the surface worth scoping. A discovery call turns it into a mapped estate and an incremental plan, on evidence rather than a pitch.

Where the line actually sits

Not all of the technology estate that resists change is debt, and calling everything “technology debt” is its own failure mode. A system that is large because it genuinely does a great deal is not in debt for being big. A license you pay for and fully use is a cost, not a debt. A supported platform you have deliberately standardized on is a choice, not lock-in. Technology debt is specifically the avoidable future cost created by expedient or deferred decisions across the estate — the EOL you keep postponing, the cloud sprawl you never pruned, the vendor exit you never priced. Keeping that line sharp is what lets you argue the case with numbers instead of adjectives, and spend repayment effort where the interest rate is actually highest — which, more often than the code metrics suggest, is below the waterline.