94% of core banking modernization programs run past their original timelines. Of course, that number is not an argument against modernizing. It only argues against the method most banks still reach for first. They build a new core in parallel, then switch everything over on one weekend.
The big-bang approach consolidates every risk in the program into one irreversible moment. For a CEO, CFO, or COO running a mid-size bank, that moment sits on top of customer trust, regulatory standing, and the ledger itself. A phased core banking replacement spreads the same work into small, recoverable steps. This is how it works, and where the money and risk actually sit.
This article lays out how phased core banking platform replacement works and where to start. It also shows how to keep the regulator comfortable while two systems of record run in parallel.
| Incremental approaches like the Strangler Fig pattern minimize disruptions during migration. |
| Composable architecture enables rapid product launches. |
| 64% of banks report slow digital transformation affects customer acquisition. |
| AI-driven modernization reduces human error in code transformation. |
Why big-bang core replacements keep failing
The reasons repeat across banks, and none of them are about the quality of the target platform.
Multi-year programs outlive their sponsors
Bain & Company puts the average traditional approach to a new core banking system at 4.7 years before it delivers a working product. A program that long has to survive budget cycles, a change of CFO or CIO, and shifting board priorities. All of that comes before it ships anything the business can use. Sponsors who approved the spend are often gone by go-live. Momentum decays with each leadership change. A program with no visible output for three or four years is the easiest line item to pause.
Undocumented business rules live only in the existing core systems
A legacy core banking system accumulates rules for decades, and many exist nowhere except in the code. The fee waiver for one customer segment, the interest logic that behaves differently in edge cases, the regulatory adjustment nobody remembers writing.
Joel Spolsky, the Stack Overflow co-founder, called the ground-up rewrite "the single worst strategic mistake that any software development company can make."
The reason applies directly to banking. Those convoluted branches are years of production fixes. Discard them in a rewrite, and you rediscover each one as an incident after cutover.
The cost of being wrong is the whole bank
In April 2018, TSB Bank moved 5.2 million customers to a new platform in a single event. Customers were locked out for days, full service was not restored until December, and the bank paid £32.7 million in customer redress. UK regulators later fined TSB £48.65 million for the planning and governance failures behind the cutover. A big-bang replacement has no graceful way to roll back once a hidden rule or a data fault surfaces mid-migration. The blast radius is every account, every payment, and every regulator watching.
What sits inside legacy systems
You cannot sequence a migration you do not understand, and the core is rarely one system.
Ledger, product engine, and the accretion around them
At the center sit two things. The general ledger records every debit and credit. The product engine defines how deposits, loans, and fees behave. Around that center, decades of additions pile up: reporting extracts, reconciliation jobs, and connections to card networks and payment rails. Some of it is custom code written for a product launched in 2006 and never retired. Mid-market banks typically run 50 to 150 active third-party connections into this estate, many of them undocumented. The ledger is small and stable. The accretion around it is where the real complexity and the compliance risk live.
Batch windows and why they constrain everything
Older cores post transactions in overnight batch runs rather than in real time. Interest accrues, statements generate, and balances settle inside a fixed nightly window. Everything downstream is timed against that window.
When a batch overruns, reporting slips and morning balances are wrong. This is also why legacy systems struggle with FedNow and RTP, which assume the real-time posting the batch model cannot produce. Any migration plan has to respect the batch window. The new core and the old one must agree on the same end-of-day state while they run side by side.
The progressive alternative: Strangle, don't replace
The pattern that consistently works is progressive replacement, and the mechanics are well established.
The strangler fig pattern applied to a banking core
The strangler fig pattern, named by Martin Fowler, wraps the legacy core in a modern routing layer. It rebuilds the core's functions one at a time behind that layer. Each rebuilt function takes live traffic while the old code for it is switched off, until the core has nothing left to do.
Fowler's warning about rewrites is worth keeping in view. Replacements "seem easy to specify," yet the existing behavior is the hard part to pin down. The strangler pattern in banking sidesteps that trap by moving proven behavior in scoped slices, rather than respecifying the whole core at once.
The coexistence layer as the real deliverable
The first thing a phased core banking replacement actually ships is not a new product. It is the coexistence layer that lets two cores run at once.
That layer has three jobs. It routes each request to whichever core owns that function. It reconciles transactions across both environments so balances agree. It keeps data synchronized through an initial load plus change data capture. Build this layer well, and every later slice becomes a controlled move. Build it in a hurry, alongside the first migration, and you pay later in extended dual-run periods and faults that surface after cutover.
| Approach | Typical timeline | Risk profile | Best suited to |
|---|---|---|---|
| Big-bang replacement | 3 to 5+ years to a single cutover | Highest, failure is systemic | Simple portfolios or a hard vendor sunset |
| Sidecar core | 18 to 36 months to first component | Lowest entry risk | New products, FedNow or RTP as first use case |
| Phased coexistence (dual-core) | 3 to 5 years for a full migration | Managed, failure stays local | Banks with complex connection estates |
| Wrapping and augmentation | 6 to 18 months | Low, but a bridge only | A stopgap, not a modernization endpoint |
Timeline ranges for phased and full-platform work follow EY's 2025 analysis of banking modernization programs.
Event streaming and keeping two systems of record honest
While both cores run, each holds state that must stay consistent. Event streaming solves this by capturing every state-changing event, an account opened, a payment posted, a rate changed, and routing it to both systems.
The new core builds its own record from that stream and proves it can keep pace before taking over as the source of truth. For high-correctness domains such as payments and the ledger, a parallel run adds a second check. Both cores process the same traffic, compare outputs, and only the trusted side's result counts until mismatches fall to near zero.
Sequencing: Which capability moves first
The order of migration decides how much risk you carry and how early the business sees a return.
Start where the business case is measurable
The first slice should pay for itself in a way the board can read on a page. A customer-facing portal, a reporting layer, or a single product line with a clear cost or revenue attached makes the case concrete. That first move also builds the muscles later waves depend on: the testing discipline, the deployment routine, the monitoring. Choosing a first slice with visible value keeps sponsorship stable through a program that will run for years.
Read paths before write paths
Move read paths before write paths. Serving a balance or a statement from the new core carries far less risk than posting a transaction to it. A bad read is visible and reversible, while a bad write corrupts the ledger. Standing up read traffic first lets the new core prove its data model against real queries with no risk to money movement. Write paths follow once the reads are trusted and reconciliation is clean.
Products with contained blast radius
Sequence products by how far a fault can spread. A closed savings product with a fixed rate and few connections is a contained first target. A demand deposit account wired into cards, payments, and overdraft touches everything and comes later.
Zions Bancorporation's 11-year program is the cautionary case here. The bank later acknowledged that deposits should have been migrated first but were left until last for organizational reasons, which stretched the timeline. Sequence by dependency and blast radius, not by internal convenience.
Keeping the regulator comfortable mid-migration
A bank running two cores is a bank under heightened supervisory attention. Plan for it from the first slice.
Reporting continuity across two systems
Regulatory reporting cannot pause because the data now lives in two places. During coexistence, statutory and management reports have to pull a single, correct view from both cores combined. That means the reconciliation layer feeds reporting as a first-class output, not an afterthought. Regulators expect the same numbers they saw last quarter, produced on the same schedule, regardless of which core now holds which product.
Reconciliation and parallel run evidence
Under OCC Bulletin 2025-24, effective January 1, 2026, an active core banking migration is a supervisory focus area in its own right. Examiners assess data migration integrity at each stage, not through a single attestation at cutover. Parallel run gives you that evidence directly. A documented mismatch rate between the two cores, trending to zero across a defined window, is the correctness evidence an examiner expects.
Audit trail requirements during coexistence
Every migration decision needs a record an examiner can follow. Which function moved, when, who approved it, what the rollback trigger was, and how correctness was verified. A coexistence period without a clean audit trail invites findings even when the migration itself is sound. Treat the trail as a program deliverable and keep it current in real time, rather than reconstructing it before an exam.
Data migration is a programme, not a step
Moving the data is the single most underestimated part of the work, and it earns its own plan.
Profiling before mapping
Profile the legacy data before mapping a single field. Two decades of accretion hide duplicate records, inconsistent formats, and orphaned references the old core tolerated, and the new one will reject. Discovering the true state of the data mid-migration, under deadline pressure, is where shortcuts get made, and defects get baked in. Profiling first turns unknowns into a scoped cleanup you can plan and cost.
Historical data: migrate, archive, or leave in place
Not all history belongs in the new core. Decide the fate of each data domain separately. Migrate the records live, archive them to a queryable store, or leave them in the legacy systems behind a read interface. Cross-era correctness is the hard part, making sure a transaction booked in 1999 still produces the right result under a 2026 schema. Moving less live data lowers risk, provided archived and retained records stay accessible for regulatory and customer inquiries.
Reconciliation tooling as a first-class deliverable
Reconciliation is not a spreadsheet exercise you run at the end. Build tooling that continuously compares balances and transaction histories across both cores. It flags divergence as an incident and produces the evidence trail reporting and examiners need. This tooling is as much a deliverable as any migrated product, and it stays in use for the full dual-run period.
Cutover, rollback, and what 'done' means
Each slice has its own cutover, and each cutover needs exit criteria written before the work starts. Those criteria are specific:
- the mismatch rate a parallel run must beat
- the error budget the new slice must hold
- the traffic ramp, from 1% of traffic to full
- who approves each step
- the exact rollback trigger and procedure
Rollback has to be tested, not theoretical, at every phase. "Done" is not the moment traffic moves. A slice is done only when the legacy code path is deleted, its tables are dropped, and its sync jobs are removed. EY's analysis found decommissioning routinely runs 12 to 24 months past original estimates. Every extra month of dual-run erodes the savings that justified the program. Retire the old, or the economics never arrive.
How Altamira approaches banking modernization
Altamira works alongside a bank's existing team on progressive core modernization. The sequence starts with discovery: extracting the business rules buried in the legacy core and mapping the connection estate before any code moves.
From there, the coexistence layer comes first, with routing, reconciliation, and data synchronization treated as the foundation the rest of the program stands on.
Slices are sequenced by measurable value and contained blast radius, with read paths ahead of write paths. Parallel-run evidence and a live audit trail are built for regulatory review from day one. The aim is a migration where the business runs better at each milestone and the regulator stays comfortable throughout.
Learn more about our legacy banking modernisation service.
A readiness checklist before the first migration wave
Before committing to a program, a bank should be able to answer these questions with evidence, not assumptions.
| Readiness dimension | Question to answer before wave one | Why it matters |
|---|---|---|
| System boundary | What functions and data does the core actually contain? | You cannot sequence what you have not mapped |
| Business rules | Which rules live only in code, and are they documented? | Unextracted rules become defects after cutover |
| Connection estate | How many third-party connections are active and documented? | Undocumented connections break during migration |
| Data quality | What is the true state of the data to be moved? | Profiling late forces shortcuts under pressure |
| Coexistence layer | Is routing, reconciliation, and sync designed and owned? | It is the first deliverable, not a mid-program add |
| Rollback | Is rollback tested at every planned phase? | Examiners assess tested capability, not intent |
| Decommissioning | Is legacy retirement funded with exit criteria? | Unretired legacy erases the savings case |
The final word
Mid-size banks face a challenging choice. Vendor consolidation, real-time payment expectations, and supervisory attention have closed off standing still.
IDC expects roughly 40% of banks to run a sidecar core by 2026, rising to 70 to 80% by 2028. That number tells you where the market has already landed.
The real choice relates to the right method. A phased core banking replacement lets a bank move on its own schedule. The bank shows progress at every milestone and keeps a rollback in hand at each step. Banks that treat modernization efforts as a multi-year capability, sequenced by value and blast radius, tend to compound the advantage. The ones that keep deferring usually meet the same work later, on a deadline, with far less room to move.
Frequently asked questions
What is core banking modernization?
Core banking modernization is the work of replacing or upgrading a bank's back-end systems: deposits, loans, payments, and the general ledger. The target is a modern, API-first, often cloud-based platform. For mid-size banks, it is the existing infrastructure decision that determines real-time payment capability, product speed, and long-term competitive position. It can be done progressively, rather than in one high-risk cutover.
Why do big-bang core banking replacements fail so often?
They concentrate every risk into one irreversible cutover. Undocumented business rules surface as incidents, historical data faults appear under deadline pressure, and there is no graceful rollback once problems emerge. IBM's Institute for Business Value reports that 94 percent of core banking programs exceed their original timelines. Multi-year programs also outlive the sponsors who approved them, losing momentum with each leadership change.
What is the strangler pattern in core banking migration?
The strangler pattern wraps the legacy core in a routing layer, then rebuilds its functions one at a time behind that layer. Each rebuilt function takes live traffic while the matching legacy code is switched off, until the old core has nothing left to do. Named by Martin Fowler, it turns one large bet into many small, recoverable ones. It is the leading alternative to a rewrite.
How can a bank run the old and new core in parallel?
It uses a coexistence layer that routes each request to whichever core owns the function. The layer also reconciles transactions so balances agree and synchronizes data with an initial load plus change data capture. Event streaming keeps both records consistent, and a parallel run compares outputs on high-correctness domains like payments and the ledger. The old core stays authoritative until the new one proves equivalent.
Which core banking transformation functions should be migrated first?
Start with read paths before write paths, because a bad read is visible and reversible while a bad write corrupts the ledger. Choose a first product with a measurable business case and a contained blast radius, such as a closed savings product with few connections. Leave demand deposit accounts wired into cards, payments, and overdraft until the pattern is proven and reconciliation is clean.
How long does a phased core banking migration take?
A targeted sidecar or single-domain move typically runs 18 to 36 months. A full-platform migration runs 3 to 5 years, per EY's 2025 analysis. The difference from a big-bang program is that value arrives from the first wave, rather than only at the end. Decommissioning often adds 12 to 24 months beyond original estimates, so fund and schedule it deliberately.
How do banks handle regulatory compliance during migration?
Reporting has to pull a single correct view from both cores while they coexist, on the same schedule regulators saw before. That makes the reconciliation layer a reporting source, not an afterthought. Under OCC Bulletin 2025-24, effective January 2026, examiners assess data migration integrity at each stage. Parallel-run evidence, with a mismatch rate trending to zero, becomes the proof of correctness they expect.
What belongs in the cutover and rollback plan?
Write the exit criteria before the wave starts. Cover the mismatch rate to beat, the error budget to hold, the traffic ramp, the approver at each step, and the rollback trigger. Rollback must be tested at each phase, not theoretical. A slice counts as done only when the legacy path is deleted and its data and sync jobs are removed.
How do you build the business case for phased modernization?
Anchor the first slice to a measurable outcome the board can read, such as a cost removed or revenue enabled. Show progress at every milestone rather than after years of silent build. Weigh it against the real cost of the legacy core: rising maintenance, scarce talent, a product tax, and a failed-program risk management. Visible, staged returns keep sponsorship funded.
