There's a kind of debt that never shows up on a balance sheet. It collects quietly in the seams of a business — in the spreadsheet only one analyst knows how to update, the integration running on a laptop nobody remembers deploying, the password that exists only in a longtime employee's memory. Every firm I've worked with carries some version of this. Most don't realize how heavy it's gotten until someone tries to lift it.
Usually that someone is me, and usually the moment is tender: a key person just left, a renewal notice just arrived, or something that "always worked" just stopped. So I want to walk through how I actually think about aging systems — which ones deserve investment, which ones deserve replacement, and which ones deserve to be left completely alone. The answer is less obvious than the modernization industry would like you to believe.
Nobody designed this. That's normal.
Here's the honest history of most companies' architecture: it wasn't designed, it accreted. A founder picked a CRM because their last company used it. An ops lead bolted a billing tool onto the side because the existing one couldn't handle a single edge case that mattered that quarter. A vendor was chosen in an afternoon because the demo was on a Tuesday and the decision couldn't wait until Friday.
None of these were bad decisions. They were fast decisions, made by people solving the problem in front of them — which is exactly what those people were supposed to do. But two years later, the company is running on twelve systems nobody chose deliberately, connected by handoffs nobody documented, and the cost of changing any one of them has become genuinely frightening.
If that describes your firm, you're not behind. You're typical. The question isn't how you got here — everyone gets here the same way. The question is what to do next, and the reflexive answer is almost always wrong.
The rip-it-out reflex
When a technology leader inherits a messy stack, the temptation is to propose the clean sweep: new platform, fresh integrations, a diagram with satisfyingly few boxes. I understand the pull. A rebuild is legible. It photographs well in a board deck. It feels like leadership.
But most "obvious" rewrites are vanity projects in disguise. The system was fine; the owner was tired. And a rewrite trades a known set of trade-offs — quirks your team has already absorbed, failure modes you've already survived — for an unknown set you'll spend two years discovering.
The second-best architecture, faithfully maintained, will outperform the elegant one that nobody owns.
That sentence has saved my clients more money than any tool I've ever implemented. Ownership — a named person who understands a system, watches it, and cares whether it works — matters more than the system itself. When I evaluate a stack, I'm not really auditing software. I'm auditing attention.
Load-bearing or just loud?
So how do you tell the difference between a system that needs replacing and one that just needs an owner? I ask three questions.
Who complains about it, and what do they actually lose? Some systems generate constant grumbling and zero measurable cost. Others fail silently while everyone works around them — re-keying data, maintaining shadow spreadsheets, quietly absorbing hours. The loud system is rarely the expensive one. The workaround is where the money goes.
What happens when the person who knows it leaves? This is the single best test of hidden risk. If the answer is "we'd figure it out from the documentation," you're fine. If the answer is a long pause, that system just told you where your real debt lives — and the fix might be documentation and cross-training, not replacement.
What does the next change cost? Don't measure a system by its elegance. Measure it by what it costs the next person who has to touch it. A crusty tool that accepts changes safely in an afternoon is healthier than a modern platform where every adjustment requires a consultant and a prayer.
Boring is a feature
Some tools earn the right to be ignored. If a system is boring, well-understood, and nobody is complaining, it is doing its job — and the urge to modernize it anyway is one of the most expensive habits a technology function can develop.
I've watched firms spend six figures replacing systems whose greatest sin was being unfashionable, while the actual risks — the un-owned integration, the single point of human failure — sat untouched one tab over. Modernization for its own sake isn't strategy. It's redecorating.
Where to start
If you take one thing from this piece, take the exercise: list the five systems your business would miss within 48 hours if they vanished. For each one, write down who owns it, where its documentation lives, and what the last change cost. Most firms can't complete the list — and the blanks are the roadmap.
That's the quiet cost of good-enough systems. Not the software. The attention nobody was assigned to pay. The good news is that attention is the cheapest thing on the menu — you just have to decide it's someone's job.
