When the Maker Stops Fixing the Software

1. At a Glance

Issue study: a public case, not an IOanyT client. None of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	A group of more than 40 credit unions sharing one core system, set beside the RBI’s position on unsupported software and one Indian bank it restricted
Size band	The credit union group: 150 branches and 300,000 members. The Indian bank: large
Region	The credit union group: not stated in the source. The regulator and the bank: India
The decision at stake	What to do when the maker of a system sets the date its support ends
The public outcome	The shared core was retired on its vendor’s date, and the group rebuilt more than 200 screens and more than 500 interfaces. In India, the regulator now tells regulated entities to avoid unsupported software, and cited IT inventory when it restricted one bank for about ten months
Why it matters to a mid-size lender	Most lenders run something past its maker’s end date. The question is whether they leave on their own plan or on someone else’s

2. The Business Problem, in the Buyer’s Words

“Every year the same letter comes from the vendor, and every year we sign for extended support because it is smaller than the replacement quote. Then the auditor asks for a list of everything we run that is out of support, and three teams send three spreadsheets that do not agree. We know we have to leave. We just never have a plan we can put in front of the board.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between a date it does not control and a list it does not have. Staying looks cheaper every year, and leaving never gets a plan.

3. What We Found

Method. We went through the public record on unsupported software in financial services: the RBI’s direction on IT governance, its enforcement actions as reported in the press, a vendor’s published case study, makers’ published support dates and the US government’s list of flaws known to be exploited, from 2022 to 2026.

When the vendor sets the date. A group of more than 40 credit unions, with 150 branches and 300,000 members, shared one core system. It was “heavily customized”. Its vendor scheduled it to sunset in August 2024. The institutions did not choose the date and could not move it.

What	Figure
Institutions sharing the system	More than 40 credit unions
Their size	150 branches, 300,000 members
The system	”Heavily customized”, scheduled to sunset in August 2024
What the replacement rebuilt	More than 200 screens and more than 500 interfaces to other systems

What the regulator says. The RBI’s direction, in force since 1 April 2024, says regulated entities “shall avoid using outdated and unsupported hardware or software”. In April 2024 the RBI barred Kotak Mahindra Bank from taking new customers through its online and mobile channels and from issuing new credit cards. Among the areas it cited were IT inventory management and patch and change management. The restrictions lasted about ten months.

Dates are published, and extensions end too. Standard support for IBM i version 7.4 ended on 30 September 2026, with a paid extension to 30 September 2029. As of 11 October 2026, the US government’s list of flaws known to be exploited held 9 entries for Apache Struts and 13 for WebLogic Server, two building blocks under many business applications.

What open gaps cost: a background case. In June 2023 the RBI imposed a penalty of 65 lakh rupees on Andhra Pradesh Mahesh Co-operative Urban Bank, a mid-size Indian bank, finding that “the bank had failed to put in place certain mandated controls which led to the cyber security incident.”

Our reading of why firms stay past the date. These four are our reasoning from the cases above. None is a regulator’s finding.

1. Nobody has the list: there is no single record of what runs, the support date of each item and what depends on it.
2. Everything depends on everything: the application needs the old framework, which needs the old server, so moving one means moving several.
3. Nobody has a written record of what the system does, so leaving feels riskier than staying.
4. Staying looks cheaper this year, because one renewal is set against the whole cost of leaving.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Renew extended support each year	A firm date to leave already exists	The system stands still while renewals add up, and the option ends on the maker’s date	Right only as a bridge with an end date
Upgrade in place to the maker’s newer version	The application runs on the new version with small changes	Old applications need the old layers below them; the upgrade becomes a rebuild	Worth checking first; often not possible
Replace the whole system on one date	The system is small and well documented	One date carries all the risk, and the list of what runs is still missing	We would advise against this for an old, layered, customised system
Write down what runs, then leave in stages, most exposed parts first	The system was built around the business and customised for years	Several stages, and two systems side by side for a time	Our recommendation for the systems around the core

5. Our Recommendation, and the Decision It Asks of the Board

For the systems a lender has built around its core (loan origination, collections, agent and branch portals, reporting): first write down what runs, who still fixes it and what depends on it, then leave in stages, moving the most exposed parts first, while the old system keeps running. Use extended support, where it is offered, as a bridge with an end date.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
A record of what runs	Several spreadsheets that do not agree	One record of every application in scope and every layer under it	The record is compared with the servers, databases and code
Items past their maker’s support date	Not counted, or counted only when asked	Each one listed, with what depends on it	The risk register
A plan against each item	”Upgrade planned”	A stage, in order, against each item	The staged plan
Whose date the plan follows	The maker’s	The firm’s own, set before the maker’s	The staged plan
Accepted risks with an end date	None	Every one tied to the stage that removes it	The risk register beside the plan
The count over time	Rebuilt at each audit	Falling with each stage	Reported at every review

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the system, the maker’s dates, and what the auditor or regulator has asked. 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 study is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a map of the system as it stands, a written specification of what it 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.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology that is still supported. We never do a single cutover. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what runs, and what the system does, in writing and portable to any supplier.
• The risk register: the items past support and what depends on them, listed before any price is set.
• The traceability matrix: every old function linked to its replacement, with how it was checked.
• The code: the new modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not patch or upgrade old software in place, and does not sell extended support.
• IOanyT does not keep the old system protected while it waits to move, and does not supply security controls. The client’s current team or vendor does that.
• IOanyT does not implement packaged core banking products, and does not work on mainframe platforms.
• Taking a plan to the regulator is the firm’s own job. Our assessment gives it the evidence to do so.
• This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a bank.

10. Sources

Source	Used for
A vendor’s case study	The credit union group
RBI Master Direction	The rule on unsupported software
TechCrunch, 24 April 2024; News On AIR; RBI press release, 24 April 2024; RBI press release, 12 February 2025	Kotak Mahindra Bank restrictions, the areas cited and their end
endoflife.date, IBM i	IBM i 7.4 support dates
CISA catalogue	Exploited flaws in Apache Struts and WebLogic Server
RBI press release, 19 June 2023	The RBI’s penalty on Andhra Pradesh Mahesh Co-operative Urban Bank and its finding

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The maker sets its date; the plan for leaving can be yours.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →