An Odoo implementation is stalled when go-live keeps slipping, users work around the system and nobody can say what is still missing. Rescuing it means stopping new scope, establishing what really works on a test copy, closing the open business decisions and fixing only what blocks daily work. I do this as an independent senior consultant, either on my own or alongside your existing Odoo partner.
What are the signs of a stalled implementation?
- The go-live date has moved more than once and nobody can explain the new one.
- Every steering meeting reopens decisions that were made months ago.
- Key users keep spreadsheets next to Odoo because they do not trust the numbers.
- Custom modules were added to solve problems that standard Odoo already solves.
- Data migration was planned for the last week and is now the main risk.
- Only one developer, often no longer available, understands the custom code.
- Invoices for the project keep coming, but the list of open issues does not get shorter.
Why do Odoo projects stall?
In my experience the cause is rarely Odoo itself. The typical reasons are:
- No gap-fit before building. Requirements were turned into custom code before checking what standard Odoo does.
- Nobody owns the process. The partner configures, the client waits, and decisions about how the company will actually work are never made.
- Too much custom code too early. Each customisation adds testing work and upgrade cost, and some silently break standard flows.
- Real data arrives late. The system was tested on demo data, and real products, bills of materials and opening balances expose problems at the end.
A real example from a manufacturing client: a custom step that ran when a sales order was confirmed rewrote the routes of every product on the order. For project sales that was intended, but for catalogue sales it removed the manufacturing route, so no manufacturing order was ever created. The fix was small. Finding it required reading the code against the business flow.
How do I approach a rescue?
Stabilise
No new features for a short period. Backups are verified, access is cleaned up, and the open issues are collected into one list with an owner for each item.
Establish the facts
I run the main business flows end to end on a test copy: quote to cash, purchase to payment, manufacturing or project delivery, month-end. What works is written down as working.
Decide
Every open issue becomes a decision for a named person: use standard Odoo, configure differently, build, or drop. Most issues turn out to need a decision, not development.
Deliver in small steps
The few remaining changes are built and tested on the copy, accepted by the key user and deployed with a backup and a rollback step.
What happens in the first 30 days?
Days 1 to 5: access and freeze
Access to a test copy, the code repository and the issue list. Agreement on a short feature freeze. Check that backups exist and can be restored.
Days 6 to 10: health check and flow tests
A focused health check plus end-to-end tests of the main flows with your key users. Result: a written situation report with what works, what is broken and what is undecided.
Days 11 to 15: decisions
Workshops with the decision maker to close open questions. Each item gets an owner, a deadline and an acceptance test.
Days 16 to 30: first fixes and a realistic plan
The blockers with the highest impact are fixed on the copy and released after acceptance. You receive a go-live or stabilisation plan with dates that the team actually believes.
What does a rescue not include?
I do not promise a fixed go-live date before the facts are known, and I do not rebuild a system just to replace someone else's code with mine. If a module works and is tested, it stays. If the real problem is a missing internal decision maker, I will say so in the first two weeks rather than invoice around it.
What remains after the rescue?
Documented decisions, a shorter and honest issue list, code in your repository with tests for the parts I changed, and an internal admin who knows how the system is set up. From there you can continue with your partner, with your own team, or with me for custom development and the next upgrade.
Tell me about your Odoo
Describe your situation in a few lines. We reply by e-mail.
Frequently asked questions
Should we start the implementation again from scratch?
Rarely. A restart throws away the configuration and data work that already functions and repeats the same decision problems. In most cases it is cheaper to keep what works, remove what does not and rebuild only the parts that are truly broken. The health check shows which case you are in.
Can you work with our current Odoo partner?
Yes. A rescue does not have to mean a change of partner. I can act as an independent technical lead next to them, review their work, agree the plan with them and leave the delivery where it makes sense. What matters is one clear plan and one owner for each decision.
What do you need from our side?
A decision maker who can close open questions within days, a key user for each main process, access to a test copy and the code repository, and an honest list of what has been promised to whom. Without a decision maker no outside expert can rescue a project.
How soon can we see progress?
The first visible result is the written situation report at the end of the second week. Concrete fixes usually start in weeks three and four, tested on a copy and accepted by your key users before they reach production.