Lenders Do Not Fear Their Old Systems. They Fear One Weekend.

It is the third year this item has been on the board agenda: replace the loan management system.

Everyone in the room agrees it has to go. It was built twelve years ago. Two people understand it. A small change takes weeks, and the auditor has started asking about software that is no longer supported.

Then someone mentions the bank that moved all its customers to a new platform in one weekend and spent the rest of the year apologising for it. The room goes quiet. The item is carried forward to next year.

What We Found

Before we suggest anything to a lender, we study its sector. For this article we went through the public record of system replacements and IT enforcement in financial services in India and the UK: regulators’ notices, company statements and press reports from 2018 to 2026.

Four findings stand out.

The costliest moment is the attempt to replace the system. The daily running of an old system came second. In April 2018, TSB Bank in the UK moved its customers to a new IT platform, and the migration failed. The bank received 225,492 complaints. It paid £32.7 million in redress to customers. The regulators fined it £48.65 million, and found it had failed to manage its outsourcing arrangement with a critical supplier. It was December 2018 before the bank was back to business as usual.

Even a replacement that goes to plan has a cost. Fino Payments Bank reported “a temporary moderation in business volumes” in the quarter it changed its core banking system.

Standing still is no longer free. The RBI’s direction on IT governance, in force since April 2024, says regulated entities “shall avoid using outdated and unsupported hardware or software”. In the same month the RBI barred Kotak Mahindra Bank from taking new customers online and issuing new credit cards, citing its IT risk management. The restrictions lasted about ten months.

What has to be carried across is more than anyone can hold in their head. When one group of more than 40 credit unions had to replace a core system its vendor was retiring, the work meant rebuilding more than 200 screens and more than 500 interfaces to other systems.

The Gap, and What Waits Behind It

Almost every conversation about an old system is about risk. Our reading of the record is that risk is half the story. The other half is what the business cannot do while the decision waits.

Look at what the regulator stopped in the case above: new customers online and new credit cards. Both are growth. When an old system becomes a regulatory problem, growth is the first thing to be held back.

Two more signs point the same way. One industry survey published in September 2026 reported that 52% of financial institutions named legacy technology as an obstacle to modernising real-time payments (the survey did not state its sample size). An RBI survey of regulated entities found that 20.8% were using AI systems, while 67% said they were interested in exploring AI use cases.

This is our reading of the evidence. It is not a measured market figure.

Four Ways Forward, Weighed

A lender in this position has four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep the system and contain it	The system is stable, changes are rare, and it has a planned end date	The regulator’s direction on unsupported software. Skills keep leaving. Growth plans keep waiting
Buy a packaged product and move on one date	The need is standard and a product already covers it	Everything moves at once. Years of custom rules must fit the product or be dropped
Rebuild the whole system and switch over	The system is small and well documented	One date carries all the risk, and the new system is specified from memory
Replace it in stages, one module at a time	The system was built in-house and has been customised for years	Two systems run side by side for a time. The work takes longer on the calendar

Whichever option is chosen, the first step is the same: write down what the old system does, from the system itself and not from memory.

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own system, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
A written record of what the system does	The original specification, years out of date	Every function in scope has its own numbered line	The record is compared with the system
The largest single go-live	Every function and every customer, on one weekend	One module	The plan, stage by stage
The way back if a go-live fails	A second migration, done under pressure	The old system is still running, so a failed stage never reaches customers	Rehearsed before each stage
Evidence that new matches old	A test report against an incomplete list	Each old function linked to its replacement and compared	A traceability matrix for each module
The decision in front of the board	One large bet, deferred each year	One stage at a time, each approved on evidence	Board papers

The starting points above are what the public cases show and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a lender.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the system, the decision that keeps being deferred, and what it is holding up in the business. You leave with a short written note of what we found.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a written specification of what the system does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What changes for the business:

Role	What they gain
CEO	Growth plans that waited on the old system can move. The board approves one stage at a time.
CTO or CIO	A system the team can change quickly, on a technology people can be hired for.
CFO	Spend released stage by stage, with no single large commitment.
COO	The business runs throughout. Staff learn one change at a time.
Risk and compliance	A record at every stage to show the board, the auditor and the regulator.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
TSB Bank moved every customer in one weekend, and the migration failed.	We replace a system one module at a time while the old one keeps running. We never do a single cutover.
The regulators found TSB had not managed its critical supplier.	The client holds the specification, the risk register and a traceability matrix for each module, and accepts every module before it is billed.
Fino Payments Bank saw business volumes dip in the quarter it changed its core system.	Staff and customers meet one change at a time, not a whole new system on one day.
Kotak Mahindra Bank was restricted for about ten months over IT risk.	Our assessment shows a firm where its system stands, with a staged plan to act on. Taking that plan to the regulator is the firm’s own job.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The specification is yours to keep, whoever does the building.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →