Check Integration Readiness Before Each Wave

TSB's 2018 migration drew 225,492 complaints. An operational readiness check before each wave turns go or no-go into a decision on evidence.

Alexander Kiel

Business Analyst · Banking & Wealth Management

07.02.2026 · 7 MIN READ · BUSINESS INTEGRATION

ON THIS PAGE

1. Set Exit Criteria for Every Wave

2. Test With Real Volumes

3. Confirm Third-Party Readiness

4. Prepare the Business Teams

5. Run the Operational Readiness Check

6. Plan the Fallback and Hypercare

Sample case: TSB

In short

FAQ

Change is one of the main causes of serious IT incidents in banks. In 2025, UK retail banks reported 446 major operational incidents to the FCA in 2025. Almost one in four (24.2%) came from a change. A readiness check before each migration wave keeps this risk under control.

Large changes carry the most risk. The FCA looked at how banks handle technology change. It found that 24% of high-severity incidents had a root cause relating to change. A bank integration packs many of these changes into a few weekends.

An integration moves in waves. Before each wave, someone has to decide: go or no-go. A readiness check gives that decision a solid basis. Would your steering committee know today what must be in place before the next wave goes live?

A readiness gate before a migration wave: evidence on data and testing, third parties, business teams and fallback feeds one integration readiness check, which leads to go, go with conditions or no-go

0 of 18 done

Click a bullet point to tick it off.

1 · Set Exit Criteria for Every Wave

Could your team say today which numbers would stop the next wave?

☐

Write go criteria you can measure before you plan the wave

☐

Give each criterion one owner and one source of proof

☐

Do not change the criteria once the steering committee approves them

Keep in mind: Readiness criteria are not a test plan. They give the decision-maker a short summary: test results, how ready the business is and which risks are still open.

FULL STEP

Before you plan a wave in detail, agree what "ready" means. Put it in numbers. For example: reconciliation breaks within tolerance, no open critical defects and enough staff trained. Each criterion needs a limit, a source of proof and one owner. Criteria written in the week of cut-over tend to bend to fit the plan.

Big changes go wrong more often. The FCA found that major changes were twice as likely to result in an incident as standard ones. Clear rules help over time: firms that had used change governance for more than a year experienced a lower proportion of incidents.

2 · Test With Real Volumes

When did your team last rehearse a cut-over with a full copy of production data?

☐

Run at least one full rehearsal with data at production size

☐

Reconcile accounts, positions and balances after every rehearsal

☐

Test peak volumes, not only an average day

Keep in mind: If a rehearsal finished on time only because steps were skipped, it failed. Write down what was cut.

FULL STEP

A wave can pass every functional test and still fail on its first Monday. Rehearse with data at production size, peak transaction volumes and the real interfaces. Reconcile every account and position after each rehearsal. Time the full run against the cut-over window.

The FCA found that firms are still heavily reliant on manual testing and peer review. Both are prone to human error. Load matters as much as correct data. On the first working day after its 2018 migration, about 10% of roughly 900,000 internet banking logins at TSB succeeded.

3 · Confirm Third-Party Readiness

Which supplier could stop your next wave and when did you last check its readiness?

☐

List every third party the wave touches

☐

Ask for test results, not assurance letters

☐

Agree support hours and escalation for the cut-over weekend

Keep in mind: A supplier's confirmation is only as good as its own suppliers. Ask who they depend on for the same weekend.

FULL STEP

Most bank integrations depend on software vendors, outsourcers and the target bank's IT provider. Ask each one for proof that it is ready, not a letter of intent. That means finished tests, support staff for the cut-over weekend and named contacts who can act.

The FCA found that over 20% of incidents at third parties were caused by change. It also found that most firms did not effectively track third-party changes. A supplier that changes its own systems in the weeks before your wave adds risk you cannot see.

4 · Prepare the Business Teams

How many extra calls can your service centre handle in the week after a wave?

☐

Train staff on the new processes before each wave

☐

Staff the call centre for peak volumes in the first week

☐

Give branches a short guide to the most common questions

Keep in mind: Business readiness needs its own sign-off. An IT go does not mean the branches are ready.

FULL STEP

IT is only half of an operational readiness check. Relationship managers, operations staff and the call centre need training and updated procedures. They also need answers to the questions clients will ask in the first week. I have worked on both sides of integrations with a leading Swiss bank, having been part of the acquired business in 2017–18 and the acquiring organisation in 2026.

