Why most ERP projects fail, and the one thing that saves them

We have taken over four abandoned ERP programmes in the last three years. Different industries, different vendors, different technology stacks — and the same underlying failure every time.

It is never the technology

In every case the software mostly worked. What had collapsed was the organisation's willingness to keep going, and that collapsed because the project asked everyone to change everything on one weekend, eighteen months after they last saw anything working.

A big-bang cutover concentrates all the risk into a single day, and it removes the only thing that keeps a long programme alive: visible progress. If the first tangible benefit arrives a year and a half after the first invoice, the project is running on faith alone, and faith runs out.

Run the old and new systems in parallel

The one thing that consistently saves these programmes is a two-way sync layer that lets the old and new systems run side by side. It is genuinely annoying to build. It feels like throwaway work. And it is the difference between a phased migration and a cliff edge.

“Two agencies told us this could not be done without shutting facilities for a weekend. It was done without a single hour of downtime.”

With sync in place you migrate one module at a time. Admissions this month, pharmacy next, billing after that. Each step is small enough to roll back, and each step delivers something people can feel. By the time you switch off the last legacy system, nobody is nervous, because they have been using the new one for months.

What to ask a vendor

If you are buying an ERP replacement, ask exactly one question: what does week six look like? If the answer involves a document rather than software someone can use, keep looking.