Big bang or increments: what four audited failures say about your cutover strategy
March 7, 2026 · PRINCE2 Agile
The most consequential decision on most large implementations is made early, discussed briefly, and rarely revisited: does this go live all at once, or in pieces?
It is usually presented as a technical question. It is not. It is a governance question, because a single cutover removes the organisation’s ability to change its mind, and the value of being able to change your mind is exactly what incremental delivery buys.
Four organisations chose a single cutover. All four have a published investigation. Read together, they describe the same mechanism working four times.
The four
TSB, April 2018. Approximately five million customers migrated off Lloyds Banking Group’s platform onto a new core banking system over one weekend. Slaughter and May’s independent review found that TSB “did not give sufficient consideration to whether a largely single-event migration was the right choice.” Across the programme 34,671 defects had been identified; 4,424 remained open at go-live. Disruption ran, on the FCA’s reckoning, from 22 April to 10 December 2018. Total 2018 cost to TSB: £330.2 million. Regulatory penalties in December 2022: £48.65 million.
Birmingham City Council, April 2022. A big-bang go-live of Oracle Fusion Cloud across finance, HR, payroll and procurement at Europe’s largest local authority, after a slip from December 2020. The solution design was never fully resolved beforehand. Bank reconciliation could not be tested end to end. For roughly eighteen months there was no usable audit trail. Budget history: £19.965 million at approval in 2021, £40 million in 2022, £131 million in 2024, £170 million reported by September 2025.
Phoenix, Government of Canada, February and April 2016. Federal pay consolidated onto a single system across roughly 101 departments in two waves. The pilot was cancelled in June 2015 because of major defects, and no comprehensive system-wide testing was performed before go-live. Twenty per cent of reviewed functions failed testing and were not retested. Over 100 critical pay processing functions were removed or deferred to stay inside the approved $155 million software budget, against IBM’s estimate of $274 million. At April 2017, 51 per cent of employees had a pay error.
Revlon, February 2018. A big-bang SAP cutover at the company’s largest manufacturing facility, as part of integrating an acquisition. Warehouse and production integration failures, inadequate user training, and an order backlog that set operations back roughly two months. Revlon’s own 10-K: 2018 net sales “were negatively impacted by service level disruptions … resulting from the Company’s launch of a new SAP enterprise resource planning (‘ERP’) system.” $64 million of net sales not shipped; $53.6 million of incremental remediation charges.
The mechanism they share
Set the four side by side and the same sequence appears.
A date is fixed before the work is understood. TSB committed publicly to a Q1 2018 migration before re-planning was complete. Birmingham’s design was unresolved at go-live. Phoenix’s budget was approved at $155 million against a $274 million estimate.
Testing is compressed to protect the date. TSB reduced load targets after early tests failed and concluded non-functional testing the day before the migration decision. Phoenix cancelled its pilot and skipped system-wide testing. Birmingham’s staff “were unable to fully test the solution because the first step in the process, loading the bank files, and key consolidation reports were failing.”
Known defects are carried across, having been reclassified. TSB’s lower internal defect count was reached, per the review, “by inappropriately excluding a number of major categories of defect.” Phoenix’s 20 per cent test failures were not retested.
And then there is no way back. This is the part that distinguishes a big bang from a bad release. Once five million customers, or an entire payroll, or a whole manufacturing site is on the new system, reversion is not an option anyone will authorise. The organisation is committed to fixing forward while the business bleeds.
Each of those four steps is individually rational under date pressure. Together they are a machine for converting schedule risk into operational catastrophe.
Why “incremental” is a governance choice
The agile answer — deliver in increments, release small, learn — is usually argued on delivery grounds: faster feedback, earlier value, less rework.
Those are real, but they are not the argument that wins in a boardroom. The argument that wins is this: an incremental release preserves the board’s ability to stop.
If you migrate one region, one product line, one factory or one customer segment, then at the end of that increment the project board has a genuine decision. Continue, pause, remediate, or abandon. All four options are live because the organisation is still running.
If you migrate everything at once, the board’s only remaining decision after go-live is how much to spend on recovery. Governance has been designed out of the plan.
PRINCE2 has always understood this. Manage by stages exists precisely so that a board can take a real decision at defined points. What PRINCE2 Agile adds is a vocabulary for making those stages small — timeboxes at iteration, release and stage level, a release map, product and project backlogs, definitions of ready and done. Version 2 keeps all of them.
The instrument is not new. What is new is having an accepted way to argue for it.
But increments are not free, and pretending otherwise is dishonest
I would be doing you no favours if I left it there, because incremental cutover has real costs that big-bang advocates raise for good reasons.
Dual running. For the duration of the transition you operate two systems, often with manual reconciliation between them. That costs money, headcount and error rate. Birmingham’s eighteen months without a usable audit trail is a warning about what happens when reconciliation breaks — but a badly designed dual-running period can produce the same exposure deliberately.
Interface complexity. Every increment boundary is an interface between old and new that must be built, tested and eventually thrown away. That work is genuine and it is never in the original estimate.
Data. Splitting a migration means splitting a data set, which means deciding what happens to a record that belongs to both sides. This is where most incremental plans actually founder, and it deserves design attention long before the increment boundaries are announced.
Change fatigue. Users experience several disruptions instead of one. There is a real argument that a single well-executed cutover is kinder to an operation than four indifferent ones.
So the choice is not “big bang bad, increments good.” It is: what does each option cost, and what does each option preserve? The failure in all four cases above was not choosing a single cutover. It was choosing a single cutover without pricing the loss of optionality, and then discovering the price after go-live.
The acceptance criteria problem
One more case, because it isolates a different part of the same issue.
Hertz contracted Accenture in August 2016 to redesign and rebuild its customer-facing website and mobile app, targeting a December 2017 launch. The date slipped to January 2018, then April 2018, and Hertz terminated before delivery. Its April 2019 complaint claimed $32 million in fees paid plus remediation costs. Accenture said the allegations were without merit and counterclaimed. I could not establish the outcome from public sources, and the common assertion that it “settled quietly” is unsourced — so I will not repeat it.
What makes the filing instructive is the nature of the allegations. Hertz alleged there was no responsive design for tablets; that code written for the Hertz North America brand “could not be used for the Hertz global brand or for the Dollar and Thrifty brands”; that front-end security vulnerabilities were “so pervasive that all of Accenture’s work on that component had to be scrapped”; that platform standards were not followed, making the application “unreliable and difficult to maintain”; and that the style guide was delivered as a PDF despite a contractual requirement for an interactive, updateable version.
Every one of those is an acceptance criteria dispute. Reusability across brands. Responsive breakpoints. Security standards. Platform conformance. The form of a deliverable, not merely its existence.
PRINCE2 has a specific instrument for this and it is one of the most neglected: the product description, which specifies a product’s purpose, composition, derivation, format, quality criteria and quality method before the product is built. PRINCE2 Agile’s definition of done does the same job in a different vocabulary.
Had a product description existed for that style guide specifying “interactive and updateable,” there would have been nothing to argue about. Had one existed for the front end specifying the security standard and the review method, the pervasive vulnerabilities would have been a failed acceptance rather than a lawsuit.
Whichever cutover strategy you choose, this is the cheapest control available. Write down what “done” means, per product, before anyone builds it.
Nine questions before you approve a cutover plan
1. How many open defects will we carry across, by severity, and who signed the classification? TSB carried 4,424 open defects. Ask for the number now, and ask who has authority to reclassify a severity.
2. What is our reversion plan, and when does it expire? Not whether one exists on paper. At what hour after cutover does reversion become impossible, and who decides?
3. What have we tested at full scale, in the configuration we will actually run? TSB tested against one data centre for an active-active design. This is the single most common gap.
4. Could we do this in two pieces? What would that cost? Price it. Even if you then choose the single cutover, you will have chosen it knowing what you gave up.
5. What is the smallest thing we could put live first, and what would we learn? Sometimes the answer is one branch, one region, one product, one factory.
6. Has anyone independent watched a real user complete a real task? Not a demo. See Phoenix.
7. What does “done” mean for each significant product, and where is that written? Reusability, performance, security standard, format, maintainability. See Hertz.
8. Are we cutting scope to fit the budget, and does the board know which scope? Phoenix removed over 100 critical functions inside the project. That decision belonged to the board.
9. What is the human cost of getting this wrong? TSB customers could see each other’s accounts. Half of Canada’s federal employees were paid incorrectly. Birmingham lost the ability to detect fraud for eighteen months. Put that on the slide, in words, next to the date.
The sentence to remember
Of everything in the four investigations, the one I keep returning to is from Slaughter and May, because of what it does not say.
“TSB did not give sufficient consideration to whether a largely single-event migration was the right choice.”
Not that the choice was wrong. That it was not sufficiently considered — never substantively discussed at board level, never weighed against an alternative, never priced.
That is a fixable failure, and fixing it takes one properly minuted agenda item.
The reversion plan nobody writes
Of the nine questions above, the one that most often produces silence is the second: at what hour after cutover does reversion become impossible?
Most cutover plans contain a rollback procedure. Very few contain a rollback decision, and they are different artefacts. A procedure describes how to go back. A decision names the person who may authorise it, the criteria on which they will decide, the point past which the option no longer exists, and what has to be true for the option to remain available until then.
That last clause is the one that gets skipped. Reversion is usually possible only while the old system still holds a reconcilable state — which means somebody has to be actively maintaining the ability to go back, at a cost, for a defined window. If nobody is funding that, the rollback procedure in the plan describes something that stopped being possible several hours before anyone looked at it.
Write four things into the plan and rehearse them: who decides, on what evidence, by when, and what we are paying to keep the option open. Then, before go-live, actually execute the reversion in a rehearsal. A rollback that has never been performed is a document, not a control — the same category error as a disaster recovery plan that has never failed a test.
Sources
- Slaughter and May, Independent Review of the 2018 TSB Migration (2019); Financial Conduct Authority and Prudential Regulation Authority Final Notices, TSB Bank plc (December 2022); TSB Bank plc, Annual Report and Accounts 2018
- Grant Thornton, Value for Money report on Birmingham City Council’s Oracle implementation (reported February 2025); Birmingham City Council commissioners’ reports
- Office of the Auditor General of Canada, Report 1 — Building and Implementing the Phoenix Pay System, Spring 2018
- Revlon, Inc., Form 10-K for 2018 and Q1 2018 earnings release; Lachman v. Revlon (E.D.N.Y.), decision of 17 September 2020
- The Hertz Corporation v. Accenture LLP, No. 1:19-cv-03508 (S.D.N.Y.), complaint filed April 2019 — outcome not publicly established
- PeopleCert, PRINCE2 Agile Foundation (Version 2) syllabus, v2.0 (May 2025) — timeboxes, release map, definition of done — peoplecert.jp