Planning an Odoo upgrade with custom modules

Custom Odoo modules should be reviewed by business value, framework impact, data dependencies, and upgrade cost before any code is carried forward.

An upgrade is a good moment to reduce unnecessary customisation. Copying every old module into the new version preserves technical debt and can hide the fact that standard Odoo now covers part of the requirement differently. Start from business behaviour For each module, describe the user decision or control it supports. Screenshots and module names are not enough. A requirement such as preventing shipment without credit approval can be tested even if the target implementation uses a different view, rule, or approval flow. Classify the change Separate fields and views from business logic, reports, integrations, security rules, and accounting behaviour. A small-looking override in stock or accounting can carry more risk than a large independent reporting module. Check target-version alternatives Review standard configuration and supported applications before porting code. The correct outcome may be retire, replace with standard, redesign, or upgrade. Document why the chosen approach wins on usability, maintenance, and control. Test data and workflows together A module can install successfully and still behave incorrectly with migrated records. Test permissions, automated jobs, reports, edge cases, and upgrade scripts using representative data. Include negative tests for rules that must block an action. Practical checklist Give every custom module a current business owner. Record the behaviour that must survive, not only the old interface. Review standard Odoo before approving a port. Identify risky overrides in accounting, stock, and security. Test upgraded code with migrated data and real user roles. Final decision Carry forward the requirement only when it still matters. Carry forward the old code only when it remains the cleanest way to meet that requirement.