The Hidden Cost of "It Still Works" in Legacy Systems

Meet Dave.

Dave runs a $60M distribution company. Twenty years in business, two locations, a solid customer base, and an ERP that has been humming along since the first iPhone was new. He knows the system has its quirks (he has mentioned it at every year-end review for the past four years). But when anyone raises modernization, Dave has an answer ready.

We have sat across the table from Dave more times than we can count. He has built something real, he is careful with money, and he is not wrong to be skeptical about technology projects. We have also watched companies just like his leave serious money on the table, not because they made bad decisions, but because they kept delaying a conversation that deserved to happen sooner.

So here is that conversation, Dave-style.

"It still works. Why would I change it?"

The opener. The classic. And on the surface, it holds up: the system boots, orders move, customers get served. Nobody is calling it a crisis.

But "works" has quietly become a very generous standard.

A system can be stable and still introduce friction at nearly every step. It shows up in small ways: inventory reports that take a few extra hours, outputs the team has learned to double-check before sending to clients, a spreadsheet living on someone's desktop that bridges two systems that never quite talk to each other. None of that stops the business. But it shapes, steadily and silently, how efficiently it runs, and how much of the team's time goes toward compensating rather than operating.

A 2025 report from the U.S. Government Accountability Office (GAO) found that federal agencies spend roughly 80% of their IT budgets on operations and maintenance of existing systems, leaving only 20% for anything new. The pattern holds in the private sector: according to Gartner, companies typically spend between 60% and 80% of their IT budgets maintaining existing systems, leaving little room for anything new. Those costs don't hold steady, either: they tend to grow 15% to 25% annually, not because anyone plans for it, but because complexity compounds and the pool of people who truly understand the system keeps shrinking.

The system works. It is just working harder than it needs to, and charging you for the privilege.

"This isn't the right time. We're too busy."

The most understandable objection. Also the one that tends to cost companies the most.

Here is the thing: a meaningful chunk of it is caused by the system. Nobody budgets for the hour someone spends every week reconciling what the system should have reconciled automatically, or the extra round of checks before a report goes out because the outputs have been wrong before.

We saw this in our work with VAS (Valley Agricultural Software), the global leader in connected farm management systems. Founded in 1981, VAS manages data for over 10 million cows across more than 3,000 dairies, a scale that, after 30 years of development, their original platform was no longer the best fit for the scale and coordination the business now required. Synchronizing work across users, maintaining compliance, and locating customer data had all become daily friction points. The team was not failing: they were working hard. But a significant portion of that work was going toward compensating for a system that had simply outgrown its original design. Once the legacy platform was migrated to a modern cloud-based architecture, VAS achieved a 30% reduction in operational costs, freed its teams from manual oversight tasks, and opened the door to expansion across more than 100 countries. The workload had not been inevitable. It had been shaped, gradually, by the system.

When Dave says "now is not the right time," what he is often really describing is a feedback loop: the system has made the team so busy compensating for its limits that there is no bandwidth left to fix them.

"Modernization is expensive. I don't have the budget for it."

Fair enough. 

Yes, modernization requires investment. But the comparison Dave is making (pay now versus pay nothing) assumes the current state is cost-neutral, and it’s not.

Legacy systems carry ongoing costs that rarely surface in a single line item. They show up in IT hours spent on maintenance and troubleshooting, in external specialists retained because they are among the few who still understand the codebase, in auxiliary tools layered on top to fill functional gaps, in reporting workflows that break at every handoff and require manual reconciliation to close. None of that gets labeled "legacy system cost." It gets absorbed into headcount, into project timelines, into the three hours someone spends every Monday morning making the weekly report actually match what happened last week.

Aggregate those effects across U.S. companies and the numbers are significant. Analysts estimate outdated technology costs American businesses trillions in lost productivity annually, not as a single visible expense, but as the accumulated weight of thousands of small inefficiencies compounding over time.

In our work with Esquire Depositions, a U.S.-based leader in legal deposition services and part of Gridiron Capital's portfolio, the existing systems had supported the business through years of growth. But as Esquire scaled (integrating acquisitions and managing nationwide deposition operations across hundreds of law firms), data spread across disconnected sources, approvals required manual coordination across teams, and reporting stopped matching operational reality in ways that slowed decision-making. Centralizing data architecture and eliminating the manual workflows produced a 40% improvement in operational efficiency and a 10% increase in enterprise valuation.

