Readiness is a decision about a service
Before deploying a release, it is easy to confuse two questions: have the tests passed, and is the service ready for change? The first answer contributes to the second but cannot replace it. A banking application might calculate instalments correctly while refusing logins, repeating requests or failing its evening processing after deployment. I would therefore want a shared account of the evidence, the remaining uncertainty and the people available to intervene.
A useful checklist should reflect the actual change. Editing an explanatory message requires different evidence from migrating customer records or changing a lending decision workflow. Collecting signatures is not the objective. The objective is to show which failures could harm customers, how those failures have been addressed and what demonstrates that the protection works. Every significant item needs both an owner and evidence that someone else can inspect.
A documented case: TSB, United Kingdom, April 2018
In their enforcement announcement of 20 December 2022, the FCA and PRA described disruption following TSB's April 2018 migration. The data transferred, but the new platform suffered technical failures affecting banking services. This is the documented event; the control approach below is my proposed interpretation, not a description of TSB's internal practice. [1]
The distinction between data correctness and service availability matters to my analysis. Matching the number of migrated accounts cannot prove that a customer can log in, see the correct balance, make a payment and receive a correct confirmation. I would express readiness through complete customer journeys, including their external dependencies and support arrangements. Success within one component must not conceal an unprepared connection elsewhere.
A hypothetical instalment migration
Imagine a fictional bank with 80,000 loans introducing a new repayment schedule store. The data team reconciles identifiers and amounts successfully. Integration testing nevertheless shows that two percent of messages take longer than the customer application allows under peak load. I would not dismiss that as a cosmetic problem. Two percent represents as many as 1,600 records requiring further investigation; it does not automatically mean 1,600 harmed customers.
My first question would be whether the messages are lost, delayed in display or merely acknowledged late after successful processing. Each explanation requires a different response. Repeating messages without checking uniqueness could create another problem. These numbers illustrate a method; they are not figures from TSB and do not establish an acceptable risk threshold for a real bank.
Building a decision package
I would begin by identifying the functions, records and interfaces that change. Alongside expected behaviour I would document assumptions about batch timing, request volumes, supported versions and supplier availability. For every successful test, I would need the application version, configuration and dataset. A result obtained against an earlier build may not support the package that will actually be deployed.
I would then separate data conversion, functional journeys, performance under load and recovery following interruption. For each area I would distinguish direct testing from estimates. Supplier capacity would not become verified merely because somebody had promised it during a meeting. I would seek a specific assurance record and present its limitations to the people responsible for the release decision.
The package should also explain outstanding defects in operational terms. A defect count treats unlike problems as if they were interchangeable. I would instead identify the affected journey, the conditions that trigger the defect, available workarounds and the consequences of delayed correction. That gives decision makers a way to evaluate the release rather than simply accept a red or green status.
Define boundaries before deployment
I would attach stop conditions to the decision. Repeated duplicate records or an unavailable balance display might justify pausing further rollout. The service owner would need to agree the particular threshold in light of the operation's importance. A universal success percentage can mislead: one failing sensitive transaction type may matter more than thousands of successful low-risk enquiries.
I would not assess the rollback plan solely by the existence of a document. I would ask whether it had been rehearsed, who had the necessary permissions and how transactions generated after the switch would be handled. Restoring the earlier application does not necessarily restore its earlier data state. Where rollback is unsafe, an alternative containment procedure must be explicit before the change starts.
Communication belongs in that procedure. Support staff need to know which customer symptoms could signal a release problem, where to report them and which statements have been approved. Technical teams need a single decision route when contradictory observations appear. Otherwise each team can be locally correct while the institution loses time assembling the overall picture.
Observe the first real operating cycle
After deployment, I would compare technical signals with business outcomes. Processor utilisation cannot show whether customers receive complete documents. Alongside response times, I would examine completed applications, unexplained reconciliation differences and repeated operations. An agreed coordination point would bring these observations together rather than leave them distributed across several unrelated conversations.
Observation must cover the service's real cycle. A monthly statement service has not been validated simply because the morning after deployment was uneventful. I would want the first relevant close or a representative rehearsal, together with named responsibility for reviewing the result. Ending heightened support too early can transfer unresolved risk into routine operations where people no longer expect a connection to the release.
Summary and recommendations
Readiness should demonstrate the ability to maintain a customer service, not just the presence of successful tests. I recommend bringing the change scope, evidence, open risks, owners and stop conditions into one decision record. For material changes, recovery should be rehearsed and observation should extend through the first meaningful operating cycle.
An analyst's contribution is to connect these pieces clearly. I would not need to decide the acceptability of every technical risk personally. I could help ensure that significant unverified claims do not disappear behind green indicators and that accountable decision makers know what they are approving. NIST's SSDF is offered as further reading on demonstrable development practices, not as a special legal requirement for this fictional deployment. [2]
Keep the decision inspectable
For the hypothetical repayment migration, I would retain a compact record linking each customer operation to evidence, uncertainty and its accountable owner. Actual switch times, versions and unplanned configuration changes belong in the record too. They let the team distinguish the tested state from an improvised recovery state and decide which checks must be repeated before ordinary support takes over.