We could say that the main factor to ensure the success of our implementation of an ERP system like Odoo, and subsequently, its operation, is determined by the Odoo partner we have chosen. In many projects we review, the problem is not Odoo, but the lack of visibility that the client has over what is being done, how it is developed, and the quality of the work delivered. For that reason, we like to explain what we should expect in our instance and, above all, so that it can be understood by non-technical profiles.
The Odoo belongs to the client.
The first thing we must do is request access to our code, even if we do not understand it, unless we already have it. This is synonymous with transparency and provides great security, as we can request external audits if we consider it necessary, for example. If our partner opposes this, it is the first sign that should raise alarms. There is no strong argument for not being able to have access to the code of your own system.
This applies whether Odoo is hosted on the partner’s servers, on Odoo.sh, or on any other cloud provider. Hosting does not remove the client’s right to access the code developed for them.
Having a minimal understanding of how an Odoo project works
Without needing to go into technical details, it is advisable to have a superficial understanding of how an Odoo project is organized. This will allow us to assess firsthand how our partner works and what signals we should watch for.
We are going to explain which aspects are worth reviewing.
How is code managed?
First of all, we must know that the code is uploaded to repositories where it is stored and managed. There are many platforms that allow the management of cloud repositories and access to them. The most commonly used are GitLab and GitHub, which probably sound familiar. Underneath, the management is standard and carried out with a version control system called Git, which allows us to perform actions on uploads and code management through commands. Returning to what interests us, we, as clients, must have access to our code by accessing one of these platforms.
Accessing our projects
Once inside the repository, we will be able to see the folder structure of the project. Normally, we will find:
- Odoo environment configuration
- Code of used modules
- Code of the modules used
- Deployment scripts
At this point, there is no need to go into more detail, but it is reasonable to ask our partner to explain how it is structured and why.
Let’s look at some of the positive signs we may find when reviewing the project:
- Clear module structure
- Continuous change history (we can ask them to show us how to view the commits; in general, they should be relatively small, not changes of 2,000 lines at once)
- Changes should have understandable messages
- Minimal project documentation
On the other hand, we must be alert to things such as:
- All the code is uploaded at once
- No change history
- Access is given to repositories we do not have access to
- There is no documentation of any kind
Project management
Another aspect we must know, and our partner must explain to us with total clarity, is how our Odoo will be managed, even if only at a high level:
- Where the servers are hosted
- Which security systems are used
- How backups are performed
- How the system is monitored
It is not necessary to understand all the details, but it is important to perceive that there is an orderly and professional management.
Origin and quality of the code
In Odoo, the code can come from different sources:
- Odoo core modules
- Odoo Enterprise modules (under license)
- OCA modules
- Third-party modules
- Custom developments
Our advice is to always prioritize Odoo core modules or OCA modules, as they come from open environments, are audited, and maintained by large technical communities. In the case of having an Odoo Enterprise license, the modules are usually good as well, although in general there are Community alternatives if we are interested. In that case, it is also important that our partners are able to explain them to us.
Regarding third-party modules, they should only be used when the provider is known, the code is accessible, and there is clear maintenance. Otherwise, they usually cause serious maintainability issues.
Developing custom modules is completely valid when there is no open alternative, as long as it is well documented, explained to the client, and properly tested.
Monitoring the implementation of CI/CD
Additionally, we can ask our partner if they have quality systems implemented for code development and deployment, known as CI/CD.
These systems allow:
- Run tests automatically
- Detect errors before reaching production
- Ensure reproducible deployments
This translates into fewer errors in production, fewer crashes after updates, and less dependency on a specific person.
The OCA as a quality mark
It is very common that many partners are OCA collaborators. This is because, in the vast majority of cases, to complete our Odoo and make it functional, we must use the modules developed by the OCA itself. The OCA is an open and collaborative community, where the code is valued by the entire community and, therefore, ensures high quality. It is not an absolute guarantee, but it is a very good sign. An active partner in the OCA usually works in line with good practices and recognized technical standards. If we want to delve into this, we can review a conversation between Harald from Sygel and Enric, our CEO, in which they talk about how to see it. We can also look at the statistics that the community shares about the most collaborative partners.
Conclusion
These recommendations are not intended to distrust the partner, but to provide visibility and control to the client. A good partner does not fear transparency and understands that the code and the project belong to the client.
Although applying these recommendations requires a small initial effort, it is more than compensated by avoiding excessive dependencies, opaque projects, or systems that are difficult to maintain. In the end, the Odoo is yours, and you should be able to access your code easily.