Resources · Market data
In short
The US legacy problem is well measured at the top and thin in the middle. GAO counts critical federal systems up to 60 years old, banks stay on cores they rate 3 out of 5, and life insurers spend over half their IT budgets on upkeep. Mid-market data runs out, while SEC, FFIEC, PCI DSS and state privacy rules now set dates for showing what a system does.
If you run a company on a core application that is ten or twenty years old, you have probably been told that everyone has the same problem. That is true, and it isn't much help. What helps is knowing how big the problem is, where it is measured, and which outside forces are about to set a date for you.
So I pulled together the US figures that can actually be checked: the federal auditor's count of aging systems, what banks and insurers report about their cores, what little data exists for the mid-market, and the regulations that now ask companies to show what their systems do. The short version: the problem is well documented at the top, thin in the middle, and regulation is quietly turning "later" into "by this date."
The Government Accountability Office is the most consistent source we have, because it has counted the same thing since 2019. The federal government spends more than $100 billion a year on IT, and agencies report that about 80 percent goes to operating and maintaining existing systems.
In June 2019, GAO reviewed 65 legacy systems and named the 10 most in need of modernization. They were 8 to 51 years old and cost about $337 million a year to run. In July 2025 GAO repeated the exercise with 69 systems. The new top 11 are 23 to 60 years old and cost roughly $754 million a year. Eight run on outdated languages such as COBOL, four sit on unsupported hardware or software, and seven operate with known cybersecurity vulnerabilities.
Two numbers matter more than the ages. Of the ten modernizations identified in 2019, agencies had completed three by February 2025. Of the eleven current systems, only three had a plan with milestones, a description of the work and a disposition for the old system. GAO is blunt: without a complete plan, a modernization has "an increased likelihood of cost overruns, schedule delays, and overall project failure."
The lesson isn't that government is slow. It is that the failure point is the plan, not the technology.
Banks are the clearest commercial parallel, because everything depends on one core platform. In the American Bankers Association's 2024 core platforms survey, 53 percent of bankers were satisfied with their core provider and 35 percent were dissatisfied, for an overall score of 3.19 out of 5. Yet 69 percent said they were likely to stay at the next contract renewal, and only 19 percent were likely to convert. Satisfaction declines steadily through the contract term and is lowest as renewal approaches.
Read those findings together and you get the real dynamic: banks don't stay because the core is good. They stay because replacing it is a big-bang event with its own risk. The US Treasury's February 2023 cloud report shows the same caution: it cites a 2021 ABA survey in which more than 90 percent of banks had something in the cloud but only 5 percent called their cloud use mature, and a separate survey in which 24 percent of North American banks had partially migrated core services.
Regulators have noticed. The OCC's Spring 2025 Semiannual Risk Perspective treats prolonged use of legacy systems as an operational risk that can introduce vulnerabilities and reduce resilience [VERIFY exact wording against the PDF].
Insurers have the same problem with policy administration systems. Celent's 2024 survey of North American life insurance technology executives found that maintaining current systems makes up more than half of IT budgets, and that policy administration investments top core-system plans. In a June 2025 note, Celent's Tom Scales put the business cost plainly: on legacy platforms, launching a product "can literally cost millions and take months, if not more than a year."
That is the figure a CFO should carry around: not the age of the system, but the share of the budget that produces no change, and the time a new product spends waiting on it.
Now the hard part. The National Center for the Middle Market at Ohio State counts roughly 200,000 US companies with revenues between $10 million and $1 billion, producing about one third of private-sector GDP and employment. That is a very large group running software nobody audits or surveys.
The closest thing to a systems survey is the Center's 2022 study of 406 technology decision makers at upper mid-market companies. It found that 43 percent described themselves as cloud native, with little or no legacy to carry. Among the rest, most had moved some systems and kept others, and only 12 percent had migrated everything. Slower-growing companies spent more of their cloud budget supporting existing applications. The economy-wide backdrop is the Consortium for Information and Software Quality's estimate that accumulated US technical debt reached about $1.52 trillion in 2022.
We could not find a credible dataset that says what share of mid-market core applications are legacy, and I would be wary of anyone who quotes one. What we have is experience. A publisher's subscription system we worked on carried its renewal pricing in one scheduled job and one person's memory. A German fintech client ran every transaction through a Rails application four years behind on framework upgrades. Neither company was small, and neither could fund the multi-year, eight-figure core program a large bank runs. That is the mid-market position: too big to ignore the risk, too small for the program that usually addresses it.
The last set of numbers are deadlines, not statistics, and they share a theme: each asks a company to know, and show, what its systems do.
"We're private, most of this doesn't apply to us." Some of it may not. But your bank is examined under FFIEC guidance and will push the questions down to you, your payment flows fall under PCI DSS, your customers live in those twenty states, and an acquirer will ask the SEC's questions whether or not the SEC does. A system nobody can describe is a disclosure problem before it is an engineering problem.
Reading across the data, four things stand out.
In practice that means starting from one business priority the system is holding back, writing down how the system behaves today, replacing one workflow at a time while the current system keeps running, and measuring each step before the next. Martin Fowler called the pattern the strangler fig in 2004. The federal and banking numbers are what happens without it.
Fabrica's CLEAR method is built around the gaps these numbers expose. Capture and Lock produce a System Specification of what the running system does, which is the evidence auditors ask for. Engineer and Attest rebuild one workflow and test it against the current system before any traffic moves, and Release shifts production by cohort with acceptance criteria and rollback. The assessment is scoped to one workflow, so a mid-market company can start without a program-sized budget.
The national figures tell you that you are not alone and that waiting has a cost. They don't tell you what your system is delaying or what a first step would take. Producing those figures is the first piece of work: the share of your budget that goes to upkeep, the initiatives queued behind the system, and the regulatory dates that apply to you. Questions to ask before your next planning cycle:
Tell us about it on a 30-minute call. We'll suggest a first scope and what a technical review would need to confirm.