Migrating from Odoo 17 to Odoo 18: What Changes, What Breaks, and How to Prepare

Odoo releases a major version every year, and each upgrade brings new features, performance improvements, and inevitably, breaking changes. Migrating from Odoo 17 to Odoo 18 requires careful planning, especially if you run custom modules or rely on community add-ons. This guide covers everything you need to know about the Odoo 17 to 18 migration: key changes, potential breakage, preparation steps, and testing strategies.

Why Upgrade to Odoo 18?

Odoo 18 introduces significant improvements across the platform:

• New OWL 3 components: Rewritten frontend components with improved performance and developer experience
• AI-powered features: Predictive lead scoring, smart bank reconciliation suggestions, and AI-assisted content creation
• Spreadsheet improvements: Native spreadsheet integration with real-time Odoo data, pivot tables, and collaborative editing
• Manufacturing upgrades: Improved production scheduling, subcontracting portal, and shop floor tablet interface
• Performance: 15-25% faster page loads through optimized asset bundling and lazy loading
• Website builder: New drag-and-drop blocks, theme customization options, and improved mobile editing

Staying on outdated versions means missing security patches, losing access to community module updates, and accumulating technical debt that makes future migrations harder.

Timeline: How Long Does an Odoo Migration Take?

| Complexity | Custom Modules | Estimated Timeline | |---|---|---| | Standard (no custom code) | 0 | 1-2 weeks | | Low (few custom fields/views) | 1-5 | 2-4 weeks | | Medium (custom workflows) | 5-15 | 4-8 weeks | | High (deep customizations) | 15+ | 8-16 weeks |

These timelines include analysis, migration, testing, and go-live. The biggest variable is custom module complexity.

Breaking Changes in Odoo 18

OWL Framework Changes

Odoo 18 continues the migration to OWL 3. If your custom modules include frontend JavaScript components, expect these changes:

Key OWL changes:

• Component lifecycle: willStart and willUpdateProps are replaced with setup() and onWillStart hooks
• Template compilation: QWeb templates now compile to optimized JavaScript at build time instead of runtime
• Service injection: Access services through this.env.services pattern exclusively; direct imports are deprecated
• Asset bundling: The web.assets_backend bundle structure has changed; update your __manifest__.py asset declarations

Example migration:

// Odoo 17
class MyComponent extends Component {
    async willStart() {
        this.data = await this.rpc('/my/endpoint');
    }
}

// Odoo 18
class MyComponent extends Component {
    setup() {
        onWillStart(async () => {
            this.data = await this.env.services.rpc('/my/endpoint');
        });
    }
}

Python Backend Changes

Model and field changes:

• fields.Monetary now requires currency_field to be explicitly declared (no longer defaults to currency_id)
• The @api.multi decorator was fully removed (deprecated since v13, but some community modules still used it)
• sudo() behavior change: sudo() without arguments now explicitly uses the SUPERUSER rather than the OdooBOT user
• search_count() now accepts an optional limit parameter for performance optimization

Deprecated methods to update:

| Deprecated (v17) | Replacement (v18) | |---|---| | fields.Many2one.search() | fields.Many2one with domain attribute | | _register_hook() | _post_init_hook in manifest | | Direct SQL in models | self.env.cr.execute() with proper parameterization | | website.published field | website.is_published (renamed) |

View and Template Changes

• Form view: sheet wrapper is now mandatory for all form views (previously optional)
• List view: tree tag is officially renamed to list (backwards-compatible alias still works but triggers deprecation warnings)
• Kanban view: QWeb t-esc is now the default; t-raw requires explicit opt-in for security
• Report QWeb: PDF rendering engine updated; test all printed reports for layout changes

Database Schema Changes

Odoo 18 includes structural changes to core tables:

• sale.order.line gains new fields for subscription management
• account.move.line includes new reconciliation-related columns
• stock.quant table restructured for improved performance with large inventories
• mail.message and mail.activity tables optimized with new indexes

These schema changes are handled by Odoo's built-in migration scripts for standard modules, but custom modules referencing these tables need manual updates.

Pre-Migration Preparation Checklist

1. Audit Your Current Installation

Document everything before starting:

• [ ] List all installed modules (official, community, and custom)
• [ ] Record current Odoo version and patch level
• [ ] Document all custom developments (fields, models, views, reports, scheduled actions)
• [ ] List all external integrations (payment gateways, shipping carriers, third-party APIs)
• [ ] Export current access rights and record rules configuration
• [ ] Back up the production database and filestore completely

2. Check Community Module Compatibility

For each community (OCA or third-party) module:

• Check if an Odoo 18-compatible version exists on GitHub or the Odoo Apps store
• If no compatible version exists, decide whether to port the module yourself, find an alternative, or remove the functionality
• Contact module maintainers for ETA on v18 ports

