Field note

The core was never the bottleneck. The operating model was

The plan said twelve months and the core replacement landed in year three. Nobody in that room was lying. They budgeted for a software install and got an operating-model change. After two decades on the payments, treasury, and integration side of these programs, here is the math I give clients before they sign a full legacy core replacement, and where the months actually go.

Jun 8, 2026 · Navin Agrawal · Strategy · 3 min read

The core was never the bottleneck. The operating model was

Visual brief

Visual brief

The core was never the bottleneck. The operating model was

As of June 2026

The plan said twelve months. The core replacement landed in year three. Nobody in that room was lying. They budgeted for a software install and got an operating-model change, and that is the gap nobody prices at kickoff.

I have spent two decades on the payments, treasury, and integration side of these programs. It is the seat where you watch the core get blamed while the real delays pile up everywhere else. None of this argues against modernizing. It argues for planning honestly, before the kickoff deck.

The math I give clients before they sign a full legacy deposit-core replacement is blunt. Take the timeline on the slide and add six to twelve months. Take the cost and add thirty to fifty percent contingency. That is the real plan, and anything better than it is upside rather than the baseline.

The core was never the bottleneck, the operating model was (as of June 2026): the real plan is to take the timeline on the slide and add 6 to 12 months and take the cost and add 30 to 50 percent contingency; the months go to configuration at 6 to 12, integration to existing rails and the treasury stack at 8 to 14 in parallel, data migration and validation at 4 to 8, and a production-like dual run before cutover at 3 to 6; a full-bank legacy migration tends to run 18 to 36 months end to end because you transform an operating model rather than swap a database; and the banks that ship budgeted for reality up front while the ones that stalled discovered it in month 14.
The slide shows a software install. The program is an operating-model change, and that is what blows the timeline.

Where the months actually go

From what I have seen up close, the time lands in four places. Configuration runs six to twelve months. Integration to the existing rails and the treasury stack runs eight to fourteen, in parallel rather than after. Data migration and validation take four to eight. A production-like dual run before cutover takes another three to six. On a Fiserv Signature integration I worked, the core itself was never the bottleneck. The end-of-day batch windows were, and so was every downstream system that assumed the old behavior, each one needing a re-test before cutover.

Cloud-native does not make it free

Greenfield on a modern, cloud-native core like Thought Machine’s Vault can move fast. A full-bank legacy migration still tends to run eighteen to thirty-six months end to end, and a complete multi-product decommission can run longer, because you are transforming an operating model, not swapping a database.

The real plan

+6-12 mo

take the timeline on the slide and add 6 to 12 months, take the cost and add 30 to 50 percent contingency.

End to end

18-36 mo

a full-bank legacy migration tends to run this long, because you transform an operating model, not a database.

The tell

Month 14

the banks that ship budgeted for reality up front - the ones that stall discovered it in month 14.

Plenty of banks still run cores that cannot do real-time natively. The work is necessary. The failure is planning for the migration on the slide instead of the one you will actually have.

Was this useful?

Choose once.

Related Posts

View All Posts »
The operating model kills payment modernization, not the tech

The operating model kills payment modernization, not the tech

A bank buys a modern payment platform and keeps the 2019 team structure, the same escalation matrix, the same three-person on-call rotation. The platform ships daily. The governance model says 90 days. Most modernization failures are operating-model failures, and the org chart defeats the architecture every time.

BRICS payment rails are real, and they are at pilot scale

BRICS payment rails are real, and they are at pilot scale

Five central banks are testing a settlement platform that does not touch SWIFT or the dollar. mBridge has been live since 2022, reached minimum viable product in mid-2024, and has moved about 55 billion dollars across roughly 4,000 transactions. SWIFT moves about 53 million messages on an average day. These are parallel rails for specific corridors, and infrastructure moves at infrastructure speed, not headline speed.

Real-time payments break your treasury org chart before they break your tech

Real-time payments break your treasury org chart before they break your tech

Your real-time rails settle in fifteen seconds. Your treasury org chart was built around an end-of-day cutoff. The gap between them is where the next reconciliation loss lives, and it shows up in three roles - cash positioning, exception ops, and intraday risk - long before it shows up in the tech stack.

Multi-rail is baseline now. The operational tax is the work

Multi-rail is baseline now. The operational tax is the work

The multi-rail debate is over - most US banks enabling instant payments now run both RTP and FedNow. The cost moved from the strategy deck to the operations floor, where exception handling becomes a decision tree, reconciliation becomes real-time position-keeping across two liquidity models, and routing is a per-transaction decision in milliseconds.