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