A new major Odoo version has landed, and the usual question follows within days: do we upgrade? Third-party coverage of Odoo 20 centres on AI agents that can create and update records, an offline mode, and a reworked approach to access rights. Whether any of that matters to you depends far less on the feature list than on the state of your current system.
A caveat before we go further: most of the detail published so far comes from partner blogs and previews, not Odoo's official release notes. Treat it as a direction, and read the official notes before you commit a budget or a date.
The feature list is the wrong place to start
New releases make good headlines, but upgrades rarely fail because a feature was missing. They fail because of what has accumulated on the current system: custom modules, modified reports, inherited views and integrations nobody has documented. The version number is the smallest part of the project.
One reported change deserves attention if you run custom code. Sources describe record rules being replaced by domains attached to each access right. If that holds in the final release, any custom module that ships its own security rules will need to be reviewed and probably reworked before it can move over. That is exactly the kind of cost that never shows up in a feature comparison.
Questions that decide the answer
- How many custom modules do you run, and does anyone still understand them? In our experience this is the single biggest driver of upgrade cost.
- Are you on a supported version today? If support for your current version is not about to end, there is no emergency.
- Is there a feature in the new release you would use within three months, or is it simply new?
- Do your integrations (bank, e-invoicing, payroll, e-commerce) have confirmed compatibility with the new version?
- Do you have a staging copy and someone with time to test it properly?
Three sensible paths
Most companies fall into one of three situations, and each has a different right answer.
- Stay put. If you are on a recent, supported version, the system works and your team has no pressing need, waiting six to twelve months is usually the cheaper choice. Early releases are typically followed by fixes, and the ecosystem of compatible add-ons catches up.
- Upgrade on a schedule. If your version is approaching end of support, plan the move now: audit custom code, run a test migration on a copy of your data, and give users time to validate before go-live.
- Re-implement instead of upgrading. If your database is full of workarounds from a rushed first deployment, a clean setup on the new version, with a deliberate data migration, can cost less than carrying old problems forward.
Be careful with the AI features
AI is the headline of this release, and it is worth testing. It is also worth reading the fine print: coverage reports that these features rely on paid IAP credits. Before building a business case around them, measure what they would actually do in your processes, such as drafting records or reading attached files, and what that would cost per month.
An AI assistant working on messy master data will produce messy results faster. If your product catalogue, customer records or chart of accounts are not clean, fix that first. It will pay off whichever version you run.
A practical way to start
Whatever you decide, take an inventory first. List your custom modules, your integrations, the reports people actually use, and the version you are on. That single page turns a vague worry into a scoped decision, and it takes a day, not a month.
If you are weighing an upgrade and want a second opinion on scope, we are happy to look at your setup on a free 30-minute discovery call. No pressure, and sometimes the honest answer is simply to wait.