Odoo 17 to 18 Migration Guide: What Breaks and How to Fix It

An Odoo 17 to 18 upgrade is a single version step, which makes it one of the more predictable migrations you can run — but "predictable" is not the same as "automatic". The database conversion itself is usually uneventful. What takes the time is your custom code, because Odoo 18 finally removed things that Odoo 17 only deprecated. If you have custom modules, at least one of them will almost certainly break, and this guide covers exactly which changes cause it.

Last verified: 13 September 2026 against Odoo's official documentation. Odoo 17 reached its planned end of standard support in September 2026, so this upgrade has moved from optional to overdue for anyone still on it.

Quick answer

• The single biggest breaking change: name_get() was deprecated in Odoo 17 and removed in 18. Any model that overrides it must be rewritten.
• Views: the <tree> tag is deprecated in favour of <list>.
• Odoo gives you a tool: odoo-bin upgrade_code rewrites source code against a target version. Odoo describes the scripts as best-effort, not silver bullets.
• Third-party apps are a hard dependency — if a vendor has not shipped an 18.0 branch, you cannot complete the upgrade with that app installed.
• Effort: a standard install with no custom modules converts quickly. With custom modules, the adaptation and testing is the project.
• Urgency: Odoo 17 is past its planned end of standard support, so security updates are no longer part of the deal.

Why this upgrade is urgent now

Odoo supports each major release for three years. Odoo 17 was released in November 2023, which put its planned end of standard support in September 2026 — that date has now passed.

In practice nothing switched off. Your system still runs, your team still logs in. What ended is your entitlement to security updates and bug fixes under standard support. For a system holding financial records and customer data, an indefinitely open vulnerability is the part that matters, and it is increasingly what gets flagged during client security reviews.

If you want the full picture of which releases are still covered and when each one expires, we keep that maintained in our guide to Odoo supported versions.

What actually breaks between Odoo 17 and 18

Odoo 18 is not a dramatic rewrite. The pain is concentrated in a small number of removals and renames that happen to sit in code almost every custom module touches.

1. name_get() is gone. This is the one that catches most teams. The method was deprecated in Odoo 17 but still worked, so plenty of modules kept overriding it and nobody noticed. In Odoo 18 it is removed. Any model overriding name_get to control how records display needs rewriting against the current display-name mechanism. Grep your whole addons path for it before you do anything else — it is the fastest way to size the job.

2. <tree> becomes <list>. The tree tag is deprecated in Odoo 18 in favour of list. Mechanically this is a simple find-and-replace across your view XML, and it is exactly the kind of change Odoo's own tooling handles for you (see below). It is high volume but low difficulty.

3. Stat button markup. The container class for stat buttons changed. The old oe_button_box still renders, so nothing visibly fails — it just falls back to legacy CSS and looks subtly wrong against the rest of the Odoo 18 interface. This is the category of problem that survives testing and gets reported by users in week two.

4. Third-party apps. Not a code change, but the most common hard blocker. Every paid or OCA app you have installed needs an 18.0 branch from its maintainer. If one does not exist, your options are to wait, to pay someone to port it, or to drop the app. Check this before you schedule anything, because it is the one constraint you cannot engineer around.

Odoo ships a tool that does part of this for you

This is worth knowing about because a surprising number of upgrade guides do not mention it. Odoo includes an upgrade_code command that rewrites source code using scripts bundled with the release, specifically for the heavy lifting of large code migrations and forward ports.

Run it with --dry-run first, which lists the files that would be rewritten without changing anything. It also accepts --addons-path, and --glob if you want to limit which files it touches. Point it at a copy of your addons, never at your only copy.

It handles the mechanical changes well — the tree to list rename is exactly its kind of work. It will not reason about your business logic. Odoo states this plainly in its own documentation: the scripts are a best-effort at migrating source code, and they are not silver bullets. Treat the output as a first pass that still needs review, not as a finished migration.

The upgrade process, step by step

Step 1 — Inventory before you touch anything. List every installed module split into core, OCA, paid third-party and custom. For each non-core module, confirm an 18.0 version exists. This single step tells you whether the project is two weeks or two months.

Step 2 — Grep for the known removals. Search your custom addons for name_get and for <tree. The counts give you a realistic estimate before anyone writes a line of code.

Step 3 — Take a verified backup. Restore it somewhere to prove it works. An unverified backup is an assumption.

Step 4 — Run upgrade_code on a copy. Dry run first, review what it proposes, then apply it to a working branch of your custom modules.

Step 5 — Convert the database in a staging environment. Never on production. This is where schema issues and module load failures surface, and where they should stay.

Step 6 — Fix what the conversion reveals, then repeat. Expect several cycles. Each pass should get shorter; if it is not, something structural is wrong with a custom module and it needs rethinking rather than patching.

Step 7 — User acceptance testing. Real users, real workflows, real data. Technical validation proves the records moved; UAT proves the business still works. The stat-button class of problem only ever surfaces here.

Step 8 — Production cutover with a rollback plan. Schedule it around genuinely quiet hours, with the verified backup as your route back and a decision made in advance about what would trigger using it.

What to test after the upgrade lands

The database converting cleanly is not the finish line. These are the areas where Odoo 18 upgrades actually generate support tickets, and they are worth walking deliberately rather than waiting for users to find them.

