Most business owners describe the problem the same way. "The system works. Customers use it every day. But every time we ask for a change, it takes forever, costs more than we expected, and something else breaks that we didn't touch."
That's the real problem. Not that the software is old. That nobody can safely change it anymore.
Those are two completely different situations, and confusing them costs companies a lot of money. Old software that works and can be changed safely is an asset — leave it alone. Software you're afraid to touch is a liability, and it stays a liability whether you rebuild it or not. The question that matters isn't "is this old?" It's "can we still move?"
Age Is Not the Reason
I want to be blunt about this, because the software industry has a financial interest in the opposite message.
Software being old is not a reason to replace it. There are systems quietly running businesses today on technology that was current a decade or two ago, and they run fine. They process orders, send invoices, handle payments, and nobody thinks about them — which is exactly what good infrastructure is supposed to do. Replacing one of those because it's "outdated" is like demolishing a warehouse because the architecture is unfashionable. It's still keeping the rain off your inventory.
The pressure to modernize usually comes from one of a few places, and most of them are bad reasons:
- A developer doesn't enjoy working in it. Legitimate feeling, not a legitimate business case. "I'd build it differently" is an aesthetic preference, not an economic argument.
- It's not the newest technology. Newer is not the same as better for your situation. The newest stack still has to be built, tested, and learned by whoever maintains it next.
- A vendor told you it's "legacy." Vendors sell replacements. That's the whole business. When the person diagnosing the problem also sells the cure, get a second opinion.
None of these mean your software is holding you back. So what does?
The Real Symptom: Change Has Become Dangerous
Here's how you actually know something is wrong. It isn't the age of the code — it's what happens when you try to change it.
Watch for these:
- Every change takes far longer than it should, and the estimates keep growing. A small request — a new field on a form, a change to how a discount is calculated — turns into weeks. And the number goes up each time, not down.
- Changing one thing breaks something unrelated. You update the checkout page and the invoicing breaks. Nobody can explain why those two things are connected, which is precisely the problem: the connections aren't understood anymore.
- Only one person can touch it — and you're afraid of losing them. If a single developer is the only human who understands how the system works, you don't have software. You have a hostage situation, and the ransom is their salary and their continued good mood.
- Nobody can safely say what will happen if you deploy a change. In a healthy system, you can predict the effect of a change and verify it before it reaches customers. When every deployment is a held breath, the system has stopped being controllable.
Notice what all four have in common. None of them is about the technology being old. They're about the system having become unpredictable and unsafe to modify. That's the condition worth spending money to fix. Age is a coincidence; danger is the diagnosis.
Why Rewriting Is the Wrong Instinct
When change becomes dangerous, the instinct is to start over. Throw it all out, build it clean, no more inherited mess. It feels decisive. It's usually a mistake.
The reason is uncomfortable but consistent: your working software knows things nobody wrote down. Over the years, it accumulated fixes for edge cases you've forgotten — the customer whose address broke the shipping label, the tax rule that only applies in one country, the payment that occasionally arrives twice and must not be charged twice. None of that is in a document. It's baked into the code that currently works.
A rewrite starts without any of that knowledge and has to rediscover it — the hard way, through real failures, with real customers. Meanwhile, your business keeps running on the old system, which still needs maintenance and still breaks, while the new one consumes budget and ships nothing customers can use. The common ending is a replacement that arrives late, missing features the old system had, and that the next team will describe as "the legacy system" within two years.
Rewrites can be justified. But "it's old" and "it's hard to work in" are not the justifications — those describe most software that has ever earned money.
slug="rescue-projects"
text="If change has become dangerous, you usually don't need a rewrite — you need someone to read the system carefully and make it safe to change again. That's the work I take on, and I'll tell you honestly if a rewrite really is the answer."
/>
What Modernization Actually Means (When It's Worth It)
Modernization done well is rarely a demolition. It's making a working system safe to change again — and most of that work is invisible to your customers, which is exactly why it gets skipped until it's a crisis.
In practice it looks like this. Someone reads the system carefully and writes down what it actually does, so the knowledge lives in more than one head. They add a safety net that catches breakage before it reaches customers, so a change to checkout can't silently break invoicing without someone being warned. They add visibility, so when something goes wrong at 2am, you find out before your customers do. And where one specific part is genuinely beyond saving, they replace that part gradually — building the new alongside the old and switching over piece by piece — instead of betting the whole business on a big-bang cutover.
The result you're paying for isn't "modern technology." It's the ability to change your own software again — quickly, cheaply, and without fear. That's the asset that got lost, and that's the asset worth buying back.
When Modernizing Is Genuinely Worth It
There are real cases where the investment pays for itself. They're rarer than the sales pitch suggests, but they exist:
- The technology is genuinely dead, not just old. Not "an older version" — abandoned. No security updates, no way to hire anyone who knows it, constant workarounds just to keep it alive. At that point the cost of keeping it running exceeds the cost of replacing it, and the security exposure alone can force your hand.
- What your business does has fundamentally changed. If you've pivoted, acquired another company, or moved from serving consumers to serving other businesses, the old system may have been built for a company that no longer exists. When every new feature is a fight against how the software was originally shaped, that's a real reason — but notice it's a business reason, not a code-quality one.
- The system is actively costing you money you can count. Not vague frustration — actual, countable losses. Support hours spent on the same recurring failure. Orders lost when it goes down. A developer's time consumed by workarounds instead of new work. When you can put a monthly number on what the current situation costs, and that number is larger than the cost of fixing it, the decision makes itself.
That last one is the honest test. If you can't name what the current situation is costing you in euros, you don't yet have a business case for spending euros to change it. You have a feeling. Feelings are worth listening to — they're often the first signal that something's wrong — but they're not yet a decision.
When to Leave It Alone
This is the part most articles on the subject skip, because most are written by people who profit from you saying yes. So I'll say the uncomfortable thing plainly: often the right answer is to do nothing.
Leave your software alone when:
- It works, changes are still safe, and it isn't blocking anything. Boring, reliable, and old is not a problem. It's the goal. Don't manufacture a crisis to justify a project.
- The pain is real but small. If the annoyance costs you a few hours a month, spending a large sum and months of disruption to remove it is a bad trade. The math has to work, and for small pain it usually doesn't.
- You can't yet say what "fixed" looks like. If nobody can describe what the system should do differently, no amount of rebuilding will produce it. That's a clarity problem to solve first — on paper, cheaply — before anyone writes code.
- The real problem isn't the software at all. Sometimes "we need to rebuild the system" is standing in for an unresolved business decision — unclear direction, a team that isn't aligned, a strategy that hasn't been made. A rewrite provides the feeling of action while the actual problem waits. That's the most expensive way to avoid a hard conversation.
A rewrite is one of the largest and riskiest bets a company makes with its technology. The default answer should be no, and the burden of proof should sit with whoever wants to say yes.
How to Decide
You don't need to be technical to make the right call. You need to answer three questions honestly.
Can we still change it safely and affordably? If yes, you almost certainly have an asset, not a liability. Age is irrelevant. Leave it alone and spend the money on something that grows the business.
If not, what is that costing us — in euros, per month? Support time, downtime, developer hours spent fighting the system instead of improving it. If you can't count it, get someone to help you count it before you commit to anything. The number is the decision.
Is the software actually the problem? If a clean, safe version of the system existed tomorrow, would you know exactly what to build next? If yes, the technical work is worth investing in. If no, fix the clarity first — that's cheaper, faster, and it might turn out the software was never the real obstacle.
The goal was never modern technology. The goal is a business that can change its own software as fast as it needs to, without fear and without a fortune. Sometimes that means modernizing. Often it means leaving good software alone. The skill — and the honesty — is telling those two apart before you spend a euro.
If your software works but every change has become slow, expensive, and frightening, that's the situation worth a careful look — not a reflexive rebuild. Let's figure out which one you're actually in.
Top comments (0)