LinkedIn "wisdom"

by "Stavros"

Why deprecation is a harder strategic capability to build than adoption, and why most organizations have no one whose actual job it is to decommission things

BY STAVROS · SEPTEMBER 22, 2026
Why deprecation is a harder strategic capability to build than adoption, and why most organizations have no one whose actual job it is to decommission things infographic

The proof is indisputable.

THE INSIGHT

I went looking for a specific number last month and could not find it.

I wanted to know what share of enterprise cloud spend goes to workloads that duplicate something else already running in the same company. Nobody publishes that. Not Gartner, not the hyperscalers. What exists are proxies, mostly self-reported. Flexera's annual survey has respondents estimating 27% of cloud spend is wasted, a number that has sat between 27 and 32% every year since 2019. Zylo counts an average of 305 SaaS applications per organization, with a bit over half the licences actually used. McKinsey asked fifty CIOs and put technical debt at 20 to 40% of the technology estate. The GAO reports around 80% of federal IT money goes to keeping existing systems breathing rather than building anything new.

None of those are measurements, and several come from vendors who sell the remedy. But when four separate guesses land in the same neighborhood, the neighborhood is probably real.

The cause has almost nothing to do with technology.

Every system I have helped launch arrived with an executive sponsor, a funded budget line, a date on a roadmap, and a demo that made someone's promotion case. Every system I have helped switch off arrived with none of that. Adoption is somebody's job. Deprecation is nobody's job. So the old thing keeps running next to the new thing, and the parallel period that was supposed to last a quarter quietly becomes the architecture.

That is the documented failure mode of the strangler fig pattern. Teams do not fail to build the new system, they never finish killing the old one, so the temporary synchronization layer becomes load bearing and nobody dares touch it. You maintain two half systems, which costs more than either whole one would.

Arkes and Blumer showed the psychology in 1985. Told about money already sunk into a doomed project, 85% of people wanted to keep going. Offered the same project fresh, only 10% would fund it. We run that experiment on our own estates every quarter.

The encouraging part is that this is fixable when someone owns it. ANZ decommissioned 264 applications in one financial year and took its capitalised software balance from A$2.9 billion to A$1.4 billion. Google devotes a chapter of its engineering book to deprecation as a named discipline. Neither happened by hoping teams would find time.

To be fair to the other side, parallel running is genuinely correct for verification and regulatory safety, and rushing a cutover can be worse than dawdling. TSB's 2018 migration cost the bank £330 million and a £48 million fine. Speed is not the goal. Ownership is.

So the question for your own organization: is there a single funded roadmap for what gets turned off next year, with a name attached and a budget number? Or is decommissioning still the thing everyone agrees is important and no one is paid to do?

THE EVIDENCE

Why Deprecation Is Harder to Build Than Adoption: A Research Brief

TL;DR

  • Deprecation is structurally starved of everything adoption gets — sponsor, budget, launch date, celebration, career upside — so "turning things off" becomes nobody's actual job, and the evidence bears out the consequences: ~27% of cloud spend is wasted year after year (Flexera), 70–80% of IT budgets go to running existing systems, and enterprises carry hundreds of redundant apps.
  • The specific statistic requested — "% of cloud spend on functionally duplicate workloads" — does not exist as a measured figure. The closest defensible proxies are Flexera's self-reported 27–32% "wasted cloud spend," Zylo's SaaS redundancy data (305 apps/enterprise, ~30–40% overlapping), and McKinsey's tech-debt estimate (20–40% of the technology estate). All are survey/self-report or vendor-derived, not hard measurements of duplication.
  • A named, funded deprecation function is rare but demonstrably works — ANZ Bank decommissioned 264 applications in one year and cut its capitalised software balance from A$2.9bn to A$1.4bn; Google treats deprecation as a first-class engineering discipline; AWS commits to 12-month deprecation notice. The failure mode at the other extreme (botched cutover) is expensive too: TSB's migration cost £330m and an £48.65m fine.

