Insights
Most ERP projects don’t fail because someone picked the wrong platform. They fail because of what happens after the contract is signed.
Short answer
Go-lives fail in the first weeks live, not in the software selection meeting. Training can’t reproduce real business stress, so the system runs slower than expected while people build real muscle memory under real pressure. That’s exactly when edge cases surface — some the old system already had a workaround for, some genuinely new — and employees and developers absorb the gap in real time unless someone planned for it.
The part nobody plans for
I’ve watched this up close, implementing an ERP and living with the result. The software decision gets all the attention — platform, license tier. The real work starts after: mapping actual workflows onto the system, training people who’ve done it the old way for years, migrating data messier than anyone admits.
You train for weeks or months. Everyone runs the new system fine in the training room. It feels like you’re ready. You’re not — yet.
It’s nearly impossible to reproduce real business stress in training. So when you go live, the system runs slower than expected — not broken, just people building real muscle memory under real pressure for the first time.
Two kinds of edge case
Some edge cases you’d actually covered before. Your old system wasn’t fancy, but your team had a workaround for that once-a-month problem. The new system doesn’t have that workaround baked in, so the old problem comes back like it’s new — except now you’re relearning a fix you used to already know, live, customer waiting or truck at the dock.
Some are not an old problem resurfacing at all — they’re an issue that never existed until the new workflow created it. The old process had no failure point there. You don’t discover you’ve created it until it happens, then you’re building a fix for something you didn’t know you’d just introduced.
The human cost
Employees promised an easier job are instead fighting a backlog of edge cases, and frustration builds fast. Developers get pulled a dozen directions at once, patching issues faster than any normal dev cycle allows.
Three things that help
Run the new system on live volume alongside the old one, not just a training demo, so the slowdown and first edge cases surface before they're customer-facing.
For the first few weeks, a couple of power users handle routine hiccups so every issue doesn’t land straight in the developer queue.
Most aren’t new — every operation like yours eventually hits them. Someone who’s built through them once can hand you that list before go-live instead of you discovering it live.
Where this comes from
Building our Dolibarr-based ERP, I lived this — five custom modules (inventory control, digital picking, a QC module, a technician module, AI-assisted bulk receiving) because our own edge cases demanded a real process, not a workaround.
Dolibarr itself is free — no license fee, and that’s real. But implementing and supporting it to actually run an operation still costs real work, same as any platform. The question is whether you pay for that once, deliberately, with someone who’s already lived through the edge cases — or pay for it live, while learning as you go.
Questions people ask
Because training can’t reproduce real business stress. Everyone runs the new system fine in a quiet training room, but the first live days run slower than expected while people build real muscle memory under real pressure for the first time. That slowdown, not a software defect, is where most go-live pain actually starts.
Edge cases are the situations rare enough that nobody built training for them, but real enough that they still need a working process. They show up live because they are, by definition, the once-a-week or once-a-month situations too infrequent to catch in a short test window.
Yes, in two different ways. The first is an old problem resurfacing: the old system had a workaround the team built up over time, and the new system simply doesn’t have it built in. The second is genuinely new: the new workflow creates a failure point that never existed before, because the old process had no equivalent step to fail at.
Three things help most: a real stress test before go-live that runs the new system against live volume alongside the old one, a first-line triage layer of power users for the first few weeks so routine issues don’t all land on developers, and pre-mapping the edge cases that similar operations typically hit so the team isn’t discovering the full list live.
Start with a conversation
Let’s talk through where the real cost and risk actually sits, before you find out live.