Most ERP projects do not fail during implementation. They fail three months after go-live.

There is a comfortable story about ERP failure in which the project collapses under scope creep, the budget triples, and everyone agrees it was doomed from the kickoff. That story exists, and it is not the common one.

The common one is quieter. The system goes live roughly on time. The integrator runs two training sessions, hands over a PDF, and invoices the final milestone. For about six weeks everything looks fine. Then the warehouse supervisor finds that the receiving flow takes eleven clicks where the old spreadsheet took two, so she starts keeping a parallel sheet "just for now". Purchasing notices the reorder suggestions are wrong because nobody maintained the lead times, so they stop looking at them. By month four the ERP is an expensive place to file invoices, and the actual business runs where it always did.

Nobody writes this up as a failure. The project was delivered. The system is live. The numbers in the board pack even come out of it. But the operational gain the company paid for never arrived.

Why the handover is the dangerous moment

An ERP implementation ends at exactly the point where the organisation starts learning what it actually needed. The requirements gathered in month one were a sincere guess. Real usage surfaces the gaps, and those gaps appear precisely when the people who could close them have moved to the next client.

The incentive structure makes this worse. An integrator paid on delivery milestones is paid to finish. An integrator paid to keep the thing running is paid to make it usable. These produce different systems.

What actually prevents it

Three things, none of them clever.

Run the old system in parallel until the new one is provably better. Not for a fixed two weeks decided in advance, but until the people doing the work stop reaching for the old one. That is a behavioural signal, and it is more honest than a sign-off form.

Count the clicks on the five most frequent tasks. Not the impressive ones from the demo. The things someone does forty times a day. If the new system is slower on those, it will lose, regardless of how good the reporting is.

Name a person, not a support queue. Someone who knows the configuration, answers within hours, and will still be reachable in month six. Most of what goes wrong after go-live is small and fixable in an afternoon, but only if there is somebody to ask.

The uncomfortable part

This has a commercial consequence. An integrator who stays through the first operating year cannot carry as many clients as one who delivers and leaves. It is a less scalable business, and it is why the model is not more common.

If you are choosing between proposals, the question worth asking both parties is simple: who will be in my warehouse during go-live week, and will they still be reachable in March? The answers tend to be clarifying.