Bramvia — Business Central Experts
ERP project rescue: what to do when your Business Central implementation has stalled
Go-live postponed three times, invoices that keep growing, an unresponsive partner and users back in spreadsheets: the 8 signs of a stalled ERP project, what can be salvaged, how it is restarted without starting over, and what to demand before spending another euro.
Short answer: a stalled Business Central project is almost never stalled because of the software. It is stalled by vague scope, customizations that modified the standard, data migrated without validation, testing done with demo data, or a partner that lost the consultant who knew it. The good news: most of what has been built can be salvaged. Our rescue starts with an independent 5-day audit — technical, functional and commercial — that tells you what exists, what is broken, what finishing costs, and whether to continue, redirect or stop. With no obligation to hire us afterwards: sometimes the honest recommendation is to stay with your current partner under a different contract. And if we do take it on, as with everything we do, each part is paid only after you accept it — the only sensible condition for someone who has been burned once.
The 8 signs of a stalled project
- Go-live has been postponed twice or more, each time for a different reason.
- The invoices keep coming but the delivered scope doesn't grow.
- "It's almost there" — for months. Nobody can say exactly what is missing.
- The consultant who knew it has left — and the replacement "is getting up to speed".
- Users have gone back to spreadsheets "in the meantime".
- Nobody dares update because something breaks.
- Testing was done with demo data and the problems appear with real data.
- The relationship has become an exchange of emails about whose fault it is.
Three or more: you have a project to rescue, not to push.
Why they stall (what we find under the bonnet)
- Scope without acceptance criteria. "Implement the ERP" as a contract. Every new requirement is a negotiation, and the project has no finish line.
- Modifications to the standard instead of extensions. Works until the first update; after that, every wave breaks something.
- Blind data migration. Everything was imported, without validating balances or cleaning master data, and the discrepancies surface at the first close.
- Customising what the standard already did. Months of development to replicate the old system, when Business Central shipped it out of the box.
- Integrations "to be determined" that were determined late and expensively.
- No owner on the client side. Nobody with authority to decide; everything escalates and waits.
The independent 5-day audit
It isn't an opinion: it is a report you can decide with — and, if needed, negotiate with.
| Block | What we deliver |
|---|---|
| Technical state | Object inventory: clean extensions vs modifications to the standard; undocumented code; version and pending updates |
| Functional state | Which processes work, which half-work, which don't; what users actually use and what they avoid |
| Data | Validation of balances and master data against the previous system; duplicates and inconsistent records |
| Integrations | Each connection: how it was built, whether it survives an update |
| Scope and contract | Promised vs delivered; invoiced vs accepted; what remains, estimated in hours |
| Risks | Compliance, security, dependence on individuals |
| Recommendation | Continue / redirect / stop, with a phased roadmap and remaining cost |
Price: from $1,600 depending on project size, fully credited if you commission the rescue. We sign your NDA before seeing anything, and the report is yours: use it with your current partner, with another, or with us.
How it is restarted without starting over
- Freeze and document. Nothing is touched until the inventory exists. It is the week that saves the most money.
- Separate what's worth keeping from what mortgages you. Clean extensions stay; modifications to the standard are rewritten as extensions or replaced by standard functionality (often, removed).
- Redefine the remaining scope in parts, with written acceptance criteria and payments tied to those acceptances.
- Validate the data against the previous system before going a step further.
- Test with real cases — your month-end close, your busiest day — in a sandbox.
- Go live in phases and stabilise with reinforced support in the first month.
With AI in the code and data analysis, the inventory that used to take weeks takes days — which is what makes a rescue viable at SMB prices.
What to demand before spending another euro
From your current partner, or anyone proposing to take the project on:
- The object inventory marked "extension / modification to the standard".
- The list of what remains with measurable acceptance criteria and hours.
- Documented data validation.
- Payment tied to acceptance, part by part.
- A name accountable for the project, on their side and on yours.
Whoever cannot produce the first three documents does not know where the project stands.
FAQ
Can you rescue another partner's project without access to their code? The extensions installed in your environment are yours and are readable; with admin access to your tenant, the inventory can be done. If the partner withholds code outside your environment, that itself is an audit finding.
What if the problem is my company, not the partner? We will say so. The lack of an internal owner and of decisions is a frequent cause, and the audit states it just as plainly.
How much does finishing a stalled project cost? It depends how much must be redone. The audit quantifies it; typically, salvaging what has been built costs considerably less than starting again — and considerably less than what has already been spent.
Is your project blocked? Tell us in confidence — the first conversation is free, and in it we'll already tell you whether the audit is needed or a change of method is enough.