Key Findings

  1. The asymmetry is real and rooted in incentives. Launches have sponsors, budgets, and celebrations; sunsets have none. Decommissioning is invisible in promotion packets, and nobody wants to be the person who "broke something" by switching it off. This is reinforced by well-documented cognitive biases: sunk cost fallacy (Arkes & Blumer 1985), loss aversion, status quo bias, and the endowment effect.
  2. "Temporary" parallel running routinely becomes permanent. The strangler-fig pattern's most-cited failure mode is never finishing the strangling — leaving two systems running indefinitely at double cost. Legacy systems run for decades (the IRS Individual Master File is ~60 years old).
  3. The duplicate estate is large but imprecisely measured. Best proxies: 27% wasted cloud spend (Flexera, stable 2019–2025); 305 SaaS apps/enterprise with ~46% of licences unused (Zylo 2026); 20–40% of the tech estate is tech debt (McKinsey).
  4. Making cost visible helps but doesn't guarantee decommissioning. Showback creates awareness; chargeback creates accountability. Both are behavioral control systems, not billing exercises.
  5. Nuance matters: parallel running is legitimate for risk management and verification; aggressive deprecation causes real harm (Google's "Killed by Google" reputation, TSB's botched cutover); and vendor "waste" numbers are largely self-reported and sold by companies with cost-optimization tools.

Details

1. The structural asymmetry between launching and sunsetting

Launching a new system comes with an executive sponsor, a funded budget line, a project team, a launch date, and a celebration (internal comms, demos, promotion cases, resume material). Sunsetting the old system has none of those. The work is invisible in performance reviews, "reduce the footprint" is harder to fund than "ship the new thing," and there's an accountability gap: nobody wants to sign off on turning something off and risk being blamed for breakage.

The behavioral-economics literature explains the stickiness. The sunk cost fallacy was experimentally established by Hal Arkes and Catherine Blumer in their 1985 paper "The Psychology of Sunk Cost" (Organizational Behavior and Human Decision Processes, vol. 35, pp. 124–140); their "radar-blank airplane" scenario found 85% chose to continue a doomed project when prior investment was mentioned, versus only 10% who would invest fresh. This bias is amplified by loss aversion (Kahneman & Tversky: losses feel roughly twice as painful as equivalent gains), status quo bias, and the endowment effect for owned systems. The Concorde is the canonical example of a project continued for decades even after officials privately called it "a commercial disaster that should never have been started." [1]

Google's engineering organization treats this as a named discipline. Chapter 15 of Software Engineering at Google (Titus Winters, Tom Manshreck, Hyrum Wright, O'Reilly, March 2020) is devoted entirely to Deprecation and opens: "All systems age… It's often better to invest effort in turning off obsolete systems, rather than letting them lumber along indefinitely alongside the systems that replace them. But the number of obsolete systems still running suggests that, in practice, doing so is not trivial." The book also notes that "Much of the initial work of deprecation is determining who is using the old system — and in which unanticipated ways" — a nod to Hyrum's Law ("With a sufficient number of users of an API… all observable behaviors of your system will be depended on by somebody"), which is exactly what makes turning things off risky. [2]

2. The parallel-running problem

Running old and new in parallel doubles operational cost: licences, infrastructure, on-call rotations, security patching, compliance/audit scope, integration surface, cognitive load, and a tax on every future change (every feature built twice or bridged).

The strangler fig pattern (coined by Martin Fowler in 2004) is the standard incremental-migration approach — route traffic to the new system piece by piece until the legacy code can be deleted. But its single most-cited failure mode is losing the discipline to finish. As practitioner accounts put it: "If only 50% of the features are migrated and the effort stops, you now have two half-systems to maintain indefinitely, which is worse than either just the legacy or just a new system." Common permanent residue includes "permanent dual-writes: the 'temporary' data synchronization layer becomes load-bearing infrastructure nobody dares remove" and "no cleanup: compatibility layers and adapters survive long past their usefulness." [3][4]

This connects to the second-system effect (Fred Brooks, The Mythical Man-Month) and the big-rewrite literature warning against throwing away working systems. Modernization programs have high failure rates: the landmark McKinsey/Oxford study (Bloch, Blumberg & Laartz, 2012) of 5,400 large IT projects over $15M found they run 45% over budget and 7% over time while delivering 56% less value than predicted, with 17% going so badly they threaten the company's existence. (More recent blog-cited figures of "68–79% modernization failure" circulate but could not be traced to a primary report within the research window — treat cautiously.)

