Can a legacy lending system be modernised without replacing it?
Usually, yes. Most systems labelled end-of-life are not failing: they are unsupported, undocumented, and frightening to touch. Those are three different problems, and only one of them needs new software. A rescue keeps the decades of business rules already encoded in the system and replaces the parts that are genuinely at the end of their life.
End of Life usually means four different things:
- No vendor support
- No one left who understands it
- A runtime or database out of support
- A UI staff workaround
Each has a different fix and only the third forces a migration.
Where these systems actually break
Before software, Andrew Stanford worked in metallurgy. Failures are rarely uniform, they happen at stress points. The same is true of a lending platform, the integration seams, the batch windows, the manual re-entry between two systems that were never introduced to each other.
The oldest code is not always the riskiest part. We often find that the core calculations still work while failures cluster around integrations, overnight processes and manual hand-offs. The practical rescue is to stabilise those pressure points first, then modernise the surrounding platform in controlled stages.
What a rescue keeps that a replacement does not
Three things and none of them appear on a project plan.
The business rules already encoded in the system. Years of legislation, customer behaviour, operational experience and edge cases, working correctly, in production, today.
The safety of a system that already behaves correctly. Every rule that has to be rebuilt is a rule that has to be re-tested, and the ones that break are rarely the ones anybody thought to write a test for.
The people who know the exceptions. The staff who know which cases the system handles oddly, and why, are a resource that a replacement project spends rather than uses.
Where the rules and the regulator meet
For a New Zealand lender, a good deal of the Credit Contracts and Consumer Finance Act (CCCFA) 2003 lives inside the software rather than in a policy document. How affordability and sustainability are assessed, what is disclosed, and when. When the terms change and the system does not, the gap between the two is invisible until somebody checks. That is a system problem before it is a compliance problem, and it is one of the things a rescue surfaces early.
Dark Arts does not interpret legislation or provide legal or compliance advice. Your advisers define the obligation; we trace where it is represented in calculations, disclosures, workflows, configuration and audit records. We can then identify where the implemented system no longer matches the approved policy.
When replacement genuinely is right
Not every system is worth saving, and a page that only argues one way is a sales pitch. There are three cases where we will tell a client to replace.
When the business has changed so much that the rules no longer describe how the firm operates. When the platform's own licensing makes modernisation uneconomic. And when the real fault is not the technology at all, but the absence of things the system was never built to do.
The last one is the most common, and the least expected.
Replacement is justified when the organisation is no longer trying to preserve the same system: the products, data model and operating process have all changed. In that situation, forcing the old architecture to imitate a new business can cost more and carry more risk than rebuilding deliberately. Age alone is not the deciding factor.
Frequently Asked Questions
How do you tell a system that is genuinely end of life from one that is just unsupported?
An unsupported system has reached the end of the vendor's commitment. An end of life system has reached the end of its value to the business.
What happens to our business rules if we modernise rather than replace? Business Rules are one of the most valuable assets a company owns. Over years or decades they've evolved through legislation, customer behaviour, operational experience, and countless edge cases.
When you replace, a business often gets caught out, it begins with "Let's just rebuild what the old system does".
Then they discover nobody actually knows everything the old system does, especially if the rules the old system follows are not well documented over time.
Modernisation gives you the opportunity to decide which rules genuinely matter and not bring decades of unnecessary complexity to the new system.
A good medernisation project separates the knowledge from the technology, so the organisation owns its rules rather than having them buried in legacy code.
How long does an assessment take before we have to commit to anything?
Our assessment is a decision making exercise. In just a few weeks you'll understand exactly where your system stands, what the risks are, and the most practical options available. Whether you choose to modernise, replace, or simply make targeted improvements, you'll have the evidence to move forward with confidence.
Can you work with a system whose original developers have left?
Absolutely in fact most of the systems we work with have outlived their original developers.
We specialise in understanding complex, undocumented applications by combining technical analysis with the knowledge of your business users.
Our goal is to preserve the valuable knowledge embedded in your system, reduce risk, and give you a clear path forward.
Do you need production access?
No! Our assessment is read-only. We don't make changes to your production environment or data during the assessment. Any recommendations are discussed with you before any implementation work begins.
Related reading: The Great Legacy System Debate: modernise or rewrite?