Connected business operations. Flexible deployment.
A practical guide for CIOs and ERP consultants on assessing, refactoring, and testing custom code during an Odoo 17 to 18 upgrade to minimize risk and ensure operational continuity.
Upgrading from Odoo 17 to 18 requires a rigorous assessment of custom code because core framework changes, API deprecations, and database schema updates can break existing modules. The recommended approach is to perform a static code analysis, identify dependencies on deprecated APIs, and refactor custom modules in a staging environment before attempting the database upgrade. This process is critical because custom code represents the highest risk factor in ERP upgrades; unaddressed incompatibilities can lead to data corruption, application crashes, or silent logic errors that affect financial reporting and operational workflows. Key risks to control include broken integrations, security rule misconfigurations, and performance regressions caused by inefficient ORM queries in the new version. By treating custom code refactoring as a distinct workstream with dedicated testing and validation, organizations can protect business continuity and ensure a stable transition to Odoo 18.
The first step in navigating custom code refactoring is a detailed compatibility assessment between Odoo 17 and Odoo 18. While Odoo maintains backward compatibility for standard modules, custom code is not automatically supported. You must review the official release notes for Odoo 18 to identify specific API changes, removed methods, and altered model behaviors. It is essential to verify whether your custom modules rely on internal APIs that may have changed or been deprecated. Additionally, check the Python version requirements for Odoo 18, as changes in the underlying Python runtime can affect how custom code executes. This assessment should be documented in a compatibility matrix that lists each custom module, its dependencies, and the specific areas of code that require review. Engaging with the Odoo community forums or official documentation is crucial for understanding version-specific nuances that may not be immediately apparent in the codebase.
Custom code often interacts with the Odoo ORM (Object-Relational Mapping) and model fields directly. In an upgrade from 17 to 18, certain ORM methods may be deprecated, and field types or behaviors might change. For example, changes in how computed fields are evaluated or how related fields are stored can impact custom logic. You should use static analysis tools to scan your custom codebase for calls to deprecated methods. Look for patterns such as direct database access via SQL queries, which can become incompatible if the underlying PostgreSQL schema changes. Additionally, review any custom models that inherit from standard Odoo models. If the parent model has changed its structure or added new required fields, your custom inheritance code may fail. This phase requires a deep understanding of the Odoo architecture and the specific changes introduced in version 18. It is recommended to create a list of high-risk code segments that need manual review and refactoring.
Beyond Python code, custom modules often include XML views and security rules. Odoo 18 may introduce changes to the UI framework or view rendering engine, which can affect how custom forms, lists, and kanban views are displayed. You must test these views in a staging environment to ensure they render correctly and that user interactions work as expected. Security rules, defined in XML, must also be validated to ensure that access rights are maintained. Changes in the security model can lead to unauthorized access or, conversely, lock out legitimate users. Reviewing these non-Python components is just as important as refactoring the Python code, as they directly impact user experience and data security.
Once incompatible code is identified, the refactoring strategy should focus on aligning custom code with Odoo 18 best practices. This involves replacing deprecated API calls with their modern equivalents, optimizing ORM queries for better performance, and ensuring that custom logic adheres to the new framework standards. Refactoring is not just about fixing errors; it is an opportunity to improve code quality and maintainability. Consider modularizing large custom modules to make them easier to test and maintain. Use automated testing frameworks to validate that refactored code behaves identically to the original version. This step requires skilled Odoo developers who understand both the legacy code and the new version's capabilities. It is important to document all changes made during refactoring to facilitate future upgrades and troubleshooting.
Many Odoo installations rely on third-party add-ons from the Odoo Apps Store or other providers. These add-ons may not be immediately compatible with Odoo 18. You must contact the vendors of these add-ons to confirm their support status for the new version. If a vendor has not released an Odoo 18-compatible version, you may need to fork the add-on and refactor it yourself, or seek an alternative solution. This can be a significant bottleneck in the upgrade process. Plan for this by identifying all third-party dependencies early and communicating with vendors well in advance of the upgrade date. If you must fork an add-on, ensure that you have the necessary skills and resources to maintain it in the long term.
The database migration is a critical component of the Odoo upgrade. Odoo uses PostgreSQL, and the upgrade process involves applying schema changes to the database. Custom modules may have added custom tables or fields that need to be preserved during the migration. You must ensure that the database backup is complete and that you have a tested restore procedure. The upgrade script will attempt to apply the new schema, but if there are conflicts with custom database objects, the upgrade may fail. It is recommended to perform a trial upgrade in a staging environment with a copy of the production database. This allows you to identify any database-level issues before attempting the production upgrade. Monitor the upgrade logs carefully for any errors or warnings related to custom tables or fields.
After refactoring and database migration in the staging environment, comprehensive testing is required. This includes unit tests for custom code, integration tests for external systems, and end-to-end business process tests. You must verify that all custom features work as expected and that data integrity is maintained. Pay special attention to financial reports, inventory calculations, and other critical business processes. User acceptance testing (UAT) should be conducted with key users to ensure that the new version meets their needs and that any UI changes are acceptable. Document any defects found during testing and prioritize them for resolution. The goal is to achieve a stable and reliable system before proceeding to the production upgrade. This phase is crucial for building confidence in the upgrade process and identifying any remaining risks.
The deployment phase involves migrating the upgraded system to the production environment. This should be done during a planned maintenance window to minimize downtime. Before the cutover, ensure that all backups are verified and that the rollback plan is documented and tested. The cutover runbook should include step-by-step instructions for stopping services, applying the database upgrade, starting services, and performing initial validation checks. Communicate the upgrade schedule to all stakeholders and users. During the cutover, monitor the system closely for any errors or performance issues. If any critical issues arise, execute the rollback plan to restore the previous version. The goal is to complete the upgrade with minimal disruption to business operations.
After the upgrade is complete, the system enters a stabilization phase. During this period, monitor the system for any unexpected behavior, performance issues, or user complaints. Keep the support team on standby to address any issues that arise. Review the logs regularly to identify any hidden errors or warnings. It is also important to gather feedback from users and make any necessary adjustments. This phase is critical for ensuring that the upgrade is successful and that the system is stable in the long term. Document any lessons learned during the upgrade process to improve future migrations. By following a structured approach to custom code refactoring and upgrade planning, organizations can successfully navigate the transition from Odoo 17 to 18 while protecting their business data and operational continuity.
Common questions on this topic. Talk to our team for anything specific to your business.
No, custom modules often require refactoring due to API changes, deprecated methods, and schema updates. Always test in a staging environment.
Common changes include deprecated ORM methods, altered model field behaviors, and changes in the UI framework. Review official release notes for specifics.
Use a staging environment with a copy of the production database. Perform unit, integration, and end-to-end tests to validate functionality.
No, third-party add-ons must be explicitly updated by their vendors. Verify compatibility and support status before upgrading.
Maintain a verified backup of the pre-upgrade database and system configuration. Test the restore procedure in a staging environment before the production upgrade.
The time required depends on the complexity and size of the custom codebase. Simple modules may take days, while complex systems can take weeks or months.
Learn how to standardize retail operations across franchises and channels using a unified ERP architecture. Discover strategies for master data governance, integration, and scalable growth.
A practical guide for CIOs and ERP consultants on migrating Odoo third-party add-ons. Covers dependency analysis, code refactoring, testing strategies, and risk mitigation for version upgrades.
Learn how to build a distribution ERP intelligence framework that unifies multi-location inventory, standardizes replenishment, and provides precise operational visibility for scalable growth.
Discuss your workflows, modules and deployment options with our team.
Back to resources