The signals that tell you whether patching or replacing your old software is the right call, with a practical assessment framework.
Best for: IT leaders, operations managersPractical guide for business decision-makers
Who this is for
IT leaders and operations managers dealing with ageing software they're not sure is worth keeping.
Question this answers
Should I invest in fixing our old system or is it time to start planning a replacement?
What you'll leave with
Clear signals that a system needs replacing vs repairing
How to assess your system's true maintenance cost
A practical audit framework you can run yourself
The signals
Old software isn't automatically bad. Some systems built 15 years ago still work beautifully because they were well-designed and the requirements haven't changed much. Age alone isn't a reason to rebuild.
The question is whether the system is helping or hindering your business.
Warning signs that suggest replacement:
Maintenance costs are rising year over year
You can't find developers who know the technology
The vendor has stopped supporting it
New business requirements are impossible or prohibitively expensive to implement
Your team spends more time working around the system than working with it
Security vulnerabilities can't be patched
Integration with modern systems is difficult or impossible
When to keep the old system
It does what the business needs, even if the UI is dated
Maintenance costs are stable and reasonable
The technology still has community support and available developers
Required changes are feasible within the existing architecture
Replacing it would disrupt operations with no proportional business benefit
When to replace
Replace when at least 3 of these apply
⚠
Annual maintenance exceeds 30% of estimated rebuild cost
⚠
The technology has no active developer community
⚠
Critical business requirements can't be implemented
⚠
Security vulnerabilities exist that can't be patched
⚠
Staff workarounds have become the norm, not the exception
⚠
Integration with modern tools requires custom middleware
How to assess your system
Calculate total cost of ownership: Licensing, hosting, maintenance hours, support contracts, workaround time, opportunity cost of features you can't build.
Assess technical health: Is the codebase maintainable? Are there automated tests? Is the architecture sound?
Map business requirements: List the top 10 things the business needs in the next 2 years. Can the current system deliver them?
Evaluate risk: What happens if the system fails? If the one person who knows it leaves? If a security vulnerability is exploited?
Get a second opinion: An external technical assessment removes internal bias and often reveals issues that insiders have normalised.
Key takeaways
If maintenance cost exceeds 30% of rebuild cost annually, replacement usually makes sense
Technology obsolescence alone isn't a reason to rebuild — business limitation is
The best assessment combines financial analysis with technical assessment
Most systems fall in the grey zone — that's where modernisation (not full rebuild) is usually the answer