It is easy to underestimate how many clients will call after a wave. After its 2023 Postbank migration, Deutsche Bank said it saw unexpected levels of client enquiries which led to backlogs. BaFin then appointed a special representative to monitor the bank. My article on transferring clients between banks covers the client letters that reduce these calls.

5 · Run the Operational Readiness Check

Has your steering committee ever said no-go and what would it take today?

☐

Hold the readiness check early enough to act on a no-go

☐

Show each criterion as met, not met or accepted risk

☐

Record the decision, the conditions and who decided

Keep in mind: A no-go is a result, not a failure. Set the date of the next possible wave before the readiness check.

FULL STEP

Bring all the proof to one steering committee meeting a few days before cut-over. The PMO shows each criterion as met, not met or met with a risk the business accepts. The committee then decides: go, no-go or go with conditions. Record the decision with the names of the people who took it.

A formal board does not guarantee a real review. The FCA found that change advisory boards approved over 90% of the major changes they reviewed. My article on the one-page decision paper shows how to present a go or no-go so the committee sees the risks, not only the progress.

6 · Plan the Fallback and Hypercare

Who in your bank can stop a cut-over at 2 a.m. and do they know it?

☐

Set the point of no return for each wave

☐

Rehearse the rollback, not only the cut-over

☐

Review incidents every day until they are back to normal

Keep in mind: Extra support ends when agreed criteria are met, not on a date. Keep it until the numbers say otherwise.

FULL STEP

Every wave needs a point of no return. Before it, you need a tested fallback. After it, you need a plan for extra support. Agree who can call a rollback, by what time and on which signals. After cut-over, review incidents, reconciliation breaks and client contacts every day until they are back to normal.

The PRA expects banks to test regularly their ability to remain within impact tolerances in severe but plausible scenarios. A failed migration wave is one of them. TSB's own review shows how fast it gets worse: in 2018, enquiries exceeded the contingency resources already in place.

How Do We Heal Medicine? | Atul Gawande (Surgeon and Writer @ TED)

SAMPLE CASE

TSB

In July 2015, Sabadell bought TSB, which still ran on the Lloyds Banking Group platform. TSB asked Sabadell's IT subsidiary SABIS to build a new platform and move it there. The migration took place over the weekend of 20 to 22 April 2018, for a bank with 5.2 million customers.

The FCA found that testing only concluded the day before the decision to migrate was taken. It also found that supplier confirmations were partly statements of good intention. The PRA later fined the former CIO, who had assured the board that the supplier was ready while TSB had not itself obtained sufficient assurance.

TSB returned to business as usual only in December 2018. It received 225,492 complaints and paid £32.7 million in redress. In December 2022, it was fined £48.65 million by the FCA and PRA.

Key takeaway: A go decision is only as strong as the proof behind it. Finish testing well before the readiness check. Check supplier readiness yourself. Show the steering committee what is still open.

"The failings in this case were widespread and serious which had a real impact on the day-to-day lives of a significant proportion of TSB's customers, including those who were vulnerable."

Mark Steward (Executive Director of Enforcement and Market Oversight @ FCA)

In Short

A readiness check turns each migration wave into a decision based on proof. Set the criteria early. Test with real volumes. Confirm third parties. Prepare the business teams. Decide in one meeting and plan the fallback.

The result is a wave that goes live when it is ready. Or a no-go taken early enough to protect clients, staff and the integration timeline. Start with the criteria for your next wave.

Frequently Asked Questions

What is an operational readiness check before a migration wave?

It is a formal review a few days before each migration wave. The PMO presents proof against agreed criteria: test results, reconciliation, supplier confirmations, business readiness and fallback plans. The steering committee then decides go, no-go or go with conditions. The decision, its conditions and the people who took it are recorded for audit.

What are typical go/no-go criteria for a migration wave?

Typical criteria cover data, technology, people and risk. Examples: reconciliation breaks within tolerance, no open critical defects and rehearsals that finished within the cut-over window. Others are signed confirmations from key suppliers, trained staff in branches and operations and a tested rollback. Each criterion needs a limit you can measure, a source of proof and one owner. The steering committee approves the criteria before wave planning starts.

Who decides go or no-go before a migration wave?

Usually the integration steering committee, based on the readiness check the PMO prepares. Business owners confirm that their teams are ready. IT confirms the technical criteria. Risk functions raise any concerns. The committee should meet early enough to act on a no-go. It should also agree in advance who can call a rollback during the weekend. The decision is then minuted.