Quick Answer
An odoo 17 to 18 migration carries real new features worth the move, including passkey authentication, which uses the webauthn protocol as a phishing-resistant login method, and readable URLs that show where a link leads and can be edited manually.
Odoo 18 also simplified product types down to a single “Goods” type and introduced a new Track Inventory field, which directly affects how existing product data maps during migration.
Most 17 to 18 migrations take 3 to 6 weeks depending on customization depth, with the biggest technical risk centered on the product type change and any custom code that touches the old tracking fields. Odoo 18 Release Notes +2
Introduction
Every version jump changes something a business assumes will just carry forward. Odoo 18’s product type simplification is exactly that kind of change for this specific migration.
This guide covers what genuinely changed between Odoo 17 and 18, what that means for existing data and custom code, and how to test the migration properly before cutover.
It complements the general framework in Odoo migration process and the broader service picture in Odoo migration services.
Data-specific migration discipline, including validation and reconciliation, is covered in more depth in Odoo data migration services, which applies fully to this version pair alongside the version-specific notes below.
What’s New in Odoo 18
Several Odoo 18 changes directly affect how a business experiences the system after migration, beyond pure feature additions. Understanding these upfront helps frame what testing should focus on.
Authentication and Navigation
Odoo 18 introduced passkeys as a new login method, described as a phishing-resistant, more secure authentication approach using the webauthn protocol instead of traditional usernames and passwords. Businesses with security-conscious login policies should evaluate rolling this out post-migration. odoo
Odoo also switched to more readable URLs, such as one that shows the model and record path directly, which can be edited manually more easily than before. This is a cosmetic but genuinely useful change for anyone navigating or sharing links to specific records. odoo
Product Types and Inventory Tracking
The most migration-relevant change in this version pair is that Odoo 18 simplified product types down to a single type called Goods, changing the widget to a radio button, and introduced a new Track Inventory field to replace the previous Tracking field in inventory settings.
Any business with products categorized under the old multi-type system needs this mapped correctly during migration, since it changes how existing product records need to be reinterpreted. cybrosys
This change also affects any custom code or reports that referenced the old product type field directly. A compatibility check against this specific field is one of the first things to verify in an assessment for this version pair.
Purchase and Inventory Improvements
A new “Generate” option was added alongside the existing import option for lot numbers, letting users automatically generate lot numbers for tracked products during receipt.
Businesses using lot tracking for purchasing should account for this workflow change during testing. cybrosys
Gantt view usability was revamped across modules, including enhancements relevant to manufacturing planning, and records can now be sorted by occurrences when grouped in list views.
These are generally additive improvements with low migration risk. biztechcsbiztechcs
Website, eCommerce, and CRM
Website “Click and Collect” flow was improved, a new order confirmation step was added to checkout before payment, and multiple warehouses can now be shown on a single website with visible stock quantity per product.
Over 60 new snippets were added to the website builder’s snippet library, along with a discovery system for finding snippets by keyword and the ability to preview a snippet before adding it. biztechcscybrosys
CRM gained a Social Share app for promoting content through communities, a net-new feature rather than a migration concern. eCommerce businesses should specifically test the checkout confirmation step change, since it alters a customer-facing flow. biztechcs
Onboarding and Interface
A tour revamp lets users record, manage, and customize onboarding and testing tours through a new interface, with the ability to enable or disable these tours from the user menu.
This mainly affects how new staff get trained inside the system post-migration rather than existing data or workflows. cybrosys
What This Means for Your Migration
The upgrade from 17 to 18 is generally considered a moderate migration in terms of breaking changes, with the product type simplification standing out as the item most likely to require deliberate data mapping attention.
Businesses with straightforward product catalogs, using the previous default type consistently, typically see a smoother transition than those with heavily customized product type logic.
Custom modules or reports referencing the old Tracking field by its previous name or structure need updating to reference the new Track Inventory field instead. This is a concrete, checkable item during the assessment phase covered generally in Odoo migration process.
Businesses using Odoo’s Point of Sale, eCommerce checkout flows, or lot-based purchasing should prioritize testing those specific areas, since this version pair touched each of them directly.
Areas untouched by version-specific changes generally carry the standard migration risk profile covered in the general process guide, not elevated risk from this specific jump.
Testing Priorities for This Migration
Testing for a 17 to 18 migration should specifically validate product records against the new Goods type and Track Inventory field, confirming existing inventory tracking behavior carried forward correctly. This is the single highest-priority validation item for this version pair specifically.
eCommerce and Point of Sale workflows should be tested end to end, given the checkout confirmation and warehouse display changes.
Any custom code referencing product type fields directly, rather than through Odoo’s standard API abstractions, needs specific review and likely rework.
Standard testing practices from the general migration process, including staging environment validation and user acceptance testing with real staff, apply fully alongside these version-specific checks.
Common Mistakes in a 17 to 18 Migration
Assuming product data carries forward without reviewing the type change. The shift to a single Goods type with a new Track Inventory field changes how existing records need interpretation. Map this specifically during the data mapping phase rather than assuming a direct one-to-one carry-forward.
Skipping a review of custom code referencing old product type fields. Custom reports or modules built against the previous multi-type structure can break silently if not updated to reference the new field. Audit every custom reference to product type and tracking fields before migration.
Not testing eCommerce checkout flow changes before going live. The new order confirmation step changes the customer journey, and skipping this test risks a broken or confusing checkout experience post-migration. Walk through the full customer checkout flow in staging before cutover.
Treating this as a purely technical upgrade with no staff communication. Interface changes like the tour revamp and navigation updates benefit from brief staff notice before go live, even though they require no technical rework. A short heads-up reduces confusion in the first days after migration.
Who Should Prioritize This Migration
Businesses currently on Odoo 17 with straightforward product catalogs and minimal custom code touching product type or tracking fields are well positioned for a relatively smooth migration to 18.
This group can generally follow the standard migration process with focused testing on the areas outlined above.
Businesses with significant custom development built around the previous product type structure, or heavy eCommerce and Point of Sale customization, should budget additional assessment and testing time given this version pair’s specific changes.
eNeedly’s broader Odoo migration services guide covers how customization depth generally affects migration cost and timeline.
This guidance matters less for businesses already on Odoo 18 or planning a jump from a much older version, where the broader multi-version considerations covered in a general version migration guide apply instead of this specific pair’s changes.
Frequently Asked Questions
What is the biggest change to watch for in a 17 to 18 migration?
The simplification of product types down to a single Goods type, paired with the new Track Inventory field, is the change most likely to require deliberate data mapping attention. Custom code referencing the old fields needs review before migration.
Does Odoo 18 change how eCommerce checkout works?
Yes, a new order confirmation step was added before payment, and multiple warehouses can now display on one website with visible stock quantities. Test this flow end to end before going live if you run an eCommerce store.
Are passkeys required after migrating to Odoo 18?
No, passkeys are an available authentication option using the webauthn protocol, not a requirement. Businesses can adopt them as an additional security layer post-migration at their own pace.
Will my custom reports need updating after this migration?
Any custom report or module referencing the previous product type or Tracking field directly likely needs updating to reference the new structure. Reports using Odoo’s standard abstractions rather than direct field references generally need less rework.
How long does a 17 to 18 migration typically take?
Most migrations in this version take 3 to 6 weeks depending on customization depth, with businesses having significant product-type-related custom code needing more time for review and testing.
Is the tour revamp something I need to configure before going live?
No, it is a net-new onboarding feature that can be configured or ignored based on training needs, and it doesn’t affect data or existing workflows. It’s worth a brief mention to staff so they know the option exists.
Key Takeaways
The 17 to 18 migration centers on one specific technical change worth real attention: the product type simplification to a single Goods type alongside the new Track Inventory field.
Every other change in this version pair, from passkeys to eCommerce checkout improvements, carries lower migration risk and mostly adds capability rather than requiring rework.
Testing should prioritize product data mapping, any custom code touching product type fields, and eCommerce or Point of Sale workflows specifically affected by this release.