Concrete durations of "temporary": The IRS Individual Master File (IMF), built in the 1960s in COBOL and Assembly, is roughly 60 years old, stores data on ~100+ million taxpayers, and is frequently called the oldest system in continuous federal use. Its replacement attempts — CADE (cancelled 2009) and CADE-2 — have repeatedly failed; the IRS was still running the modernized engine "in parallel with the old system" as of 2024. GAO (GAO-23-106821, 2023) found 10 critical federal legacy systems ranging from 8 to 51 years old, collectively costing $337 million/year to operate. Commonwealth Bank of Australia replaced its core banking platform starting in 2012 (with Accenture and SAP SE); the effort took five years and cost more than A$1 billion ($749.9 million), per Reuters/Computerworld coverage. Underscoring why banks hesitate to switch: COBOL is estimated by a widely re-cited Reuters report (April 2017) to underpin ~220 billion lines of code and ~$3 trillion in daily commerce, including 95% of ATM swipes and 80% of in-person transactions — an order-of-magnitude estimate, not an audited counter. The maintaining engineers are aging out: industry/workforce reporting estimates the average COBOL developer is ~55 and that ~10% retire each year (a directional industry estimate, not a measured figure). [5]

3. The key data request: % of cloud spend on functionally duplicate workloads

This exact statistic does not exist as a measured, published figure. No named analyst (Gartner, Forrester, IDC) or vendor publishes "X% of cloud spend goes to workloads that duplicate the functionality of other running workloads." The closest defensible proxies, with their limitations:

  • Flexera 2025 State of the Cloud Report (14th annual, 750+ respondents, released 19 March 2025): respondents self-estimate 27% of cloud spend is wasted — a figure stable at 27–32% every year since 2019. The 2026 report shows it ticked up to 29%. This is a self-reported survey estimate, not a measurement, and Flexera sells cost-optimization tools. At Gartner's projected ~$675–723bn 2025 cloud market, 27% implies ~$180bn+ globally — but "waste" here means idle/overprovisioned resources, not functional duplication specifically.
  • FinOps Foundation State of FinOps 2025 (organizations responsible for $69bn+ cloud spend): "workload optimization and waste reduction" is the #1 priority for 50% of practitioners, two years running. In 2026, a practitioner quote notes diminishing returns: "We have hit the 'big rocks' of waste and now face a high volume of smaller opportunities."
  • "Zombie" infrastructure: Uptime Institute and related research found ~30% of servers globally were "comatose"/unused (~10 million zombie servers, ~$30bn in idle capital). Industry estimates put 30–40% of enterprise VMs as idle "zombies." These are measured by utilization thresholds (e.g., <5% CPU over 30 days) but vary by methodology. [6]
  • SaaS duplication (the closest thing to true functional overlap): Zylo's 2026 SaaS Management Index reports the average organization runs 305 SaaS apps (696 for large enterprises), spends $55.7M/year, and only 54% of licences are used (~46% unused, ~$19.8M/year waste). Internal audits typically find 30–40% of apps overlap with at least one other tool. IT directly manages only ~13% of an organization's SaaS. Vendr/Productiv/Zylo triangulate wasted SaaS spend on duplicates + unused licences at 15–30% of the SaaS budget. Productiv found ~48% of enterprise apps are "unmanaged." All SaaS-management vendors sell consolidation tooling — treat as directional. [7]
  • Application portfolio rationalization: Gartner's TIME framework (Tolerate/Invest/Migrate/Eliminate) is the standard lens. Gartner estimates best-practice rationalization can cut application TCO by ~30%, and that firms failing to coordinate SaaS lifecycles will overspend by ≥25% through 2027. Consultancy case studies commonly report ~30% of an application portfolio identified for immediate retirement. [8]
  • Legacy/run-the-business spend: The widely-cited benchmark is that ~70–80% of IT budgets go to operations/maintenance ("run") vs. new development ("change"). GAO reports the US federal government spends ~80% of its $100bn+ annual IT budget maintaining existing systems. McKinsey (2020 survey of 50 CIOs at $1bn+ firms): tech debt equals 20–40% of the total technology estate's value before depreciation, and 10–20% of new-product budgets get diverted to servicing it. [9]
