An Odoo upgrade can expose problems that have been hidden inside custom code for years. A module that works correctly in your current environment may rely on a field, method, view, dependency, or framework behavior that changes in the target version.
The risk is not limited to modules developed in-house. Third-party apps, Odoo Community Association (OCA) modules, and customizations built with Odoo Studio also need attention before an upgrade.
Before moving to a newer release, use this checklist to review your custom Odoo modules, identify compatibility risks, and prepare for a test environment. The goal is to establish what still works, what needs to change, and what should not be carried into the upgraded system. Reviewing custom Odoo modules before an upgrade helps identify compatibility issues before they affect production. Our Odoo upgrade services include custom-module assessments, dependency reviews, test upgrades, and workflow validation to prepare your system for the move.
1. Build an Inventory of Every Customization
Start by identifying everything in your database that extends or changes standard Odoo functionality. Do not rely on your original development list. Modules are often added over time by different developers, implementation partners, and internal teams.
Create an inventory that includes:
Custom Python modules developed specifically for your business.
Third-party and marketplace modules.
OCA modules installed from community repositories.
Odoo Studio fields, views, reports, and automations.
Custom website templates and frontend components.
Modified reports, email templates, and server actions.
External integrations that depend on custom models or fields.
Record the module name, current version, developer or vendor, source repository, dependencies, business owner, and current maintenance status.
Also document what each module does. A module name such as sale_extension does not explain whether it controls sales approvals, changes pricing calculations, or adds fields to customer orders. Record the business function so you can test the right behavior later.
Checklist
☐ Every installed non-standard module is listed.
☐ Each module has an identified owner or maintainer.
☐ Source code is available for modules that require code changes.
☐ Business-critical functionality is documented.
☐ Unused modules and obsolete customizations are flagged.
2. Compare the Module Code With the Target Odoo Version
Do not assume that code written for your current Odoo release will run unchanged in the next one. Odoo updates its ORM, framework APIs, security mechanisms, views, JavaScript components, and standard models over time.
Review each module against the target version's developer documentation and source code. Understanding how Odoo modules are structured also makes compatibility reviews easier. Our guide on how to build a custom module in Odoo explains the module structure, Python models, manifest files, access permissions, and views that developers need to understand when maintaining custom code.
Pay particular attention to:
Python methods and imports: Search for methods, classes, and imports that have been deprecated, renamed, or removed. A method that still works in your current release may no longer exist in the target version.
Models and fields: Check references to standard Odoo models and fields. A renamed or removed field can affect computed fields, related fields, domains, constraints, reports, and business logic.
XML views and inherited views: Review XPath expressions and inherited views. An extension that targets a view element that has moved or disappeared can fail during installation or module updates.
JavaScript and OWL components: Review frontend components, event handling, imports, and asset declarations. Changes to the web client can affect custom widgets and screens even when the Python code remains valid.
Security definitions: Review access-control files, record rules, groups, and permissions. Changes to the security framework can affect module installation and user access.
For every issue, record the affected file, the relevant target-version change, the required code adjustment, and the test that will confirm the fix.
Do not treat a successful code search as proof of compatibility. A module can install without errors and still fail when a user runs a particular workflow.
3. Check Whether Third-Party Modules Are Maintained
A third-party module is a dependency, not a guarantee of compatibility. Its availability in your current Odoo version does not mean the developer has released a version for your target release.
Check the vendor's official website, app listing, or source repository for:
A release that explicitly supports your target Odoo version.
Recent commits, release notes, and maintenance activity.
Open issues involving installation, security, or functionality.
Required dependencies and supported editions.
License terms and access to the source code.
A documented upgrade path for existing module data.
For OCA modules, check the relevant repository and branch for the target version. Do not assume that a module on an older branch has already been ported.
A module with no target-version release should be treated as an unresolved dependency. Contact its maintainer, check whether a supported alternative exists, or establish whether your team can maintain the code.
Avoid installing an unverified replacement simply because its description appears to match the old module. Compare the actual functionality, data model, permissions, and integration requirements first.
Checklist
☐ The vendor confirms support for the target Odoo version.
☐ The module's dependencies are also compatible.
☐The license permits the intended use and maintenance.
☐ Critical issues and unresolved bugs have been reviewed.
☐A replacement or maintenance owner is identified where support is unavailable.
4. Review Odoo Studio Customizations
Odoo Studio changes are part of your database's customization layer. They can affect how users enter information, view records, generate reports, and move through business processes.
Review the Studio changes that support important workflows, not just the visible fields on a form.
Check:
Custom fields: Identify fields used in domains, automated actions, computed fields, reports, imports, exports, and integrations. A field that appears unused on a form may still support another process.
Views: Review modified form, list, kanban, and search views. Check whether inherited elements still appear in the target version and whether users can access the information they need.
Automations: List automated actions and confirm their triggers, conditions, and actions. Pay attention to automations that create records, update statuses, send notifications, or initiate approvals.
Reports and document layouts: Review custom PDF reports, quotation layouts, invoice formats, and other documents. Check both the displayed information and the values used to generate it.
Access rights: Confirm that the correct user groups can view and edit custom fields and records. A customization that works for an administrator may fail for a regular employee.
Export your Studio customizations before testing so you have a reference copy. Odoo documents the Studio export process in its Models, Modules, and Apps documentation.
Checklist
☐ Critical custom fields are documented.
☐ Modified views display the expected fields and actions.
☐ Automated actions run under the correct conditions.
☐Reports and document layouts retain the required information.
☐ User permissions are tested with the relevant roles.
☐ Studio customizations have been exported for reference.
When Studio changes no longer meet your business requirements, Odoo customization services can help assess existing functionality and extend workflows, fields, reports, and business logic where standard configuration is not enough.
5. Map Module Dependencies and External Connections
Custom Odoo modules rarely work in isolation. One module may extend a standard model, another may add fields to that extension, and a third may use those fields in a report or integration.
Review the dependency declarations in each module's __manifest__.py file. Confirm that every dependency exists in the target version and that the installation order remains valid.
Then inspect connections outside Odoo.
Examples include:
Payment gateways that read invoice or transaction data.
E-commerce platforms that exchange products, prices, and orders.
Shipping services that use delivery records and tracking references.
External reporting tools that query custom fields.
Middleware that calls custom API endpoints.
Scripts that read or update Odoo database records directly.
For each connection, document the data exchanged, authentication method, endpoint, responsible vendor, and the Odoo models or fields involved.
An integration can continue authenticating successfully while transferring incomplete or incorrect data. Test the full transaction, not just the connection status. When an upgrade affects data exchange between Odoo and external applications, Odoo integration services can help review API connections, synchronization rules, data mapping, and error handling across connected systems.
6. Test the Modules on a Copy of the Database
Never use your live production database as the first environment for compatibility testing.
Create a separate test environment using a recent backup of your production database. Include the relevant filestore and attachments when preparing the test environment, and make sure the database and filestore correspond to the same backup.
Odoo recommends requesting an upgraded test database and thoroughly testing it before upgrading production. Its documentation also explains that custom module source code must be ready for the target version before the database upgrade can proceed.
Use the test environment to check two separate things:
Installation: Can each custom module install or update successfully in the target version? Check module dependencies, data files, security definitions, XML views, and asset declarations.
Runtime behavior: Does the module perform its intended function after installation? Test the actual screens, calculations, automated actions, reports, and transactions that depend on it.
A module passing installation checks is not proof that its business logic works. Test with representative records and realistic user permissions.
For technical guidance, see Odoo's official documentation on upgrading a customized database.
7. Run Workflow Tests, Not Just Module Tests
A module can pass its individual tests and still disrupt a process that crosses several Odoo applications.
For example, a custom sales module may work correctly on its own, but the complete order-to-cash process can fail when the sales order creates a delivery, triggers an invoice, and updates a custom reporting field.
Build test scenarios around the way employees use the system.
Area | What to test |
Sales | Create quotations, confirm orders, apply discounts, and review custom approval rules. |
Inventory | Receive products, reserve stock, process deliveries, and validate custom tracking fields. |
Accounting | Create invoices, register payments, issue credit notes, and check custom financial reports. |
Purchasing | Create purchase orders, receive goods, and verify custom approval workflows. |
CRM | Convert leads, assign activities, and confirm custom fields remain available. |
Reporting | Generate reports, export records, and compare calculated values. |
Automation | Trigger scheduled actions, server actions, and automated record updates. |
Integrations | Send and receive data through connected applications and API endpoints. |
Include positive and negative tests. Confirm that valid actions work and that invalid actions are rejected correctly. For example, test whether a user without approval rights is prevented from confirming a restricted order.
Odoo's upgrade testing guidance specifically calls out external integrations, cross-application workflows, data exports, automated actions, and server actions as areas to test.
8. Record the Results and Decide Whether Each Module Is Ready
Do not rely on informal notes or a developer's confirmation that everything looks fine. Record the result of each check so the team can see what has passed, failed, or remains unresolved.
Use a simple tracking sheet:
Module | Compatibility result | Required action | Owner | Status |
Sales approval extension | Passed | None | Sales systems owner | Ready |
Custom invoice report | Failed | Update report fields | Developer | In progress |
Third-party shipping app | No target release | Confirm vendor support | Logistics owner | Blocked |
Studio sales fields | Passed | Retest with sales users | Odoo administrator | Ready |
Set clear acceptance criteria before approving the upgrade. At a minimum:
All business-critical modules install and update successfully.
Critical workflows pass their test scenarios.
User permissions behave as expected.
Reports and calculations produce the expected results.
External connections exchange the correct data.
No unresolved critical defects remain.
Module compatibility should remain part of your ongoing maintenance routine, not just a one-time upgrade task. Our Odoo maintenance checklist covers regular reviews of custom modules, third-party apps, integrations, and technical dependencies. Keep failed tests visible. Do not mark a module as ready simply because the developer has completed the code changes.
Final Checklist: Are Your Custom Odoo Modules Ready?
Before approving the upgrade, confirm that you can answer yes to these questions:
☐Have you identified every custom, third-party, OCA, and Studio customization?
☐ Have you checked the source code against the target Odoo version?
☐Have you confirmed that third-party dependencies are maintained?
☐ Have you reviewed custom fields, views, reports, and automations?
☐ Have you checked module dependencies and external integrations?
☐ Have you tested on a copy of the production database?
☐ Have you tested complete business workflows with actual user roles?
☐ Have you documented test results and resolved critical failures?
If any critical item remains unchecked, the module is not ready for production.
Need Help Preparing Your Custom Odoo Modules for an Upgrade?
Custom Odoo modules, third-party applications, Studio changes, and external integrations all need to be reviewed before moving to a newer release. A module that installs successfully is not necessarily compatible with the business workflows that depend on it.
A structured review helps your team identify outdated code, unsupported dependencies, security issues, and broken integrations before they affect production. Testing a copy of your database also gives developers and process owners the opportunity to resolve issues and confirm that critical operations still work as expected.
Versich helps businesses assess custom modules, review third-party dependencies, adapt existing functionality, and validate upgraded environments before production cutover. contact us to discuss your custom modules and upgrade requirements.
