What a Live Core Banking Cutover Actually Requires From a Delivery Partner

The business case for core modernisation is written around target-state architecture. The casualties happen in a multi-week window most business cases barely mention - and a 2026 Vietnamese cutover shows why the window, not the architecture, is where delivery discipline is actually tested.

Key Takeaways

• Research into more than 50 core-banking transformations found only around 30% completed a full migration of ledgers and products, and timelines were underestimated by as much as 75% (Friese et al., 2022).

• A 2025 IBM Institute for Business Value study of CIOs reports that 94% of modernisation projects exceed their planned timelines (Ramamurthy et al., 2025) - evidence that the overrun usually surfaces at the point of execution, not at the design stage.

• Sacombank's 2026 move to a Temenos-on-IBM-Power hybrid cloud platform, delivered with Red Hat OpenShift, is a verified, dated APAC case that illustrates what a disciplined cutover looks like when it goes right (Temenos, 2026; IBM, 2026).

• The "phased versus single cutover" choice is a genuine trade-off, not a solved problem - a phased, dual-running approach reduces one-shot risk but can strain compliance, training and operations for months (Desai et al., 2023; im Brahm, 2025).

• Delivery-team sizing and governance for the cutover window is a distinct discipline from steady-state delivery capacity - one case cited by McKinsey dedicated more than 200 people to a single core conversion event (Desai et al., 2023).

Introduction

Most core banking modernisation business cases are written backwards. They spend the majority of their pages - and the majority of board attention - on the target-state architecture: which core platform, which cloud, which integration layer, which data model. The cutover itself, the multi-week event in which the bank actually moves live transaction processing from the old system to the new one, is typically reduced to a single line item: "go-live."

That is the wrong place to under-invest. Architecture decisions are made over months, reviewed by committees, and revisited when they're wrong. A cutover window is not like that. It is a compressed, largely irreversible event with a named weekend, a fixed crew, and a narrowing set of options the longer it runs. Research across more than 50 core-banking transformations found that only around 30% achieved a full migration of ledgers and products, and that banks underestimated migration timelines by as much as 75% (Friese et al., 2022). A separate 2025 study of banking CIOs found 94% of modernisation projects run over their planned timeline (Ramamurthy et al., 2025). Those overruns are not architecture failures. They are failures of what happens in the room during the event - rehearsal discipline, rollback authority, and whether the delivery team is actually resourced for a specific, time-boxed crisis rather than ongoing BAU capacity.

A live, verifiable 2026 case makes the point concretely. In August 2026, Sacombank - one of Vietnam's largest commercial banks - announced it had completed a move of its Temenos core banking platform from on-premises infrastructure to a hybrid cloud environment, running on Red Hat OpenShift and IBM Power, with Temenos Payments Hub added to support cross-border payments (Temenos, 2026; IBM, 2026). The release reports meaningful operational gains: a 200% improvement in application performance, three-times-faster deployment cycles, and a 50% reduction in server footprint (IBM, 2026). Those are architecture outcomes. What the release does not disclose - and what every bank considering a similar move needs to plan for regardless - is the governance discipline inside the cutover window that got a bank processing roughly 13 million transactions a day (Temenos, 2026) from one state to the other without disrupting retail and SME customers mid-event. That is the part a delivery partner has to own, and it's the part this piece is about.

The Architecture Decision Gets the Business Case; The Cutover Gets the Casualties

The imbalance between architecture planning and cutover planning shows up directly in the data on where core transformations actually fail. McKinsey's analysis of more than 50 transformations over seven years found that planning phases can run up to three years and implementation four to ten years - and that the longer the timeline, the more scope creep accumulates from shifting regulatory, technology and market requirements (Friese et al., 2022). The same research found that banks which skipped agile and DevOps discipline missed performance gains of up to 50%, some projects overspent by 100%, and in less successful cases legacy applications were still carrying 10-20% of production functionality more than five years after the official go-live (Friese et al., 2022).

