An Odoo health check is an independent audit of one Odoo database: its configuration, custom modules, performance, access rights, data quality and readiness for the next version. I review the system on a copy or with read-only access, test what I suspect, and deliver a written report where each finding has evidence, a risk level and a recommended fix. It is the usual first step before a rescue, an upgrade or larger development.
When does a health check make sense?
- You took over an Odoo system from a previous partner or an employee who left.
- Users complain, but nobody can say which problems are configuration, which are code and which are habits.
- You plan an upgrade and need to know how much custom code has to move.
- Finance does not trust stock valuation, margins or reconciliation.
- You want an outside view before a large investment in new modules or a new partner.
What does the audit cover?
| Area | What I look at | Typical findings |
|---|---|---|
| Configuration | Companies, warehouses and routes, journals, taxes and fiscal positions, units of measure, automated actions, scheduled jobs | Routes that conflict, duplicate journals, taxes set per product instead of per fiscal position |
| Custom code | Every non-standard module: manifests, overrides of core methods, tests, translations, licences of third-party add-ons | Core behaviour replaced instead of extended, no tests, copied third-party modules with unclear licences |
| Performance | Worker and cron settings, slow requests in the logs, heavy computed fields, filestore size, long-running scheduled jobs | Too few workers for the number of users, a computed field recalculated on every save |
| Security and access rights | Groups, access rules and record rules, multi-company rules, portal and public routes, API keys, database manager exposure | Users seeing other companies' records, public URLs guessable by sequential ID, an open database manager |
| Data quality | Duplicate partners and products, missing units, unreconciled items, stock valuation layers compared with accounting balances | Interim stock accounts that never clear, negative stock hidden by settings |
| Operations | Backups and restore tests, mail servers, monitoring, where the code lives | Backups that run every night but produce empty files, code that exists only on one server |
| Upgrade readiness | Version support dates, custom modules against the target version, third-party module availability | Fields and methods removed in the target version, add-ons with no maintained port |
Access rights are reviewed against Odoo's own model of groups, access rights and record rules, and upgrade readiness against the official support and upgrade policy.
What is the deliverable?
A written report and a walkthrough call. The report lists findings in three groups: critical (data, money or security at risk), important (costs time every week) and later (worth doing with the next change). Each finding has the evidence, the cause and one or more fix options with a rough effort range.
The report also contains:
- a list of all custom and third-party modules with a short verdict for each: keep, fix, replace with standard or remove;
- quick wins your admin can do without development;
- an upgrade outlook: which version you should target and what blocks it;
- what not to touch, because it works and changing it adds risk.
In the walkthrough call we go through the critical items with the people who will decide, and I answer questions from your admin or partner.
How long does it take?
For one company database with a moderate number of custom modules, plan for roughly one to two weeks of calendar time from access to walkthrough. Larger multi-company setups or many custom modules take longer. The scope and dates are agreed before the work starts, and the health check has a fixed scope, so it does not quietly grow into a project.
How do you prepare?
Access
A recent database copy with its filestore, or a user with administrator rights on a test copy. For self-hosted systems, read access to the Odoo configuration and logs.
Code
Access to the git repository with your custom modules, or an archive of the addons folders if there is no repository yet (that is a finding in itself).
Your top problems
Five problems that cost you the most, in your own words, with an example record for each.
One contact person
Someone who knows the daily processes and can answer short questions within a day.
What happens after the health check?
You decide. Some companies fix the quick wins internally and stop there. Others give the report to their existing partner. Others ask me to rescue a stalled implementation, port the custom code for an upgrade or rewrite a module properly. In every case you own the report and can share it with whoever you want.
Tell me about your Odoo
Describe your situation in a few lines. We reply by e-mail.
Frequently asked questions
Do you need access to our production database?
Not necessarily. A recent copy is often enough, and it can be anonymised if you prefer. For performance and operations checks, read-only access to production logs and server settings helps. I never change production during a health check; it is a review, not a repair.
Is the health check useful if we plan to replace our partner?
Yes. It gives you an independent picture of what you have before you talk to anyone else: which custom code exists, what state the data is in and what an upgrade would involve. Any partner, including your current one, can work from the same report.
Will you fix the problems you find?
Only if you want me to. The report is written so that your internal team or your existing partner can act on it. Many quick wins are configuration changes your admin can make in an afternoon. Larger fixes are scoped separately after the walkthrough.
Can you audit an Odoo Online database?
Yes, with a narrower scope. On Odoo Online there is no custom Python code and no server to inspect, so the review concentrates on configuration, access rights, data quality, Studio customisations, integrations and upgrade timing.