The selection phase of an ERP project is comfortable. There are demos to watch, feature matrices to build, references to call. It feels like the decisive work, and vendors encourage that feeling because it is the phase where they compete.
Then the system is chosen, and the project meets the part nobody rehearsed: moving a live business from what it runs today onto something else, without stopping trading. That is where implementations come apart.
Three failure modes, none of them the software
1. Migrating data that was never correct
Every business has stock records that disagree with the warehouse, customers who exist twice under slightly different names, and a supplier ledger with entries nobody can explain. The old system tolerated this because people worked around it — the storeman knew the real figure, the accounts clerk knew which duplicate was live.
Migration removes the workaround and keeps the error. Worse, it makes the error authoritative: it is now in the new system, which is supposed to be the single source of truth, and the people who knew the correction have no place to put it.
Data cleansing is unglamorous and always underestimated. It is also the single activity most likely to determine whether the first month after go-live is calm or chaotic. Budget for it explicitly, do it before migration rather than during, and accept that it will surface disagreements between departments that the old system was quietly absorbing.
2. Going live everywhere at once
Big-bang cutover — finance, inventory, sales, purchasing and HR all switching on the same Monday — is attractive because it appears to minimise the awkward period of running two systems. It maximises risk instead.
When five modules go live together and something breaks, you are diagnosing across five modules with every department blocked simultaneously. Sequenced implementation gives you a smaller surface, a team that has learned the system before the next module lands, and an early win that keeps the project funded.
A sequence that usually works
Start with inventory or finance — whichever is currently causing the most pain and has the clearest success measure. Prove it. Add purchasing and sales once stock is trusted. Leave HR and payroll until last: they are the least urgent and the most sensitive to getting wrong.
3. Parallel running that nobody actually does
Parallel running — operating old and new together and comparing outputs — is the standard safety net, and it is standard because it works. It also doubles the data entry for the team doing it, during the period when they are least familiar with the new system.
So it gets abandoned quietly in week two. Nobody announces this. The comparison stops being done, discrepancies stop being caught, and the first genuine divergence between the systems is discovered at month-end when the accounts do not close.
If you plan parallel running, resource it: name who does the comparison, agree what tolerance counts as a discrepancy, and set the date it ends. An unresourced parallel period is worse than none, because it provides the reassurance without the checking.
The question that predicts the outcome
When evaluating an implementation partner, the selection conversation tells you little — every vendor demos well. The useful question is about the switchover:
Walk me through the last cutover you did. What went wrong, and what did you change afterwards?
A partner who has done several will answer immediately and specifically, because cutover problems are memorable. One who describes a flawless history either has not done many or is not being straight with you. Neither answer is what you want to hear after signing.
What good looks like
- Data cleansing scoped and priced as its own phase, before migration begins.
- A documented sequence of modules with a defined success measure for each, not a single go-live date.
- A named person accountable for parallel comparison, with an agreed end date.
- A rollback plan that has been tested, not just written.
- Training delivered to the people who will use the system daily, not only to the managers who selected it.
None of this is about which ERP you chose. It is about whether the switchover was treated as the risky part of the project, which it always is.
Key takeaways
- ERP projects are usually judged on selection and decided at cutover.
- Migrating uncleansed data makes existing errors authoritative and removes the human workarounds that were hiding them.
- Sequenced go-live beats big-bang: smaller failure surface, a team that has learned, and an early win.
- Unresourced parallel running is worse than none — it provides reassurance without checking.
- Ask a prospective partner what went wrong on their last cutover. A flawless history is not a good sign.
Questions or a correction? Contact the 2M team. Examples explain a method; results depend on your operation and configuration.