The first implementation didn't take. The data is untrusted, half the team works around the system, and the workbooks that were supposed to disappear are all still open. So the business does the logical thing: it blames the platform and starts looking at replacements.
Then the second implementation fails in the same place as the first — and that's the moment worth paying attention to, because two failures against different vendors is evidence about the requirement, not about the vendors.
The failure is almost never the software
Business platforms are mature. Most categories have been solved, repeatedly, by people who've seen more businesses like yours than we ever will. When an implementation fails, the software is rarely the reason — it's just the only part anyone can point at.
Here's what's usually underneath.
The real process was never in scope
Discovery captured what people said they do. The business runs on what they actually do, which lived in a spreadsheet nobody mentioned.
Nobody technical was in the room
Or the only technical person present worked for the vendor. Integration and data reality got assessed by someone with a quota.
The data's history got waved through
Twenty years of records with three naming conventions and a period where someone used the notes field as a database.
The exception turned out to be the rule
Configured for the standard case. The standard case is 60% of volume. The other 40% is where the margin is.
Change the vendor and every one of those survives intact. That's why the second one fails. You replaced the only component that wasn't broken.
The tell: the spreadsheets came back
The clearest signal an implementation didn't take isn't a support ticket. It's a workbook.
If people quietly rebuilt a spreadsheet after go-live, the system refused to model something real and the business still had to happen. That workbook is a bug report written by the people who understand the business best — and nobody reads it as one.
Go-live is not the finish line, and adoption is not a training problem. If your team is working around the system six months later, they're not being difficult — they're routing around damage. Ask what the workaround prevents, and you'll find the requirement that was missed.
What to do differently the second time
Do a post-mortem on the first one — properly
Not who to blame. What the system couldn't do, and why nobody knew that before signing. That answer determines whether you need a new platform at all.
Start from the workarounds
Every spreadsheet, every re-key, every 'oh, we just do that manually'. These are the requirements. They're also the acceptance criteria.
Get someone technical who isn't selling
Someone whose only job is to find out whether it fits, with no stake in the answer being yes.
Test against the exception, not the demo
Take your most awkward real case — the one with the negotiated terms, the split shipment and the backorder — and make the vendor run it. Demos use clean data on purpose.
Scope the integrations before you sign
The licence is rarely what hurts. The connections to your logistics, your customers, and your finance system are the actual project.
Sometimes the platform was fine
This is the finding nobody wants and it's common enough to say plainly: a fair share of "the system doesn't fit" turns out to be a configuration decision made years ago by someone who's since left, or an integration that was never built and pushed the work into spreadsheets.
In that case the honest recommendation is to fix what you have, and it's the cheapest outcome on the table. We'd rather find that than sell you a migration — which is easier to say when we're not the ones selling you the licence.
What the good version looks like
An Australian confectionery distributor came to us running on one system and a wall of workbooks. We mapped how the business actually ran — spreadsheets included, because that's where the rules were — then chose the platform against that, and built the integrations no platform reaches.
Forty per cent of the spreadsheets were retired, and orders now reach the third-party warehouse through an API rather than an inbox.
The difference wasn't the platform. It was reading the workarounds before choosing it, and treating the integrations as the project rather than an afterthought.
Before you sign the second one
Ask one question, and be uncomfortable with the answer: what, specifically, did the last system refuse to do — and have we confirmed this one will?
If the answer is a feature list, you're about to repeat it. If the answer is a real case, run end to end, with your actual data — you're probably fine.
Frequently asked questions
Rarely because of the software. Implementations fail when the process that actually runs the business was never in scope — because it lived in a spreadsheet nobody mentioned during discovery, or because the exception case turned out to carry most of the margin. Changing vendors leaves all of that intact.
Not until you know what the last system refused to do. Two failures against different vendors is evidence about the requirement, not the vendors. A fair share of "the system doesn't fit" turns out to be a configuration decision or a missing integration — in which case fixing what you have is the cheapest outcome available.
Test against your most awkward real case rather than the demo — the one with negotiated terms, a split shipment and a backorder — using your actual data. Demos use clean data on purpose. If the vendor can run your worst case end to end, you have evidence rather than a feature list.
The licence is rarely the expensive part. The cost lands in month eight, when the integrations to logistics, finance and customers turn out to be the actual project — and in the staff time spent maintaining the workarounds the system was bought to remove.
Find out what the last one missed — before you sign the next one
An independent review of what actually went wrong, from someone who doesn't sell the licence.
Related reading
- Software Review & Implementation — independent assessment; we don't resell licences and carry no vendor quota, so the recommendation is whatever the assessment supports, with any platform partnership the group holds disclosed up front
- How to choose business software without getting sold to — where this sequence starts
- The ERP worked — for the people who chose it — what it costs when nobody technical is in the room
- Wholesale & Distribution — what this looks like in distribution