Executive Paper No. 05 · Migrations

A Migration Without a Rollback Path Is a Bet

Every cutover puts the business on the line for a weekend. Operations and technology leaders should refuse to go live until they can prove they can come back.

The Decision in Front of You

Your organization will move something important in the next two years. It might be a data center exit, a cloud migration, a database engine change, an operating system upgrade across hundreds of servers, or a rewrite onto a new application framework. Each of these ends in a cutover: a window in which production work stops on the old platform and starts on the new one.

The decision is what you require before you approve that window. Most go/no-go meetings ask whether the new platform is ready. The more useful question is how the team returns to the old platform, how long that takes, and whether anyone has done it.

The stakes are measured in customers who cannot pay, ship or get paid. At TSB Bank, the cost of a failed cutover included £48.65 million in regulatory fines and £32.7 million in customer redress, a combined £81.35 million before counting the bank's own remediation costs 12.

What's Happening

The reference case: TSB, 2018

Over the weekend of 20 to 22 April 2018, TSB moved five million customers' records to a new banking platform in a single migration event 34. The data moved. The platform failed. Online, mobile, telephone and branch banking were disrupted across all 550 branches and a significant share of TSB's 5.2 million customers 23. TSB did not return to business as usual until December 2018 2.

The Prudential Regulation Authority's final notice, published in December 2022, sets out what went wrong before the weekend. In the weeks before migration, TSB accepted a supplier proposal to run performance testing on only one of the two data centres, leaving a test environment that the regulator described as distinctly different from production 3. That decision was neither documented nor escalated 3. Non-functional testing, which covers performance and capacity, ran until the day before the go-live decision 3. TSB later said the two data centres, specified to be identical, had been configured inconsistently and that this was a key cause of the disruption 4.

On rollback, the notice is blunt. A roll-back plan was not possible in the circumstances, and once migration had occurred it was essentially impossible to roll back from the changes made 3. The board had asked for a fall-back plan in case migration could not go ahead 3.

The independent review commissioned by TSB's board, written by the law firm Slaughter and May and published in November 2019, criticized the choice to move five million customer records in a single weekend. It found that alternatives such as a phased migration were not seriously considered and that the board did not substantively discuss the approach 5. TSB had run nine dress rehearsals and a pilot with more than 1,600 staff before go-live 4. Its late performance testing still ran on one data centre, and the fault sat in the difference between the two 34.

Recent cases show the pattern continuing

BNF Bank, Malta, 2025. In late March 2025, BNF replaced the core banking system it had run since its founding in 2008 with Temenos Transact, and switched its card network from Visa to Mastercard in the same transition 67. Customers were locked out of accounts, and some reported missing funds and double transactions for nearly a month 8. In May the chief executive apologized and said the data migration, including accounts and balances, had been completed and fully reconciled 7. According to a commentator's summary of the chief executive's interview with the Times of Malta, the bank had run more than 3,500 tests over 18 months, spent more than €1 million stabilizing services, accepted that changing card provider at the same time was a mistake, and was asked by Malta's financial regulator to take corrective measures 9.

Reconciled balances proved the data arrived intact. Customers still could not use their accounts, and a second major change in the same weekend made faults harder to isolate.

GTBank, Nigeria, 2024. Guaranty Trust Bank began moving to the Finacle core banking platform on Friday, October 11, 2024, and told customers to expect completion by the following Monday 10. The migration overran. Some customers could not withdraw money, and the bank was still apologizing publicly in late November, more than six weeks after the start 10. The same coverage notes that Sterling Bank customers saw several days of disruption during a core migration in September 2024, and that Zenith Bank had an outage while preparing its own move 10. Public reporting does not describe the bank's rollback plan. The lesson for executives is that a cutover window needs a defined abort time; once it passes, the business is committed to fixing forward for as long as that takes.

