Bramvia — Business Central Experts
Your ERP implementation failed. Here's what to do in the next 30 days
Go-live slipped three times, the budget doubled, users went back to spreadsheets. Why ERP projects fail (it is almost never the software), what can be salvaged, how to run an independent audit, and what to demand before spending another dollar.
Short answer: if your ERP implementation has failed or stalled, the cause is almost never the software. In the projects we are called into, it is scope with no acceptance criteria, customizations that modified the standard, data migrated without validation, testing done on demo data, no decision-maker on the client side, or a partner that lost the consultant who knew your system. The good news is that most of what has been built can usually be salvaged — and that the recovery starts with a document, not a new contract: an independent audit of what exists, what is broken, what finishing costs, and whether to continue, redirect or stop. Here is what to do in the next 30 days, in order, and what to demand from anyone who wants to take the project on.
First: is it failing, or just slow?
Eight signals. Three or more means recovery, not another push:
- Go-live has slipped twice or more, each time for a different reason.
- Invoices keep arriving; delivered scope doesn't grow.
- Nobody can say precisely what remains before go-live.
- The consultant who knew your system has left.
- Users have gone back to spreadsheets "in the meantime".
- Nobody dares apply updates because something breaks.
- Testing was done with demo data; real data breaks things.
- The relationship is now an email thread about whose fault it is.
Why ERP projects actually fail
Scope without acceptance criteria. "Implement the ERP" as a contract. Every requirement becomes a negotiation and the project has no finish line. This is the single most common root cause.
Modifying the standard instead of extending it. It works until the first update, then every release breaks something and the partner "can't upgrade yet".
Blind data migration. Everything imported, balances never validated against the legacy system, discrepancies surface at the first close — when trust is hardest to rebuild.
Rebuilding the old system. Months of development to replicate what the new ERP already did out of the box, because nobody asked "does the standard cover this?"
Testing on demo data. The awkward cases — the odd discount, the partial shipment, the year-end accrual — never got tested. They show up on day one of live.
No owner on the client side. Nobody with authority to decide. Everything escalates and waits. A partner cannot fix this one for you.
Big-bang go-live. No phasing, no fallback. When something breaks, there is nowhere to retreat to.
Your next 30 days
Days 1-3: freeze and protect. Stop new development. Confirm you have admin access to your own tenant, that the code is in a repository you control, and that data backups exist. Write down what is in production today and what people are actually using.
Days 4-10: get an independent audit. Not from the partner who built it. The audit should produce:
| Block | What it must tell you |
|---|---|
| Technical state | Object inventory marked clean extension / modification to the standard; undocumented code; version and pending updates |
| Functional state | Which processes work, which half-work, which users avoid |
| Data | Balances and masters validated against the legacy system; duplicates and orphans |
| Integrations | How each is built and whether it survives an update |
| Scope vs contract | Promised vs delivered; invoiced vs accepted; what remains, in hours |
| Recommendation | Continue, redirect or stop — with a phased plan and remaining cost |
Days 11-20: decide with the document in hand. Three legitimate outcomes: continue with the same partner under a rewritten contract; change partner and keep what's salvageable; or stop and re-scope. All three are better than continuing without the document.
Days 21-30: restart small. One part, with written acceptance criteria, paid only after acceptance. It re-establishes whether delivery is possible before anyone commits to the rest.
What to demand before spending another dollar
- The object inventory with each item marked standard / app / extension.
- The remaining work with measurable acceptance criteria and hours.
- Documented data validation against the legacy system.
- Payment tied to acceptance, part by part — no upfront, no retainers you can't cancel.
- A named person accountable, on their side and yours.
- Your code in your repository and your tenant in your name.
Anyone who cannot produce the first three documents does not know where the project stands — which is the actual problem.
What it usually costs to recover
Less than starting over, and usually far less than what has already been spent. The audit itself is a fixed, small engagement (from $1,600, credited in full if you commission the recovery). The remaining build depends entirely on what the inventory finds — which is exactly why the inventory comes first and the quote comes second.
With AI-assisted code and data analysis, the inventory that used to take weeks takes days. That is what makes a recovery affordable at mid-market prices.
FAQ
Can someone audit a project built by another partner? Yes. The extensions installed in your tenant are yours and are readable with admin access. If a partner withholds source code outside your environment, that itself is a finding.
What if the problem was us, not the partner? The audit says so. Missing internal ownership and slow decisions are a frequent root cause, and pretending otherwise guarantees a repeat.
Should we switch software? Rarely the answer. In the projects we audit, the platform is usually fine and the delivery was not. Switching software restarts the clock and repeats the risk.
Is it too late if we already went live badly? No. Post-go-live stabilization is a normal engagement: fix data, fix process, retrain, and clear the backlog of things people work around.
Project stalled or failed? Tell us in confidence — the first conversation is free, and in it we'll tell you whether you need the audit or just a change of method.