A separate, independently sourced claim puts the failure rate even higher: Objectway's Karl im Brahm states that "around 80 percent of all migration projects fail - usually due to incomplete or incorrect data," with core banking migrations specifically achieving only a 20% success rate (im Brahm, 2025). We flag this figure for what it is: a vendor executive's stated claim, with no disclosed methodology, sample size or definition of "failure" behind it. It should be read as directional industry sentiment, not a verified statistic - but it is consistent in direction with the independently sourced IBM and McKinsey figures above, and the explanation it offers (data quality, not platform choice) is directly relevant to cutover planning: most of what breaks during a cutover weekend is a data or sequencing problem discovered under time pressure, not an architecture flaw discovered in production.

The practical implication is that the business case's implicit model - "get the architecture right and the rest follows" - understates where the actual risk sits. Architecture choices are revisited over quarters. Cutover-window failures are discovered in hours, with customers mid-transaction.

Inside the Cutover Window: What Actually Breaks

A detailed account of how banking transformation teams run a cutover weekend, published by the European consultancy zeb in September 2025, describes the operating model that separates a controlled event from a chaotic one (zeb, 2025). Preparation starts weeks or months ahead, with a named-owner plan broken down by timeframe. Critically, "a dress rehearsal simulates the weekend in order to test and adjust the plan" before the real event - treating the cutover itself as something to be rehearsed, not just scheduled. A control centre, staffed around the clock in shifts, coordinates the cutover team, project management, technical experts and quality assurance, with the bank's own board members often present. Communication infrastructure - contact lists, reporting chains, on-call rosters, a live "cut-over chat" - is built in advance, not improvised on the night (zeb, 2025).

McKinsey's research into core banking migrations during M&A integration adds the governance layer that sits above the control centre: weekly dashboards tracking vendor deliverables, daily defect-tracking calls, and biweekly escalation calls with the vendor's senior leadership running in parallel with the technical cutover work (Desai et al., 2023). The same research found that successful migrations are typically underpinned by adopting roughly four-fifths or more of the selected core platform's native functionality - a discipline that reduces the amount of custom logic that has to be rehearsed and validated during the cutover itself, as opposed to during steady-state development (Desai et al., 2023).

What these two sources converge on is that the cutover window is a distinct operating mode, with its own staffing model, its own reporting cadence, and its own decision rights - not a scaled-up version of normal sprint governance. A delivery partner evaluated only on steady-state capability (code quality, sprint velocity, architecture fluency) has not been evaluated on the thing that actually determines whether the go-live weekend holds.

The Counterargument: When a Phased Approach Adds Risk Instead of Removing It

It would be a mistake to present "parallel-run, phased, de-risk everything" as the uncontested right answer, because the evidence does not support that as a universal rule. McKinsey's own M&A-focused research frames this explicitly as a trade-off, not a settled preference: "a phased rollout keeps two cores running at once," which strains training, compliance and operations simultaneously, and can delay the point at which the bank actually captures value from the new platform (Desai et al., 2023). Their guidance to leadership teams is to first assess honestly whether the organisation can actually manage a phased rollout - in terms of people, process maturity and change capacity - and if it cannot, a single, well-rehearsed cutover may be the lower-risk path, not the higher-risk one.

There is also a vendor-sourced counter-example worth naming, with appropriate caution. LHV Bank's 2026 migration to Tuum's platform for its UK operations is reported as a phased, modular transition specifically designed to avoid what the coverage calls a "high-risk 'big bang' approach," with the vendor claiming zero downtime during the migration window (Paterson, 2026). This is useful as an illustration of the phased approach working as intended - but it comes from vendor-promoted coverage with no independently disclosed metrics, durations or third-party verification, and should be read accordingly.

The honest synthesis: neither "always phase it" nor "always cut over in one event" survives contact with the evidence. The real decision variable is organisational capacity - specifically, whether the bank and its delivery partner can sustain the operational strain of running two cores at once for the length of time a phased approach requires, without the parallel burden degrading either system's service quality. That capacity assessment is itself a cutover-readiness question, and it belongs in the framework below rather than in the architecture business case.

The Cutover Control Tower: A Framework for Delivery-Partner Readiness

