The biggest mistake in core banking modernisation may happen before you even select a platform. 

The market loves a vendor list: Temenos vs. Mambu vs. Fiserv vs. FIS, scored on a grid of performance, scalability, customisation and reliability. It makes for a dangerously incomplete decision. 

That’s because the hard part isn’t choosing a platform that can process transactions or expose an API. They can all do that serviceably. The hard part is getting from the old world to the new one without derailing your business and existing products along the way.

That is where modernisation programs succeed or fail. The migration strategy needs to cover what moves first, what stays put, how dependencies are sequenced, and how quickly the organisation can prove each step is working. A platform can be technically excellent and still sit at the centre of a stalled transformation. The real question, then, is “How do we actually get there?”

McKinsey’s analysis of core banking transformations found that banks routinely underestimate how long it takes to integrate a new core with existing back-office applications, which is one of the most consistent culprits of budget and timeline overruns in these programs. That’s not a platform problem, they all handle integration adequately on paper. It’s a sequencing and execution problem, and it’s where the right modernisation partner can shine. 

Why vendor selection isn’t the real risk, sequencing is

The instinct is to treat modernisation as a procurement decision: shortlist platforms, run an RFP, pick a winner. But the platform is the commodity layer and every major vendor can process transactions, manage a ledger, and expose an API. What separates a modernisation program that ships from one that stalls is the order in which the migration happens and how rigorously each step is validated before the next one starts.

Institutions that treat every data domain as equally urgent by migrating the easy ones first because they’re easy, just tend to end up with the highest-risk domains (credit, fraud, AML, regulatory reporting) running last, on whatever budget and attention they have left. That’s why sequencing by risk, not by convenience, is a decision the modernisation partner makes with you, not one that shows up on a feature comparison sheet.

What “Operational Risk” actually means in a core migration

“Risk” in a modernisation context isn’t an abstract concept, we can look at four concrete points of failure to watch out for: 

• Data migration integrity — records, balances, and product logic that don’t map cleanly from the legacy system, discovered too late to fix cheaply.
• Parallel-run breakdown — running old and new systems side by side to validate outputs before cutover is the standard safeguard, but it only works if the vendor has done it before at your scale.
• Regulatory exam exposure — a migration that can’t produce a clean audit trail or explain a discrepancy to a supervisor mid-transition.
• Customer-facing disruption at cutover — the moment old and new systems switch over is where account access, payments, and transaction processing are most exposed.

A commonly recommended safeguard against the worst of these is the “dual run” approach. This way, you are operating legacy and new core systems in parallel long enough to catch discrepancies before the old system is decommissioned, with data quality treated as its own subproject rather than a checkbox inside the main migration.

Evaluating a vendor on risk-reduction capability, not just features

The criteria below are what actually separates a vendor who reduces your operational risk from one a true tech partner that is ready to implement the platform competently.

1. Parallel-run track record, not just a stated methodology

Any vendor can describe a dual-run approach in a proposal. 

Quiz them on the specifics, learn how they would set up and approach a parallel run. They should be able to provide an in-depth look at the discrepancies it can catch and what will go wrong without it.

2. Data migration discipline, assessed early

Data quality problems are the single most common cause of migration cost and timeline overruns. A strong vendor starts data profiling and quality assessment during the discovery phase, rather than treating it as a simple to-do item that starts once the build begins.

3. Regulatory engagement during an active program

A vendor should have an expert on board who has actually walked a modernisation through a supervisory conversation mid-program, understands what documentation and audit trail a regulator expects and can anticipate the problems changes will bring. This is different from general compliance familiarity and worth verifying with some direct questions. 

4. Sequencing philosophy

Ask directly, which data domains and product lines they’d migrate first and why. “We migrate whatever’s easiest first to build momentum” is a weaker answer than a vendor who can explain how they’d prioritize by risk exposure: credit, fraud, AML, and regulatory reporting domains, even if it means a harder start.

5. Rollback and contingency planning

A migration plan without a defined rollback trigger and process is a plan that assumes nothing will go wrong. Things will go wrong. Ask what conditions would trigger a rollback at cutover, and what that process actually looks like operationally. 

Modeling the real cost of modernisation

