Odoo 20 is out: what breaks in custom modules, by area

Short answer. Between Odoo 19.0 and 20.0, Community Edition, 32,680 things changed in core that custom code can depend on: Python methods, fields, XML views and records, and JavaScript modules, spread over 408 core modules and 13 business areas. Four areas carry more than 40% of it: Platform & Framework, Website & eCommerce, HR & Payroll and Accounting. The sharpest edges for custom modules are removed controller routes and reworked business-logic methods rather than one dramatic rewrite.

Odoo 20 was released on 24 September 2026 (release notes). The release notes describe what is new. They do not describe what a custom module written against 19 runs into. This post is the second half of that picture, for Community Edition, with numbers you can check against the per-area migration guides.

What is counted: changes in Odoo core between 19.0 and 20.0 that custom code can depend on. What is not counted: Enterprise modules. The total includes roughly 6,800 changes inside country localisation modules (about a fifth of it, 2,850 of them from one Chinese city-list module that Odoo 20 drops); the module count and the area table below leave localisation and theme modules out, which is why the areas do not add up to the total. Read the total as the size of what moved in core, not as the effort to upgrade any particular module. A module that touches none of it has nothing to do.

Where the changes land

Changes by business area, Odoo 19 → 20, Community Edition:

The remaining roughly 11,100 changes sit in smaller apps that do not form an area of their own, in country localisation modules and in themes. By module, the five that moved most are mail (1,722), base (1,502), account (1,294), website (1,253) and point_of_sale (1,032), followed by website_sale (1,020), stock (850) and hr_work_entry (834).

Two things stand out. First, mail and base lead, and nearly every custom module inherits from both, so even a module that lives in Purchase or CRM is exposed to the two biggest moving parts. Second, the four leading areas are the ones where custom modules are usually the heaviest: framework hooks, web controllers, payroll rules and accounting logic.

What the changes look like, area by area

The counts tell you where to budget time. The per-area guides tell you what to look for. A sample of what they already name, so you can recognise it in your own code:

Platform & Framework. The theme is removed routes and helpers that custom code hooked into. The guide names the removal of the helper that trimmed tracebacks off access-denied errors, the bus "missed notifications" check on the bus controller, and the generic calendar credential check. If you subclassed a core controller, catalogue every route you touch before you upgrade; a silent 404 in the browser is the most likely first symptom. Per Odoo's release notes, record rules are also replaced by a domain on access rights, so security files are worth a dedicated pass.

Website & eCommerce. Most of the risk sits in the cart, delivery, donation and checkout flows rather than in the data model. The guide names the cart-quantity and clear-cart endpoints, the pickup-location lookup and setter, the donation payment page and transaction routes, and the website info sitemap generator, all removed or moved. The JavaScript that calls these routes is detected by a scan but not auto-fixed, so plan reviewer time for the front end.

HR & Payroll. The highest-volume area after the framework and website. hr_work_entry alone carries 790 changes. Custom payroll rules, work-entry generation and leave logic are the places to look.

Accounting. Per Odoo's release notes, the accounting structure itself changed in 20 (parent accounts and depreciation models among them). Anything that extends account.move, reports or reconciliation should be treated as a full review rather than a search-and-replace.

Point of Sale. Several server-side data-loading, loyalty and hardware-config entry points were removed or reshaped. The guide names the kiosk self-ordering data endpoint, the gift-card status and loyalty-partner lookups, the manager-access employee list and auto-validation toggle on pos.config, and the loyalty-history hook on pos.order. Modules that hook into ordering, coupons or terminal setup need targeted rework.

Inventory. Broad but mostly mechanical: the removal of copy_data overrides on carriers, categories and pricelists (Odoo stopped forcing "(copy)" suffixes), a few pricelist and product fields disappearing, and a batch of unit-of-measure fields renamed from product_uom_id to uom_id. The renames touch commonly referenced records, so sweep domains, views and Python together.

Sales. Breakage clusters around billing logic and stored computed fields: timesheet-to-invoice links, sales-team invoicing KPIs and targets, the expense-policy field on product templates, and the order-level recompute-prices and recompute-taxes actions.

Manufacturing. The same unit-of-measure rename lands on BoMs, BoM lines, byproducts and the production-split wizard, plus the retirement of several maintenance helpers and legacy fields such as the BoM consumption tolerance.

Across the board, Font Awesome icons are replaced by Material Symbols per Odoo's release notes, which shows up as view and asset changes rather than tracebacks.

19 → 20 or 18 → 20?

Many databases sat out 19 and will go 18 → 20 as one jump. Counted the same way, that jump carries 44,778 changes across 445 core modules, 37% more than 19 → 20, and the increase shows up in every business area. The upside of one jump is one test cycle and one go-live; the cost is carrying both releases' changes at once. The 18 → 20 guide covers that path separately.

How to use these numbers

1. Rank your custom modules by the areas they touch, using the table above. A module on website_sale and account is in two of the top four areas; a module on crm alone is in the smallest.
2. For each module, start with controllers and routes, then Python overrides on core models, then views, then JavaScript. That order matches where the removals concentrate.
3. Read the per-area guide for each area you hit. Each one lists the items that need the closest look, with real before/after code, and a checklist at the end.
4. Scan the module before you quote. A free scan lists the breaking changes it detects in your code, with file and line, and an effort estimate for that scope, so the number in the proposal is about your module, not about Odoo in general.

Scan a module for Odoo 20, free, no card

Per-area guides for 19 → 20: Pillar · Website & eCommerce · Point of Sale · Inventory · Sales · Manufacturing

FAQ

Does 32,680 changes mean my module needs 32,680 fixes? No. It is the size of what moved in Odoo core between 19.0 and 20.0. A module only meets the changes in the parts of core it touches. Most modules meet a few dozen at most; a scan tells you which.

Is this Enterprise too? No. The figures are Community Edition only. Enterprise adds modules and changes that are not in these counts, and the Enterprise totals are considerably higher.

What changed most between Odoo 19 and 20 for developers? By volume: Platform & Framework (4,038 changes), Website & eCommerce (3,819), HR & Payroll (3,120) and Accounting (2,509). By kind: 6,035 Python methods changed and 1,894 removed, and 3,679 XML views or records changed with 1,750 removed. The recurring pattern is removed controller routes and reworked business-logic methods.

Is Odoo 20 released? Yes. Odoo 20 was released on 24 September 2026, with the release notes at odoo.com/odoo-20-release-notes and a 20.0 branch on GitHub.

Should I go 18 → 20 directly or 18 → 19 → 20? Directly is one test cycle and one go-live, but carries 44,778 changes against 32,680 for a single step from 19, 37% more. If your custom code is light, one jump is usually cheaper overall. If it is heavy in the top four areas, price both paths before deciding.

What does a scan check and what does it not? It loads the module against the target version and lists detected breaks in Python, XML and JavaScript with file and line, then generates re-validated fixes for most Python and XML findings. JavaScript breaks are detected and handed off with context, not auto-fixed. Scans are free and unlimited.

Figures: VersionBridge, Community Edition, 19.0 → 20.0; quote with attribution and a link.