Preparing your experience
Eleven migration waves over twenty-two months moved a 4.2 million customer book onto a modern core with no unplanned downtime and no customer-visible incident.
The bank ran a core platform first installed in the early 1990s. Product logic had accumulated in over eight thousand stored procedures, documentation covered perhaps a third of it, and the two engineers who understood the interest accrual engine were both within four years of retirement.
A previous attempt at replacement had been abandoned after eighteen months and a substantial write-off. The board’s appetite for a second big-bang programme was, understandably, zero.
Meanwhile the business needed instant payments, a product launch cycle measured in weeks rather than quarters, and an end to the nightly batch window that made 24×7 service impossible.
We proposed a progressive migration: the new core would run alongside the old one, taking ownership of one product family at a time, with continuous reconciliation between the two ledgers and a rollback that could be executed inside fifteen minutes.
The first six months built no customer-facing functionality at all. Instead we built the foundation — an event backbone capturing every posting from both cores, a reconciliation engine comparing balances position by position, and an integration layer that let channels talk to either core without knowing which held the account.
Migration then proceeded in eleven waves, beginning with current accounts for staff, then retail savings, then term deposits, then the lending book. Each wave ran in dual mode for a full month-end cycle before the legacy records were closed.
Payments were modernised in parallel, with an ISO 20022 hub supporting instant rails and inline sanctions screening — capability the legacy core could never have supported.
“The reconciliation engine was the thing that convinced our board. For the first time we could prove, every night, that both ledgers agreed to the last fils. After that, each wave stopped being a leap of faith.”
An agent-based claims pipeline reduced the average motor claim cycle from six days to four hours, with 58% of claims settling without adjuster intervention.
0 hrsAverage claim cycle, from 6 days
Read the case study
A sovereign cloud landing zone and shared service layer allowed forty citizen services to be delivered on common identity, payment and notification components.
0Citizen journeys on shared components
Read the case study
A template-based Oracle Fusion rollout consolidated four ERP systems across nine countries and cut the group close from nineteen days to four.
0 daysGroup close, from 19 days
Read the case studyWe will tell you honestly whether this approach transfers to your situation.