Extending the capability-governance questions this series raised in "The Insourcing Decision Most CTOs Get Backwards" (sourceCode, 15 September 2026) into the cutover-specific context, we propose The Cutover Control Tower - five governance stations a delivery partner needs to have demonstrably staffed and rehearsed before a cutover date is locked, not just before the architecture is signed off.

1. Rehearsal Discipline. Has the cutover sequence been run end-to-end, at least once, in a dress-rehearsal environment that simulates production load and timing - not just unit- and integration-tested in isolation? (zeb, 2025)

2. Rollback Authority. Is there a named individual, not a committee, with the authority and the pre-agreed criteria to call an abort before the point of no return - and has that threshold been defined in hours and data states, not sentiment?

3. Resourcing Elasticity. Can the delivery partner surge to event-specific staffing - potentially multiples of steady-state headcount, in the range of the 200-plus-person conversion teams documented in major transformations (Desai et al., 2023) - without silently pulling capacity from unrelated production support?

4. Reporting Cadence. Is there a live control centre with defined shift coverage, a single reporting channel, and a cadence of defect-tracking and escalation calls that runs during the event, not only in post-incident review (zeb, 2025; Desai et al., 2023)?

5. Recovery Capacity. Is there a defined, resourced stabilisation period after go-live - parallel monitoring, a declared period before the migration is called "successful," and capacity held back specifically to absorb post-cutover defects rather than immediately reassigning the team to the next project?

A delivery partner that cannot answer all five with specifics - names, thresholds, headcount, cadence - has a plan for the architecture and a hope for the cutover.

What This Means for the Buying Committee

For the CTO: The cutover-readiness conversation needs to happen before the statement of work is signed, not during mobilisation. The architecture RFP and the delivery-partner RFP are testing different things, and most procurement processes only formally score the first one. Ask the delivery partner to walk through their last cutover event using the five stations above - not their platform credentials.

For the Head of Engineering / Engineering buyers: The practical risk is capacity cannibalisation - the cutover team quietly being drawn from the same pool as BAU production support, so that a successful go-live weekend is bought at the cost of degraded support coverage for everything else running in production during that window. Resourcing Elasticity (station 3) is the question to press hardest, specifically asking whether surge staff are genuinely additive or borrowed.

For Risk and Operations stakeholders: Rollback Authority (station 2) is usually the weakest-governed of the five in practice, because defining an abort threshold in advance requires admitting, before the event, that failure is possible - a conversation sponsors are often reluctant to have. It should be documented and signed off independently of programme sponsorship.

The sourceCode Perspective

sourceCode positions itself around insourcing technical teams into banks and insurers across Australia, Malaysia and Vietnam, rather than running fully outsourced, black-box delivery. That model has a direct bearing on cutover readiness, for a specific reason: a team that insources - that works inside the client's own workflows, tooling and reporting lines day to day - is in a materially better position to stand up the Cutover Control Tower's reporting and rollback stations convincingly, because the escalation paths and decision-makers it needs during the event are the same ones it already works alongside during steady state. A delivery model that only shows up at mobilisation has to build that trust and those reporting lines from zero, inside a multi-week window that has no slack for it.

This is also where the questions raised in this series' earlier piece on insourcing decision-making apply with the most force. The governance discipline question that matters when choosing an insourcing partner for ongoing delivery - can this team operate inside our structures, under our oversight, without needing to be managed as an external black box - is the same question, under far less forgiving time pressure, during the weeks around a cutover.


A partner whose governance habits only hold up under steady-state conditions is the one most likely to improvise during the event itself. We would rather a prospective client stress-test that discipline against the five stations above before a cutover date is on the calendar than discover the gap during the dress rehearsal - or worse, during the real thing. Talk to us here!

Conclusion

The Sacombank-Temenos-IBM upgrade is a genuinely useful 2026 reference point precisely because the public account of it is honest about what it discloses: architecture outcomes, not cutover mechanics (Temenos, 2026; IBM, 2026).


That gap is normal - vendors and banks report the destination, not the weekend it took to get there - but it means every bank and every delivery partner evaluating a similar move has to plan the cutover discipline independently of what any press release says. The evidence across more than fifty transformations, two independent McKinsey studies and one practitioner cutover-weekend account converges on the same point: the architecture decision gets reviewed by committee and revisited over years; the cutover gets one shot, a named weekend, and a team that either has rehearsed rollback authority and elastic resourcing in place, or doesn't.


