An Odoo project that doesn't go as planned is a more common situation than it appears, and it is nothing exceptional in the deployment of management software. You've committed time and resources, and the result doesn't match what was expected. Before proposing anything, this situation needs to be acknowledged for what it is: a project rarely fails because of a single party, and we do not have full knowledge of the context — deadlines, budget, communication, constraints on both sides — in which decisions were made. This document describes how to take over a struggling Odoo project in a measured way, without opportunism.
There is no need to look for someone to blame before acting. An Odoo deployment involves several parties — the provider, the client company, sometimes third parties such as a hosting provider or another connected software vendor — and each influences the final outcome. What matters at this stage is not reconstructing the history of decisions, but understanding the system's actual current state and deciding what to do next with full knowledge of the facts.
Typical situations
Several scenarios come up regularly among companies looking to take over an existing Odoo project.
- The previous provider is unreachable or has ceased trading. No more responses to requests, no more follow-up, sometimes no company left at all.
- The project stopped partway through. Part of the configuration exists, but the deployment was never finished.
- The budget was exceeded without going live. Resources were invested, but the tool still isn't usable day to day.
- The instance is live, but unusable. Teams work around the tool, going back to Excel or old systems, for lack of configuration suited to their actual processes.
- The accounting produced is wrong. Discrepancies, inconsistent VAT returns, bank reconciliations that never get done.
- Undocumented development work. Custom code runs in production without anyone knowing exactly what it does or why it was written that way.
- No one in-house knows how the instance works. Dependence on a single person — often the provider itself — has crept in without the company realising.
The first step: taking back control of your access, your code and your data
Before any diagnosis or decision about what comes next, the company must make sure it genuinely controls its own assets. This is a step to handle as a priority, often even before looking for a new provider, because access that is lost can become very difficult to recover once the link with the previous provider is permanently broken.
- Administrator access to the Odoo instance, not just a user account.
- Access to the hosting the instance runs on, or at least knowledge of who hosts it and under what contract.
- Ownership of the associated domain name, if there is one, and its DNS management.
- The code for any custom development, in a repository the company controls, not just on the provider's machine.
- Existing backups and an up-to-date data export, regardless of what happens next.
Until these elements are secured on the company's side, any discussion about the project's future remains shaky: you cannot calmly decide the future of a system you don't control. In the most strained cases, where contact with the previous provider is broken, this step may require approaching the host directly, checking the contractual terms on data ownership, or asserting a right of recovery provided for in the original contract. It is sometimes an uncomfortable process, but it determines everything that follows.
The technical and accounting assessment
Once access is secured, the next step is a full diagnosis, similar in method to a standard Odoo instance audit, but geared towards a rescue decision rather than a simple snapshot. It covers accounting and VAT configuration, payroll settings where they exist, active modules, custom development work and its level of documentation, data quality, access rights, and the state of backups. The accounting dimension is examined with the same rigour as the technical dimension: an instance that runs without visible errors can still produce incorrect figures, and this specific point is often what prompted the search for new support.
This diagnosis answers very concrete questions. Are the accounting entries generated so far usable, or does a period need to be revisited to correct them? Does the VAT return submitted to the authorities genuinely match the company's activity? Do the custom developments in production pose an immediate risk, or can they wait for a later stage? The answers to these questions determine the urgency of each action, and avoid treating a secondary point as a priority while a more serious problem goes unaddressed.
Deciding: repair, rebuild, or reset to standard
The assessment leads to a choice between three options, and that choice should rest on concrete criteria rather than a general impression of the situation.
- Repairing the existing setup makes sense when the base is generally sound: the configuration matches actual needs, the custom developments are of reasonable quality, and the problems found are localised and identifiable.
- Starting from a clean base is justified when the configuration strays too far from the company's actual processes, when the developments are too fragile or too numerous to be made reliable one by one, or when data quality is too degraded to be reliably corrected.
- Resetting the instance to Odoo standard means removing the riskiest customisations and returning as far as possible to native functionality, particularly when the custom developments are undocumented and complicate every version upgrade. This is often the most sustainable path in the medium term.
The deciding factor is not the apparent scale of the damage, but the sustainability of each option over time: a quick repair that leaves the same causes in place will only have postponed the problem. A technically unstable instance whose business configuration is sound doesn't need rebuilding; conversely, a stable instance built on processes that no longer match the company's actual activity will remain a burden regardless of the technical fixes applied.
Remediation
Once the option is chosen, remediation follows the priorities identified during the assessment: correcting the accounting and VAT configuration first, since it has a direct and immediate impact on the company's legal obligations, then making the data reliable, then taking over or replacing the most fragile developments. Depending on the needs, this may draw on our pages dedicated to Odoo Accounting, payroll, or custom development. When the situation is closer to a new deployment than a correction, it belongs on our Odoo implementation page.
Documentation and knowledge transfer
A project rescue that only fixes the symptoms reproduces the dependency that led to the original situation. Documentation is therefore not a side step: every configuration choice, every custom development, every business rule set up in Odoo must be written down somewhere in a way that someone who wasn't involved in the project can understand. This documentation does not need to be exhaustive in the sense of a complete technical manual: above all, it must answer the questions an outsider would ask on discovering the instance — why this field exists, what this automation is for, what business rule justifies this setting rather than another.
This work goes hand in hand with a knowledge transfer to your teams, so that day-to-day use of the tool no longer depends on a single person, whether internal or external. See our Odoo training page for this support, and Odoo support for ongoing follow-up once the instance has been restored.
Avoiding this situation with the next provider
Certain precautions, set out at the start of a new working relationship, significantly reduce the risk of ending up in a similar situation again:
- Reversibility: the concrete ability to change provider without starting from zero, planned from the outset rather than negotiated in an emergency.
- Access: the company permanently keeps administrator access to its instance, its hosting and its domain name.
- Documentation: required as a project deliverable, not left as an option at the provider's discretion.
- Code ownership: custom development work carried out for the company belongs to it, in a repository it controls.
These four points don't guarantee a project will run without a hitch, but they do guarantee that a hitch stays fixable. To place this approach within the full range of our services, see Odoo ERP in Geneva and Odoo in Geneva. If the concern is more about the general state of an instance than a clearly stalled project, our Odoo instance audit page may be the more suitable starting point.