Know Which Part Gives Way First, and Move It Before the Next Peak

The board has asked for options after the last outage. The technology head brings two.

The first is to replace the whole platform. It would take years, the quote is very large, and nobody in the room wants to own the risk.

The second is to buy more hardware. It was also the answer last year. The outage happened anyway.

The board approves the hardware, because the other choice is too big to make in one meeting.

What We Found

We looked at what the public record says about the cost of repeated outages, and at how firms usually decide what to do after one.

The cost of the next outage is real, and only part of it is counted. In the January and February 2025 outages at a UK bank, which fell on payday, “56% of online payments” failed “over a three-day period”. The bank expects to pay “between £5 million and £7.5 million in compensation”.

Repeated outages can cost growth itself. On 24 April 2024 the RBI barred Kotak Mahindra Bank from taking new customers online and issuing new credit cards for about ten months, citing “frequent and significant outages” among its reasons. In an older case, after two years of outages at HDFC Bank, the RBI ordered it on 2 December 2020 to stop new digital launches and stop sourcing new credit card customers.

The choice after an outage is usually framed as everything or nothing much. This is our reasoning. The system was built, bought and budgeted as one application, so it is assumed it must be kept or replaced as one. More hardware helps only if hardware was the limit. A full replacement cures far more than is failing. And the price of the next outage, in compensation and in growth, is rarely on the page beside them.

What Moving One Part Opens Up

Our reading is that the third option changes more than the size of the bill.

• The firm can say yes to volume. A partner or a product that would add load is no longer turned down because the system could not carry it.
• Spending starts to improve something. Money that went on hardware every year goes on removing a limit once.
• The board sees a direction. An incident record with fewer repeats at each review reports progress, not just recovery.

This is our reading. It is not a measured market figure.

Three Ways to Spend After an Outage, Weighed

Option	When it fits	What it risks
Add hardware and monitoring	The servers really are the limit	When the limit is one table, queue or job, the same part gives way at a slightly higher load next time
Replace the whole platform	The system is small, or failing everywhere	Years of work and risk for functions that were never failing, and the large option often never starts
Find the part that gives way first, and move it first	A few parts of an old system fail under load	The new part and the old system must exchange data, and that join must be built with care. A second weak part will follow the first

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Peak-day incidents with a root cause	”Under investigation”, then closed	Every one with a cause, traced to a part of the system	The incident record beside the map of the system
The part known to fail first	Found on the day it fails	Named, with what depends on it, and first in the staged plan	The risk register and the staged plan
Recovery rehearsed before each peak	Staff on standby, nothing rehearsed	Rehearsed by the firm’s own team before each peak, until the weak part has moved	The firm’s rehearsal record
The moved module tested at peak volume	Not tested before customers use it	Tested at the volume of the busiest day before it is accepted	The acceptance record for each module
Repeat incidents	The same weakness under a new name	None from a part that has moved	Reported at every review

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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.

A small part of the finished benchmark might look like this.

Weak part	Stage that moves it	Status
The collections posting table, shared by month-end jobs	Stage 1: collections module	Moved; tested at month-end volume before acceptance
The overnight interest run	Stage 2: interest module	Rehearsed before each peak; moves at stage 2
The report queue	Stage 3: reporting module	Named; moves at stage 3

The rows above are an illustration, not taken from a real system.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the system, the options the board has been offered and the last peak days. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
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, starting with the part that gives way first. 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 above. As each module is accepted 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.

We have scaled a system before: in a cloud migration for an e-commerce client outside financial services, capacity went from 300 to more than 30,000 concurrent users. That client is not a bank, and we do not present it as one.

This has a price. The join between the new part and the old system must be built with care, the weak part must be protected through each peak until it moves, and a second weak part will follow the first. The work is real. It is also the size of the problem.

At the end you hold three things: the specification, the matrix, and a benchmark with every moved part dated.

What changes for the business:

Role	What they gain
CEO	The firm can say yes to products and partners that add volume.
CTO or CIO	The part that broke can now grow with demand, and the rest of the system is left alone.
CFO	A bounded piece of work with a price, in place of yearly hardware or a quote for the whole platform.
COO	Collections and disbursals keep moving at month end.
Risk and compliance	Fewer incidents to report, and a specific action to point to behind the improvement.

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

The case	What IOanyT does
A UK bank expects to pay £5 million to £7.5 million in compensation after outages that fell on payday.	Our part is narrower. We do not work on mainframes. For the systems a firm builds around its core, we move the part that gives way first, one module at a time.
The RBI restricted Kotak Mahindra Bank and, in an older case, HDFC Bank after repeated outages.	Our staged plan names the weak parts and the order to move them, and the benchmark shows progress at each review. Taking a 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 next time the board asks for options, one of them is the size of the problem.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →