Public incident analysis. This article draws on the Financial Conduct Authority and Prudential Regulation Authority’s public enforcement materials and TSB Bank’s published 2018 results about the bank’s April 2018 IT migration. Oscillate Infotech did not build, migrate, investigate, or advise on that programme and has no non-public information about it. Confirmed figures come from those official publications. Sections labelled independent analysis are Oscillate Infotech’s operational reading of the documented pattern.
Confirmed facts from the regulatory record
TSB’s Main Migration Event ran over 20–22 April 2018, with the new platform live on 22 April 2018. The FCA Final Notice records that the data migration itself was successful, yet serious platform and service problems followed go-live across online and mobile banking, telephone banking, branches, and consequential payment and debit-card services.
Disruption affected all of TSB’s 550 branches and a significant proportion of roughly 5.2 million customers. TSB did not return to a business-as-usual position until 10 December 2018. Between 22 April 2018 and 7 April 2019, TSB received 225,492 complaints relating to the migration incident and paid £32,705,762 in redress in that period. In December 2022 the FCA and PRA announced combined penalties of £48.65 million. TSB’s 2018 full-year results recognised £330.2 million in post-migration costs and foregone income.
Successful data load is not service readiness
Moving customer records onto a new platform answers whether balances and identifiers arrived. It does not answer whether login, payments, telephony, branch tools and support capacity can absorb real demand on day one. The regulatory record’s insistence that data migrated successfully while channels failed is the distinction this article keeps in view.
Why channel failures cascade
Independent analysis. When digital paths degrade, customers shift to phone and branch. Shared dependencies then amplify queues. A green data-load panel can sit beside failing journeys because those journeys share identity, session, payment and infrastructure layers the load job never exercised at production scale.
Go-live evidence versus test completion
Independent analysis. Passing a test plan is not the same as proving the business can run. Readiness includes production-like load, end-to-end journeys across every channel you will open, known defects with named workarounds, support surge capacity, and a go/no-go owner who can still stop. One additional happy-path test would not automatically have prevented a multi-month recovery; residual-risk governance sits beside technical tests.
Controls tied to this failure pattern
Independent analysis:
- Separate sign-off for data accuracy from sign-off for service readiness.
- End-to-end tests across every customer channel scheduled for night one.
- Load tests that include failure-driven telephony and branch surge.
- Monitoring of customer outcomes (login success, payment success, queue times), not only batch status.
- Named go/no-go ownership and a written list of deferred defects.
- Supplier accountability that still operates under incident conditions.
Rollback after new transactions begin
Independent analysis. Once customers create new activity on the new platform, “restore last night’s database” is rarely a clean business rollback. Dual-running, reconciliation and a defined point of no return belong in the plan before cutover. If reverse is impractical, the go-live bar—or the phased cohort design—must be stricter.
Lessons for smaller cutovers
Spreadsheet-to-system moves, Access upsizing and ERP go-lives fail with the same shape: rows look right; day-one processes do not. Phased cohorts, parallel runs and reconciliation reports keep the business alive while the new path proves itself.
Our data migration, legacy system integration, Access development and application maintenance work treats “rows arrived” as a checkpoint. Related reading: Access Under Load and Legacy System Modernization.
How we assess migration readiness
- Which journeys must work in hour one, and how will you measure them?
- What happens to secondary channels if the primary channel fails?
- Which defects are deferred, who owns the workaround, and when does it expire?
- Who can halt further cutover steps at 10 a.m., and to what state?
Independently written and illustrated from documented public facts, with no third-party creative assets reproduced.
Sources
- Financial Conduct Authority and Prudential Regulation Authority, TSB fined £48.65m for operational resilience failings (20 December 2022).
- Financial Conduct Authority, Final Notice: TSB Bank plc (20 December 2022) — MME 20–22 April 2018; go-live 22 April; successful data migration with post-go-live channel failures; BAU from 10 December 2018; ~5.2 million customers; all 550 branches impacted; 225,492 complaints and £32,705,762 redress (22 April 2018–7 April 2019).
- TSB Bank, TSB announces 2018 full year results — £330.2 million post-migration costs and foregone income for 2018.
