In April 2018 a UK bank moved its customer and corporate data onto a new IT platform. The data moved successfully. The service did not. According to the Bank of England and FCA announcement of the TSB penalties, all of TSB’s branches and a significant proportion of its 5.2 million customers were affected when the new platform failed on arrival, across branch, telephone, online and mobile banking. Recovery took until December. In December 2022 the two regulators fined the bank £48.65 million, and it had already paid £32.7 million in redress to customers.
The detail worth holding onto is the first one: the data migrated successfully. By the measure many migration plans track, the project worked. The regulators’ finding was about something else — that the bank failed to organise and control the programme adequately, and to manage the operational risk in its arrangements with a critical third-party supplier.
Moving data and moving a business are two different events. Many programmes measure the first and bet on the second.
Why the date is the wrong unit
Cutover dates are usually set by something outside the operation: a licence expiring, a vendor’s resourcing plan, a financial year, a board commitment made eighteen months earlier. The date then becomes the thing everyone manages to, and every trade-off after that is made in its favour.
The better question is not when but how much disruption the business can absorb, and for how long. UK financial regulation has a useful name for this. Under FCA PS21/3 on operational resilience, firms identify their important business services and set an impact tolerance for each — the maximum disruption the service can tolerate before harm to customers or markets becomes unacceptable. The firms it covers had until 31 March 2025 to be able to stay within those tolerances.
Most businesses are not regulated that way, but the idea travels well. A distributor can say that orders must be taken and shipped within one working day. A clinic group can say appointments must be bookable again within four hours of any outage. An accounting practice can say no client filing deadline may be missed. Once that sentence exists, the cutover plan has something to be tested against, and the date becomes an output of the plan rather than its premise.
Five decisions that belong to the business
A migration has hundreds of technical decisions, and the project team should own them. Five decisions should not be delegated to the project, because their consequences land on the operation.
1. What “correct” means, agreed before anything moves
Reconciliation is usually treated as a test step at the end. It works far better as a definition at the start. For each kind of record — customers, open orders, balances, stock, contracts — agree three things: the count that must match, the value total that must match, and a short list of the hard cases that must be checked by hand. Partial deliveries, credit notes against closed invoices, merged customer accounts: every business has its own.
Where personal data is involved, there is also a data protection angle. The ICO’s guidance on the accuracy principle expects organisations to take all reasonable steps to ensure personal data is not “incorrect or misleading as to any matter of fact”. A migration that silently truncates addresses or merges two customers creates exactly that. Clean at the source, before extraction; cleaning in transit hides the problem inside the migration scripts, where nobody in the business can see it.
2. The cutover pattern, chosen by the cost of an error
| Pattern | Suits | What it costs |
|---|---|---|
| Single cutover | Tightly coupled data that cannot live in two systems; a short, quiet window | Everything depends on one weekend; rollback must be real, not theoretical |
| Phased by entity, site or product line | Separable units; a pilot site that is representative | Interfaces between old and new for the duration; a longer programme |
| Parallel running | Where an error is expensive and hard to detect — payroll, billing, regulatory reporting | Double entry or automated comparison for weeks; tired teams |
The cheapest pattern on paper is often a single cutover. It is only cheap if nothing goes wrong. The choice is a statement about how much risk the business is prepared to carry, and it should be made by the people who will carry it.
3. Go/no-go criteria and a rollback point, written before the weekend
At two in the morning on cutover night, with a sponsor on the phone and a vendor team that has been awake for twenty hours, nobody makes a good decision about whether a 0.4% reconciliation break is acceptable. That decision should already have been made, in daylight, on one page: the conditions for proceeding, the conditions for stopping, who has the authority to stop, and the last moment at which going back to the old system is still possible.
A rollback that has never been exercised is not a rollback. The point of no return should be known to the hour, and everyone on the call should know when it has passed.
4. A rehearsal of the cutover, not only a test of the system
System testing proves the new platform works. It does not prove that the organisation can move onto it in the time available. A full dress rehearsal — production-sized data, the real runbook, the real people, a stopwatch on every step — answers the questions that sink cutovers: whether the extract finishes in the window, whether the load order is right, whether the reconciliation can be completed before the business opens.
NIST’s Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1) treats a recovery plan as something that is tested, exercised and maintained rather than written once. The same discipline applies to the cutover plan. One rehearsal usually finds enough to justify a second.
5. Hypercare measured in business outcomes
The weeks after go-live decide whether a cutover is remembered as a success. Monitoring that reports the system is up is not enough. Watch the operation: orders posted, invoices matched, payments released, calls answered, the size of the exception queue and how old its oldest item is. Name an owner for each, meet daily, and agree in advance what triggers escalation. The damage that lingers after a cutover is usually a small error nobody was assigned to notice.
The third party is part of the cutover
The TSB finding named outsourcing risk explicitly. Most mid-market migrations depend on an implementation partner or a software vendor, and the contract usually covers the build far better than it covers the cutover. Before signing, it is worth confirming that the agreement gives you rehearsal time with the vendor’s team, named people on cutover night, access to logs and data during hypercare, and a defined exit if the platform does not perform.
For financial entities in the EU, the Digital Operational Resilience Act (DORA) sets out in Article 9 an expectation of documented ICT change management in which changes are recorded, tested, assessed, approved, implemented and verified in a controlled way. Outside regulated finance it is a sound checklist for any organisation changing a core system.
What this cannot do
- It does not rescue a poor choice of system. A well-run cutover onto a platform that does not fit the operation still leaves the operation on a platform that does not fit.
- It does not remove risk; it prices it. Rehearsals and parallel running cost time and money. The purpose is to spend that deliberately rather than discover the cost on the night.
- It does not replace engineering competence. Reconciliation rules and go/no-go criteria are only as good as the extract, transform and load work underneath them.
- It is not legal or regulatory advice. PS21/3 and DORA apply to the firms in their scope. Where they apply, your legal and compliance advisers decide what they require of you.
Where to start
If a system change is on the horizon, four pieces of paper will tell you most of what you need to know. A one-sentence tolerance for each service the business cannot interrupt. A reconciliation definition for each record type, with its hard cases. A one-page go/no-go and rollback note with a named decision-maker. A rehearsal date in the plan, well before the cutover date. If any of the four is hard to write, that difficulty is the most useful finding the programme will produce.
If you are changing a core system and want the cutover designed from the operation’s side, that is data, integration and migration work, and it usually starts with an assessment.
