Loading…
A 41-year-old mainframe core retired in favour of a cloud-native ledger and account engine — without a single minute of customer-visible downtime across 11M retail accounts.
“Two prior vendors had failed at this. Spalce treated the migration as a risk-management problem first and an engineering problem second. That is why it worked.”
A tier-1 European retail bank had been trying to retire its 41-year-old mainframe core for nine years. Two prior vendors had failed. We led a 22-month engagement that re-platformed the core onto a cloud-native ledger and account engine, ran the new and legacy systems in parallel for thirteen months with a continuous reconciliation harness, and executed the final cutover during a routine maintenance window with zero customer-visible downtime. The bank now runs its core on infrastructure it can change weekly rather than annually.
The bank's core was a 41-year-old IBM mainframe stack written largely in COBOL and PL/I. It held 11 million retail and small-business accounts and was the system of record for €240B in deposits. Two previous attempts to retire it — one with a global systems integrator, one with a packaged core-banking vendor — had ended in costly rollbacks. The board had told the CIO that there would not be a third attempt. The next attempt either succeeded or the strategy of cloud-native core banking would be abandoned for the rest of the decade.
The constraints were unforgiving. The new core had to handle every regulatory return the legacy system handled, including ECB stress-test data, with bit-exact equivalence. No more than fifteen minutes of customer-visible downtime was acceptable, and the regulator had to be persuaded that the migration was safe before it began, not after.
We treated this as a risk-management programme that happened to have an engineering substrate. The first six months were spent building a continuous reconciliation harness that read every transaction off the mainframe and replayed it into the new ledger, comparing balances at every boundary. The harness ran in shadow mode for nine months before any cutover decisions were taken. Regulators and internal risk committees received weekly variance reports, and the project's go-or-no-go criteria were defined by reconciliation metrics, not by feature completeness.
On the engineering side, the new core was built in Java on a Kubernetes platform we co-designed with the bank's platform team. The ledger was event-sourced, the account engine was strangler-fig migrated function by function, and every regulatory report was reproduced as a separate workstream with its own bit-exact equivalence test against the legacy output.
The cloud-native core consists of an event-sourced ledger, a domain-driven account engine, a regulatory reporting service, and a payments orchestration layer that integrates SEPA, TARGET2, and the bank's card schemes. The whole thing runs on Kubernetes across two European regions with active-active failover. The reconciliation harness — built originally as a migration tool — now runs in production as a continuous correctness check against shadow copies of every batch run.
“On the night of the cutover I went home at 11 pm. By 6 am the new core had cleared a full overnight batch with bit-exact regulatory output. That was the moment forty-one years of risk lifted.”
The final cutover happened during a routine Saturday-night maintenance window in month twenty-two. No customer-visible downtime occurred. By Monday morning the mainframe was running in shadow mode for a contractual six-week tail before final decommission. Every regulatory return for the subsequent quarter matched the legacy baseline to the cent. The bank now deploys to its core on a weekly cadence — a change measured against the legacy system's annual release cycle.
Regulated migrations succeed when reconciliation is the product. Every previous attempt at this programme had been organised around feature completion milestones; ours was organised around reconciliation variance trending to zero. That alignment of engineering work with risk-committee evidence is what made the eventual cutover decision feel anticlimactic rather than heroic. Heroic cutovers are how you end up as the third failed vendor.
Tech Stack
Services Engaged
Get the long-form case study including architecture diagrams, operating cadence, and the unabridged interviews.
Tell us a little about yourself and we'll send you the PDF.
Let's talk. We'll walk you through what an engagement looks like end to end.
Talk to our team