When TSB was carved out of Lloyds Banking Group, it kept running on Lloyds’ IT systems under an expensive transitional arrangement. Its Spanish parent, Banco Sabadell, set out to move TSB onto a new core banking platform of its own, Proteo4UK. The migration was attempted over a single weekend in April 2018, and the go-live on the weekend of April 22 turned into one of the most visible IT failures in UK banking history. The authoritative primary account is the independent review commissioned by TSB’s Board from the law firm Slaughter and May, published in full by the bank.
The migration itself moved an enormous amount of data. The Slaughter and May review notes that the project transferred millions of customer accounts and that the data was migrated, in the bank’s words, “to the penny.” But moving the data correctly was not the same as having a platform ready to run it. The review found that the main migration event was followed by extensive service disruption and instability, with large numbers of customers unable to access their accounts through digital channels.
A striking finding in the review concerned the production environment itself. TSB’s own analysis revealed that the two data centers, which were specified to be configured identically, were in fact inconsistently configured, and that this discrepancy went undetected despite extensive testing. The review pointed to the need for stronger oversight of suppliers and raised questions about whether the testing regime had truly validated end-to-end readiness rather than individual components.
The customer impact was severe and prolonged. Online and mobile banking were unreliable for weeks, some customers saw other people’s account details, and the disruption opened the door to a surge in fraud attempts as criminals exploited the chaos and customer confusion. TSB ultimately compensated affected customers, replaced senior leadership, and took direct control of its IT operations.
The TSB episode is a canonical example of the risks of a “big bang” cutover, where there is no incremental fallback once the switch is thrown. Its lessons run through software-testing discipline, environment parity, supplier governance, and disciplined root-cause-analysis of why a large, tightly coupled distributed-system can pass component tests yet fail catastrophically in production.