The Clock Your Business Didn't Know Was Running

You probably didn't see it coming. Most people don't.

Over the years, the software your business runs on has worked fine. But slowly, you find bugs that don't seem like much at first. Then you notice updates are coming slower and slower, with fewer real fixes and patches that don't solve known problems. Then there's an email from your vendor — or worse, a conversation with your IT person — and the word "end-of-life" enters your vocabulary for the first time. Suddenly, the system you've trusted for a decade is a liability. And every developer you talk to has a different opinion about what to do next.

This isn't an edge case. This is the world most businesses are walking into right now. And THIS is where projects go wrong before they even start.

Let's start with the scope of what we're actually dealing with.

More than six in ten U.S. businesses are running their operations right now on software their vendors have already walked away from — or are about to. Not as a temporary bridge while they modernize. As their primary infrastructure. The systems processing their orders, managing their inventory, running their customer relationships. Built on platforms that are, by every technical definition, abandoned.

In banking, it's even more entrenched. Seven out of ten banks globally still run on legacy systems as of 2025. Ninety-five percent of every ATM transaction processed anywhere in the world runs on COBOL — a programming language that most universities stopped teaching years ago. The financial system that moves trillions of dollars daily is held together, in large part, by code older than the internet.

And the bill for keeping all of it alive is staggering.

U.S. organizations spend more than $520 billion every year just maintaining legacy software systems. According to Gartner, 40% of IT budgets are consumed entirely by technical debt — money spent not building anything new, not gaining any competitive ground, just keeping old systems from collapsing. A Deloitte study puts the figure even higher, with some organizations devoting 55 to 80 percent of their entire IT budget to maintenance.That leaves, in the worst cases, as little as 20 cents of every technology dollar available for innovation, growth, or modernization.

And the waste compounds at the human level too. The average software developer spends nearly 14 hours a week — a third of their working time — on technical debt. When asked how much of that time they consider genuinely wasted, the average answer is 17 hours. In an organization with 25 developers earning average salaries, that waste adds up to nearly $1 million in lost productivity every single year. Not from a cyberattack. Not from a failed project. Just from the daily drag of keeping old systems running.

But the financial bleeding, as severe as it is, isn't actually the most urgent threat.

That would be the people — or rather, the disappearance of them.

The average COBOL developer is 62 years old. The specialists who know how to maintain legacy systems well enough to keep them stable are commanding $180 to $250 an hour when you can find them at all. Fewer than 2,000 COBOL programmers graduated worldwide in 2024. Nearly all remaining RPG talent — the programmers who keep a significant portion of business-critical systems running — is expected to retire by 2030. And when they go, they take something with them that no amount of documentation can fully replace: institutional knowledge. Industry research suggests 42% of critical business knowledge is at risk when key personnel retire. For legacy systems, where most applications were never adequately documented to begin with, that number is almost certainly higher.

What you're left with is a system that nobody fully understands, running on infrastructure nobody fully supports, maintained by a workforce that is aging out of existence.

Into this vacuum steps a threat that is very much not aging.

CISA's Known Exploited Vulnerabilities catalog grew 34% year over year, with legacy system vulnerabilities accounting for 61% of new additions in 2025. These are not theoretical exposures sitting in a researcher's report. They are active attack vectors being exploited right now, in the wild, against real businesses. Ransomware groups have industrialized their reconnaissance. They use automated tools to scan networks specifically for legacy system signatures — because they know those environments lack modern endpoint detection, have minimal network segmentation, and are critical enough that companies will pay to restore them. The average ransomware payment in 2025 was $2.3 million. Recovery costs typically run three to five times that amount on top of the ransom itself. And according to the 2025 Verizon Data Breach Investigations Report, 68% of breaches involving legacy systems started not through a direct attack on the system itself, but through a compromised third-party component — a vendor, a plugin, a dependency that also stopped receiving updates years ago.

The three largest cyber insurers in the world — Chubb, AIG, and Beazley — have taken notice. Beazley, long considered the specialist's choice for cyber coverage, began pulling back from the market entirely in 2025 as legacy-related claims outpaced premiums. Those still writing policies are now routinely denying claims for unpatched vulnerabilities and outdated systems. The message from the insurance industry is unambiguous: if you're running end-of-life software, you may be paying premiums for coverage that won't be there when you need it.

This is no longer theoretical. The wreckage is documented.

Easter 2025. Marks & Spencer — one of Britain's most recognized retail brands, with revenues exceeding £13 billion — suffered a ransomware attack that brought its operations to a halt. Staff reverted to pen and paper. Employees manually walked the floor checking refrigerator temperatures because automated monitoring systems were offline. The financial toll is projected to exceed £300 million in lost profit. Not from a startup with no IT department. From one of the most established retailers on earth.