4. A named, funded deprecation function is rare but works
  • ANZ Bank (named, primary disclosure): In FY18 (year ended 30 Sept 2018), ANZ decommissioned 264 applications as part of its simplification push — a 35% increase on the prior year — and cut its capitalised software balance from A$2.9bn (2015) to A$1.4bn, the lowest of Australia's big four banks. CEO Shayne Elliott: "We no longer mortgage our future with rising and unsustainable software capitalisation… we've moved from having the highest software balance of our peers to the lowest." (Corroborating but anonymized vendor case studies report similar scale — e.g., one large global bank retiring 533 applications for ~$12M/year in licensing savings — but the bank is unnamed, so treat as directional.)
  • Google: Treats deprecation as first-class engineering (Chapter 15 above), with published deprecation policies and techniques like renaming implementation-only symbols "to see which users are depending on them unaware." [10]
  • AWS: Commits contractually to at least 12 months' prior notice before discontinuing material functionality or making backwards-incompatible API changes. Its formal lifecycle defines Maintenance → Sunset (typically 12-month timeline) → Full Shutdown. For Lambda runtimes, AWS extended its deprecation notification from 60 to 180 days and recommends guardrails (CloudFormation Guard, AWS Config) so "developers can only create functions using supported runtimes" — a governance gate. Notably, AWS does not block invocations of functions on deprecated runtimes, illustrating how even a disciplined vendor keeps old things alive rather than force-breaking them.

Practices that make deprecation tractable: dated end-of-life commitments; "no new system without a retirement plan" gating; migration budgets that fund decommissioning as a deliverable, not a hoped-for follow-up; sunset clauses at procurement; tracking "systems retired" as an explicit metric/OKR; traffic-based usage evidence to prove a system is unused; tombstoning; and internal chargeback/showback so owners feel the cost. On visibility: showback "produces awareness" but "IT visibility alone does not reliably change behavior"; chargeback "introduces consequences, and with them, accountability." Most programs start with showback and graduate to chargeback once cost-allocation accuracy passes ~90%. [11]

