Key Takeaways
- Vendor and industry commentary consistently places core banking migration failure well above 50%, but the headline "80% fail" figure circulating in trade media is a vendor-sourced estimate, not an independently audited statistic - this article names that limitation explicitly rather than repeating it as fact.
- Independent research tells a more precise and more useful story: McKinsey's analysis of more than 50 core banking system (CBS) transformations over seven years found only around 30% fully migrated ledgers and products to the new platform, with cost overruns of 50-100% against initial estimates.
- The pattern across McKinsey, Oliver Wyman and Forrester's documented case research is consistent: the proximate failure trigger is rarely the target platform itself. It is legacy data that is incomplete, inconsistent or never properly understood before cutover planning begins - compounded by organisational immaturity for the scale of the change.
- Platform selection absorbs a disproportionate share of executive attention, board reporting and vendor-day scrutiny, while legacy data condition - completeness, lineage, reconciliation readiness - is typically assessed late, informally, or only after go-live problems surface.
- sourceCode's view is that this is a sequencing problem as much as a technical one: a hard, evidence-based checkpoint on data condition - a "Migration Data Gate" - before cutover planning starts converts an unknown risk into a managed one.
Introduction
Core banking replacement is back on the agenda for Australian regional and mutual banks. Decades-old core platforms, built for overnight batch processing rather than real-time, API-connected banking, are increasingly difficult to extend, integrate and staff. The commercial logic for modernising is not in serious dispute among CTOs and CDOs.
What is in dispute - or at least underexamined - is why so many of these programs run over time, over budget, or fail to complete as scoped. The conventional wisdom inside many institutions is that the risk sits in platform selection: choosing the wrong core, the wrong system integrator, or the wrong architecture. Vendor RFPs, board papers and analyst briefings are structured around this assumption.
The evidence points somewhere else. Across the independent research available - McKinsey's multi-year analysis of core banking transformations, Oliver Wyman's modernisation guidance, and Forrester's documented case review of banking platform failures - the recurring proximate cause of delay, cost overrun and scope failure is the condition of legacy data going into migration, not the target platform's functional fit. This article sets out that evidence, explains why platform-centric thinking persists despite it, and proposes a specific governance mechanism - the Migration Data Gate - that gives CTOs and CDOs a way to act on it before cutover planning, rather than during cutover remediation.
This matters now because core banking decisions made in the next 12-24 months by Australian mutuals and regional banks will be live for a decade or more. A migration that stalls at 60% of scope, or that quietly leaves legacy components running "temporarily" for years, is a strategic cost, not an IT incident.
The Evidence: Why Core Banking Migrations Actually Fail
What the vendor-sourced "80% fail" claim actually says - and doesn't say
The figure most frequently cited in core banking migration commentary is that roughly 80% of migration projects fail, with a corresponding 20% success rate. This claim originates from Objectway, a core banking and wealth technology vendor, via a 2025 blog published on The Wealth Mosaic, attributed to Objectway's DACH CEO Karl im Brahm (Objectway, via The Wealth Mosaic, 2025). Im Brahm attributes the failures "usually [to] incomplete or incorrect data" ahead of technology or budget constraints.
This is directionally useful and consistent with the independent evidence below - but it should be read for what it is: a vendor executive's stated figure, with no named sample size, time period, methodology, or definition of "failure" disclosed in the source. Objectway sells migration and core banking services, which does not make the claim wrong, but it does mean it cannot be treated as an independently verified statistic. We cite it here because it is the figure already circulating in BFSI technology discourse, and because its causal claim - data condition over technology - is corroborated by independent research. The 80% number itself should not be repeated as audited fact.
What the independent research actually shows
The more rigorous and more conservative picture comes from McKinsey's analysis of more than 50 core banking system transformations completed over the preceding seven years: only around 30% of these programs had fully migrated ledgers and products onto the new core (McKinsey & Company, "How to get a core banking transformation right: eight mistakes to avoid," n.d.). The same analysis found cost overruns of 50-100% against initial budget estimates were common, planning phases routinely extended toward three years, and implementation often ran four to ten years. In less successful programs, legacy applications were still carrying 10-20% of production functionality more than five years after the new core had technically gone live.
McKinsey's companion analysis of core banking migrations undertaken during M&A integration reinforces the data dimension specifically: among its seven success factors, "data consolidation" - moving to a single enterprise data model, building reliable householding data, and getting data mapping right before conversion - sits alongside business ownership and minimising customisation as a primary determinant of whether a conversion finishes on time and under budget (McKinsey & Company, "Core banking migration during M&A: seven keys to success," 2023).
Oliver Wyman's 2025 guidance on core banking modernisation makes the data point even more directly operational: it recommends that any phased migration explicitly build in data cleansing, integrity verification and pilot deployments before bulk data transfer, framing the legacy data problem as foreseeable and manageable rather than an inherent hazard of the undertaking (Oliver Wyman, "10 Key Areas For A Successful Core Banking Modernization," 2025). Oliver Wyman's analysis also names a second, related cause: "program transformations often fail due to gaps in required skillsets and reliance on non-permanent staff" - an organisational capacity issue that compounds a data quality issue, because contract staff without institutional data knowledge are poorly positioned to interrogate decades of undocumented legacy records.
Forrester's documented case research - summarised in trade press coverage of its "Anatomy of a Disaster" analysis of major banking platform transformation failures - makes a complementary, non-data-specific point that still bears directly on this topic: principal analyst Jost Hoppermann's finding, drawing on cases including the UK Co-operative Bank's cancelled core migration (reported at close to £300 million in sunk cost), is that "today's banking platform transformations rarely fail because the technology is not up to the task" (Forrester Research, cited in TechCentral.ie, n.d.). The Co-op Bank's own independent review, led by Sir Christopher Kelly, concluded the programme "was not set up to succeed" - an organisational and governance verdict, not a technology verdict. Forrester's broader diagnosis - organisational immaturity, internal-only project scope, culture-sourcing mismatches, and unchecked scope creep - describes exactly the conditions under which a legacy data problem goes undetected until it is expensive to fix: a program run entirely inside the technology function, without the business-side data ownership and the time pressure to validate legacy records properly before cutover.
Taken together, the independent evidence supports a specific, more defensible version of the headline claim: legacy data condition and organisational readiness to interrogate it - not the comparative merits of the shortlisted target platforms - are the dominant drivers of core banking migration delay, cost overrun and incomplete scope.
The Migration Data Gate: A Decision Framework for Pre-Cutover Data Readiness
The Migration Data Gate is a formal checkpoint, owned jointly by the business and technology sides of the institution, that requires legacy data to meet defined completeness, accuracy and reconciliation thresholds before cutover planning - not just cutover execution - is permitted to begin. It sits deliberately earlier in the program than most institutions place their first serious data quality review, which typically happens during migration rehearsal or user acceptance testing, by which point the target architecture, integration contracts and cutover sequencing are already substantially fixed.
The Gate asks four questions before a single migration script is finalised:
- Completeness - Is every data domain required by the target core (accounts, products, KYC/AML records, collateral, guarantor relationships, standing instructions) actually present in a usable, extractable form in the legacy estate, including in satellite spreadsheets and shadow systems that sit outside the system of record?
- Accuracy and consistency - Does the legacy data reconcile against independent sources of truth (general ledger, regulatory reporting extracts, core-to-core historical reconciliations) within a defined tolerance, and are known exceptions catalogued rather than assumed clean?
- Lineage and ownership - For each critical data domain, is there a named business owner who can attest to its condition, rather than a technology team inferring condition from schema alone?
- Remediation runway - Where gaps exist, is there a costed, time-boxed remediation plan with its own governance, rather than an assumption that gaps will be "fixed in migration"?
A program that cannot answer these four questions with evidence does not proceed to cutover planning - platform selection, integration design and organisational change management can and should continue in parallel, but the cutover date is not fixed, and the business case is not finalised on the assumption of clean data, until the Gate is passed. This reverses the sequencing problem described above: it forces the single largest source of documented risk to be assessed and governed before it is locked into a fixed-date, fixed-scope program plan.
Why This Keeps Happening: The Underlying Drivers
Three structural factors explain why platform-centric thinking persists despite the evidence.
Procurement incentives favour comparable, scoreable criteria. Platform functionality, vendor references, licensing cost and implementation methodology can all be scored in an RFP matrix. Legacy data condition cannot be scored the same way without first doing the forensic work of profiling it - which is precisely the step institutions are trying to avoid committing budget to before a platform decision is made.
Data condition is organisationally inconvenient to surface early. Admitting that core customer and product data has unknown completeness implicates years of operational practice, not just a technology choice. McKinsey's finding that less successful transformations still had legacy systems carrying 10-20% of functionality five years after "go-live" is consistent with this: gaps discovered late are patched by keeping the old system alive, rather than remediated properly, because remediation was never resourced as a distinct, named workstream.
Governance structures reward visible milestones over invisible risk. Cutover dates, platform go-lives and integration completions are visible to boards and regulators. Data quality remediation is not naturally visible unless an institution deliberately creates a gate and reports against it - which is exactly what the Migration Data Gate is designed to do.
What Most Institutions Get Wrong - and the Honest Counterargument
The most common planning error is treating data migration as a late-stage technical workstream - "extract, transform, load" - executed by the systems integrator once the target platform and integration design are settled. By that point, as McKinsey's and Oliver Wyman's findings suggest, the program's cost and schedule baseline is already fixed around an assumption of clean data that has not been tested.
A fair counterargument deserves equal weight here: platform choice is not irrelevant, and framing this purely as a data problem risks letting vendors and integrators off the hook on genuine integration complexity. Some documented failures - including elements of the Co-op Bank case - involved platforms that could not in fact support the bank's product complexity without extensive customisation, which is a platform-fit failure, not a data failure. Oliver Wyman's own guidance notes that bridging differences in integration patterns typically requires a dedicated abstraction layer, and McKinsey's M&A research flags that minimising customisation to adopt at least 80% of a core's native functionality is itself a success factor independent of data condition. The honest position is that data condition is the dominant, most consistently documented and most under-governed risk - not the only one. A Migration Data Gate manages the data risk; it does not substitute for rigorous platform due diligence, integration architecture review, or realistic customisation scoping.
Business Implications for CTOs and CDOs
For an Australian regional or mutual bank evaluating core replacement, the practical implications are direct:
- Business case assumptions should separate data remediation cost from migration execution cost. A business case that bundles an unknown data remediation cost into a fixed migration budget is building in the 50-100% overrun pattern McKinsey documents from the outset.
- Cutover date should be a Gate output, not a Gate input. Setting a go-live date before data condition is assessed inverts the risk management logic and creates the exact pressure that leads to "fix it in migration" decisions.
- Data ownership needs a named business executive, not just a technology lead. Forrester's and the Co-op Bank review's findings on organisational immaturity point specifically to programs run inside the technology function without credible business ownership.
- Board and APRA-facing risk reporting should include data readiness as a distinct line item. Under CPS 230, APRA's operational risk management standard in effect from 1 July 2025, regulated entities are required to strengthen resilience of critical operations and third-party risk management (APRA, 2024). A core banking migration is a material change to critical operations; a documented, evidenced data readiness gate is a natural artefact to support that resilience obligation, though institutions should confirm specific CPS 230/CPG 230 obligations with their own risk and compliance function rather than relying on this characterisation alone.
Technology and Data Implications
Practically, standing up a Migration Data Gate requires capability most institutions have not built specifically for a migration program: independent data profiling against the legacy estate (not vendor-supplied extraction tooling alone), reconciliation against general ledger and regulatory extracts, a catalogued exceptions register with named owners, and a remediation backlog with its own budget and timeline that is tracked separately from the platform implementation plan. This is deliberately not a one-off audit. Oliver Wyman's recommendation to build in cleansing, integrity verification and pilot deployments across a phased migration implies the Gate concept extends through each migration wave, not only the first.
What Leaders Should Do Next
- Commission an independent legacy data readiness assessment before finalising cutover dates or locking the migration business case - treat it as a distinct, resourced workstream, not a line item inside the systems integrator's statement of work.
- Name a business executive - not a technology program manager - as accountable owner for data condition across each critical domain.
- Build the four Migration Data Gate questions into program governance now, even if platform selection is already underway, so the Gate can be exercised before cutover planning is finalised.
- Separate the data remediation budget and timeline from the platform implementation budget and timeline in board reporting, so risk is visible rather than absorbed silently into contingency.
- Confirm with risk and compliance how data readiness evidence should be documented to support CPS 230 critical-operations and third-party risk obligations.
The sourceCode’s Perspective
From sourceCode's perspective, the recurring pattern in core banking migration failure is not a surprising one - it is a sequencing failure that is entirely preventable once named. In our experience working with BFSI environments across APAC, legacy data condition is almost always known, informally, by someone in the business well before a migration program starts - a reconciliation team, a product owner, a long-tenured operations analyst. The problem is rarely a total absence of information; it is the absence of a formal mechanism that requires that knowledge to be surfaced, evidenced and acted on before the cutover date is fixed.
We don't believe the answer is to slow platform evaluation down or to treat data remediation as a prerequisite that delays modernisation indefinitely - Australian mutuals and regional banks facing genuine legacy core constraints cannot afford open-ended delay either.
The Migration Data Gate is designed to run in parallel with platform selection and architecture design, not ahead of it in sequence, while ensuring the one variable with the clearest evidence base behind it - legacy data condition - is governed with the same rigour as the platform decision itself, rather than discovered during rehearsal.
Conclusion
The industry commentary that "most core banking migrations fail" should be treated carefully: the specific 80% figure circulating in trade press is a vendor estimate, not an audited statistic, and this article has said so explicitly. But the independent evidence - McKinsey's analysis of over 50 transformations, Oliver Wyman's modernisation guidance, and Forrester's documented case research - converges on a more defensible and, for CTOs and CDOs, more actionable conclusion: legacy data condition, not platform selection, is the dominant and most consistently under-governed driver of core banking migration failure, delay and cost overrun.
Platform fit still matters, and should not be waved away by a data-quality narrative. But for institutions currently building the business case and governance structure for core replacement, the evidence argues for a specific, early, jointly-owned checkpoint on legacy data - a Migration Data Gate - before cutover planning, rather than during it.
If your institution is in the early stages of core banking evaluation, a structured pre-migration data readiness review is a practical way to pressure-test this risk before it is locked into a fixed-date program plan. Book a pre-migration data readiness review with sourceCode here!
FAQ
What causes most core banking migration failures: the platform or the data? Independent research - including McKinsey's analysis of more than 50 core banking transformations - finds that legacy data condition and organisational readiness to assess it are more consistently documented causes of delay, cost overrun and incomplete scope than deficiencies in the target platform itself. Platform fit still matters and is a separate, genuine risk category.
Is it true that 80% of core banking migration projects fail? That specific figure comes from a 2025 Objectway blog published via The Wealth Mosaic, attributed to an Objectway executive, with no disclosed sample size or methodology. It should be treated as a vendor-sourced estimate, not an independently verified statistic. Independent research (McKinsey) puts full-scope completion closer to 30% across the transformations it studied, using a different definition of success.
What is a Migration Data Gate? A Migration Data Gate is a formal, jointly business-and-technology-owned checkpoint that requires legacy data to meet defined completeness, accuracy, lineage and remediation-readiness thresholds before cutover planning begins, rather than during cutover rehearsal.
When should a bank assess legacy data quality in a core migration program? Before cutover planning and before the cutover date is fixed - not during user acceptance testing or migration rehearsal, by which point the program's schedule and budget baseline are already set around an untested assumption that legacy data is clean.
Does APRA's CPS 230 apply to core banking migration? CPS 230, APRA's operational risk management standard effective from 1 July 2025, requires regulated entities to strengthen the resilience of critical operations and manage third-party risk. A core banking migration is a material change to critical operations, so documented data readiness evidence is a reasonable component of resilience reporting - institutions should confirm specific obligations with their own risk and compliance function.
Does better data quality guarantee a successful core banking migration? No. Forrester's documented case research and McKinsey's M&A migration analysis both point to organisational factors - business ownership, program governance, minimising customisation, realistic cutover sequencing - as independent success factors alongside data condition. A Migration Data Gate addresses one major, well-evidenced risk category; it does not replace broader program governance.
Reference List
APRA (Australian Prudential Regulation Authority) (2024) APRA issues final guidance to strengthen operational resilience across the financial sector. Available at: https://niba.com.au/news/apra-issues-final-guidance-strengthen-operational-resilience-across-financial-sector (Accessed: 2 November 2026).
im Brahm, K., cited in Objectway (2025) Core Bank Migration: Why 80% of All Projects..., The Wealth Mosaic. Available at: https://www.thewealthmosaic.com/vendors/objectway/blogs/core-bank-migration-why-80-percent-of-all-projects/ (Accessed: 2 November 2026). [Vendor-sourced statistic; not independently corroborated against a primary dataset.]
McKinsey & Company (2023) Core banking migration during M&A: Seven keys to success. Available at: https://www.mckinsey.com/industries/financial-services/our-insights/banking-matters/core-banking-migration-during-ma-seven-keys-to-success (Accessed: 2 November 2026).
McKinsey & Company (n.d.) How to get a core banking transformation right: Eight mistakes to avoid. Available at: https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/tech-forward/how-to-get-a-core-banking-transformation-right-eight-mistakes-to-avoid (Accessed: 2 November 2026).
Oliver Wyman (2025) 10 Key Areas For A Successful Core Banking Modernization. Available at: https://www.oliverwyman.com/our-expertise/insights/2025/may/next-gen-core-banking-modernization.html (Accessed: 2 November 2026).
Olympic Banking System / ERI (2026) The core technology challenges facing Australian mutual banks and credit unions in 2026. Available at: https://www.olympicbankingsystem.com/en/blog/australian-mutual-banking-technology-challenges/ (Accessed: 2 November 2026).
TechCentral.ie, citing Forrester Research (Hoppermann, J.) and Finnegan, M., Computerworld UK (n.d.) Management, not technology, to blame for most core-banking replacement failures. Available at: https://www.techcentral.ie/management-blame-core-banking-replacement-failures-tech/ (Accessed: 2 November 2026).