Banking Modernization Statistics

Part 8 closed the practical arc; this part gathers the numbers the whole series has leaned on into one place. A discipline first, in keeping with how we publish: every figure here is named, dated, and attributed to its source, and where we do not have a sourced number, we say so rather than invent one. These figures are drawn from our maintained statistics hub, refreshed quarterly — the canonical home, where any correction lands first. The aim is to let the case for modernizing a regulated core rest on attributable facts, not superlatives.

The COBOL footprint in banking

The first set of figures establishes that this is not a niche problem:

43% of banking systems were built on COBOL; 80% of in-person transactions and 95% of ATM swipes relied on it; and roughly $3 trillion in daily commerce flowed through COBOL systems. — Reuters, 2017

Estimates of COBOL in production worldwide range from roughly 220 billion lines (Reuters, reported 2017, via IEEE Spectrum) to upper-bound figures above 800 billion (Micro Focus, by 2022).

What these support: COBOL is load-bearing infrastructure across financial services at enormous scale, concentrated in exactly the systems that move money. What they do not support: a precise current figure. The Reuters percentages are from 2017 and we present them as such; the line-count range is wide because no one has an exact inventory. The honest reading is directional and dependable — the footprint is vast — not a precise present-day census.

The workforce: the clock everything runs against

The single most decision-relevant figure in the series:

The average age of a COBOL developer is roughly 58, with about 10% of the COBOL workforce retiring each year. — IBM, reported via Fujitsu, 2020

This is the number that turns the footprint from interesting into urgent, and the reason is given in full in Part 3: the retiring developers are often the only complete copy of the core’s undocumented behavior. It is also the most local statistic — it applies directly to your institution if the people who understand your core are near retirement, regardless of any industry aggregate.

The maintenance burden

Two figures explain where the money already goes:

The run-the-business share of IT budgets is roughly 55–57%. — Deloitte (Global CIO Survey)

Technical debt can amount to 20–40% of the value of an entire technology estate, and addressing it can free up to 50% more engineering time. — McKinsey & Company

Together these say most of the IT budget keeps yesterday running, and a meaningful slice of the estate’s value is debt that taxes everything built on top of it. (We deliberately do not cite the often-repeated “70% of IT budget goes to maintenance” figure attributed to Gartner — we have not been able to source it to a specific, dated origin, and the Deloitte 55–57% figure is the one we stand behind.)

The market

For timing context rather than decision-making:

The mainframe modernization market is projected to grow from $8.39 billion in 2025 to $13.34 billion by 2030, a 9.7% compound annual growth rate. — MarketsandMarkets, reported August 21, 2025

This is the mainframe modernization market broadly, not a banking-specific figure, and we label it as such — but since banking is among the largest mainframe footprints, it is a reasonable proxy for the direction of spend. A near-10% CAGR sustained over five years is the analyst signal that this work has crossed from discretionary to budgeted across large enterprises.

What these numbers do not say

In the spirit of naming limits plainly:

• They do not support a precise current count of banking COBOL, a failure rate specific to core banking programs, or any claim about what a given modernization costs. The “up to 70% of digital transformations fail” figure (BCG, September 2023) that this series cites as the base rate for big-bang change is about transformations broadly — we use it as the base rate for all-at-once programs, not as a banking-specific statistic.
• They do not make your decision. An industry aggregate is a fact about the sector, not an instruction. A stable, supported, well-understood workload is not more urgent to modernize because a market grew or an average shifted.
• We deliberately omit figures we cannot source to a named, dated origin. If a banking statistic you have seen elsewhere is not here, the likeliest reason is that we could not stand behind its provenance — and an unsourced statistic does not ship.

This is the same standard the whole statistics hub holds to: exact, attributed, dated, and refreshed quarterly. If any figure is revised at its source, the hub is where the correction lands first.

Numbers calibrate; they don’t decide

Statistics describe the aggregate; they do not modernize anything, and they should not be the reason you do. The workforce figure is the one most likely to apply directly to you because it is concrete and local — if the two people who understand a critical core workload are within a few years of retiring, the macro numbers are beside the point and that local clock is everything. Use these figures to calibrate your sense of the landscape and your timing, then make the decision on your own system’s facts: its pressures, its data, its undocumented rules, its real cost of standing still.

Where this leads

This is the close of the series. Across nine parts the throughline has held: a regulated core runs real money under real scrutiny, a big-bang rewrite is indefensible against both the outage risk and the audit, and the defensible path is incremental — discovery first, parity-proven slices, zero-downtime cutover, rollback throughout, and the honesty to leave alone what does not need to move. The numbers here say the pressures are real and widespread; they do not say what your core needs. That answer comes from understanding your specific system. If you want to turn these aggregates into a decision grounded in your own facts, a discovery call is a 30-minute conversation to scope your core — no deck, no quote before we understand what we are quoting. Or start where this series started: Part 1, and read the arc in order.