I have been involved in more than twenty ERP selections in UK retail, and the same five mistakes appear in almost every one. They are not technical mistakes. They are process mistakes, made by sensible people under time pressure, and they are expensive because they are invisible at the moment they happen. The cost arrives eighteen months later, when the project is over budget and the system is not doing the job the demo promised.
Mistake 1: Buying before requirements are written
The most common opening line in a selection project is "we know what we need". The second most common is the discovery, three months later, that nobody had written it down. Requirements documents are not bureaucracy. They are the only defence you have against buying the system the vendor wants to sell instead of the system you need.
Write requirements before inviting a single demo. Structure them by business process: order capture, stock allocation, fulfilment, returns, purchasing, finance, reporting. Mark each requirement must have, should have or nice to have. Then ask vendors to respond in writing against that structure before they show you anything. The ten selection questions article gives you the vendor side of this conversation, but the requirements document comes first. A vendor that pushes back on your format is telling you how the implementation will go.
Mistake 2: Choosing on demo quality
Demos are theatre. The vendor has scripted the scenario, prepared the data and rehearsed the presenter. You are watching the best hour of the system's life, performed by its most experienced user. Buying on that hour is like judging a car on the dealership's test route.
The fix is a structured demonstration. Give every shortlisted vendor the same five scenarios from your requirements document and a day to prepare. Use your own data, your own products, your own prices. Then watch what happens when the script breaks: how long does it take the presenter to recover, and does the system do what you asked or what they wanted to show? I have seen a vendor lose a contract in under ten minutes once the prepared demo ended. That was the demo doing its real job.
Retail sector coverage matters here too. The Retail Economics research library documents how varied retail operating models have become across the UK market, from food to fashion to DIY. A demo built for one of those models tells you nothing about the other two.
Mistake 3: Treating data migration as an afterthought
Every ERP project has a moment where the new system is ready and the old data is not. The team that promised a smooth cutover discovers that the product master has 14,000 duplicate SKUs, the last four years of stock adjustments were never posted, and the customer database contains three different spellings of the same account. Migration is where timelines die.
Start data work at selection, not after signature. Export your product master, stock history and open orders now, and measure the cleaning effort honestly. If your data is in the state most retail data is in, the migration will be the largest workstream in the project. Plan for it that way, or the implementation timeline you were quoted will be fiction.
Mistake 4: Underestimating integration scope
Retailers buy an ERP and then connect it to everything they already run: the shop till, the ecommerce platform, the marketplaces, the payment provider, the carriers, the loyalty system. Each connection is a project. The ERP quote never includes them properly, and the integration line in the budget is the one that grows.
Before signing, draw the integration map. Every system that sends data to or receives data from the ERP, every interface, every sync frequency, every owner. The marketplace integration shows what one channel alone involves. Multiply that by every channel you run, and you have the real scope. If the map has more than a handful of arrows, integration cost will exceed the licence cost, and you should budget accordingly.
Mistake 5: Signing a one sided contract
The last mistake is the least discussed and the most expensive. Retailers sign contracts where the vendor's obligations are vague, the acceptance criteria are absent and the exit terms are punitive. When the system underdelivers, the retailer discovers the contract gives them no way to hold the vendor to account and no clean path out.
Three clauses matter above all: acceptance criteria tied to your requirements, a remedy period with consequences if the system fails them, and clean data export rights on exit. Negotiate these before price. The implementation mistakes article describes what happens when these clauses are missing, and it is not a good look for anyone's budget. If your procurement team objects that these clauses are unusual, ask them which side they are representing.
Why the mistakes repeat
None of these mistakes come from stupidity. They come from pressure: the old system is failing, the board wants a decision, the season is coming. The counterweight is process. A written requirements document, a structured demo, an honest data audit, an integration map and a balanced contract will not make the project easy. They will make it survivable, which is the realistic goal.
If you are at the start of this journey, read the readiness signals and the build versus buy analysis before the vendors get in the room. And if you are choosing between architectures while you are at it, the single platform versus best of breed comparison settles the argument with process rather than opinion.