June 2024. Synnovis, a major pathology services provider for some of London's most prominent hospitals — King's College, Guy's and St Thomas' — was hit with ransomware. More than 10,000 outpatient appointments were postponed. Over 1,700 elective procedures cancelled. Up to 300 million patient records potentially compromised. Healthcare — where the stakes are measured not just in money but in lives — running on systems that couldn't protect themselves.

A Southeast U.S. healthcare network learned the same lesson the hard way in July 2025. A ransomware attack through a legacy patient portal shut down their systems for six days. The cost to have rebuilt the portal properly beforehand: $450,000. The amount they ultimately paid — in ransom, recovery, and operational losses — was 27 times that. The portal had been on the modernization to-do list for three years.

Three years.

At this point, a reasonable person might conclude that the answer is straightforward: modernize. Replace the legacy systems. Build something new. The math is obvious. The risk is documented. The path forward seems clear.

It isn't.

Here is where the crisis doubles back on itself and becomes something far more treacherous.

Seventy percent of digital transformation initiatives still fail to meet their objectives. Not in some distant era of primitive technology — right now, in 2026, after decades of lessons learned and trillions spent. A Bain study from 2024 found that 88% of business transformations fail to achieve their original ambitions. The Project Management Institute puts one in five enterprise projects as failing to meet basic business goals. And for the most ambitious modernization efforts — the ones that actually try to replace what's broken rather than patch around it — the failure rate climbs higher still.

Global IT spending has tripled since 2005, from $1.7 trillion to $5.6 trillion annually. According to IEEE Spectrum, despite that investment, software success rates have not meaningfully improved in two decades.

So this is where your business actually stands.

Your legacy systems are a liability — financially, operationally, and from a security standpoint — that compounds every month you delay. The vendors are gone. The developers are retiring. The attackers are organized, automated, and specifically hunting for you. Your insurance carrier is rewriting the fine print.

And when you decide to do something about it, the odds are against you.

This is the part where most consultants would pivot to their sales pitch. I'm not going to do that. Because before we talk about solutions, I want to tell you something I learned the hard way — in a different industry, in a different era — about what happens when an entire sector waits too long to face a crisis it could see coming.

I know this pattern. Not from a case study. Not from a consulting engagement. From living inside it while it happened.

For nearly two decades, I built a career as a sound designer and composer in broadcast television. Emmy in hand, clients like CNN and the Turner networks, billing $35,000 to $50,000 a month doing high-end work for clients who valued what specialists could do. It was a good run. And then, slowly — so slowly that most people convinced themselves it wasn't really happening — it wasn't.

Streaming didn't kill cable television in a single blow. It chipped away at revenue one year at a time, which made denial not just possible but almost rational. Every year the numbers were a little worse. Every year the executives held meetings and made reassuring noises and did not make plans. The frog didn't jump because the water never quite felt like it was boiling. Until it was.

I watched the people running these organizations do what people in denial always do: they didn't adapt, they compressed. When revenue dropped, they didn't reimagine the model — they squeezed the vendors. Artists became commodities. A bag of rice has a price. So did we. The in-house talent fared no better. A producer became a writer/producer. Then a writer/producer/editor. Then a writer/producer/editor/graphics person. Then all of that, plus sound designer, mixer, and whatever else needed doing that week. Specialists were valued in principle and eliminated in practice. Production standards dropped in every discipline because the budget required it, and because the executives signing the checks couldn't hear the difference between good and good enough — until the audience could, and by then it didn't matter.

CNN eventually laid off an entire department that had once been my primary client pool. I remember the day the big red CNN logo came down from CNN Center. It felt like a funeral for something that had deserved better.

The Turner networks told similar stories of slow rot. My LinkedIn feed still carries the evidence — talented people from broadcast television, a decade later, still looking for work, still hoping to find something that resembles the world they built careers inside. I went from billing at the top of my field to scraping for $50 an hour with a handful of small sessions each week at one of the few networks still willing to pay for quality audio. Most had decided audio wasn't worth a separate line item. If you pushed back on inferior assets, you were labeled high-maintenance. The client didn't lose sleep over it. They just found someone cheaper who wouldn't push back.

What I lived through wasn't a technology problem. The technology — streaming, on-demand, digital distribution — was just the surface. The real failure was a failure of imagination at the executive level. The people running those organizations could not envision a way forward, so they didn't build one. They managed the decline instead of redirecting it. And everyone who depended on them — vendors, specialists, in-house talent, entire departments — paid the price for that failure of vision over the course of years.

