Old software is comfortable. It works, mostly. People know its quirks. The workarounds are documented (or at least memorised). Replacing it feels like risk.

But keeping it has a cost too: slow performance, security vulnerabilities, inability to integrate with modern tools, and a growing team of people who know how to work around problems rather than solve them.

The decision isn't always obvious. Here's how to think about it.

The repair trap

The most common mistake is incremental patching without a plan. You fix one thing, and it breaks something else. You add a feature, and it takes three times longer than it should because the codebase is fragile. Each patch makes the next one harder.

At some point, you're spending more on patches than a rebuild would cost. But because each individual patch seems small, nobody notices the total.

When patching makes sense

  • The core functionality still works and meets business needs
  • The changes needed are isolated. You can fix one area without destabilising others
  • The technology stack is still supported and getting security updates
  • The team understands the codebase well enough to work in it safely
  • The cost of patching for the next 2–3 years is clearly less than rebuilding

When rebuilding makes sense

  • The technology is end-of-life. No security patches, no community support
  • Every change takes disproportionately long because of accumulated complexity
  • The system can't integrate with modern tools your business needs
  • Performance is degrading and can't be fixed with infrastructure upgrades alone
  • You're spending more than 60% of dev time on maintenance rather than new features
  • Key knowledge holders have left and nobody fully understands how it works

The middle path

It doesn't have to be all-or-nothing. The approach we use most often is strangler fig migration: rebuild piece by piece while the old system keeps running.

  1. Identify the most painful or most valuable module
  2. Build the new version of that module alongside the old system
  3. Route traffic to the new module once it's proven
  4. Repeat for the next module

This spreads the cost, reduces risk, and delivers value incrementally. You're never betting the whole business on a big-bang migration.

The right answer depends on your specific situation. But the worst answer is usually "do nothing and hope it holds together." Legacy debt compounds just like financial debt, and it gets more expensive the longer you wait.

Kasun Wijayamanna Founder & Lead Developer Postgraduate Researcher (AI & RAG), Curtin University - Western Australia
Legacy SystemsSoftware BudgetingIT Leaders