A go-live date has already moved twice. Finance is still closing the month in a parallel spreadsheet, because nobody fully trusts the numbers coming out of the new system yet. On the warehouse floor, someone went back to a paper log “just for this week,” and that was two months ago. Nobody on the leadership team can say with confidence when the project will be done, or what “done” even means at this point.
This isn’t a training issue or a rough patch. It’s a failed implementation that is still technically in progress, and that’s arguably worse than one that has openly stalled, because nobody has said out loud that it’s broken. Everyone is still calling it a delay.
The Symptoms Get Normalized
Few companies arrive here through one obvious disaster. It’s usually a slow accumulation of small signals that each, on their own, seemed manageable at the time:
- Parallel systems are still running for anything that matters – invoicing, inventory counts, payroll – months after go-live.
- Reports pulled from the new system don’t match reports from the old one, and nobody can fully explain why.
- Manual workarounds that were supposed to be temporary have quietly become permanent: side spreadsheets, double entry, “we’ll clean that up later.”
- The employees who know the business best have stopped raising issues. Not because things improved, but because they stopped expecting anything to change and started routing around the system instead.
- The go-live date has moved more than once, without a specific reason this time will be different.
- Every new problem gets answered with more customization rather than fewer, stacking complexity on top of a foundation nobody fully trusts.
No single item on that list means the project has failed. The combination of silent workarounds and repeated schedule slips is what makes it worth taking seriously.
Why These Projects Break
It’s tempting to look for one villain, usually the implementation partner. In practice, most of these projects break for a small number of recurring reasons, and the vendor is rarely the whole story.
Scope grows without being re-costed. Customization requests get approved one at a time, each reasonable on its own, because saying yes is easier than saying no in a project review. A year and a half later, the system is carrying business logic nobody remembers agreeing to, none of it was budgeted as a group, and the original timeline has no real relationship to the amount of work left.
The business process was never mapped before configuration started. Teams move straight into building screens and workflows around how they assume the business operates, instead of documenting how it actually runs first. The software ends up modeling a version of the company that doesn’t exist, so people fight the system rather than use it.
Nobody on the client side owned the decisions. A successful implementation needs one person internally with the time, authority, and product knowledge to make fast, informed calls. Without that person, either every decision stalls waiting for consensus, or the vendor ends up making calls it shouldn’t be making alone – and those rarely get revisited until something breaks downstream.
Most failed projects are some mix of all three, not one bad actor. That distinction matters, because it changes what a rescue needs to fix first.
Before You Call a New Partner
A first conversation with a new implementation partner moves faster, and gets a more honest answer, when you walk in with a clear picture instead of the version written for the board. It helps to have on hand:
- The original scope document and timeline, or whatever is left of it.
- A list of every system still running in parallel, and specifically what each one is used for.
- Two or three recent reports that don’t reconcile between systems, and the point where the numbers start to diverge.
- The names of the people who genuinely understand the current configuration – not always the ones who signed the original contract.
- Administrative access to the current environment. A meaningful assessment isn’t possible from the outside.
- Any log of customizations or scope changes, even an informal one buried in email or Slack.
- A candid list of what’s broken versus what’s merely annoying. The two get conflated constantly, and they call for different responses.
What Rescue Work Looks Like
A rescue engagement isn’t a second attempt at the original project. It starts narrower, with an audit that separates what’s genuinely blocking the business from what’s cosmetic. That distinction drives everything after it.
At VentorTech, we’ve worked on about 20 Odoo rescue projects over the years, alongside 14 years of Odoo implementation experience. Across those projects, this triage phase is usually where clients see progress fastest. It’s common to close up to 80% of the critical, business-blocking issues within the first two to four weeks, before the wider architecture gets touched at all. Critical here means anything stopping people from doing their jobs: invoicing that won’t process, stock counts that don’t match the warehouse, payroll that fails to run. The structural and process-level fixes get staged over a longer timeline, once the business has stopped bleeding on the urgent stuff.
What tends to surprise clients most is how rarely a full restart is the right call. In our experience, it has never once been necessary to rebuild from zero. Most of what looks unsalvageable from the inside – the data, the core configuration, a good share of the customizations – turns out to be reusable once someone understands it properly instead of writing it off. What usually needs rebuilding isn’t the system. It’s the process and decision-making structure that let it drift in the first place.
Why There’s No Single Price Tag
Every company coming out of a failed implementation wants a number before they’ll even start the conversation. That’s understandable, and it’s also not something anyone can give honestly at this stage. Cost depends on a handful of factors that vary enough between companies that a headline figure would be misleading:
- How much of the original scope can be trusted as-is, versus needs independent re-verification.
- Whether data quality problems sit underneath the configuration problems – these are often more time-consuming to fix than the configuration itself, and they’re rarely visible until someone looks.
- How much institutional knowledge left the building with the original implementation team.
- Whether the business processes were ever documented, or only exist in the heads of two or three long-tenured employees.
- How many manual workarounds have piled up since go-live. Each one has to be understood and carefully unwound, not just switched off.
A short, well-scoped audit is what turns those variables into a real estimate instead of a guess dressed up as one. As a general benchmark, the audit itself typically represents up to 10% of the expected project budget.
Where to Start
If two or three of the symptoms above sound like your current project, the honest next step isn’t waiting for a clearer signal, or a full collapse. It’s an independent audit of where things stand. That audit doesn’t commit you to a rescue. It answers one question: what’s broken, what would fixing it involve, and roughly what would it cost. Everything after that is a decision made with real information instead of a guess.
