Almost every bank has now conceded the argument. The core is the constraint. Real-time payments, agile product launches, open banking APIs and a genuinely unified customer view all run into the same batch-oriented platform that was engineered decades ago for a different business. According to research by Thought Machine and IDC, 98 percent of banks are planning core modernization within the next three years.
What has not been settled is the shape of the program. Should the bank modernize incrementally, hollowing out the core one domain at a time while the legacy platform keeps running? Should it commit to full replacement, decommission the legacy core and migrate everything to a new platform? Or should it do both, running a phased migration toward a new core as the eventual end state?
This is a capital allocation and risk appetite question long before it is a technology question. Standing still is expensive: the same research projects that outdated systems will cost global banks more than $57 billion annually by 2028, up from $36.7 billion in 2022. But moving badly is worse. When TSB migrated customer data to a new platform in April 2018, the UK Financial Conduct Authority later recorded that every branch and a significant proportion of its 5.2 million customers were affected, that business as usual did not resume until December, and that TSB was fined £48.65 million.
So the executive question is narrower and harder than the one usually debated in steering committees. Not which platform, but how much of the institution to put at risk at any one moment, and what evidence the bank will accept before it moves the next tranche.
Core systems built for overnight batch processing have become a strategic liability. Thought Machine and IDC project that outdated systems will cost global banks over $57 billion a year by 2028, up from $36.7 billion in 2022, and 98 percent of banks intend to modernize within three years.
The real debate is sequencing. Incremental modernization lowers immediate risk and lengthens the timeline. Full replacement removes the legacy constraint outright but concentrates the risk into a single cutover with no margin for error. Most banks end up somewhere between the two.
The institutions that succeeded, among them Zions, RBC, JPMorgan Chase, TD and BMO, all proved capability somewhere small before scaling it. Sequencing discipline, not platform selection, is the decision that determines the outcome.
By the numbers
$57B
projected annual cost to global banks of outdated systems by 2028, up from $36.7 billion in 2022, with 98 percent of banks planning core modernization within three years
– Thought Machine and IDC
70%
of bank IT budget is consumed simply by maintaining technical debt, while software costs have grown around 8 percent a year since 2017, outpacing banking revenue growth
– Accenture Banking Top Trends, 2026
20-40%
of the value of the entire technology estate, before depreciation, is technical debt according to CIOs; the worst affected fifth of firms are 40 percent more likely to have incomplete or cancelled IT modernizations
– McKinsey, 2023
5.2M
TSB customers, and every branch, hit by the fallout from a single-event platform migration in April 2018; business as usual did not resume until December and regulators imposed a £48.65 million fine
– FCA and PRA, 2022
800B+
lines of COBOL are running on production systems in daily use worldwide, and 92 percent of surveyed organizations call their COBOL applications strategic
– Micro Focus / Vanson Bourne, 2022
3x
longer than initially expected, and over budget, for the Zions Bancorporation core transformation, a phased program that still ended in a full legacy retirement by mid-2024
– Zions Bancorporation FutureCore program, 2024
What Does Standing Still Actually Cost the Balance Sheet?
Most core modernization business cases open with capability: what the bank could launch if the platform allowed it. That framing loses budget arguments, because it competes against every other growth proposal. The stronger case is the one already sitting in the run-rate.
Accenture’s Banking Top Trends 2026 puts roughly 70 percent of bank IT budget into the maintenance of technical debt, with software costs growing around 8 percent a year since 2017, faster than banking revenue. That is not an engineering statistic. It is a statement about how much of the technology budget is already committed before a single strategic decision is taken.
McKinsey’s research on technical debt reaches the same place from the asset side. CIOs estimate that technical debt amounts to 20 to 40 percent of the value of their entire technology estate before depreciation, and companies in the bottom fifth for debt severity are 40 percent more likely to have incomplete or cancelled IT modernizations than those in the top fifth. Debt does not only cost money. It reduces the odds that the next modernization attempt finishes.
The Four Constraints Executives Actually Feel
Legacy cores fail in four recognizable ways, and each one shows up somewhere other than the IT budget.
| Legacy constraint | Where the business feels it |
|---|---|
| Slow processing, limited real time | Traditional cores rely on batch processing and update transactions in overnight cycles. Many older cores do not run in real time at all, which blocks genuine 24/7 instant services and participation in instant payment schemes. |
| Limited flexibility and agility | Monolithic architectures mean a new feature requires code changes in multiple places plus lengthy regression testing. Large banks have found that apparently simple offerings, such as a combined view of a customer’s accounts, required multi-year projects because the data sat in separate legacy systems. |
| Security and compliance risk | As systems age they become harder to secure. Legacy cores may carry outdated security protocols and were never designed to withstand modern cyber threats. A breach of the core could compromise millions of accounts, and regulatory change lands faster than release cycles absorb it. |
| Operational cost and technical debt | Mainframes demand specialist skills and proprietary support contracts. Years of layered patches accumulate into a technical debt load that drains the IT budget and, with COBOL engineers retiring, concentrates knowledge in fewer and more expensive hands. |
The scale of the estate is easy to underestimate. Independent research conducted by Vanson Bourne for Micro Focus found more than 800 billion lines of COBOL running on production systems in daily use, with 92 percent of respondents describing their COBOL applications as strategic. These are not abandoned systems waiting to be switched off. They are load-bearing assets that the business still depends on, which is precisely why replacing them is difficult.
Incremental or Big Bang: Which Pathway Fits Your Institution?
There are two honest pathways and one pragmatic blend. Incremental, or phased, modernization keeps the existing core running while components are replaced or upgraded around it, with old and new coexisting until migration completes. Full replacement, the big bang, decommissions the legacy core and migrates every account and product to a new platform in one project or a tightly compressed sequence.
Both are defensible. They fail differently, and that difference is the whole decision.
| Incremental (phased) modernization | Full replacement (big bang) |
|---|---|
| Risk. Drastically lower immediate risk. Modernization happens in manageable segments, reducing the likelihood of system-wide failure. | Risk. Extremely high and concentrated. Often compared to open-heart surgery because of the potential for catastrophic failure during cutover. |
| Customer impact. Minimal downtime. Core systems stay operational throughout, so service levels hold while the estate changes underneath. | Customer impact. No margin for error. Any misstep in migration or configuration can produce severe outages or data integrity issues. |
| Timeline. Long. Programs commonly run several years, increasing exposure to evolving technology risk and shifting business priorities. | Timeline. Short in theory, but preceded by intensive planning and frequently subject to documented time and budget overruns. |
| Architecture. Temporary complexity. Running old and new in parallel adds integration overhead, duplicated processes and dual-run reconciliation. | Architecture. A clean slate. Legacy constraints are eliminated and business processes can be redesigned from the ground up. |
| Capability. Value arrives in increments. Each tranche delivers something before the program ends, which sustains funding and patience. | Capability. Immediate next-generation capability once live: real-time processing, agile product development and seamless API connectivity. |
| Cost. Carrying cost is higher for longer, because the bank funds two estates and the people who understand both. | Cost. Larger long-term savings once legacy systems and support contracts are decommissioned and IT teams stop patching legacy code. |
| Failure mode. Fatigue. The program loses sponsorship, stalls halfway, and the bank ends up permanently running two cores. | Failure mode. Cutover. Everything works in rehearsal and then does not work on the night, in front of every customer at once. |
Incremental modernization also carries an operational advantage that rarely makes the slide: fail-fast capability. Problems are isolated and fixed inside one tranche without touching the rest of the estate. Big bang offers no equivalent. The TSB experience is instructive because it was not a technology failure in isolation: the FCA found the firm failed to plan the migration properly and that project governance was insufficiently robust.
The Third Path: Hybrid and Greenfield
In practice the lines blur. Many banks adopt a hybrid strategy, running a multi-year phased migration while holding a completely new core as the eventual target state. Greenfield strategies suit digital banks and smaller players without a heavy legacy estate, and they also serve larger institutions as a proving ground: stand up the new platform somewhere with no legacy integration burden, learn on real customers at contained scale, then migrate the main estate with evidence rather than optimism.
How Should Your Institution Choose? Apply Five Tests
The pathway decision is usually presented as a matter of ambition. It is better treated as a matter of tolerance. Five tests, answered honestly by the executive committee rather than by the program team, will point most institutions to the right answer.
| Test | How to read the answer |
|---|---|
| 1. Blast radius. If the cutover fails at 2am, how many customers lose access, and for how long before the fallback is proven? | If the answer is millions of customers and an unrehearsed fallback, the institution is not choosing between pathways. It is choosing incremental, and the only question left is the sequence of tranches. |
| 2. Data confidence. Can the bank reconcile balances between old and new to a tolerance the CFO and the regulator would both sign? | If reconciliation variance cannot be measured today, no migration date should be set. Data quality is what most often turns a phased plan into a stalled one. |
| 3. Knowledge coverage. Is the business logic in the core documented, or does it live with a shrinking group of engineers? | Undocumented logic favours incremental modernization with an API layer first. The bank must rediscover its own rules before it can safely re-implement them elsewhere. |
| 4. Sponsorship horizon. Will the current sponsor and funding model survive a program longer than a strategic plan cycle? | Phased programs die of sponsorship fatigue more often than technical failure. If the horizon is short, sequence tranches so each delivers a visible business outcome. |
| 5. Competitive clock. Is the bank losing propositions to challengers now, or protecting a stable book? | Acute competitive pressure justifies a greenfield proposition alongside the phased plan. It rarely justifies compressing the migration of the existing book. |
Read the five together. A bank with contained blast radius, strong reconciliation, documented logic and a durable sponsor can genuinely consider full replacement. A bank that fails two or more should treat big bang as an outcome to arrive at over time, not a project to start.
Choose the pathway that matches your evidence, not the one that matches your ambition.
Every modernization approach eventually asks the same question: can the bank prove that the new system does what the old one did, for every product, every edge case and every regulatory report? Incremental modernization asks that question many times at small scale. Full replacement asks it once at total scale.
Institutions that cannot answer it at small scale have no business attempting it at total scale.
What Five Banks Learned Doing This for Real
The public record of North American core programs is more useful than any vendor comparison, because it shows what the pathways cost in practice.
Zions Bancorporation: a decade of phased discipline
Zions Bancorporation, a US regional bank with more than $90 billion in assets, spent over ten years transforming its core. Discussions began in 2011. The FutureCore initiative ran on TCS BaNCS in three phases: consumer loans in 2017, commercial loans in 2019, deposits in 2023. By mid-2024 Zions had retired its legacy cores. The program took roughly three times longer than expected and went over budget. It also worked. Zions ran old and new in parallel, migrated branch by branch, and added a year for API integration before the final deposit conversion.
RBC: build and partner rather than replace
Around the mid-2010s Royal Bank of Canada explored a full core replacement, with Temenos T24 reportedly under consideration. That project did not proceed to completion, a reminder that deep pockets do not make big bang replacements less daunting. RBC moved instead to a build and partner approach, selecting Infosys Finacle for core banking and Volante’s VolPay for payments while building other components internally. The bank’s own framing was that it had to fundamentally change its way of working to address technical debt, having found that several different platforms across the business created inconsistent experiences and slow delivery.
JPMorgan Chase: greenfield first, then migrate
In 2021 JPMorgan Chase announced plans to replace its US retail core with Thought Machine’s cloud-native Vault platform, moving away from a legacy, siloed system toward a more fluid universal platform where products run in real time on a single system. The sequencing is the lesson. JPMorgan had already launched Chase UK on Vault in 2021, testing the core in a greenfield environment with no legacy integration burden. Having proved the platform there, it extended the decision to the much harder US estate.
TD and BMO: modernize the layer the customer touches
TD Bank faced mobile-first expectations while the legacy core stayed unchanged, and modernized the digital and mobile layers first using Azure cloud services, containerized APIs and API management alongside a mobile app refresh. That strengthened the digital brand and laid foundations for eventual core work. BMO confronted fragmented legacy systems with product duplication across business lines, and adopted a hybrid approach integrating new digital services through backend API orchestration on Google Cloud with Apigee API Gateway and SAP, improving developer velocity, time to market and real-time reporting readiness.
| Institution | The transferable lesson |
|---|---|
| Zions Bancorporation | Phased migration works, and it takes longer than the plan says. Budget for the overrun explicitly and migrate branch by branch rather than by calendar. |
| Royal Bank of Canada | Abandoning a full replacement is not a failure. API-led integration can deliver the customer outcome the replacement was meant to deliver. |
| JPMorgan Chase | Prove the platform where the stakes are lowest. A greenfield bank is the cheapest possible rehearsal for a core migration. |
| TD Bank | Modernizing the experience layer buys time and credibility, provided leadership stays honest that the core problem remains unsolved. |
| Bank of Montreal | API orchestration across fragmented systems can deliver omnichannel onboarding and real-time reporting before any core replacement decision is made. |
One pattern runs through all five. None of these institutions bet the bank on a single event. Each found a way to buy evidence before it bought commitment.
Seven Steps That De-Risk the Execution
Whichever pathway the bank chooses, the execution sequence is broadly the same. What changes is how many tranches there are and how long the bank runs in parallel.
- Assess and segment legacy workloads. Classify by regulatory criticality, coupling to other systems and MIPS consumption. That segmentation, not organizational convenience, sets the migration order.
- Establish a secure cloud landing zone. Build the target environment with compliance baked in, covering PCI-DSS, SOC 2 and supervisory expectations, before any workload moves.
- Build API layers around legacy systems. Wrap core services so real-time access is possible without rewriting the core. This step delivers customer-visible value earliest and buys the program its sponsorship.
- Migrate low-risk batch jobs first. Use them to validate performance, benchmark cost in the new environment and test integration patterns where failure is recoverable.
- Convert and refactor high-value code. Transform legacy code into portable microservices, prioritizing the logic that constrains product launches rather than the code that is simply old.
- Execute incremental switchover by tranches. Go live by product line, geography or customer segment. Run dual systems and validate each tranche before starting the next.
- Retire the mainframe and reinvest the savings. Decommission infrastructure and support contracts, and redirect the recovered run-rate into customer experience rather than back into the general IT budget.
The Vendor Landscape Is No Longer a Two-Horse Race
Four platforms dominate the conversation, and each maps to a different pathway. Temenos offers cloud-deployed cores with co-existence support that suits phased migration. Finxact, now part of Fiserv, provides API-first, real-time architecture enabling parallel deployment and new product launches while the old system still runs. Mambu delivers SaaS-based composable banking on open APIs, popular with challengers and increasingly with incumbents. Thought Machine’s Vault is fully cloud-native and uses smart contracts for flexible product configuration, which is what attracted JPMorgan Chase.
Platform selection matters less than most steering committees assume. All four can support a modern bank. None of them will rescue a program with unclear sequencing, weak data reconciliation or an absent sponsor.
The most common failure in core modernization is not choosing the wrong pathway. It is choosing a pathway and then funding it as though it were the other one.
Incremental programs get budgeted like big bang programs, with a fixed end date and a single business case, and then die when the third tranche slips. Big bang programs get governed like incremental ones, with a tolerance for slippage that a single cutover cannot absorb. Funding model, governance cadence and pathway have to agree.
ML arteka works with banks to align those three before the first workload moves, because the sequencing decision is far cheaper to correct on paper than in production.
How Do You Prove the Program Is Actually Working?
A multi-year core program will outlast at least one budget cycle and possibly one executive team. It survives on evidence. Five practices separate programs that report progress from programs that can prove it.
- Establish strong leadership and governance. A board-level steering committee with IT, risk, operations and customer experience represented, meeting on a cadence that matches the tranche schedule rather than the reporting calendar.
- Enforce data migration discipline. At least two full rehearsal cycles before any tranche goes live, with structured mapping and validation, and a hard reconciliation variance limit during dual runs.
- Set incremental KPI targets. Publish migration milestones in advance and report against them, alongside error rates, performance and availability.
- Design for operational resilience. Target zero customer-visible downtime with active-active multi-region deployment, so a tranche failure degrades rather than stops service.
- Maintain rigorous security controls. Encryption at rest and in transit, quarterly penetration testing, and demonstrable compliance with FFIEC, OSFI and PCI-DSS v4.
The milestone targets below are the ones a phased program should be prepared to publish to its board at the outset.
| Milestone | Target to commit to |
|---|---|
| Year 2 | 20 percent of core transactions migrated to the new stack |
| Year 4 | 50 percent migrated and carrying live customer traffic |
| Every dual-run period | Reconciliation variance of 0.01 percent or less |
| Every tranche | Two or more full rehearsal cycles completed before go-live |
| Every release | Zero customer-visible downtime, validated by active-active failover |
Report these to the risk committee, not only to the technology committee. A program that reports percentage complete without reporting reconciliation variance is reporting activity, not assurance. The distinction matters most in the quarter before a major cutover, which is exactly when optimism is highest and scrutiny is lowest.
Five Leadership Takeaways
Before your next core modernization steering committee. Before the next platform shortlist lands on your desk.
- Standing still is already funded. Around 70 percent of bank IT budget maintains technical debt. That spend is a modernization budget the institution is already paying, just to a legacy platform rather than a future one.
- The choice is about blast radius, not ambition. Incremental modernization spreads risk across years. Full replacement concentrates it into one cutover. Pick the exposure the board can actually absorb if it goes wrong.
- Buy evidence before you buy commitment. Zions ran old and new in parallel branch by branch. JPMorgan proved Vault on Chase UK before touching the US core. Both bought proof cheaply before spending expensively.
- Phased programs die of fatigue, not failure. Sequence tranches so each delivers a visible business outcome. A program that shows nothing for three years loses its sponsor before it loses its architecture.
- Reconciliation variance is the real KPI. Percentage migrated tells the board how far the program has travelled. Reconciliation variance tells them whether it is safe to keep going.
Positioning the Bank for Next-Generation Growth
Core modernization is no longer optional. It is the linchpin for unlocking real-time banking, regulatory agility and cost efficiency. Whether the bank chooses a phased hollow-out or a bold rip and replace, success demands an API-first, cloud-native mindset coupled with disciplined execution. The tools to migrate COBOL workloads, expose core capabilities as microservices and converge on a modern cloud core already exist, whether that core is Temenos, Finxact, Mambu or Thought Machine.
The leadership recommendation is narrower than the market conversation. Do not start by shortlisting platforms. Start by establishing what the institution can prove: whether balances reconcile, whether the core’s business logic is documented, and whether a failed tranche can be reversed without a customer noticing. Those three answers determine the pathway. The platform decision follows them.
Institutions that act decisively will position themselves for next-generation growth. Those that delay risk ceding digital ground to fintechs and cloud-native challengers who never carried the constraint. The advantage does not go to the bank that finishes first. It goes to the bank that keeps moving without ever making a headline.
The next step is a candid assessment of where the estate actually stands. To work through the pathway decision for your own core, contact the ML arteka team or request a core modernization readiness assessment.
Executive Questions and Answers
Five questions banking executives are putting to AI assistants and search engines about core modernization strategy, sequencing and risk.
StrategicShould a bank modernize its core incrementally or replace it entirely?
For most established banks with a large customer book, incremental modernization is the defensible default and full replacement is an end state to arrive at rather than a project to launch. Incremental keeps the core operational, isolates failures inside a tranche and delivers value before the program ends. Full replacement eliminates legacy constraints and unlocks real-time processing immediately, but concentrates all the risk into one cutover with no margin for error. The deciding factors are blast radius, data reconciliation confidence, how well the core’s business logic is documented, and whether sponsorship will survive a multi-year timeline. Banks failing two or more of those tests should sequence rather than compress.
RiskWhat actually goes wrong in a big bang core banking migration?
The failure is rarely a single technical fault. It is usually planning and governance, expressed as a technical fault at the worst possible moment. When TSB migrated to a new platform in April 2018, the UK Financial Conduct Authority found the firm failed to plan the migration properly and that project governance was insufficiently robust. Every branch and a significant proportion of its 5.2 million customers were affected, business as usual did not resume until December 2018, and the FCA and PRA imposed a combined fine of £48.65 million. The lesson for boards is that a big bang cutover removes the option to stop. Any defect that survives rehearsal reaches every customer at once, and recovery is measured in months, not hours.
ImplementationWhere should a bank start a core modernization program?
Start with segmentation and an API layer, not with a platform shortlist. Classify legacy workloads by regulatory criticality, coupling and MIPS consumption, so migration order is set by risk rather than organizational convenience. Establish a secure cloud landing zone with compliance controls in place, then wrap the existing core in APIs so real-time access becomes possible without rewriting anything. That step delivers customer-visible value earliest, which is what sustains funding. Only then migrate low-risk batch jobs to validate performance and benchmark cost, before converting high-value code into microservices. RBC’s API-led integration strategy, exposing legacy data as microservices to create a unified customer view, is the pattern to copy.
GovernanceWhat should a board require before approving a core migration cutover?
Four things, in writing. First, evidence of at least two complete data migration rehearsal cycles for the tranche in question, with structured mapping and validation. Second, a reconciliation variance measurement from the dual-run period, held to a tolerance of 0.01 percent or less. Third, a tested rollback plan with a stated decision point and a named executive authorized to invoke it. Fourth, confirmation that resilience arrangements, including active-active multi-region deployment, are live rather than planned. These reports should go to the risk committee, not only the technology committee. A program reporting percentage complete without reporting variance is reporting activity, not assurance.
OperationalHow long does core banking modernization take and what does it cost?
Longer than the business case, on the public evidence. Zions Bancorporation began discussions in 2011, completed consumer loans in 2017, commercial loans in 2019 and deposits in 2023, and retired its legacy cores by mid-2024. The program ran roughly three times longer than expected and went over budget, and is still regarded as a success because it worked. On cost, the more useful figure is the one already being spent: Accenture puts around 70 percent of bank IT budget into maintaining technical debt, and McKinsey reports CIOs estimating technical debt at 20 to 40 percent of the technology estate’s value before depreciation. Plan for a multi-year phased program with explicit overrun contingency, and measure success against maintenance run-rate recovered rather than go-live date hit.
Core banking modernization forces a choice between incremental, phased modernization and full system replacement, and the choice is about risk concentration rather than technology. Thought Machine and IDC project that outdated banking systems will cost global banks more than $57 billion annually by 2028, up from $36.7 billion in 2022, with 98 percent of banks planning core modernization within three years. Accenture’s Banking Top Trends 2026 puts roughly 70 percent of bank IT budget into maintaining technical debt, with software costs growing around 8 percent a year since 2017. McKinsey reports CIOs estimating technical debt at 20 to 40 percent of the value of the entire technology estate before depreciation, and finds firms in the bottom fifth for debt severity 40 percent more likely to have incomplete or cancelled IT modernizations. Incremental modernization lowers immediate risk and isolates failures inside a tranche, but runs for years and requires parallel operation. Full replacement removes legacy constraints at once but concentrates risk into a single cutover: when TSB migrated in April 2018, the FCA recorded that every branch and a significant proportion of its 5.2 million customers were affected, business as usual did not resume until December, and regulators fined the bank £48.65 million. Zions Bancorporation, RBC, JPMorgan Chase, TD and BMO each proved capability at contained scale first, using phased tranches, API-led integration or greenfield pilots.