5. Counter-arguments and nuance
  • When parallel running is correct: risk management, regulatory rollback requirements, phased-migration safety, and verification periods. Good practice runs old and new in parallel comparing outputs (e.g., a regional bank ran a 90-day parallel operation with staged decommissioning and rollback before retiring a 40-year COBOL core; the IRS runs its new engine in parallel to confirm identical outputs). [12]
  • When aggressive deprecation harms: Google's "Killed by Google" reputation — 200+ products retired — is a cautionary tale that erodes enterprise trust; when Google Reader shut in 2013 it had a loyal but declining base (~1 million monthly active users per TechCrunch/comScore, with its single most-popular feed at ~24.3M subscribers), and the backlash still fuels a running joke that damages Google's credibility on enterprise longevity. And a botched cutover is worse than dawdling: TSB Bank's April 2018 migration onto Sabadell's Proteo4UK platform (moving ~1.3 billion customer records off Lloyds-hosted systems) affected all branches and a significant proportion of its 5.2 million customers, cost the bank £330m (per BBC, citing TSB's Feb 2019 statement, which also noted ~80,000 customers switched away), drew a £48.65m FCA/PRA fine (£29.75m FCA + £18.9m PRA, announced 20 Dec 2022, reduced 30% from £69.5m for settlement), generated ~225,000 complaints, and wasn't back to business-as-usual until December 2018. TSB paid £32.7m in customer redress. (Media reports put the number "locked out" at ~1.9 million; the FCA release itself says only "a significant proportion of 5.2 million.")
  • Are the waste numbers overstated? Largely self-reported. Flexera's 27% is respondents' own estimate. SaaS-overlap figures come from vendors selling consolidation tools. More rigorous benchmarks explicitly exclude compliance-mandated redundancy and DR capacity, which is why they show lower waste rates than tools that count all idle capacity as waste. Treat "27% wasted" and "30–40% overlap" as directional magnitudes rather than precise measurements. [13]

Named concepts to give the idea a handle: sunk cost fallacy / loss aversion / status quo bias / endowment effect; Conway's Law and Team Topologies; Wardley mapping (inertia to change); the strangler fig pattern (Fowler, 2004); the second-system effect (Brooks); technical debt (Ward Cunningham, 1992); "innovation tokens" / "choose boring technology" (Dan McKinley, 2015); Hyrum's Law; and Gartner's TIME framework.

Recommendations (for the post's framing)

  1. Lead with the asymmetry, not the numbers. The sharpest hook is "every launch has a sponsor; no sunset does." Then land the data as proof.
  2. Use the strongest, cleanest numbers: 27% cloud waste (Flexera, stable since 2019); 305 SaaS apps and 46% unused licences (Zylo 2026); 20–40% tech debt (McKinsey); 70–80% of IT budgets on "run" (GAO for federal). ANZ's 264 apps / A$2.9bn→A$1.4bn is the single best "it works" proof point.
  3. Be honest that the perfect stat doesn't exist. Saying so builds credibility; offer the proxies.
  4. Close with the fix: name a deprecation owner, fund decommissioning as a deliverable, gate new systems on a retirement plan, and make cost visible via showback/chargeback.

Thresholds that change the recommendation: if "run" spend exceeds ~70% of IT budget, or SaaS licence utilization drops below ~55%, or a strangler-fig migration passes ~50% with no dated cutover, decommissioning should be escalated to a funded, owned program.

Caveats

  • Nearly all "waste" and "overlap" percentages are self-reported surveys or vendor-derived estimates, not measurements. Flag them as such.
  • The exact "% of cloud spend on functionally duplicate workloads" statistic does not exist; the proxies measure adjacent things (idle resources, unused licences, tech debt).
  • The COBOL "$3 trillion daily" and "10%/year retirement" figures are widely-cited order-of-magnitude industry estimates, not audited data.
  • Anonymized vendor/consultancy case studies (e.g., "533 apps retired," "68–79% modernization failure") could not be tied to named companies or primary reports; the ANZ, McKinsey/Oxford, GAO, Flexera, Zylo, FCA, and AWS figures are the primary-sourced anchors.
  • The TSB "1.9m customers locked out" figure is a media estimate; the FCA release says only "a significant proportion of 5.2 million."
  1. Leadership IQ + 2 — https://www.leadershipiq.com/blogs/leadershipiq/the-sunk-cost-fallacy
  2. oreilly + 2 — https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch15.html
  3. Notna — https://notna.tech/blog/strangler-fig-pattern-guide/
  4. DEV Community — https://dev.to/godofgeeks/strangler-fig-pattern-for-migration-4ci2
  5. Wikipedia + 2 — https://en.wikipedia.org/wiki/Individual_Master_File
  6. Anthesis Global + 2 — https://www.anthesisgroup.com/insights/zombie-servers-hunting-down-the-lost-capital/
  7. Zylo + 4 — https://zylo.com/blog/too-many-apps
  8. Orbus Software + 2 — https://www.orbussoftware.com/resources/blog/post/the-complete-guide-to-application-rationalization
  9. McKinsey & Company — https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-debt-reclaiming-tech-equity
  10. goodreads — https://www.goodreads.com/notes/53526633-software-engineering-at-google/1886243-jeff-thomas
  11. Usage AI + 2 — https://www.usage.ai/blogs/finops/governance/showback-vs-chargeback/
  12. Appitsoftware — https://www.appitsoftware.com/blog/cobol-to-cloud-banking-modernization
  13. Vendorbenchmark — https://vendorbenchmark.com/blog/cloud-waste-unused-spend-benchmark-data

EDITORIAL BRIEF

Commissioned from our research desk. Subject to final editorial discretion.

Why deprecation is a harder strategic capability to build than adoption, and why most organizations have no one whose actual job it is to decommission things. Cover the asymmetry where launching a new system has a sponsor, a budget, and a celebration, while sunsetting the old one has none of those—so both run in parallel indefinitely, doubling operational cost. Research what percentage of enterprise cloud spend goes to workloads that duplicate functionality of other running workloads. The reader should walk away questioning whether their organization has a single funded deprecation roadmap.