The Cutover Control Tower is a way to find out which, before the date is locked rather than after the event has started.

FAQ

Is a phased, parallel-run cutover always safer than a single "big bang" cutover? No. Evidence is mixed. McKinsey's research frames it as a genuine trade-off: a phased approach reduces one-shot risk but strains compliance, training and operations by running two cores simultaneously, and organisations that cannot sustain that strain may be better served by a single, well-rehearsed cutover (Desai et al., 2023).

What is the actual failure rate for core banking migrations? Verified research puts the number of transformations completing a full migration of ledgers and products at only around 30% across a sample of more than 50 (Friese et al., 2022), and 94% of modernisation projects exceeding their planned timeline in a 2025 CIO study (Ramamurthy et al., 2025). A frequently cited "80% fail" figure (im Brahm, 2025) comes from a vendor executive with no disclosed methodology and should be treated as directional, not verified.

How big should the delivery team be for a core banking cutover event? There is no universal ratio, but one documented case dedicated more than 200 people specifically to a core conversion programme, backfilled across workstreams from a broader talent pool (Desai et al., 2023). The more important question than headcount is whether that capacity is genuinely additive to BAU support or quietly borrowed from it.

What should a bank ask a delivery partner before agreeing a cutover date? At minimum: has the cutover sequence been dress-rehearsed under production-like conditions; who has named authority to call a rollback and under what defined threshold; how will staffing surge without degrading other production support; what is the live reporting and escalation cadence during the event; and what resourced stabilisation period follows go-live before success is declared.

Reference List

Desai, M., Hyde, P., Kanagasabai, K. and Noteboom, P. (2023) Core banking migration during M&A: Seven keys to success. McKinsey & Company, 20 April. Available at: https://www.mckinsey.com/industries/financial-services/our-insights/banking-matters/core-banking-migration-during-ma-seven-keys-to-success (Accessed: 12 October 2026).

Friese, R., Kube, H., Schöbl, S. and Soller, H. (2022) How to get a core banking transformation right: Eight mistakes to avoid. McKinsey & Company, 17 February. 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: 12 October 2026).

IBM (2026) SACOMBANK modernizes its core banking system, driving digital transformation through Red Hat OpenShift and IBM Power. IBM Case Studies, 24 August. Available at: https://www.ibm.com/case-studies/sacombank/ (Accessed: 12 October 2026).

im Brahm, K. (2025) Core bank migration: why 80 percent of all projects fail. The Wealth Mosaic, 22 October. Available at: https://www.thewealthmosaic.com/vendors/objectway/blogs/core-bank-migration-why-80-percent-of-all-projects/ (Accessed: 12 October 2026). [Note: statistic is a vendor-stated claim with no disclosed methodology; treated as unverified/directional in this article.]

Paterson, A. (2026) LHV Bank and Tuum reveal blueprint for seamless core banking migration. FF News, 27 July. Available at: https://ffnews.com/videos/lhv-bank-and-tuum-reveal-blueprint-for-seamless-core-banking-migration (Accessed: 12 October 2026). [Note: vendor-promoted coverage with no independently disclosed metrics; treated as illustrative, not verified.]

Ramamurthy, S., Baldwin, A., Sironi, P. and Connelly, D. (2025) The 94% core banking problem. IBM Institute for Business Value, 22 September. Available at: https://www.ibm.com/thought-leadership/institute-business-value/report/core-banking-modernization (Accessed: 12 October 2026).

Temenos (2026) SACOMBANK Modernizes Core Banking with Temenos and IBM. Temenos press release, 26 August. Available at: https://www.temenos.com/?p=169904 (Accessed: 12 October 2026).

zeb (2025) From planning to go-live: success factors for the cut-over weekend in IT transformations. zeb career blog, 17 September. Available at: https://zeb-career.com/en/blog/success-factors-for-the-cut-over-weekend-in-it-transformations (Accessed: 12 October 2026).