The boldest plan in one of our projects was to replace the eighteen-year-old ERP over a single weekend. Switch the old system off on Friday evening, migrate over the weekend, and by Monday morning everything runs on the new one. On the slide it looked like an elegant cut: one go-live date, one clean break, and after that the legacy burden is history. It was the boldest plan. It wasn't the smartest. Because on that Monday morning everything would have been new at the same time — the interface, the data, the integrations, the processes, the permissions. And if any one of them jams, it doesn't jam in one place but everywhere at once, and nobody knows where to start.
When an SME wants to get rid of an old system, everyone pictures the same thing: the new one replaces the old one, on a date marked in red in the project plan. Management likes the go-live date because it looks clean and is easy to communicate. The vendor of the old system has just announced the end of support, and suddenly everything has to be new right away. The Head of Operations sits alongside and thinks about something else, because they own the operation, not the slide. They know: on the weekend when everything is switched over at once, nobody sleeps. And on Monday, they are the one who has to answer for it, not the slide.
Why the Go-Live Date Is the Real Risk
A big bang replacement concentrates the entire risk of a project onto a single point in time. For months you build the new system, migrate data, rewrite integrations — and none of it runs in real operation until the switch is flipped. Until then every test is a test against assumptions, never against reality. The first real day under load is also the day from which there is no way back. Anyone who has ever stood in the server room on a Monday like that knows the feeling: there is no such thing as a small error any more. Every error is a production outage, because the old system that would have caught it was switched off yesterday.
And the eighteen-year-old ERP isn't just a piece of software. It's eighteen years of quiet special cases. The one posting rule a colleague built in back in 2011 for exactly one major customer. The field that officially means the storage location and unofficially has served for years as a note for the field sales team. The nightly routine nobody touches any more, because no one quite knows what it does — only that accounting calls when it fails. None of these eighteen years are written down in any specification. They live in the running system, and a big bang forces you to get all of them right at the same time. Over a single weekend.
Not every legacy system needs to be replaced right away.
The Project Where We Didn't Flip the Switch
In one of our projects this was exactly the decision on the table. An ERP that had grown over time, the core of the business, around 4,000 orders a month, plus warehousing, purchasing and invoicing — all in one system that had been running for eighteen years and that nobody could explain in full any more. The trigger was mundane and pressing at the same time: the vendor had set the end of maintenance for the coming year. Management wanted the grand solution: new ERP, go-live date, done. The Head of Operations didn't object. They asked a different question. Which part of this system is actually causing us pain right now — and which part just runs?
The honest answer was sobering for the grand plan. The pain didn't sit in the whole ERP. It sat in three places: order entry was sluggish and almost impossible for new staff to learn. The reports arrived too late and in formats nobody needed any more. And an interface to shipping was so brittle that it had to be fixed by hand once a month. The rest — posting logic, warehouse management, the master data core — had been running unspectacularly for years. Nobody woke up at night because stock postings weren't working. They just worked.