Sonos, 2024. Sonos released a rebuilt mobile app on May 7, 2024 11. Complaints were widespread, and many customers asked for the old app back 12. In August the chief executive explained why that was not possible: the company had updated the software running on its speakers and in its cloud since the launch, and after extensive testing it concluded that re-releasing the old app would make the problems worse 12. Sonos estimated short-term remediation at $20 million to $30 million, cut about 100 jobs and postponed two product launches 11. Its rollback path had decayed as the rest of the system moved on.

Google Cloud's June 2025 global outage traced to new code that had no feature flag, a switch that turns a change off without redeploying 13.

Why the Usual Approach Fails

Rollback plans are written and never executed. A document that says "restore from backup and repoint DNS" is a hypothesis until someone runs it against production-sized data and times it. Without that timing, nobody can say when the decision to reverse has to be made.

Rehearsals use the wrong environment. TSB's rehearsals were real and numerous 4. Its performance testing ran against an environment that differed from production in the place that failed 34. A rehearsal proves only what its environment shares with production.

Data checks stop at the database. Row counts and checksums confirm that records moved. A customer logging in or a card authorizing needs its own test. BNF's balances reconciled while customers were locked out 78.

Schedules squeeze the safety work. When a program runs late, testing is compressed and run in parallel instead of in sequence. Commentary on the FCA's findings at TSB noted that testing finished only the day before migration 14. Go-live dates announced to customers or regulators become commitments that override what the test results say.

Cloud providers' own guidance anticipates these failures. Microsoft's Cloud Adoption Framework tells teams to retain the source environment as a fallback, keep the ability to revert DNS records and configuration, verify data with checksums and hashes instead of row counts alone, and watch the new platform closely for the first 24 to 48 hours. It warns against premature declarations of success 15. AWS guidance asks teams to document a rollback procedure in the cutover plan, include rollback time when sizing the downtime window, and rehearse the cutover 16.

The Framework: The Reversible Cutover

A cutover is ready when the team can show three things to the executive who approves it. A rollback has been rehearsed and timed. Old and new systems have processed the same work in a parallel run and produced the same results. Data has been verified by the people who own the business process. A written point of no return then tells everyone when reversal stops being an option.

Exhibit 1The Reversible Cutover: no go-live until the way back has been proven
flowchart LR
    A[Rehearse rollback<br/>on production-equivalent<br/>environment, timed] --> B[Parallel run<br/>same transactions<br/>outputs compared]
    B --> C[Verify data<br/>counts, checksums,<br/>business sign-off]
    C --> D[Go / no-go<br/>point of no return<br/>written down]
    D --> E[Cutover<br/>one change<br/>at a time]
    E --> F[Hold period<br/>old system kept<br/>ready to resume]
    F --> G[Decommission<br/>after criteria met]
    E --> H[Roll back<br/>if abort criteria hit]
    H --> A

Source: author's framework, consistent with Microsoft Cloud Adoption Framework 15 and AWS Prescriptive Guidance 16.

Rehearse the rollback. Run the full reversal at least once on an environment that matches production in configuration, data volume and network layout. Time it. The measured time sets the latest moment in the cutover window when a rollback can still start.

Run in parallel. Push the same real transactions through old and new systems for a defined period and compare the outputs: balances, invoices, shipments, reports. Differences get explained before go-live. Where a full parallel run is impossible, compare a sample of real transactions replayed against the new system.

Verify data at two levels. Technical checks cover counts, checksums and hashes 15. Business checks cover the twenty or thirty transactions that matter most, performed by the people who own them, with written sign-off.

Write down the point of no return. Reversal becomes impractical at a known moment, usually when the new system accepts writes the old one cannot absorb. Name it, time it, and list the abort criteria checked before crossing it.

Change one thing at a time. BNF's chief executive called the simultaneous card switch a mistake 9. Two changes in one window give a fault more places to hide.

Hold before you decommission. Keep the old system ready to resume for a defined period, and keep anything that depends on it backward compatible. Sonos lost its rollback option because the systems around the old app changed while it was out of service 12.

