Migrate Odoo Modules Across Versions

This skill guides migrating Odoo modules between major versions, handling API changes, deprecated methods, renamed fields, and new view syntax. Mention @odoo-migration-helper, specify your source and target versions, and paste your module code, and it returns a list of breaking changes with before/after code fixes plus a migration checklist specific to your module's features. It covers the most common breaking changes between versions 14 through 17, such as the v16-to-v17 attrs visibility syntax replacement and chatter block changes, and the v15-to-v16 website_published-to-is_published field rename, alias_domain moving off the company model onto a dedicated mail.alias.domain model, updated account.move.line grouping/aggregation rules, and mail_thread_id being deprecated in favor of message_ids.

Use it when upgrading a custom module from Odoo 14/15/16 to a newer version, getting a checklist of things to check before running odoo-upgrade, fixing deprecation warnings after a version upgrade, or understanding what changed between two specific Odoo versions.

It covers v14 through v17 only - it does not address v13 or older, since the pre-manifest-era module structure is fundamentally different. The Odoo.sh automated upgrade path has additional steps not covered here. Enterprise-specific modules (e.g. account_accountant, sign) may have undocumented breaking changes and should be tested on a staging environment with an Enterprise license. JavaScript OWL component migration (v15 Legacy to v16 OWL) is a complex topic not fully covered by this skill.

Input: source and target Odoo version, plus your module's code. Output: a breaking-changes list with before/after code diffs and a module-specific migration checklist.

Migrating attrs visibility syntax (domain-based, v16) to an inline Python expression (v17):

<field name="discount" attrs="{'invisible': [('product_type', '!=', 'service')]}"/>
<field name="discount" invisible="product_type != 'service'"/>

Best practices are framed as explicit do's and don'ts: do test with --update=your_module on each version before pushing to production, use the official Odoo Upgrade Guide for an automated pre-upgrade analysis report, check OCA migration notes and a community module's HISTORY.rst, and run npm run validate after migration to catch manifest or frontmatter issues early; don't skip intermediate versions (migrate v14 to v15 to v16 to v17 sequentially, never jump), don't forget to bump version in __manifest__.py, and don't assume an OCA module is migration-ready without checking its GitHub branch for the target version.

References Odoo's official Upgrade Guide (upgrade.odoo.com) for automated pre-upgrade analysis, OCA migration notes and module HISTORY.rst files for community modules, and the __manifest__.py version field convention.

Odoo developers upgrading custom or community modules across major version boundaries, who need concrete before/after code fixes rather than reading full changelogs for each version jump.