• Every custom form and list view. The tag rename and the stat button markup both cause visual regressions that load without error. Open each one rather than trusting that the module installed.
• Record display names. Anywhere name_get was overridden, records may now display differently in dropdowns, breadcrumbs and many2one fields. Users notice this immediately.
• Reports and PDF templates. Custom QWeb layouts survive the upgrade more often than not, but spacing and table rendering can shift.
• Scheduled actions and automations. Confirm they still fire and still target the right records after the conversion.
• Access rights. Verify a normal user, not just an administrator, can do their job. Permission regressions hide well from admin accounts.
• Every integration end to end. Push a real transaction through each connected system rather than confirming the connection is green.

Run this list against staging before go-live and again on production afterwards. It takes an hour and it is the difference between finding problems yourself and having your finance team find them.

Should you go to 18, or straight to 19?

A fair question if you are starting this now, since Odoo 19 is already out and supported for longer.

Going straight to 19 means one project instead of two, and a longer support runway once you land. The catch is that you compound two sets of breaking changes, and when something fails you have two candidate causes rather than one. It also widens the third-party app problem: every app now needs a 19.0 branch, and ecosystems settle around a release over time.

Our general view: if your customisation is light and your app list is short, going to 19 in one step is reasonable. If you carry meaningful custom code, step to 18 first, stabilise, then plan 19 as a smaller separate project — we have covered that next step in the Odoo 18 to 19 migration guide. Testing at each stage catches problems while they are still separable.

How long it takes

For a standard installation with no custom modules, the database conversion itself is quick — often minutes rather than hours. That figure is where unrealistic expectations come from, because almost nobody is in that position.

With custom modules, the realistic shape of the project is module adaptation and testing, which typically runs in weeks rather than days and scales with how much custom code you carry and how many third-party apps need checking. The conversion is the short part; making your own code work on the new version is the project. That distinction matters when you are negotiating a timeline, and it is the same reason a version upgrade is not the same job as a migration from another system.

Want to know which of your modules will break? An assessment greps your addons for the known removals, checks every third-party app for an 18.0 branch, and comes back with real scope before you commit to a date. Book a free migration assessment.

Odiware's approach to version upgrades

We treat a version step as a code compatibility project rather than a data project, because on a single-version upgrade that is what it actually is.

The sequence starts with the module inventory and a grep-level audit of the known removals, which produces a realistic estimate instead of an optimistic one. Custom modules are then upgraded on a branch, with upgrade_code used for the mechanical rewrites and human review for everything else. The database conversion is rehearsed in staging until it runs clean twice in a row, and only then scheduled on production with a tested rollback route. We stay close through the first weeks afterwards, because the subtle UI-level regressions surface in ordinary daily use rather than in testing.

That methodology is the same one behind our Odoo migration services, whether the project is a single version step or a move from another ERP. A recent example from the same team: a mid-sized IT services company moved its HRMS, payroll and recruitment setup between Odoo Community versions with custom Indian payroll rules — PF, ESI, PT and TDS — that had to keep calculating correctly throughout. Monthly payroll cycles ran without disruption. The full Odoo migration case study covers how.

Odoo 17 to 18 upgrade FAQ

Is Odoo 17 still supported?

Odoo 17 reached its planned end of standard support in September 2026. The system keeps running, but security updates and bug fixes under standard support have ended. Extended support may be available at additional cost depending on your hosting type.

What is the biggest breaking change in Odoo 18?

The removal of name_get(). It was deprecated in Odoo 17 but still functional, so many custom modules still override it. In Odoo 18 it no longer exists, and any model relying on that override needs rewriting.

Can I upgrade Odoo 17 to 18 automatically?

The database conversion is largely automated, and Odoo's upgrade_code command handles many mechanical source changes. Neither reasons about your business logic, so custom modules still need human review and testing before production.

What happens to my third-party apps?

Each needs an 18.0 branch from its maintainer. If one does not exist you must wait for it, pay to have it ported, or remove the app. Check this before scheduling the upgrade, because it is the constraint you cannot work around technically.

Do I need to rewrite all my custom modules?

Rarely. Most need targeted changes rather than a rewrite — the removed methods, the view tag rename, and any UI markup that has moved on. The exception is a module built around a pattern Odoo has since restructured, which can be cheaper to rebuild than to patch.

Should I skip 18 and go straight to Odoo 19?

It is technically possible, and reasonable if your customisation is light. With substantial custom code, stepping to 18 first keeps each set of breaking changes separable, so a failure has one obvious cause rather than two.

How long does an Odoo 17 to 18 upgrade take?

The conversion itself is quick on a standard install. Realistically the timeline is set by custom module adaptation and testing, which scales with how much custom code and how many third-party apps you have. An inventory and a grep of your addons will size it far better than any generic estimate.

Will I lose data upgrading from 17 to 18?

Not when the upgrade follows a proper sequence with a verified backup, staging rehearsal and validation. Data loss in version upgrades is almost always a symptom of skipping the staging step rather than a flaw in the conversion itself.

Start with a grep, not a date

The most useful hour you can spend on this upgrade is not planning a cutover weekend. It is searching your addons path for name_get and <tree, and checking whether every third-party app you depend on has shipped an 18.0 branch. Those three answers determine whether this is a fortnight or a quarter, and they cost nothing to find out.

With Odoo 17 now past its supported window, the question is no longer whether to do this, only how carefully.

Know the scope before you commit to a date. An assessment audits your modules, integrations and custom code against Odoo 18 and comes back with real scope, timeline and risk. No obligation attached. Book a free Odoo migration assessment.

Editorial note: technical details are taken from Odoo's official documentation as of 13 September 2026. Behaviour and tooling change between releases — verify against current documentation before planning an upgrade.