Exhibit 2Rollback looks different for each kind of cutover, and each kind has its own point of no return
Cutover type What rollback means Typical point of no return Verification before go-live
Data center move Repoint traffic and DNS to the original site, which stays powered and current Original site lease ends or hardware is removed Full failover and failback test; performance test in the new site at production load
Cloud migration Revert DNS and configuration; resume on the retained source environment 15 New system accepts writes that are not replicated back to the source Checksums on migrated data; end-to-end tests of critical processes 15
Database engine or schema change Switch application back to the old database, fed by reverse replication Reverse replication is turned off, or the new schema accepts data the old one cannot store Row counts, checksums, and replayed production queries compared on both
Operating system upgrade Boot the previous image or snapshot Snapshot expires or data written after upgrade cannot be read by the old version Staged rollout to a small share of servers first, with defined health checks
Application or framework rewrite Route users back to the old version behind a switch or feature flag Backend, firmware or data format changes that the old version cannot handle 12 Parallel run on real transactions; old and new outputs compared

Source: author's analysis, informed by Microsoft Cloud Adoption Framework 15 and AWS Prescriptive Guidance 16.

Costs, Risks, and Tradeoffs

Reversibility costs money and time. Some systems do not justify it.

Exhibit 3Tradeoffs of requiring a reversible cutover
Area Cost or risk Mitigation
Double running Old platform, licenses and hosting stay paid for during the hold period Set a fixed hold period with exit criteria in the business case from the start
Schedule Rehearsals and parallel runs add weeks before go-live Plan them into the original timeline; refuse to compress them when the program runs late
Reverse replication Writing new data back to the old system adds engineering work and its own failure modes Limit reverse replication to the hold period; test it in rehearsal
False comfort A rollback rehearsed on the wrong environment proves nothing, as TSB showed 3 Require that rehearsal environments match production in configuration and volume
Decision paralysis Teams roll back for minor issues that a fix forward would solve faster Agree abort criteria in advance; AWS guidance also calls for fix-forward contingencies 16
When this is wrong Low-risk, stateless or easily rebuilt systems; brief maintenance changes behind an existing feature flag; vendor-mandated cutovers where no old version can run Use standard change control and a tested backup; for vendor-forced moves, negotiate a supported fallback in the contract

Source: author's analysis.

How to Act

Exhibit 4A one-year roadmap
Window Actions Owner Milestone
First 30 days List every migration planned in the next 18 months. For each, record the business processes affected, the planned cutover window, and whether a rollback has ever been executed. CTO with COO Migration register approved; each entry marked rehearsed or not rehearsed
First 30 days Adopt the three go-live conditions as policy: rehearsed rollback, parallel run, business-signed data verification. COO Policy issued; applies to every cutover that touches customers or money
First 90 days For the next major cutover, build a production-equivalent rehearsal environment. Rehearse the rollback and record the time. Write the point of no return and abort criteria. Migration program lead with infrastructure lead Rollback executed end to end with measured duration under the planned window
First 90 days Define the parallel run and the 20 to 30 business transactions that must match. Assign a business owner to each. Business process owners with QA lead Parallel-run plan and sign-off list approved
First 365 days Run every major cutover through the gates. Keep each old system ready through a defined hold period. Review each cutover within two weeks of go-live. CTO Zero customer-facing cutovers without a rehearsed rollback; post-cutover reviews on file
First 365 days Report to the executive committee on rollback rehearsal times, parallel-run mismatches found and fixed, and hold periods completed. COO Quarterly report delivered and reviewed

Source: author's recommendation.

Questions to Ask Your Team

  1. Have we ever executed this rollback, end to end, and how long did it take?
  2. How does the rehearsal environment differ from production, item by item?
  3. At what time during the cutover weekend does rollback stop being possible?
  4. Which business transactions will we compare between old and new before we switch, and who signs off on each?
  5. Are we changing anything else in the same window, and could that change go separately?
  6. How long will the old system stay ready to take traffic back, and what keeps it compatible in the meantime?
  7. If testing slips, what gives way: the go-live date or the test plan?
  8. What would we tell customers and regulators on Monday morning if we had to roll back?

