Core Banking Modernization: What Engineering Leaders Wish They Had Known Before Starting

IBM's Institute for Business Value put a number to what most engineering leaders already know from experience: 94% of core banking modernization projects exceed their original timelines. This study reflects the gap between what organizations understand when they start and what they discover once the program is underway.

This post is about the strategic and operational decisions made in the first 90 days that determine whether a program runs for three years or seven, whether it delivers the business case that justified it, and whether the engineering team comes out the other end with a system that actually works the way the business needs it to.

These are the things that consistently surface too late. They are identifiable before the program begins (if the right work is done first).

Why This Is the Decade of Core Banking Decisions

As of 2025, 98% of banks were planning to upgrade their core banking systems within three years. The drivers are not new — legacy maintenance consumes 15–20% of annual IT budgets, COBOL skills are retiring faster than they are being replaced, and fintech competitors unburdened by legacy infrastructure are growing at 85–100% CAGR versus the 10–15% typical of incumbents. The imperative has been clear for a decade. What changed is that the cost of not acting has become more visible than the cost of acting.

The industry has also largely settled on the right approach. IDC projects that 40% of global banks will pursue sidecar modernization strategies by 2026, rising to 70–80% by 2028. The sidecar model (running a modern core in parallel with the legacy system, handling a defined subset of customers or products first) has replaced big bang replacement as the industry standard because it compresses risk and allows course correction between phases. The Commonwealth Bank of Australia's billion-dollar, five-year big bang replacement and the German banks that abandoned comprehensive replacement programs after years of sunk cost are the cautionary case studies. The industry learned from them.

Knowing the right approach, however, is not the same as executing it correctly. The 94% statistic suggests the gap is in execution, not strategy. Here is where that gap consistently shows up.

What Most Programs Learn Too Late

The following patterns appear consistently in post-program retrospectives. None are surprising in hindsight. Most are avoidable if the right questions are asked before the vendor is selected and the program is scoped.

The Sequencing Decision That Determines Everything Else

Of the decisions made early in a core modernization program, sequencing has the largest downstream impact. Zions Bancorporation's migration to TCS BaNCS is the US mid-market benchmark: an 11-year program that consolidated six operating environments onto a single platform and rationalized approximately 500 deposit products to roughly 100. The outcome was significant — Zions deployed PPP loans in three days at the onset of the pandemic. The sequencing lesson is what matters most for programs starting today.

The programs that perform best against their original timeline share a structural characteristic: they build the abstraction layer before they migrate the core. The abstraction layer isolates the rest of the technology stack from the core migration — downstream systems connect to one stable interface, and the core changes beneath it. This adds work at the beginning. It removes a category of risk that otherwise shows up as cascading integration failures in the middle of the program, when they are most expensive to resolve.

The programs that consistently exceed timelines by the largest margins are the ones that try to migrate the core and update all dependent integrations simultaneously. What looks like parallel efficiency on a program plan is, in production, a coordination surface area that expands faster than it can be managed.

The Regulatory Dimension Most Programs Treat as a Post-Migration Cleanup

Under OCC Bulletin 2025-24, effective January 1, 2026, a bank in active core modernization is formally classified as being in a period of elevated operational risk — a supervisory focus area in the OCC's risk-based examination framework. The question an examiner asks is not what platform the bank is migrating to. It is whether the program has documented decision rights, tested rollback capability, and evidence of correctness at every migration stage.

For engineering leaders, this means compliance governance cannot be built around the technology outcome. It needs to be built into the program structure from day one — with a governance framework that can demonstrate to an examiner, at any point in the program, that the institution knows what it is doing and why.

DORA requirements for European institutions add a parallel dimension: third-party risk management, ICT incident reporting, and operational resilience testing all apply during the migration period, not just after it. Building those obligations into the program governance early is materially less expensive than retrofitting them under examiner scrutiny.

On Vendor Selection: The Decision That Comes Last, Not First

Most core modernization programs begin with vendor selection. The market has clear options at the $1B–$5B asset tier: Fiserv CoreAdvance for institutions currently on Premier, Jack Henry's cloud-native deposit core for SilverLake institutions evaluating FedNow and RTP roadmaps, FIS Affinity Edge for Horizon institutions that have completed an integration estate review, and challenger platforms like Mambu for sidecar use cases and Thought Machine for institutions with strong internal engineering capacity.

The right sequence is the reverse of what most programs do. The integration estate audit — a complete inventory of what connects to the core, how, and what breaks if the core changes — should precede the vendor decision, not follow it. The vendor that performs best in a demo may be the worst fit for a specific integration estate. That discovery should happen before the contract is signed, not after the program has started.

Where to Start

The programs that perform best against their original timelines share a common characteristic beyond sequencing: they do the comprehension work before they do anything else. A complete integration estate audit, documented business rules, a realistic decommissioning budget, and a governance framework that satisfies regulatory scrutiny — all of this is available before the first vendor contract is signed. Almost none of it is vendor-dependent.

The IBM IBV study found that the gap between programs that perform and programs that do not is not primarily a technology gap. It is a preparation and governance gap. That is fixable — but only if it is identified before the program is scoped, not after it is already underway.

Explore One Primero’s Technology Delivery Services →