Service acceptance establishes that a migrated system can deliver its required business operations, including failures and recovery. Data-transfer acceptance establishes that the defined information moved correctly. TSB’s April 2018 migration provides a documented case in which those outcomes diverged.
The FCA’s release of 20 December 2022 states that the data migration succeeded, while the new platform immediately suffered technical failures that disrupted banking channels. The regulator identified programme-control and outsourcing-risk failures and reported that a return to business as usual took until December 2018.
Preserve the limits of the account
These findings describe a historical migration and its aftermath. They do not establish TSB’s current operating condition, corruption of the transferred data, or a rollback to the previous platform.
The inspected release also cannot support an invented account of a particular failed test, database setting, or technical repair. A complete causal reconstruction would require additional evidence linking each proposed mechanism to the incident.
A migration case remains useful without that reconstruction. The documented separation between data success and service failure is sufficient to challenge acceptance criteria that treat transferred information as the entire service.
Define acceptance around an operation
The following acceptance approach is an inference from that distinction and from operational monitoring practice, rather than a description of the tests TSB performed or omitted.
A business operation needs inputs, identity, application behavior, dependencies, and an observable result. Row reconciliation addresses part of that path. It does not exercise every interface, authorization decision, capacity condition, or external service on which the operation depends.
A test portfolio should therefore connect data checks to representative user journeys and background work. The accepted population and operating conditions should be explicit so that a passed sample is not represented as proof of every service path.
Monitor symptoms and diagnostic context
Google’s SRE guidance distinguishes black-box monitoring of externally visible symptoms from white-box monitoring based on internal instrumentation. These signals serve complementary purposes.
A healthy process or responding endpoint can coexist with a failed business action. Conversely, a user-visible failure needs internal context to support diagnosis. More logs do not establish that operators can recognize the consequential symptom or determine its scope.
A controlled failure exercise can test whether a material business failure produces actionable evidence and reaches a named responder within the required interval. That is a proposed validation method, not a claim about an unobserved TSB monitoring configuration.
Outsourced work still needs inspectable results
A supplier can perform a defined migration activity while the overall service remains dependent on customer decisions and other components. Acceptance responsibilities should follow the end-to-end outcome across those boundaries.
The record should identify who supplies evidence, who evaluates it, who resolves exceptions, and who can stop or alter the transition. A completion statement from one workstream should retain its actual scope when passed into a programme decision.
Recovery also requires a specific disposition for transactions accepted after cutover. General rollback guidance can inform that design without implying that TSB used or rejected a particular reversal route.
Keep the retrospective evidence separable
A migration review should record impact, mitigation, contributing conditions, decisions, and follow-up actions with their sources and dates. Google’s postmortem model provides a useful structure while leaving room for migration-specific alternatives and longer-term outcomes.
Competing explanations and missing evidence should remain visible. A coherent story is not enough to establish that one technology or sourcing model caused the result.
The reusable distinction is precise: correct movement of data and successful operation of the resulting service require different demonstrations. A migration decision needs both where both are required outcomes.