Closing

A cutover is a short window in which the whole business depends on one plan working. A rollback that has been rehearsed, a parallel run that matched, and data that business owners have signed off turn that window into a decision that can be reversed. Without them, the organization is betting its customers and its regulatory standing on the first attempt. Approve the cutover only when the team can show you the way back.


Sources

  1. Financial Conduct Authority and Prudential Regulation Authority. "TSB Fined £48.65m For Operational Resilience Failings." Joint press release via Mondo Visione. 2022. https://mondovisione.com/media-and-resources/news/uk-financial-conduct-authority-and-uk-prudential-regulation-authority-tsb-fined-20221220/.
  2. Bank of England. "TSB fined for operational resilience failings." News release. 2022. https://www.bankofengland.co.uk/news/2022/december/tsb-fined-for-operational-resilience-failings.
  3. Prudential Regulation Authority. "Final Notice to TSB Bank plc." 2022. https://www.bankofengland.co.uk/-/media/boe/files/prudential-regulation/regulatory-action/final-notice-from-pra-to-tsb-bank.pdf.
  4. TSB Bank. "Slaughter and May." Press release on publication of the independent review. 2019. https://www.tsb.co.uk/news-releases/slaughter-and-may/.
  5. IT Pro. "TSB's IT disaster pinned on 'big bang' approach to migration." Coverage of the Slaughter and May report. 2019. https://itpro.com/business-strategy/digital-transformation/354155/tsbs-it-disaster-pinned-on-big-bang-approach-to.
  6. FinTech Futures. "BNF Bank migrates to Temenos Transact with Validata's ConnectIQ." 2025. https://www.fintechfutures.com/core-banking-technology/bnf-bank-goes-live-on-temenos-transact.
  7. BNF Bank. "A message to BNF customers." Press release. 2025. https://www.bnf.bank/about/news/a-message-to-bnf-customers.
  8. Lovin Malta. "BNF Bank customers still facing problems almost a month after tech update." April 2025. https://lovinmalta.com/news/bnf-bank-customers-still-facing-problems-almost-a-month-after-tech-update.
  9. Bonnici, A. "BNF's botched upgrade: the final chapter." Commentary summarizing Times of Malta reporting. October 2025. https://www.alanbonnici.com/2025/10/bnfs-botched-upgrade-final-chapter.html.
  10. Nairametrics. "GTBank admits challenges in core banking transition, apologizes to customers." November 2024. https://nairametrics.com/2024/11/28/gtbank-admits-challenges-in-core-banking-transition-apologizes-to-customers.
  11. TechSpot. "Sonos struggles with layoffs, delays after disastrous app redesign." 2024. https://www.techspot.com/news/104400-sonos-struggles-layoffs-delays-after-disastrous-app-redesign.html.
  12. 9to5Mac. Coverage of Sonos CEO Patrick Spence's August 20, 2024 Reddit AMA on the old app. August 2024. https://9to5mac.com/2024/08/21/old-sonos-app/.
  13. Google Cloud. Service Health incident report for the June 12, 2025 outage. 2025. https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW.
  14. DLA Piper, Technology's Legal Edge. "Managing migration and go-live risk: lessons from the TSB/Sabadell migration." 2023. https://www.technologyslegaledge.com/2023/01/managing-migration-and-go-live-risk-lessons-from-the-tsb-sabadell-migration/.
  15. Microsoft. "Complete the migration." Cloud Adoption Framework for Azure. https://learn.microsoft.com/azure/cloud-adoption-framework/migrate/release/complete-migration.
  16. Amazon Web Services. "Pre-cutover stage." AWS Prescriptive Guidance: Best practices for migration cutover. https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/pre-cutover-stage.html.

The views in this paper are the author's own and do not represent any employer. Scenarios are hypothetical. This paper is not legal, financial, or compliance advice.

From the author

Want this decision made with your numbers?

Watkins Labs does the work this paper describes. Talk to Chris directly: no sales team, no pitch deck.

Systems down? Emergency recovery