Odoo 20 is out, and the feature list is longAI agents that create and update records, read-replica database support, a rebuilt mobile interface, a lighter inventory app. Most of the coverage stops there.
The harder question is whether any of it justifies a migration. A major-version upgrade costs development time, testing time and a maintenance window, and it puts every custom module you own back on the table. For some businesses that math works out immediately. For others it doesn’t, and waiting for a release is the better call.
Here’s what actually changed, what to check before you commit, and how the migration runs if you decide to go ahead.
When Odoo 20 is actually available to you
Odoo 20 was unveiled at Odoo Experience 2026 in Brussels, held from 24 to 26 September 2026.
The version is officially released, but “released” means different things depending on where your database lives. Odoo Online customers get it on Odoo’s schedule. Odoo.sh and on-premise deployments move when you decide to move, which is both the advantage and the responsibility of self-hosting. In practice, access rolls out over the weeks following the announcement rather than all at once.
Two threads run through this release. The first is scaleread-replica architecture and query handling aimed at databases that have outgrown a single instance. The second is autonomy: where Odoo 19 had AI assisting inside workflows, Odoo 20 has AI acting on records. Alongside both, the extensibility work gives developers more room to customize without fighting the framework.
Odoo 19 vs Odoo 20: what genuinely differs
Four changes separate the two versions in a way you can act on. Everything else in Odoo 20 is refined.
| What changed | Odoo 19 | Odoo 20 |
|---|---|---|
| Scope of AI | Assists inside a workflow, drafts text, generates content, suggests | Agents that create and update records themselves |
| External AI tools | No native way to connect an outside model or agent | MCP support, so external agents can reach the database |
| Database reads | Reporting, search and transactions share one instance | Read replicas take reporting off the primary database |
| Light inventory | Stock tracking means running the full warehouse app | Mini Stock tracks levels and value without transfer workflows |
What’s new in Odoo 20
AI that acts, not just assists
The headline change is AI agents. Odoo 19 already had AI helping with content generation, text processing and similar productivity tasks useful, but always a human pressing the button at the end. Odoo 20 extends this to AI agents that can create and update records inside your workflows, with automation actions and smart search built around them.
MCP support is the other half of this. It lets external AI agents connect to your Odoo database directly, which means you can point your own model or assistant at your operational data instead of waiting for Odoo to build the integration. There’s also an AI-enabled Helpdesk workflow that reads customer conversations and helps teams resolve tickets faster, and broader AI-powered workflow automation across the modules.
The practical argument for all of this is proximity. Your customer, sales and inventory data already lives in Odoo, so AI running inside Odoo doesn’t need an export, a sync or a middleware layer to reach it.
Read replicas for databases that have outgrown one instance
Odoo 20 supports database read replicas, which separates read-heavy work from transactional work. Instead of reporting queries, searches and daily transactions all competing for resources on the same database instance, reads get routed elsewhere:
- Users creating and updating transactions → primary database
- Reports, dashboards and read-heavy queries → read replica
If your month-end reporting slows the system down for everyone else, this is the single most relevant change in the release. If your database is small and your reporting is light, it changes nothing for you.
A mobile interface built for mobile
Interfaces and form views have been redesigned for small screens. This matters most for the people who were never going to sit at a desk anywaytechnicians logging work, warehouse staff checking stock, sales reps updating an opportunity between meetings. The goal is routine updates happening where the work happens, rather than queuing up until someone gets back to a desktop.
Mini Stock for businesses that aren’t warehouses
Mini Stock tracks stock levels and inventory value without the transfers, picking and warehouse configuration the full Inventory app requires. Products sold or received update stock levels, inventory value is tracked, and you get basic visibility nothing more.
It’s aimed at service businesses, small retailers and anyone who needs to know what they have on hand without running full warehouse and supply chain operations. Odoo 20 also brings redesigned labels and integrated CMR documents to the full Inventory app.
Point of Sale gets more configurable
The Point of Sale changes cluster around hardware, payments and restaurant operations. Chromium can now access supported local devices directly through the browser, removing several of the hardware setup steps the old approach needed. POS presets make it easier to configure different operating modes: dine-in, takeaway, delivery and floor-plan configuration has improved.
On payments, Odoo 20 adds or expands integrations with providers including Mollie, M-Pesa and Wero.
Field Service moves into Planning
Field Service is now integrated into the Planning workflow, so technician schedules sit alongside the operational detail of the job. A maintenance company’s flow runs: customer requests service → technician assigned in Planning → equipment history reviewed → parts checked → service performed → work recorded → customer updated.
The gain is that coordinators and technicians stop switching between systems to answer two basic questions: what needs doing, and what’s available to do it with.
eCommerce and website, more tightly connected
Odoo continues to close the gap between the website and everything behind it: sales, inventory, payments and marketing. The 2026 eCommerce work adds AI-assisted content creation, product recommendations, upselling, promotions and Click & Collect pushing the website from a storefront that sits on top of your ERP toward one that’s genuinely part of it.
More industry-specific functionality
Odoo is expanding its vertical coverage construction, hospitality, recruitment, repair services and care organisations among them. These build on the existing industry solutions, and the practical benefit is less custom process redesign during implementation. If your sector is on that list, check what ships out of the box before scoping custom work.
What to check before you commit
Every feature list is written from the upside. Here’s the other half, because these are the things that actually determine how long your migration takes.
Third-party modules lag the release. Community and marketplace modules are maintained by their authors, not by Odoo, and they get ported on their own schedule. Some arrive within weeks of a major version, some take months, some never arrive at all. Before anything else, list every third-party module you depend on and check its status for 20. One unported module you genuinely need can stall the whole project.
Custom code written against changed internals. Any module relying on models, methods or APIs that moved between versions will need work. The volume depends entirely on how your customisations were written; code that stuck to documented, supported extension points usually survives a version jump with minor edits, while code that reached into Odoo’s internals tends not to.
AI features are not free. Odoo 20’s built-in AI runs on credit-based In-App Purchases, so usage carries a cost that scales with how much you use it. If AI is your main reason for upgrading, model that cost at your expected volume before you build a business case around it. Connecting your own provider through MCP is the alternative, and it moves the cost to your existing AI subscription instead.
Early releases carry early-release bugs. The first weeks of any major version surface issues that didn’t appear in testing. If your Odoo instance runs something you can’t afford to have wobblepayroll, production scheduling, a live storefront, there’s a reasonable argument for letting a point release or two go by first.
As a general rule, the customisations that cause the most trouble in a major-version jump are the ones sitting closest to accounting entries, stock moves and report templates; those are the areas Odoo reworks most between releases. Added fields, new views and simple automated actions usually survive a version jump with minor edits. Modules that override core methods usually don’t.
Who should upgrade, and who should wait
Upgrading makes sense if:
- Your reporting or dashboards slow the system down for everyone else. Read replicas target exactly this problem.
- You’re several versions behind and losing access to security updates and supported technologies. This becomes urgent rather than optional at some point.
- Repetitive manual work is eating real hours, and the new automation could take some of it. Check that against the IAP cost before deciding.
- You’re growing across teams, locations, products or markets, and the current setup is straining.
- Your custom modules have become hard to maintain. A migration is a natural moment to retire what you no longer need.
Waiting is the better call if:
- Your current version is stable, supported, and nothing on your list of problems appears in the Odoo 20 changelog.
- You depend on third-party modules that haven’t been ported yet.
- Your team is mid-way through something that needs the system to stay predictable: a busy season, an audit, a product launch.
- The only driver is the AI features, and you haven’t yet modelled what they’ll cost at your usage.
The test isn’t whether Odoo 20 is better. It is. The test is whether it solves something that’s costing you money right now.
How the migration runs, step by step
- Audit what you have. Document your current version, hosting setup, database size and configuration. Inventory every custom module, every integration and every automated action, then mark what you no longer use. Things you retire here are things you don’t have to port, test or maintain afterwards.
- Check compatibility against Odoo 20. Go through your custom modules, apps and dependencies and sort them into three piles: works as-is, needs changes, needs rebuilding. Third-party modules go in a fourth pile “waiting on the author” and that pile drives your timeline more than anything else.
- Scope and plan. Define the Odoo migration scope, timeline and rollback strategy before touching anything. Phase the work, and pick a window when business operations are at their lightest. The rollback plan matters most on the day you’re most confident you won’t need it.
- Prepare customisations and integrations. Update custom modules against Odoo 20 and adapt the integrationsAPIs, connectors, webhooks, scheduled jobs. Anything that talks to an external system needs testing from both directions, not just yours.
- Migrate the database. Take a verified backup first, then migrate. Afterwards, check records, configurations, access rights and data relationships. Access rights in particular tend to shift quietly during a version jump and nobody notices until someone can’t see a record they need.
- Test properly. Run functional, security and performance testing across your real workflows, sales, purchase, manufacturing, inventory, payroll, whatever your business actually depends on. Have the people who use each module daily test their own, because they’ll spot wrongness that a test script won’t.
- Train the team. New capabilities only pay off if people know they exist. Role-based Odoo training is more effective than a single all-hands walkthrough, since a warehouse user and an accountant need entirely different things from the new version.
- Deploy, monitor, tune. Schedule the production migration, go live, then watch closely for the first few weeks. Expect to fine-tune configuration after real usage reveals what testing didn’t.
As a rough shape: a small database with few customisations can move in two to four weeks including testing. A mid-sized deployment carrying twenty or thirty custom modules and several live integrations more commonly runs six to twelve weeks. Past that, what stretches a timeline is rarely the migration itselfit’s waiting on third-party modules and rewriting customisations that were built against core internals. Any estimate produced before the audit in step 1 is a guess, including a confident one.
Pre-migration checklist
Work through this before the migration starts, not during it.
- Current Odoo version, hosting environment, database size and configuration documented
- Custom Python modules, XML views, JavaScript components and automated actions audited
- Every third-party module checked for Odoo 20 availability, with a decision for any that aren’t ported
- APIs, payment gateways and connected apps reviewed for compatibility
- Field, model and relationship changes mapped, so records migrate correctly
- Verified backup of the production database and configuration files restored once, to prove it works
Full upgrade rehearsed on a test database, with real workflows exercised
- Maintenance window scheduled, downtime communicated, rollback plan written down
- AI credit usage estimated, if you plan to use the built-in AI features
Five problems that come up, and what to do about them
Custom modules built on deprecated code. Modules relying on models, methods or APIs that changed between versions will break, usually loudly. Review the codebase for deprecated dependencies early, update the modules, and test them against a clean Odoo 20 instance rather than against your migrated database that separates code problems from data problems.
Data mapping errors. When fields, models or data structures change between versions, records don’t always land where they should. Analyse the existing schema first, map the affected fields and models explicitly, and validate migrated records against the source database rather than eyeballing a few samples. Count rows.
Broken integrations. Changes to APIs and authentication methods can quietly disconnect external systems. Audit every integration, update API calls and connectors where needed, and run end-to-end tests that confirm data flows both ways. The failure mode here is silent syncs stop and nobody notices until the numbers don’t match.
Performance and dependency issues. Large databases, third-party Python packages and infrastructure configuration can all affect migration speed or post-migration stability. Assess environment dependencies up front, optimise where needed, and run performance testing before production deployment, not after.
Dirty data. Duplicates, outdated records and incomplete fields make migration harder and carry the mess into your new database. Identify data-quality problems before you start, clean and validate, and treat the migration as the opportunity to finally do it. You won’t get a better one.
Of the five, custom module compatibility and dirty data account for most lost time. The first because the work is genuinely hard to scope until you’ve attempted it, the second because the state of a production database is almost always worse than the people using it believe.
What it costs and how long it takes
There’s no useful single number here, and anyone who gives you one without looking at your setup is guessing. The variables that actually move cost and timeline are your current version. A jump from 17 is a different project than a jump from 19 along with database size, the number and complexity of custom modules, how many integrations you run, and whether the third-party modules you depend on have been ported yet.
That last one is worth repeating, because it’s the variable most often left out of estimates and the one most likely to blow up a timeline. You can’t develop your way around a module whose author hasn’t released a version for Odoo 20.
Broadly, a small deployment with light customisation sits at the two-to-four-week end, a mid-sized one with meaningful custom work at six to twelve. But the honest answer is that the audit produces the estimate, not the other way round. A day spent inventorying modules and integrations will tell you more than any published range, including this one.
Conclusion
Odoo 20 is a real step forward. AI that acts on records rather than just drafting text, reading replicas for databases that have outgrown one instance, a mobile interface built for the people who actually use mobile; these are substantial changes, not a version bump.
But the features aren’t the question. The question is whether any of them solve something that’s costing you money today. If your reporting is slow, if you’re falling out of support, if manual work is eating hours you can’t spare the case. If your current version is stable and nothing on your problem list shows up in the Odoo 20 changelog, there’s no prize for moving first.
Start with your own workflows rather than the release notes. Find the thing that’s actually hurting, then check whether Odoo 20 fixes it. That’s a much shorter conversation than a feature comparison, and it gives you a real answer.
FAQs
Does every business need to migrate to Odoo 20?
No. Businesses on older versions, those planning major customisation work anyway, or those who specifically need the new capabilities have the strongest case. If your current version is stable and supported, waiting is a legitimate choice rather than a failure to keep up.
Do Odoo 20’s AI features cost extra?
Yes. The built-in AI runs on a credit-based In-App Purchase system, so cost scales with usage rather than being included in your subscription. The alternative is connecting your own AI provider through Odoo’s MCP support, which moves the cost to a subscription you may already be paying for. Model this before you build a business case on the AI features.
What are the new AI features in Odoo 20?
Agentic automation, AI agents that create and update records, file-based interactions, automatic model selection, image generation, voice dictation, and MCP support for connecting external AI agents to your Odoo database.
Which modules get updates in Odoo 20?
Accounting, Sales and CRM, Point of Sale, Inventory and Supply Chain, Purchase and Manufacturing, Website and eCommerce, HR, Payroll and Attendance, and Helpdesk and Communication.
How do I upgrade from Odoo 19 to Odoo 20?
Start with an audit of your custom modules, integrations, database and third-party dependencies. That audit tells you whether this is a two-week project or a three-month one, and it’s worth doing before you commit to a timeline or a budget. From there, follow the process above, or talk to a partner who has run the version jump before.
About the author
This post was written by the Odoo team at Ahex Technologies, a Hyderabad-based software development and Odoo ERP implementation company working across implementation, migration, custom module development and ongoing support.
Write and Win: Participate in Creative writing Contest & International Essay Contest and win fabulous prizes.
About the Author
