Every organization I’ve worked with has one. A system nobody wants to touch. It runs the payroll, or the case files, or the core transactions, and it has done so for two decades without a catastrophic failure. The people who built it are either still around or recently retired. Replacing it means a budget fight nobody wants to start, so the decision gets pushed to next year. And the next year.

I used to think of this as a technology problem, something for the CIO to solve on a timeline of their choosing. I don’t anymore. The deferral is a leadership decision dressed up as a technical one, and the executive who owns continuity, compliance, and institutional knowledge is the one carrying the risk, whether or not they’ve ever opened the system in question.

Nowhere is this pattern easier to see than in public sector modernization, where the deferral cycle plays out over decades and in full public view. That’s why I talked to Grant Halsey , VP of sales and marketing at Software Solutions, whose company works with local governments navigating exactly this kind of modernization. The lessons apply just as directly to any founder or operator sitting on a system that “still works.” Here’s what that conversation taught me about where the thinking breaks down:

1. Deferral is a governance gap, not a budget gap.

It’s tempting to treat the replacement decision as a line-item problem, deferred without much thought each budget cycle. Halsey explained why that thinking takes hold. “If they defer the decision, the organization can usually keep functioning tomorrow. It becomes very easy to say, ‘Let’s get through this year and revisit it next year.’ This creates a dangerous asymmetry: Nobody gets blamed for renewing maintenance for another year, but everyone remembers a major implementation that goes poorly.”

That incentive structure shows up in the numbers. In IBM’s 2025 research on enterprise IT spending, organizations estimated that 17% to 27% of their total IT budget goes toward dealing with technical debt rather than building anything new. Three-quarters of the executives surveyed pointed to the same root cause Halsey described: IT treated as a cost center, with incentives that reward deferring a fix over preventing the debt in the first place.

The shift, as he framed it, is simple. Stop asking whether the system can still operate, and start asking whether it’s still helping the organization become what it needs to be five or 10 years from now. That’s the leadership question buried inside a maintenance decision.

2. Legacy risk compounds through people as much as code.

The visible risk is technical: outdated architecture, brittle integrations, security gaps. The risk I underestimated is the human one. Halsey pointed to an opportunity cost that’s much harder to quantify. Every hour talented employees spend compensating for outdated technology is an hour they’re not spending on higher-value work like serving customers, analyzing information, and solving the problems that actually move the organization forward.

That cost doesn’t stay theoretical. In 2020, New Jersey’s unemployment system , built on a decades-old programming language, buckled under a surge of pandemic-era claims, and the state found itself publicly appealing for volunteers who still knew how to work with it. Too few people remained who understood the system well enough to respond when it mattered most.

That’s the pattern Halsey identified. The longer an organization waits, the more workarounds accumulate, institutional knowledge disappears as employees retire, and the gap between current capabilities and modern technology widens. When the people who understand why a system works the way it does leave, they take the ability to modernize on the organization’s own timeline with them.

3. Modernization fails when ownership stays with IT alone.

Even leaders who accept the first two points often get this one wrong. They approve the budget, hire the vendor, and hand the project to IT — and then wonder why it stalls midway through. Part of the problem is structural, Halsey explained, because a decision like this touches several groups at once. IT sees the technical issues, finance is watching the cost, and department leaders feel the day-to-day friction the old system causes. With that many stakeholders involved, he said, it’s easy for everyone to have a piece of the decision and for no one to actually own the outcome.

Halsey’s read on the fix is direct. “The healthiest organizations make someone at the leadership level accountable not simply for selecting software, but for answering a larger question: ‘What capabilities does this organization need for the next decade, and what prevents us from having them today?’”

That accountability can’t be delegated to a vendor selection committee. It has to sit with someone responsible for where the organization is headed, uptime included.

If you’re an operator reading this and picturing the exact outdated system I’m describing, you already know the conversation you’ve been putting off. These systems tend to fail quietly, staying just functional enough that deferring the decision keeps looking like the safer choice, until the day it stops being one. The leaders who get ahead of this treat ownership as theirs to claim before anyone asks for it, weighing what the organization will need years from now against what’s standing in the way today.