I’ve spent decades working on financial systems other people had given up on.
Most legacy systems are doing the majority of their job correctly. A small percentage fails, and that failure gets mistaken for total collapse.
When that happens, the reflex is predictable:
- Rip it out
- Rewrite it
- Replace everything
Sometimes that’s correct. Sometimes it is an expensive mistake.
Before software, I worked in metallurgy. Failures are rarely uniform. They happen at stress points. The job is to find those points, understand why they failed, and fix or reinforce them, not assume the entire structure is unsalvageable.
Software is the same:
- The brittle parts are knowable
- Integration pain has a cause
- Compliance gaps have a shape
And buried in every legacy system is something replacement projects consistently underestimate: decades of business rules and hard-won knowledge baked into the code.
Rescue is a different discipline to replacement. It requires:
- Understanding before action
- Patience to read what someone else built
- Respect for the business rules embedded in the code
- The confidence to say “this is fixable” when replacement is the easier story
Precision instead of demolition. Modernisation that builds on what already works, and replacement when it’s genuinely the right call.
If your system is considered “end of life”, it’s worth validating that before you replace it.
