Core banking migrations have a reputation problem, and the reputation is earned. The industry's folklore is full of multi-year programs that ended in postponed cutovers, weekend war rooms and, occasionally, front-page outages. Yet the conclusion many banks draw — never touch the core — is exactly wrong. The right conclusion is: never migrate everything at once.
Why big-bang fails
A big-bang cutover assumes you can freeze a living bank, copy it perfectly, and unfreeze it on a new platform over a weekend. Each assumption fails independently: the freeze never holds, the copy is never perfect, and the rollback plan is never truly rehearsed. The risk compounds multiplicatively with scope — which is why the only reliable lever is to shrink the scope of each step.
The strangler pattern, applied to banking
The alternative is incremental: stand the new core up beside the old one, move one domain at a time, and let the legacy system shrink until switching it off is an administrative act rather than a leap of faith. For this to work, the receiving platform must be genuinely modular — each module independently deployable and able to interoperate with a legacy estate. That is a structural property of KORE's architecture, not a project technique.
A typical sequence: customers first (the customer master is the least transactional, most valuable domain), then accounts, then payments, then products — deposits, financing, cards — in the order your business dictates. Each step delivers standalone value: a unified customer 360, real-time account truth, instant payments — before the next step begins.
The unit of migration is the module, not the bank. Every step should be small enough to rehearse, verify and — if needed — reverse.
What the first 90 days look like
Days 1–15: sandbox and mapping
Stand up a sandbox and walk your real journeys on it. Map your product catalog, fee structures and approval policies onto platform configuration. Identify the first module and the integration points with the legacy estate. Output: a module map and a scoped plan.
Days 15–60: configure and integrate
Configure the first module — products, fees, limits as data. Wire it to your channels through the typed SDK. Run the data migration for that domain only, with reconciliation reports proving the copy. Stand up the audit chain in your tenant and validate it end to end.
Days 60–90: parallel-run and go live
Run the module in parallel against the legacy system, compare outcomes daily, then cut traffic over progressively. Go-live is boring by design — the system has been running for weeks; only the routing changes. Output: one production module live, evidence in hand, and a roadmap for modules 2–N. The full path is described on how it works.
Three habits that keep it safe
- Configuration over code. Products, fees, limits and approvals should be data on the new platform — every line of custom migration code is risk you keep paying for.
- Evidence over confidence. Reconciliation and audit-chain validation at every step — the platform should prove the migration, not the program manager.
- Commercials that follow scope. Pay for the modules you've adopted, not the platform you might someday use. See how KORE prices this.
Ninety days will not migrate a tier-1 bank. It will do something more valuable: prove, on one production module, that the next decade's core works in your environment — and turn the remaining migration from a bet into a schedule.