Odoo Migration & Upgrade Services

Odoo releases a new major version each year — the latest is Odoo 20 — and supports the three most recent versions. For Enterprise databases, Odoo's upgrade service produces an upgraded test copy first, requested from the database manager on Odoo Online, the Upgrade tab on Odoo.sh, or Odoo's upgrade tool for self-hosted installations. The service is included with an Enterprise subscription, can move a database across several versions in one request, and handles standard Odoo data. Switching edition isn't part of an upgrade.

Odoo's upgrade service needs an Enterprise subscription code, so Community databases usually go through OpenUpgrade, an Odoo Community Association (OCA) project that migrates one version at a time, with coverage that varies by module. In both cases, custom modules must be made compatible with the target version; on Odoo.sh, the upgrade then runs those updated modules automatically.

Between versions, Odoo renames models and fields, changes methods and reworks views; front-end code built with the OWL framework often changes more than Python code. Each custom module has to be adapted, and custom fields sometimes need migration scripts so data lands in the right place.

Third-party modules need checking too: some vendors publish a version for each release, others stop. Where a module has no upgrade path, we replace it with standard features, an OCA alternative or a small custom module.

• Python models & business logic
• XML views & QWeb reports
• JavaScript & OWL components
• Migration scripts for custom data

Heavily customised databases several versions behind sometimes cost more to upgrade than to rebuild. If many customisations exist only because older versions lacked a feature, a fresh implementation on the latest version — moving master data, open transactions and balances, but not every customisation — can leave you with a cleaner system. The assessment compares both routes so you can decide on facts.

Switching edition on the same version is mainly a matter of adding the Enterprise code and subscription. The real work is everything around it: Community add-ons that replicated Enterprise features, such as accounting or barcode modules, must be mapped to standard apps, their data moved and the old modules removed.

Businesses often combine the switch with a version upgrade or a move to Odoo.sh or Odoo Online. Doing them together saves a round of testing, but it also makes the project larger, so we plan it carefully.

Moving from another ERP, an accounting package or spreadsheets is a data project as much as a software one. Each data set is mapped to Odoo's structures — chart of accounts, taxes, units of measure, product variants — cleaned, loaded in trial runs and signed off by its owner in the business.

Closed history usually stays in the old system or an archive, while open orders, stock and balances move at cut-over. This page covers the migration; the wider rollout follows our Odoo implementation approach.

• Customers & vendors
• Products, variants & BoMs
• Chart of accounts & taxes
• Open orders & invoices
• Stock on hand
• Opening balances

The main factors are the gap between source and target versions, the amount and quality of custom code, the number of third-party modules, data volume, integrations, any hosting or edition change, and how much time your team can give to testing.