Go-Live

First, understand the bet. An enterprise system replacement is not an IT purchase; it is open-heart surgery on a running company. Every order, invoice, pallet and payslip must keep flowing while the organs that process them are swapped. The projects run for years, cost from tens of millions into the billions, and consume armies of consultants — an entire global industry exists just to implement them. Boards approve them for a genuine prize: one system, one set of numbers, one version of the truth, replacing the tangle of aging legacy systems held together by three specialists near retirement. Roughly half of these projects, decade after decade of surveys agree, end up seriously over budget, behind schedule, or worse. The stories that follow are the "worse".

The genre's founding legend is Hershey, 1999. America's biggest chocolate maker was replacing its core systems and, running late, made two decisions that now appear in textbooks with red circles around them: it compressed the testing schedule to protect the date, and it chose a big-bang go-live — everything at once — in July, precisely when orders for its two biggest seasons, Halloween and Christmas, come flooding in. The new system came up; the flow of orders through it did not. Warehouses held over a hundred million dollars of Kisses and Jolly Ranchers that the system could not steer onto trucks. Shelves went empty in the most chocolate-critical quarter of the year, sales fell, the share price dropped sharply, and business schools acquired their favourite opening slide: the company that had the chocolate, had the customers, and lost Halloween in the software between them.

Hershey survived, fixed it, and later completed upgrades smoothly — a detail the legend drops but this series keeps: the same company, chastened, became a case study in doing it right. The lesson was never "systems don't work". It was that a go-live date had been treated as a promise to the calendar instead of a conclusion from the testing — and the calendar, unlike the testing, cannot tell you anything.

The pattern repeats with the reliability of physics, and the catalogue is worth reading like a coroner. FoxMeyer, in the mid-1990s, is the extreme case: a five-billion-dollar drug distributor bet on a new ERP and an automated warehouse simultaneously, while also signing aggressive new contracts priced on savings the unbuilt system was supposed to deliver. Orders misfired, stock vanished into the automation, costs exploded — and in 1996 the company collapsed into bankruptcy and was sold off for a fraction of its size. The trustees sued the software maker and the consultants for hundreds of millions; the settlements are confidential; the corpse is not. It remains the reference answer to "can a software project actually kill a company?"

The gentler entries rhyme. A US utility went live on schedule in 2012 — in the same week a hurricane devastated its service area — because contract penalties and project fatigue made the date immovable; payroll promptly broke, workers were overpaid, underpaid or unpaid through the storm recovery, and the total repair bill ran toward a billion dollars. A famous cosmetics company's 2018 go-live jammed its main distribution centre so badly it could not fulfil orders from its biggest customers — and it learned the modern coda: shareholders now sue over botched go-lives, arguing the risk was known and understated. A major British city council's finance-system project ran so far over — from tens of millions towards ten times that — that it became a contributing factor in the council's effective bankruptcy. And in the industry's most discussed anti-disaster, a giant European discount retailer simply stopped: seven years and roughly half a billion euros into its programme, it cancelled the whole thing and returned to its old system — reportedly because the software assumed one way of valuing inventory and the company refused to abandon its own. Ridiculed at the time as waste, the decision has aged into grudging respect: it is the catalogue's only entry where somebody pulled the plug before the go-live did it for them.

Read as one text, the catalogue keeps confessing the same three sins. Testing compressed to protect a date. Complexity multiplied by customisation — every "but we've always done it this way" hard-coded into the machine at premium prices. And the sunk-cost engine from this series' other cases: with two hundred million spent, no executive can afford to be the one who stops — so the only acceptable direction is forward, which is how a late project becomes a disaster instead of just a late project.

Strip away the technology and every entry in the catalogue is the same collision: standard software encodes one way of running a business, and a company is a thousand people's habits pretending to be processes. Go-live is the moment those two meet without an interpreter. That is why the projects are hard in a way that building a bridge is not: the bridge does not argue back. The industry's own veterans put it as a fork — change the software to fit the company, and inherit complexity forever; or change the company to fit the software, and fight every department whose "always" is being deleted. The failed projects almost all tried to do the first while claiming to do the second; the famous cancellation happened because one company understood the fork and refused both prongs honestly.

Two quieter truths complete the picture. The successes are invisible by definition — thousands of companies cross these go-lives every year without headlines, usually the ones that tested until the testing said yes, went phased instead of big-bang, cleaned their data before moving it, and treated the project as business change with software attached rather than the reverse. And the game never ends: entire generations of these systems are now reaching end-of-support, pushing a worldwide wave of migrations to newer cloud versions on vendor deadlines — thousands of companies queued for their own go-live day this decade, consultants scarcer and dearer than ever, every board reading the old catalogue nervously. The people who carry these projects — the analysts, consultants and administrators who translate between the company's habits and the system's rules — have quietly become some of the most consequential people in any business: the interpreters at the collision.

So the case ends where the practitioner lives, with the question every project in the catalogue answered too late: when the company's way and the system's way disagree, who decides which one bends — and is that person in the room? Companies that can answer before the go-live get the boring, invisible success. Companies that can't find out on the day the switch is flipped — with the trucks waiting, the payroll due, and Halloween coming.