IMX impromatrix

Home / Insights / Odoo 16 → 18 migration

GUIDE · UPDATED JULY 2026

Odoo 16 to 18 migration: what breaks and what it costs

By the Impromatrix consulting team – Odoo since 2020, ERP since 2011

Two version jumps, one project. Your data will make it; some of your customisations won't – here's exactly which ones, what the fix costs in 2026, and how the cutover works without stopping your business.

What breaks – by area

Area
What happens in 16 → 18
Typical effort
Standard data
Customers, products, orders, stock, accounting entries migrate reliably via OpenUpgrade or Odoo's upgrade service.
Low – scripted
Custom view XML
The attrs/states syntax was removed in 17 – every custom view using it must be rewritten. The single most common breakage.
Medium – mechanical
Custom JS widgets
Anything predating OWL 2 needs porting; old-style widgets don't load at all in 18.
High per widget
QWeb reports
Custom invoice/delivery templates usually need touch-ups; layouts and inherited templates shift between versions.
Low–medium
Third-party modules
OCA modules: mostly ported to 18 already. Paid app-store modules: check before you commit – some are abandoned and need replacing.
Audit first

What it costs (2026, EU consulting rates)

System profile
Cost range
Duration
Configuration only, no custom code
3,000 – 6,000 €
3–4 weeks
Typical SME: 5–15 custom modules
6,000 – 15,000 €
4–6 weeks
Heavy custom + integrations
15,000 – 25,000 €+
6–10 weeks

Rule of thumb: the cost driver is custom code, not database size. An audit (1–2 weeks) prices your case precisely – and usually finds modules cheaper to delete than to migrate.

Can I skip Odoo 17 and go straight to 18?

Yes. On Community, OpenUpgrade runs the 16→17→18 steps in sequence inside one project – you never operate on 17. On Enterprise, Odoo's hosted upgrade service jumps directly. Either way it's one cutover, not two.

Will my OCA modules work on 18?

Most maintained OCA modules are ported within months of a release; by 2026 the 18.0 branches are mature. The audit checks each one – where a port is missing, there's usually a successor module or the feature has landed in core.

How much downtime should we plan for?

Practically none during working hours. The migration runs repeatedly on copies until it's boring; the real cutover happens on a weekend – final delta Saturday, verification Sunday, live Monday. See the six-version jump we ran this way →

Should we migrate ourselves or hire help?

If you have zero custom code and an in-house admin comfortable with PostgreSQL, a DIY OpenUpgrade run is feasible. With custom modules, the porting work is developer work – the honest question is whether your developer's weeks cost less than a fixed-price migration with a rollback plan.

Is 16 → 18 also the moment to drop Enterprise?

Often, yes – the database is being converted anyway, so switching edition adds little extra work. If licence costs bother you, have the audit price both paths. How the conversion works →

What would your jump cost?

Send us your version and module list – we'll estimate the migration honestly, free.

Book a free consultation