Vendor pricing conversations tend to focus on license or subscription cost, which is usually the smallest line item in the total program. A more complete total cost of ownership model breaks down into four buckets: the platform license or subscription itself; integration and data-foundation work, which is typically the largest first-year cost and the one vendors are most likely to under-scope in a proposal; ongoing run and compliance-evidence upkeep once live; and the cost of inaction: the manual reconciliation, slow closes, and delayed product launches that come from staying on the legacy system longer than planned.

A tech partner who can model all four buckets against your actual data volumes and regulatory scope is giving you a more honest cost picture than one whose estimate starts and ends with some starter fees. 

Questions to ask a modernisation vendor before you sign

• Walk me through a parallel-run engagement: what should it catch, and what will fail at cutover without it?
• When does data quality assessment start in your engagement model?
• Which data domains would you sequence first on our program, and why those specifically?
• What’s the actual rollback trigger and process at cutover?
• How would you itemise the cost estimate across licensing, integration, ongoing run, and the cost of staying on our current system longer? 

How Vacuumlabs approaches core modernisation risk

Vacuumlabs is a financial product development company that partners with banks and fintechs to accelerate innovation. They design, build, and launch digital products, specialising in core banking transformation, new bank builds, and wealthtech. As a true business partner, Vacuumlabs combines fintech expertise with technical delivery to reduce risk and accelerate time to market. 

For the platform-selection side of this decision, our core banking implementation partner article covers the full evaluation framework in more depth, and our core banking solutions page details our delivery model. If you’re mid-scoping a modernisation program, you can also talk to our team directly.

Frequently Asked Questions

How do I select a digital banking vendor for modernisation?

Evaluate a vendor on risk-reduction capability, not just platform features: their internal knowledge of running parallel/dual-run migrations, how early they start data quality assessment, whether they’ve engaged with regulators mid-program (not just at initial licensing), their philosophy on sequencing data domains by risk, and whether they have a concrete rollback process rather than a stated contingency plan. Ask for specifics and not just a general capability pitch.

What causes core banking modernisation projects to fail?

The most common causes are underestimating integration timelines with existing back-office applications, poor data quality discovered too late in the process, and treating parallel-run validation as optional rather than a core safeguard. McKinsey’s research points to integration-timeline underestimation specifically as one of the most consistent drivers of the budget and schedule overruns that derail these programs.

How long does a core banking modernisation typically take?

Timelines vary widely by scope. A phased modernisation with a limited initial scope can show results within months, while a full core replacement with multi-jurisdiction compliance typically runs multiple years. A useful discipline, regardless of total program length, is targeting an early defensible win, a single high-leverage data domain migrated and validated in parallel within the first few months, to retain stakeholder confidence before the harder, higher-risk domains are tackled.

What’s the difference between a core banking platform vendor and a modernisation delivery partner?

A platform vendor (Thought Machine, Tuum, Mambu, SaaScada, and similar) provides the core banking software itself, the ledger and product engine. A modernisation delivery partner is the team responsible for the migration: data quality and migration discipline, parallel-run management, integration with existing systems, and getting the institution through cutover and regulatory scrutiny safely. The platform is a license; the delivery partner owns the risk of getting there. 

How do I migrate from a legacy core to a cloud-native platform?

The platform choice matters less than the sequencing. Every major vendor can process transactions and expose an API — what separates a migration that ships from one that stalls is the order data domains move in and how rigorously each step is validated before the next starts. Sequence by risk, not convenience: migrating the easiest domains first tends to push the highest-risk ones (credit, fraud, AML, regulatory reporting) to the end, running on whatever budget and attention is left. The standard safeguard is a “dual run” — operating legacy and new core systems in parallel long enough to catch discrepancies before the old system is decommissioned, with data quality treated as its own subproject rather than a checkbox inside the main migration. A vendor worth hiring makes this sequencing decision with you, based on your specific risk exposure, not off a generic playbook.

What is the average cost of core banking replacement?

There’s no single reliable average, because the platform license is usually the smallest line item. A complete total cost of ownership model breaks into four buckets: the platform license or subscription itself; integration and data-foundation work, which is typically the largest first-year cost and the one vendors most often under-scope in a proposal; ongoing run and compliance-evidence upkeep once live; and the cost of inaction — the manual reconciliation, slow closes, and delayed product launches that come from staying on the legacy system longer than planned. A vendor who can model all four buckets against your actual data volumes and regulatory scope is giving you a more honest cost picture than one whose estimate starts and ends with a starter fee.

This article was created with AI assistance and refined by our editorial team.