Why 60% of bank migrations miss their cutover deadline

We pulled the public record on every core-banking migration we could find between 2018 and 2025 — board reports, regulator filings, news coverage, post-incident reviews. Fourteen migrations with enough detail to be useful. Nine missed their original cutover deadline by more than 90 days. Three got cancelled mid-project.

What's interesting isn't that they missed. It's where in the timeline things broke.

The three failure modes

1. Reconciliation discovered late (8 of 14)

The most common failure is the project team assuming reconciliation is a final step before cutover — something you do once everything else works. Then they reach that step and discover hundreds of thousands of records the destination won't accept, because the destination's constraints are stricter than the source's. Now they have a choice: delay cutover to fix the data, or cutover dirty and break customer experience in production.

TSB Bank's 2018 cutover is the canonical example: hundreds of thousands of customers locked out for weeks because address-format mismatches and account-status semantics differed between the legacy Lloyds platform and the new Sabadell-owned core. The reconciliation problem was visible in early UAT — but treated as a UAT issue, not a cutover blocker.

2. Regulator audit shows up unprepared (4 of 14)

Banking regulators (FCA, CBN, OSFI, BAFIN) increasingly ask post-cutover for a full audit trail: which migration job moved which record, who approved schema changes, what reconciliation diffs were resolved and how. Most migration projects can produce some of this from their CI logs, but not in the structured format the regulator expects. The result is a 3–6 week post-cutover delay producing the audit pack, during which the regulator can block any second-phase work.

SAAQ Quebec's 2025 SAAclic rollout ran into this directly. The C$1.1B overrun included an estimated 18 weeks of post-cutover audit reconstruction that wasn't budgeted.

3. Naming-collision class (3 of 14, and growing)

The bug class we wrote about here: source-system formatted names and target-system normalized names appear identical to humans but different to the target's unique constraint. Wreaks havoc on dedupe logic, account-merge pipelines, and customer-facing search.

We're seeing this one more often because newer target systems (cloud-native core platforms, modern tax administration platforms) enforce stricter uniqueness invariants than legacy systems did. The platform upgrade exposes data quality issues the old platform tolerated.

What the 5 successful ones did differently

• ●Ran reconciliation in week 4, not month 4. They knew their data quality on a real-shape sample before they committed to a cutover date.
• ●Built the audit pack as the work was happening, not after. Every migration job emitted structured audit records the regulator could read directly.
• ●Treated naming, address, and code-mapping normalization as first-class agents with versioned rule libraries — not as one-off SQL scripts.
• ●Had a written war-room playbook for cutover weekend, including who has authority to roll back and on what criteria.
• ●Budgeted a 12-week buffer between "cutover-ready" and "regulator-cleared." Every one of them used the buffer.

The honest version

We built Migratio specifically because we lived through the failures. The Schema Mapper, Naming Library, Reconciliation, and Exception Triage agents aren't features we invented — they're the four parts of a successful migration playbook, productized. The 5 banks that succeeded did this work manually, with senior engineers and 18 months of runway. The 9 that missed didn't have that depth.

Our pitch is straightforward: if you're considering a core migration, ask yourself which of the three failure modes you're closest to. If the answer is "all three," book a discovery call. The honest answer might be to wait 18 months — we'd rather tell you that on a 30-minute call than discover it together at month 9.