The rollout failed. That doesn't mean starting from zero
After a failed boxed-ERP rollout the first question isn't "what do we build now" but "what of what already exists still has value".
Who this is for
- Companies whose team uses a rolled-out system minimally
- Organisations paying licences for modules nobody opens
- Boards deciding whether to fund more of the rollout or leave
What it covers
- An audit of what is actually happening
What is used, what is being worked around with a spreadsheet, where the data sits and what state it is in.
More
It ends in a recommendation that may read "stay with what you have" — and sometimes does.
- Carving out what hurts most
Instead of replacing everything: building the one missing area and integrating it with the existing system.
More
The cheapest way to find out whether the problem was the tool or the process.
- Data migration
Moving records, history and documents with consistency checks.
More
Historical data is always inconsistent — the only question is how much has to be repaired before a new system can trust it.
- Leaving without stopping the company
Running in parallel through a transition period, module by module.
More
Switching the whole company over in one weekend is the scenario where a fault stops sales.
In depth
Why ERP rollouts fail
In the projects we have watched from the sidelines, the usual cause wasn't technology but scope agreed before the process was understood. The system was given requirements written down in a meeting, and the exceptions appeared during the build — by which point including them was too expensive.
What we don't do
We don't sell our own ERP as the answer to every failed implementation. If the problem is organisational, a new system will only entrench it — and we say so before a contract is signed, not after.
Questions about this scope
Will you tell us everything has to be rewritten?
Only if the audit says so, and it rarely does. More often it pays to keep the core and build the missing areas around it. "Rewrite everything" is a convenient recommendation for a vendor and an expensive one for a client, so we treat it as a last resort.
How long does the audit itself take?
Usually two to three weeks, depending on the number of modules and access to the data. It ends in a document you can take to any vendor — including one that isn't us.
Does the current vendor have to cooperate?
It helps but isn't required. There is usually a route to the data through the database, an export or an API. Which of those we have is the main cost driver of the migration, so we check it first.
The parent service and related scopes
Got an idea? Let's talk.
The first call is free. We reply within one business day.