The system had always worked. What became visible was how much it was limiting where the company could go.

"We tried something like this before and it was a disaster."

Some experiences leave marks. A technology project that ran two years over schedule, burned through budget, and delivered a system nobody ended up using tends to be one of them. Dave's hesitation here is not stubbornness. It is institutional memory, and it is earned.

What is worth separating is what actually failed. For years, the dominant approach to legacy modernization was a full replacement: shut down the old system, stand up the new one, and hope the transition held. Scope too large, risk too concentrated, no room to adjust once execution started. That is where most of the horror stories came from.

That approach has largely given way to something more incremental: smaller scopes, faster delivery, and modernization that happens while the business keeps running. The risk profile is genuinely different from what it was ten years ago.

The failed project from 2015 was a different kind of undertaking.

"My team knows the system. Retraining everyone sounds like a nightmare."

True. Also: your team's expertise at navigating this system is partly a measure of how hard they have had to work around it.

When people spend years with the same tools, they develop workarounds that start to function like institutional knowledge. They know which reports to double-check, which processes need manual intervention, which colleague to call when something breaks in a specific way. That knowledge keeps operations running, but it also creates fragile dependencies concentrated in specific people. 

There is a broader cost here. Teams spending a significant portion of their time compensating for tools have less capacity to improve the business itself. That shifts the organizational focus from growth to maintenance, and it tends to show up eventually in retention numbers. The retraining concern is real. So is the quiet erosion that happens when capable people spend their days on workarounds.

"We're not planning to sell, so we don't need to impress investors."

The most sophisticated argument Dave makes. Also the one that concerns us most.

In private-equity-backed companies, technology maturity now factors directly into valuation. Diligence teams ask about the system stack, documentation, and key-person dependencies. Fragile legacy infrastructure with undocumented integrations is a red flag that affects price. But even for companies with no near-term transaction on the horizon, the more immediate questions are: 

• How many decisions is Dave making without reliable data?
• How quickly can the business respond when a competitor with better infrastructure starts moving into the same market?
• What happens when the people who know where all the workarounds live decide to move on?

The legacy system is not just an IT issue. It is a ceiling on what the business can become. And it lowers a little each year it stays in place.

What changes when companies actually address it

For Dave, or anyone running a business on tools that have quietly stopped keeping up, the results rarely show up first in the tech metrics.

Esquire Depositions saw it in workforce productivity and enterprise valuation. VAS saw it in operational costs and the ability to expand into markets the old system could never have supported. 

The pattern across these engagements is consistent. The value does not come from the technology itself: it comes from removing friction from how the business actually runs day to day. The specific mechanisms vary, but the starting point is almost always the same: a system that still runs, but no longer fits.

The part that doesn't usually come up until it's too late

Legacy systems rarely announce their failure. They keep working, just a little worse each year, until something puts them under real pressure.

In December 2022, Southwest Airlines learned this the hard way: their crew scheduling system collapsed under the strain of a winter storm, canceling more than 15,000 flights during the holiday season and stranding over 2 million travelers. The airline's own pilots union had flagged the system's fragility months before it failed. The U.S. Department of Transportation launched a formal investigation and ultimately fined Southwest $140 million, the largest consumer protection penalty in the agency's history. Total cost to the company, including refunds and lost revenue, exceeded $1.1 billion.

Southwest's CEO, Bob Jordan (not Dave), put it plainly in the aftermath: "We're still using IT from the '90s, and processes from when our airline was a tenth of the size."

Not every company ends up there. But a lot of them eventually reach a point where they realize the system has been shaping more decisions than they noticed, limiting more growth than they measured, and accumulating more risk than they priced in. The status quo carries a cost. It is real, it is measurable, and it grows.

So, Dave, when do you want to have the real conversation?

The good news is that this does not have to be a massive, all-or-nothing initiative. Effective modernization today tends to be incremental by design: scoped to specific high-impact areas, sequenced to protect business continuity, and supported by AI tools that compress timelines and make it easier to measure impact at every step.

The starting point is not the technology. It is understanding how work actually happens inside the business: where delays accumulate, where errors originate, where the team is compensating for tools that were never meant to carry this much weight. From there, modernization becomes a sequence of well-scoped decisions rather than a single leap of faith.

If you are running a business that has outgrown its tools, even if those tools still technically work, let's talk about where to start.