Upgrade safely by cloning production to staging, updating custom modules for target ORM APIs, running official migration scripts, and testing critical workflows. Pin third-party modules to maintained versions, diff Odoo source for renamed fields, run -u on modules in dependency order, and fix xpath view breaks before production cutover with rollback database snapshot ready.
Steps
- Snapshot database and filestore; build staging on target Odoo 17 or 18 build.
- Audit installed modules; drop abandoned OCA repos without migration branch.
- Run OpenUpgrade or Odoo enterprise upgrade service for major jumps from 16.
- Update custom __manifest__.py version and fix deprecated decorators and field definitions.
- Execute test suite and manual scripts on MRP, stock, and accounting flows.
- Upgrade modules with odoo-bin -u module_list -d db --stop-after-init in CI.
- Schedule production window with read-only users and post-upgrade reconciliation checks.
Common mistakes
- Upgrading production without staging parity on custom code.
- Skipping -u on dependent modules causing view registry errors.
- Leaving Python 2 patterns or removed account models from ancient forks.
- Not updating website themes and QWeb templates for asset bundles.
- Assuming Odoo.sh auto-upgrade covers unmaintained private modules.
Odoo version notes
Major upgrades from 16→17→18 require module porting in Community and Enterprise. Enterprise subscription includes upgrade service for standard modules; custom code remains your responsibility. OpenUpgrade supports Community paths. Odoo.sh provides upgrade forks—test custom Git branches on duplicate before merge.
When to bring in help
If the fix touches custom modules, regulated traceability, or production outages, a focused rescue sprint beats months of trial and error. See our Odoo service.