When a bank moves to a new system, my first question would not be whether its tables have been copied. I would want to know whether a customer can see an account, make a payment and receive a clear confirmation at the right time. Data migration is one part of the change. Readiness also involves capacity, permissions, integrations, support and a workable response to failure. These dimensions require a shared assessment even though different teams own them.
The real case: TSB in the United Kingdom
TSB moved to a new IT platform in April 2018. The FCA announcement of 20 December 2022 explicitly distinguished successful data transfer from subsequent platform failures disrupting banking services. The FCA and PRA imposed combined penalties of £48.65 million. Their findings concerned change governance and operational and outsourcing risks. The public account does not justify attributing the incident to one particular incorrect table or an unspecified missing test.
My interpretation: validate the service as a whole
I would separate readiness into three questions. Were the data transferred correctly? Do the dependent processes work? Is the organisation ready to detect and manage a complication? A positive answer to the first does not answer the other two. Rather than seek one overall success indicator, I would assemble evidence linked to particular services and customer consequences.
I would start with a simple map of a customer request. Signing in, retrieving a balance, checking available funds, entering a payment, authorising it and receiving confirmation are different control points. Each needs a system, an owner, an expected outcome and evidence of validation. The map should support an actual decision, rather than exist only as a convincing presentation.
A hypothetical example: 99.9 percent needs context
The following numbers are illustrative and do not describe TSB. A bank migrates one million customer records and 999,000 pass automated checks. A 99.9 percent success rate sounds reassuring. However, the remaining thousand might include payroll accounts or customers with no alternative access channel. A percentage cannot establish acceptability without explaining who and what is affected.
I would list all exceptions, classify their consequences and examine shared characteristics. Suppose eight hundred relate to the same product and currency combination. That suggests a possible common transformation issue, rather than eight hundred unrelated minor defects. I would still investigate the remaining cases: a different cause requires a different correction and a different test of that correction.
A second assessment would test the service under an expected peak workload. Correct balances in a control file do not prove that customers can retrieve them when many people sign in at once. Data checks could pass while the service remains unusable. I would record these as separate findings so that a positive overall status cannot conceal the precise weakness.
How I would prepare the release decision
First I would agree the critical services and scenarios with their business owners. Then I would align the versions behind the evidence: the software build, reference tables, reporting date and permission set. Results from another configuration can still be informative, but they should not silently substitute for checks of the final configuration. The decision pack needs to say what was actually tested.
For every unresolved issue I would document its scope, likely customer impact, proposed containment and accountable owner. A workaround does not automatically make an issue acceptable. Someone must be able to perform it quickly enough and at sufficient scale. Demonstrating a manual correction for five records does not establish that the same procedure can handle five thousand during a busy operating day.
I would define stop conditions with equal care. Who decides, on which signal, and until what point is reversal feasible? Restoring a database may not restore the service if new payments or messages have already reached another system. The recovery plan needs a way to reconcile those transactions, prevent duplicate processing and retain evidence of what has and has not completed.
Supplier evidence and bank responsibility
I would distinguish a supplier assurance, a completed test and the evidence delivered to the bank. A statement that a component is ready is a starting point. A joint decision needs the scope of the checks, known exceptions and external dependencies. The bank's service owner should be able to explain how the component evidence supports end-to-end readiness. This is my proposed analytical method, not a claim about an undisclosed TSB contract.
Communication would also be part of the rehearsal. Customer support needs to distinguish an ordinary delay from an incident; specialists need a consistent incident view; management needs a short explanation of consequences and options. Differences between these views can slow the response even when the technical team identifies the fault correctly. I would test the handover during a simulated failure and check whether the right decision follows.
What I would look for after launch
Release approval should define the first operating period, not end the investigation. I would compare the observed service volumes, error patterns and reconciliation results with the assumptions used for approval. A quiet first hour is weak evidence if the principal workload arrives the next morning. Monitoring should therefore cover the full relevant cycle and the people responsible should know when heightened observation can safely end.
I would also keep the exception population visible. Closing an incident ticket does not prove that every affected customer or record has been restored. A reconciliation between the original affected list, corrective actions and verified outcomes would provide a stronger closure basis. New discrepancies should be assessed for a shared cause before being treated as unrelated support requests.
Finally, I would assess the handover to ordinary operations. Support staff need the remaining limitations, the operations team needs ownership of monitoring signals, and the service owner needs a clear account of unresolved risks. Project documentation should become a usable operating reference rather than an archive that nobody consults after the migration team leaves.
Summary and recommendations
Correctly transferred data are necessary evidence, not the final verdict on a safe launch. I would recommend three distinct views: migration quality, critical-service performance and the ability to handle exceptions. Each should identify an owner, a measurable criterion and a traceable result. Management can then combine them into a release decision without hiding the remaining uncertainties.
My priorities would be to start from customer consequences, examine risky combinations, rehearse recovery and test the organisational response. I see the analyst's contribution as a precise account of readiness and its limits. The deciding factor is not the number of tests listed, but whether their results demonstrate that the bank can continue providing the services customers need.