// 28 August 2026

Modernise the Bank Without Betting the Bank

Every big-bang core replacement is the same wager: that years of undocumented behaviour can be rebuilt, migrated, and switched on over a single weekend, and that nothing important was missed. Banks that win this bet win nothing they couldn’t have had anyway. Banks that lose it make the news.

Ask a banking leader why the core hasn’t been modernised and the answer is rarely ignorance. Everyone knows the estate is old. The honest answer is fear, and the fear is rational: the industry’s most famous modernisation stories are the ones that went wrong.

The cautionary tale is well documented. When TSB moved 5.2 million customers onto a new platform in April 2018, the cutover happened in one go – and the disruption ran for months. Customers were locked out of their accounts, complaints passed 225,000, and the FCA and PRA eventually fined the bank £48.65 million for operational resilience failings, describing the impact as widespread and serious.

None of which makes modernisation optional. Platforms age past vendor support, change gets slower and dearer every year, and product launches queue behind systems nobody wants to touch. So the question worth asking is narrower than it looks: how do you modernise a bank’s estate without concentrating the risk of the whole programme into a single event?

The Big Bang Is the Riskiest Trade in Banking

A core replacement run as one programme with one cutover has a specific risk shape. Everything unknown in the old estate – the undocumented batch job, the reconciliation quirk someone patched in 2011, the interface only one supplier still understands – stays invisible until the weekend it all has to work. Testing helps, rehearsal helps more, and neither can enumerate behaviour nobody wrote down.

A big-bang cutover concentrates every unknown in the estate into a single weekend, which is exactly where a bank can least afford unknowns. And the programme wrapped around it has its own gravity: by the time doubts surface, the sunk cost is measured in years, so the cutover date hardens into a commitment nobody feels able to question.

Regulators Have Already Picked a Side

Since 31 March 2025, UK banks have been required to stay within the impact tolerances they set for their important business services – not to aim for them, to stay within them, severe-but-plausible scenarios included. The EU’s DORA regime has applied to financial entities since January 2025 and demands the same discipline in different words. A migration weekend is a severe-but-plausible scenario you schedule yourself.

The regulator’s question is no longer “did the migration work?” It is “show the evidence that the service stayed within tolerance while you changed it.” That standard is very hard to meet from inside a big bang, and close to routine in an approach that changes one thing at a time, keeps rollback live, and produces evidence at every step.

Strangle the Legacy, Don’t Swap It

The pattern that works in regulated estates is old, boring, and proven: carve capabilities out of the core one slice at a time. Map the important business services first. Take one capability – payments initiation, onboarding, a product engine – and route it through the new component while the legacy keeps running alongside. Dual-run until the numbers reconcile. Keep the switch-back live until the evidence says you no longer need it. Then retire that slice of the legacy for good, and take the next one.

Comparison diagram: a big-bang cutover lands every unknown in the estate on a single weekend, while slice-by-slice modernisation retires risk step by step with rollback kept live and value delivered per slice

The risk profile inverts. Instead of one event carrying every unknown, each step is small enough to test honestly, reverse quickly, and evidence properly. Each slice is a fixed-scope engagement that pays for itself – if the programme stopped tomorrow, everything already moved keeps working and keeps earning. Value arrives in weeks, and the board reviews results rather than forecasts.

The AI Lens Stops You Modernising Twice

There’s a newer reason to sequence the work this way. Most banks now carry AI ambitions – fraud models, credit decisioning, servicing copilots – and every one of them runs on the same foundations modernisation touches: data quality, integration, event flows, governance. A modernisation designed without asking what AI will need from the estate produces an estate that has to be reopened within a couple of years.

A modernisation sequenced without an AI lens is a modernisation you’ll do twice. The fix costs almost nothing at design time: score each slice for AI readiness as you carve it – is the data clean and reachable, are events exposed, is lineage recorded – so the estate you pay for once is the estate your models will need anyway.

Four-step order of work for modernising a bank once: map important business services, carve one capability out of the core, dual-run with daily reconciliation and live rollback, then retire the legacy slice - with an AI-readiness lens applied at every step

Q&A: Modernising Bank Systems

Why do big-bang core banking migrations fail?
Because the risk concentrates at a single cutover: every undocumented behaviour in the legacy estate has to be discovered, rebuilt, and proven over one weekend. Testing and rehearsal shorten the odds but can’t enumerate what nobody wrote down – and by cutover time the sunk cost makes delay feel impossible. TSB’s 2018 migration remains the textbook case: months of disruption, more than 225,000 complaints, and a £48.65 million fine.

What’s the alternative to replacing the core in one go?
Incremental modernisation, often called the strangler fig pattern. Map the important business services, carve one capability at a time out of the core, dual-run it against the legacy until the numbers reconcile, keep rollback live, then retire that slice and move to the next. Each step is small enough to test, reverse, and evidence, and each delivers value on its own.

What do regulators expect when a bank changes its systems?
Evidence that important business services stay within their impact tolerances while the change happens. The UK’s operational resilience regime has required exactly that since March 2025, and DORA applies the same discipline across the EU. A change approach that produces evidence at every step meets the standard by construction; a cliff-edge cutover has to hope.

Where does AI fit in bank modernisation?
On the same foundations. AI in banking depends on data quality, integration, and governance – the exact things modernisation touches. Scoring each modernisation slice for AI readiness while it’s being designed costs little and stops the estate being reopened for AI two years later.

Working Through This With Vertex Agility

Our Banking & FinTech capability is run by senior people who have done exactly this at some of the largest banks in the world – carving capabilities out of regulated estates without drama, under supervision, with the evidence trail regulators now expect. Engagements are fixed-scope and start with a capability review: weeks not months, your estate mapped against the questions above, a sequenced plan the board can fund one slice at a time, and an AI-readiness lens on everything as standard.

If you want the 15-minute version of the question a capability review answers properly, start with the free Future Readiness Audit – and if operational resilience is the sharper worry, the free Downtime Defence Audit runs the same way.