Yesterday, NATS — the UK’s air traffic control provider — suffered a flight-processing system failure that restricted departures and arrivals across Heathrow, Gatwick, Manchester, Stansted, Luton, and beyond, cancelling close to a thousand flights and stranding tens of thousands of passengers. It’s the third major NATS failure in just over three years, following the catastrophic August 2023 outage that cost airlines over £100 million, and a further incident in July 2025. Ryanair’s chief operating officer didn’t hold back: “It is clear that no lessons have been learned.”
I’ve spent my career as a Cutover Manager — over 300 cutovers, major and minor, several of them large international ones. Whenever an incident like this hits the news, I have the same conversation with a good friend of mine who’s built his career as a Major Incident Manager. We come at these events from opposite ends of the same process, and between us, I think we can actually explain why this keeps happening.
Two Jobs, Two Kinds of Stress
My job exists to get a system live safely — planning the sequence of steps that takes a system from old to new, or reverts cleanly back if something goes wrong, ideally without the end user ever noticing anything happened at all. My friend’s job starts exactly where mine is supposed to have already succeeded: when something has gone wrong in production and needs to be found, understood, and fixed, under real-time pressure, with the whole organisation watching.
I’ve always said that if one of my cutovers goes badly, the responsible cutover manager will be in pieces — and it’ll follow them into every future cutover they plan. My friend tells me his side of it is different but no less brutal: the incident manager won’t be sleeping, chasing a root cause under enormous pressure, often with only a partial picture of what actually changed. My own claim to whatever professional pride I can take is a simple one: in over 300 cutovers, none of mine has ever made the news cycle the next working day. A successful cutover, by my own definition, is one that either goes through cleanly or reverts cleanly — either way, without the end user ever being affected.
Why the Failures Keep Coming From the Same Place
Modern system upgrades aren’t a quick app update. They’re months, sometimes years of development, at a cost running into hundreds of millions of pounds, delivered under enormous commercial and political pressure to hit a fixed date and a fixed budget. And the two phases that consistently get squeezed hardest when that pressure bites are the two I know best: testing, and cutover itself. Businesses want delivery. Under pressure, stage gates get concessions. Standards get lowered just enough to hit the date. That’s where the faults come from, almost every time.
Birmingham City Council’s Oracle ERP disaster is close to a perfect case study. The project was budgeted at £19 million. It went live in April 2022, and by the time an independent audit from Grant Thornton examined what had actually happened, the total cost had climbed toward £216.5 million, with the system still not fully functional four years after go-live. Fraud detection capability was switched off for eighteen months because the system couldn’t reliably support it. £2 billion in transactions were posted to the wrong financial year. The council went on to issue a Section 114 notice — effectively declaring bankruptcy — and while it points to a separate equal pay liability as the primary cause, independent research from Sheffield University’s Audit Reform Lab concluded the failed IT system was actually the council’s biggest single financial problem. Grant Thornton’s own audit found the root cause wasn’t primarily technical or a resourcing shortage. It was governance — decisions made, under pressure, to proceed past checkpoints that should have stopped the project going live in the state it was in.
TSB’s 2018 core banking migration tells the same story from the private sector. Moving 5 million customers and 1.3 billion records off Lloyds’ systems onto a new platform, the migration went live in April 2018 and immediately fell apart — 1.9 million customers locked out of their own accounts, some able to see other customers’ data, branches and phone lines overwhelmed for a full week. The independent Slaughter and May review that followed attributed it, in the words later reported, to a “lack of common sense” — the bank rushed the transition and failed to test it properly. The root technical fault came down to inconsistent configuration between two data centres — precisely the kind of detail a properly resourced, unrushed cutover rehearsal exists to catch before it ever reaches production. TSB’s own CIO was later personally fined £81,000 by the Bank of England’s regulator specifically for assuring the board the migration was ready to proceed without having actually verified that the key supplier was prepared to go live. Total cost to TSB: around £366 million, and the CEO’s job.
The Fix That’s Really Just a Plaster
Here’s the part my friend and I keep coming back to in these conversations. When an incident like NATS’s happens, the pressure to restore stability fast is enormous — planes are grounded, passengers are stranded, and every hour of continued disruption is a headline. That pressure produces exactly the same dynamic that caused the original problem: a fix gets pushed through fast, under stress, without the full, unhurried root-cause analysis a calmer environment would allow. NATS restored its system within a few hours yesterday. Whether that restoration addressed the actual underlying fault, or simply patched the symptom well enough to get flights moving again, is precisely the kind of question that tends to only get answered properly after the next failure — which, on NATS’s own recent record, has arrived roughly once a year for the last three years running.
Are IT Projects Becoming Too Big to Control?
I think the honest answer is that scale itself isn’t the enemy — chaos under pressure is, and scale simply makes that pressure worse. Every one of these examples — NATS, Birmingham, TSB — involves genuinely complex, high-stakes systems that needed real time, real testing, and a deployment strategy built around the possibility of failure, not just the hope of success. And in every one of these examples, that time was the first thing sacrificed once the project ran over budget or over schedule, because a business under commercial pressure will almost always choose to compress the phase the public can’t see — testing and cutover — rather than delay a launch date the board has already committed to publicly.
That’s not a technology problem. NATS, Oracle, and Sabadell’s Proteo platform are all, on their own technical merits, capable systems used successfully elsewhere. It’s a project management and governance problem, repeated at scale, across sectors, for years — and until stage gates stop being treated as the flexible part of a project timeline, this is a list that’s going to keep getting longer, one news cycle at a time.