3. Prepare Custom Module Ports

For each custom module, assess the migration effort:

Low effort (1-3 days per module):

• Modules with only new fields and simple views
• No JavaScript/OWL components
• No overrides of changed core methods

Medium effort (3-10 days per module):

• Modules with OWL components requiring updates
• Overrides of deprecated or changed core methods
• Custom reports needing QWeb updates

High effort (10+ days per module):

• Deep integration with changed core modules (accounting, inventory, website)
• Complex OWL frontend applications
• Modules using deprecated or removed APIs extensively

Working with experienced Odoo migration specialists significantly reduces the time and risk of porting custom modules.

Migration Execution Steps

Step 1: Set Up the Migration Environment

Production (v17) ──backup──> Test Database (v17)
                                    │
                              Upgrade to v18
                                    │
                              Test Database (v18)
                                    │
                              Validation & UAT
                                    │
                              Production (v18)

Create an isolated environment with:

• A fresh Odoo 18 server installation
• A copy of your production database
• All custom modules ported to v18

Step 2: Run the Database Upgrade

For Odoo Enterprise: Use Odoo's official upgrade service at upgrade.odoo.com. Upload your database, and Odoo SA runs the migration scripts for all standard modules.

For Odoo Community: Use the openupgrade project by OCA. OpenUpgrade provides community-maintained migration scripts for standard modules:

1. Install OpenUpgrade for the target version
2. Run the migration against your test database
3. Review the migration log for errors and warnings
4. Fix any issues and re-run until clean

Step 3: Port Custom Modules

For each custom module:

1. Update __manifest__.py version to 18.0.x.x.x
2. Fix Python code (deprecated APIs, changed method signatures)
3. Update JavaScript/OWL components to v3 patterns
4. Fix XML views (tree to list, sheet wrapper, template changes)
5. Run the module's test suite and fix failures
6. Test manually in the staging environment

Step 4: Data Verification

After migration, verify data integrity:

• Accounting: Compare trial balance totals between v17 and v18. They must match exactly.
• Inventory: Verify stock quantities for a sample of high-value products.
• Sales/Purchase: Confirm open orders and their statuses carried over correctly.
• Contacts: Check that customer and vendor records are intact, including addresses and bank details.
• Attachments: Verify that documents, images, and file attachments are accessible.

Testing Strategy

Level 1: Automated Tests

Run the full test suite for every installed module. Fix all failures before proceeding.

Level 2: Functional Testing

Test core business workflows end-to-end:

• Create a quotation, confirm it, deliver goods, create an invoice, register payment
• Process a purchase order through receipt and vendor bill
• Run a manufacturing order from BOM to finished product
• Complete a full bank reconciliation cycle
• Generate and verify key financial reports

Level 3: User Acceptance Testing (UAT)

Have actual users from each department perform their daily tasks in the staging environment for 5-10 business days. Track issues in a shared spreadsheet or project management tool.

Level 4: Performance Testing

Compare page load times, report generation speed, and search performance between v17 and v18 with production-level data volumes.

Go-Live Strategy

Recommended approach: Weekend migration

1. Friday evening: Take a final production backup. Freeze all transactions.
2. Saturday: Run the upgrade on the production database. Port any last-minute data.
3. Sunday: Complete data verification and smoke testing. Deploy to production servers.
4. Monday morning: Go live. Monitor closely for the first 48 hours.

Have a rollback plan ready: keep the v17 database backup and server configuration available so you can revert within hours if critical issues emerge.

Frequently Asked Questions

Q: Can I skip versions and migrate from Odoo 16 to Odoo 18 directly? Yes, but it is more complex. Each version has its own migration scripts, and skipping versions compounds the changes. Odoo's upgrade service handles multi-version jumps, but custom module porting requires addressing breaking changes from every skipped version. Budget 50-100% more time for multi-version migrations.

Q: Will my custom reports break during migration? Potentially. QWeb report templates frequently change between versions due to updated data structures and rendering engine improvements. Test every printed report (invoices, delivery slips, purchase orders) after migration and adjust templates as needed.

Q: Should I migrate or start fresh? Migrate if you have years of historical data, complex configurations, and trained users. Start fresh if your current installation is heavily customized beyond repair, has significant data quality issues, or if your business processes have changed so much that a reconfiguration would be faster. Most businesses choose migration to preserve their operational history. Consult an Odoo consultancy partner to evaluate which approach fits your situation.

Professional Migration Support

Migrating between Odoo versions is a technical project that benefits from experienced hands. ECOSIRE's Odoo migration services cover the complete process: pre-migration audit, custom module porting, data migration, testing, and go-live support.

Contact our team for a migration assessment and timeline estimate based on your specific Odoo installation. We will analyze your modules, customizations, and data complexity to provide an accurate scope and budget.