Core Banking Modernization: Why Rip and Replace Usually Fails
Big-bang core banking replacements have a poor track record for a reason — what the strangler pattern looks like applied to core banking, and where it still gets hard.
Core banking replacement projects have one of the worst track records in enterprise software — multi-year timelines, budgets that double, and a meaningful share that get cancelled before going live. The common thread in the failures we've studied and the ones we've been brought in to help recover isn't technology choice. It's the decision, usually made early and with good intentions, to replace the entire core system in one cutover rather than incrementally.
Why "rip and replace" is structurally risky, not just historically unlucky
A core banking system touches account management, transaction processing, interest calculation, regulatory reporting, and integrations with dozens of downstream systems — card processing, payments networks, fraud systems, statement generation. A big-bang replacement requires all of that to work correctly, simultaneously, on cutover day, tested against production-scale data and edge cases that only show up after years of real accounts accumulating unusual states.
The math on this is unforgiving:
- Edge case density compounds with account age. Accounts opened a decade ago under since-changed product rules, accounts with manual adjustments from long-resolved disputes, joint accounts with ownership changes — a big-bang cutover has to correctly handle all of this on day one, with no ability to fix issues gradually while most of the system stays on the known-working path.
- Regulatory reporting can't have a gap. Reports that feed into central bank submissions or anti-money-laundering monitoring can't go dark during a transition, which means the new system has to be fully validated against the old system's output before it's trusted, not validated after go-live when problems surface.
- Rollback is nearly impossible in practice. Once customer transactions have been processed on the new system for even a day, rolling back to the old system means reconciling that day's activity backward, which is often harder than the forward migration was.
The incremental alternative: strangle by product line or customer segment
The core banking modernizations that have actually succeeded in our experience follow a pattern closer to the strangler fig approach used in application architecture, applied at the business-capability level rather than the code level.
- Pick a low-risk product or segment first. A newly launched product with few existing accounts, or a small customer segment, lets the new core system prove itself against real transactions with a contained blast radius if something's wrong.
- Run old and new in parallel with a routing layer, deciding which accounts are served by which system, rather than migrating and cutting over simultaneously. This routing layer becomes one of the most important pieces of new infrastructure in the whole project, even though it doesn't appear on the original scope list.
- Migrate segment by segment, validating each wave against the previous system's historical output before moving to the next, so problems are caught and fixed at a scale of thousands of accounts, not millions.
This takes longer in calendar time than a planned big-bang cutover — often 18-36 months for a full migration rather than the 12 months a rip-and-replace plan might promise on paper. But the rip-and-replace plans rarely hit their 12-month promise anyway; the incremental approach's longer timeline is usually more honest, and it's a timeline the institution can actually survive if something goes wrong midway, because most of the business is still running on the proven system.
Where the routing layer gets genuinely hard
Account-level routing is straightforward when accounts are independent. It gets hard fast with joint accounts, linked accounts (a mortgage and the checking account it auto-debits from), and household-level product bundling — all common in retail banking. These relationships mean a segment boundary that looked clean on an org chart turns out to have dozens of edge-case links to accounts nominally in a different segment. We've found it's worth mapping these relationships explicitly before committing to a segmentation plan, rather than discovering the links mid-migration.
Data reconciliation is the unglamorous work that determines success
The single biggest predictor of a smooth core banking migration wave, in our experience, is the rigor of the reconciliation process run before and after each cutover — comparing transaction histories, balances, and interest calculations line by line between old and new systems for every migrated account, not a sample. This is unglamorous, high-volume validation work, and it's exactly the kind of work that gets under-resourced when a project is already behind schedule and pressure mounts to just cut over.
Institutions that get this right treat reconciliation tooling as a first-class deliverable of the migration project, built and tested before the first wave migrates, not assembled reactively after the first discrepancy is found in production. The ones that struggle tend to have built reconciliation as an afterthought, discovering gaps in their comparison logic at the same time they're discovering gaps in the migration itself.
Core banking modernization is one of the few domains where the boring, incremental path is genuinely the fast path, once you count the cost of a failed big-bang attempt. Institutions considering this kind of migration are usually better served starting with a segmentation and reconciliation strategy assessment before committing to any core system procurement — the vendor selection matters less than most RFPs assume if the migration approach underneath it is unsound.
Daniel Vu
Chief Technology Officer & Co-Founder