I'm telling you this because the businesses facing the legacy software crisis today are living inside the same pattern. The signals are the same. The denial is the same. The slow compression — patching instead of replacing, squeezing vendors instead of investing, doing more with less until the less isn't enough — is the same. The timeline is different. The stakes, for many businesses, are higher. But the story rhymes in ways that should concern anyone paying attention.

The executives in broadcast didn't see it coming, even when they could. Most of them knew the model was broken. They just couldn't bring themselves to act before the acting became mandatory — and by then, acting gracefully was no longer an option.

That is exactly where a significant portion of American businesses sit today with their technology.

So what actually separates the projects that succeed from the ones that don't?

It isn't the technology stack. It isn't the budget. It isn't the methodology — Agile, waterfall, hybrid, or otherwise. Organizations have thrown all of these variables at the problem for two decades and the failure rate has barely moved. IEEE Spectrum's analysis is blunt about it: despite tripling global IT spending since 2005, software success rates have not meaningfully improved. More money, better tools, and the same outcomes.

The variable that actually determines success is almost never discussed in the technical literature, because it isn't technical. It's human.

Every failed modernization project I have ever seen — and I have seen a lot of them, usually after someone else has already tried and given up — broke down at the same place. Not in the code. Not in the architecture. In the space between the people who understand the business and the people who understand the technology. Those two groups do not naturally speak the same language. They don't share the same priorities, the same timelines, the same definition of done, or the same tolerance for ambiguity. When they're left to work it out themselves, they usually can't. The business stakeholders feel ignored and misunderstood. The technical team feels micromanaged and second-guessed. Trust erodes. Decisions stall. Scope creeps. Budgets blow. And eventually someone declares the project a failure and everyone points at someone else.

What's missing isn't better developers or a more detailed requirements document. What's missing is a translator.

Not a project manager. Not a product owner. Not a business analyst with a certification. A translator — someone who genuinely inhabits both worlds, who can sit across from a CEO and understand exactly what the business needs to accomplish, and then turn around and convey that to a development team with the precision and context they need to build it correctly. Someone who can hold the technical reality and the business reality in the same hand and find the path between them.

But translation alone isn't enough. Because this isn't just a language problem. It's a trust problem.

The translator's most important function isn't converting terminology. It's building and maintaining trust between two groups of people who are, by temperament and training, predisposed to misunderstand each other. Business stakeholders need to trust that their vision is being heard and protected. Technical teams need to trust that the decisions being made above them are informed and rational. When that trust exists, projects move. When it breaks down — even briefly, even partially — everything stalls.

Building that trust requires more than technical fluency. It requires understanding how people work. What their filters are. What their biases are. How a CFO processes risk differently than a lead developer. How an executive who has been burned by a previous failed project carries that experience into every conversation about the new one, often without saying so. How a developer who has been handed impossible requirements by people who didn't understand the technical constraints has learned to protect themselves with skepticism.

My wife Betsy is, among other things, a serious student of personality systems — the frameworks that illuminate how different people process information, make decisions, and respond to uncertainty. Her insights have been a genuine game-changer in how I navigate the human complexity inside a build. Knowing that the CTO and the COO sitting across from each other in the same meeting are filtering the same information through completely different cognitive lenses — and knowing how to bridge that gap in real time — is the difference between a project that maintains momentum and one that quietly comes apart at the seams while everyone wonders what went wrong.

This is the capability that the legacy crisis is going to demand at scale. Not more developers. Not better project management software. Human translators who can stand in the gap between what a business needs and what a technical team can build, and who understand that their primary job is not to manage a timeline but to guard and grow the trust that makes the work possible.

The businesses that navigate this crisis successfully will have that. The ones that don't — the ones that hand a requirements document to a dev shop and hope for the best — will become entries in next year's failure statistics.

If any of this feels familiar — if you're reading it and recognizing your own systems, your own to-do list, your own executives who haven't quite gotten around to making a plan — that recognition is worth something. Most businesses in your position already know, somewhere, that the clock is running. What they don't always know is that the path forward exists, that it doesn't have to end in the statistics we've been discussing, and that the difference between a successful modernization and a failed one is almost never what they think it is.

I built Atherton Hill specifically for this moment. Not to sell technology. Not to manage a project from a distance. To stand in the room with you — between your business and your technical team — and make sure that what gets built is actually what you need, that the people building it understand why it matters, and that the trust required to get from here to done stays intact through every decision, every setback, and every pivot along the way.

The legacy crisis is real. The modernization trap is real. But so is the way out.

If you're ready to talk about what that looks like for your business, I'm not hard to find.