10decoders
The Data Was Right and the Bank Still Went Dark
In April 2018, TSB moved about five million customer records to a new platform over a single weekend. Contemporary reporting on the aftermath says the data itself migrated successfully. What failed was everything around it. Customers could not log in by phone, online, mobile, or in branches, and some were still reporting problems in December of that year. The independent review by Slaughter and May, published in November 2019, found that the platform was not ready to support the full customer base and that the live proving had not been carried out at a sufficient scale.
That distinction matters for anyone planning a modernization. Most migration test plans are built around reconciliation: row counts, checksums, field-by-field comparisons between source and target. Those checks answer one question, which is whether the data arrived. They say nothing about whether the new system can authenticate five million people on a Monday morning, whether the batch jobs finish inside the window, or whether the call center can see the same account the customer sees.
The review also found that the board did not weigh the single-event approach against phased alternatives, and that the programme involved more than 70 suppliers and over 1,400 people, with weak oversight of the suppliers. TSB has disputed parts of the report and points to two data centres that were configured differently despite being specified as identical. Even on TSB’s account, the lesson holds. A migration is a change to a running service, and the service is what customers experience. Treating it as a data copy with a go-live date at the end is how teams pass every reconciliation check and still fail on day one.
A migration is finished when the service survives its first full day of real traffic, not when the row counts match.
Six Ways a Reconciled Migration Still Fails on Day One
None of these show up in a row-count report. The severity label reflects how much damage each causes when the data is correct but the cutover is not ready.
| Cutover gap | What happens in production | Severity |
|---|---|---|
| Rehearsals run at a fraction of real volume | Dress rehearsals pass on a sample. Full customer load exposes slow queries, lock contention, and exhausted connection pools that no small test could reach | Critical |
| No tested path back once new writes exist | Rollback works until customers transact on the new system. After that, going back means reconciling changes made in two places, which nobody has practiced | Critical |
| Authentication and identity not tested at scale | Accounts exist and balances are right, but logins fail, sessions time out, or credentials do not carry across. Customers see an empty door | High |
| Environments differ in ways nobody listed | Production sites are configured differently from the ones tested. A setting that matched in rehearsal behaves differently under real load | High |
| Batch, reporting, and downstream feeds left for later | The online path works while overnight jobs, statements, and partner feeds break. The damage shows up a day or a week after go-live | Moderate |
| Support teams see a different record than customers | Agents work from stale views or separate tools, so they cannot confirm or fix what customers report | Moderate |
Not sure where your cutover readiness gaps are?
10decoders reviews a planned migration against the failure modes above, covering rehearsal scale, rollback after live writes, and environment parity. You get a ranked gap list and a cutover plan your leadership can sign off.
Book a Free AI Assessment →Cutover Is a Load Event, Not a Copy Job
The most useful shift is to treat the cutover as a performance and recovery event with its own test plan. That starts with rehearsal at full scale. A dress rehearsal on a tenth of the data tells you the scripts run. It does not tell you how the platform behaves when every customer arrives at once, which is exactly what happens after a weekend outage. Generate synthetic load at production volume, include the login path, and run it against an environment built from the same configuration as production, not one that is supposed to match it.
The second shift is to plan the way back before the way forward. Rolling back is easy on the first night, while the old system is still the system of record. It gets harder with every new transaction on the target. Decide in advance the point after which you will roll forward instead, and rehearse both. If you cannot describe how a payment made on the new system at 9am would be reflected on the old one at noon, you do not have a rollback plan. You have a hope that nothing will need one.
The third is to avoid the single-event cutover where the business allows it. Moving customers in cohorts, starting with staff and a small low-risk group, turns one irreversible weekend into a series of small, observable steps. Each cohort gives you real traffic, real support calls, and real evidence before the next one moves. A phased approach takes longer on paper. It is also the only approach that lets you stop when the first signal is bad, rather than after five million people have crossed over.
Data Checks Are the Test Plan
Row counts and checksums gate go-live. Rehearsals use sample data, rollback is a paragraph in the runbook, and one weekend is planned for everyone.
Full-Volume Rehearsal and Parity Checks
Load tests run at production volume including login, environments are compared setting by setting, and the team has practiced both rollback and roll-forward.
Cohort Cutover With Stop Criteria
Customers move in staged cohorts, each with written go and stop thresholds. Support, batch, and downstream feeds are in scope from the first cohort.
Checklist: Is Your Cutover Ready, or Only Your Data?
Answer these for the next migration on your roadmap. Any item you cannot evidence is a gap to close before a date is set.
Ask your migration team for the rollback rehearsal, not the reconciliation report, and read the first one more carefully.
What to Do This Week
01 List every cutover assumption you have not tested
Take the current cutover plan and write down each statement it depends on, such as “the target handles peak logins” or “production matches staging.” Mark each one as evidenced, assumed, or unknown. The assumed and unknown rows become your test backlog, ranked by how bad a failure would be on the first Monday after go-live.
02 Compare rehearsal and production settings line by line
Export configuration for every environment involved, including each data centre or availability zone, and diff them. Look at capacity, connection limits, timeouts, certificates, and network rules. Any difference with no written reason gets either fixed or accepted by a named person. This is a one-day task that would have been cheap to do before any large cutover.
03 Rehearse rollback with live writes in the target
In a rehearsal environment, run the cutover, push a few thousand realistic transactions through the new system, then execute the rollback and time it. Record what could not be reversed cleanly and who made the call. If the exercise exposes a gap, you have found it with nothing at stake.
04 Replace the single go-live date with cohort gates
Draft a cohort plan: staff first, then a small group of low-risk customers, then larger waves. For each cohort, write the numbers that would pause the next wave, such as login failure rate, payment error rate, and support queue length. Get these thresholds approved by the business owner before the project sets a calendar date.
Let 10decoders Pressure-Test Your Cutover Plan
We review one planned migration: rehearsal design and load profile, environment parity, authentication and batch coverage, rollback and roll-forward rules, and a cohort plan with stop criteria. You leave with a ranked gap list and a readiness checklist your steering group can use.