Project Name
Odoo 16 to Odoo 19 Migration for an Industrial Equipment and Valve Manufacturer
Our client is a mid-market industrial equipment and valve manufacturer operating its full business, including sales, procurement, inventory, repair operations, and financial reporting, on Odoo as its core ERP platform. Over several years of operation on Odoo 16, the organisation had built a significant layer of custom module logic covering repair order workflows, purchase Incoterm handling, product family management, and a suite of custom PDF reports tailored to their specific operational and financial reporting requirements.
With Odoo 16 approaching end of life, the client engaged Ksolves to migrate to Odoo 19 in a structured, risk-managed engagement, with a firm go-live target of July 24–26, 2026 and a hard requirement that all existing workflows and custom logic carry forward without regression.
Moving from Odoo 16 to 19 revealed several core changes that disrupted established custom workflows and reporting.
- Repair Order Model Completely Rewritten in Odoo 19: Odoo 19 removed the dedicated repair line and fee models, moving parts to stock.move. This required compatibility work across 11 removed v16 fields without modifying the core Odoo 19 model.
- Multiple Custom PDF Reports Crashing on Removed v16 Fields: Years of custom reports built for Odoo 16 were failing in Odoo 19 due to removed fields, requiring systematic identification and remediation before UAT.
- Draft Invoice PDF Crash From False Name Return: The invoice PDF print_report_name returned False for draft invoices in Odoo 19, causing report crashes and requiring a targeted fix without changing the established layout or output.
- Cost Analysis Report Removed Entirely From Odoo 19: A financial report used by the client was removed with no native replacement, requiring a custom rebuild that matched the v16 layout and field structure to maintain reporting continuity.
- Studio-Copied Report Templates With No External ID: Studio-copied report templates lacked external IDs, preventing standard XML overrides and requiring an alternative remediation approach for each affected template.
- Purchase Order Incoterm Not Carrying Forward on Copy: The Incoterm field was not being duplicated correctly when POs were copied in Odoo 19, requiring a targeted copy() method fix to restore the procurement workflow.
Ksolves, an AI-first Odoo development company, followed a structured migration approach using a dedicated Odoo.sh staging_dev branch for development and testing before production deployment. Odoo 16 remained live throughout the engagement, with its staging environment maintained in parallel for data reference and a zero-downtime cutover planned for go-live.
- Computed Stub Fields for All 11 Removed v16 Fields: Computed stub fields were added to repair.order for all 11 fields removed in Odoo 19, preserving compatibility with existing custom logic and report templates without rewriting every dependency.
- stock.move Extension With Repair Line Type: The stock.move model was extended with a type field related to repair_line_type, bridging the gap between the v16 repair line model and Odoo 19's new stock.move-based structure.
- Repair Order PDF Updated for v19 move_ids Structure: The repair order PDF was updated to use the v19 move_ids structure, aligning it with the new data model while preserving the established report layout.
- Invoice PDF Draft Crash Fixed: The invoice PDF print_report_name method was updated to handle False returns on draft invoices, resolving the crash without changing the report layout or output.
- Purchase Order Incoterm Copy Method Fixed: The PO copy() method was updated to correctly duplicate the Incoterm field, restoring the expected procurement workflow when creating POs from existing records.
- Custom Cost Analysis Report Rebuilt for Odoo 19: A custom Cost Analysis report was rebuilt in Odoo 19 to match the v16 layout and field structure, replacing the removed native report without changing the finance team's workflow.
- Server-Side Product Family Constraint: A server-side constraint was implemented to require family selection for storable products, with validation working consistently across Inventory and Sales.
- QA and UAT Approach: Five pre-UAT bugs were identified, fixed, and verified before handover. A comprehensive test case sheet covered key business workflows, while the UAT build included the v19 staging server, release notes, and delivery timeline. The v16 staging environment remained available throughout UAT for data cross-reference without impacting the live system.
Technology Stack
| Category | Technology |
|---|---|
| Platform | Odoo 19 (migrated from Odoo 16) |
| Custom Modules | repair_customization · purchase_customization · product_customization · pri_reports · account_customization · sale_customization |
| Deployment | Odoo.sh – staging_dev branch |
| Version Control | GitHub – processresourcesinc repository |
| Infrastructure | Parallel v16 Staging Server – ks_june18 |
The migration delivered a stable Odoo 19 environment with validated workflows, functional reports, and improved data integrity.
- All Custom PDF Reports Functional in Odoo 19: Every custom PDF report, including the repair order, invoice, and rebuilt Cost Analysis report, now functions in Odoo 19 without visible changes to established layouts or outputs.
- Repair Order Compatibility Preserved Across a Complete Model Rewrite: Stub fields for all 11 removed v16 fields and the stock.move extension bridge the v16-to-v19 model changes, preserving existing repair workflows and report templates.
- All Five Pre-UAT QA Bugs Resolved Before Handover: Every identified regression was fixed and verified before UAT, allowing the team to focus on business validation rather than defect discovery and protecting the go-live timeline.
- Zero Production Downtime Planned Across the Migration: Odoo 16 remained live until cutover, with its staging environment maintained for data reference throughout UAT, reducing operational risk during the transition.
- Product Family Validation Enforced Across Inventory and Sales: A new server-side constraint now ensures storable products have a family selected across both Inventory and Sales, improving data integrity in Odoo 19.
This migration required more than a version upgrade. It required adapting years of custom business logic to Odoo 19’s changed architecture. Ksolves addressed the model rewrite, rebuilt the removed Cost Analysis report, fixed critical report and workflow issues, and strengthened product data validation. With all five QA issues resolved before UAT and custom reports fully functional, the migration was structured to preserve business continuity while preparing the environment for a controlled Odoo 19 go-live.
Are Custom Modules and PDF Reports Making Your Odoo Migration Feel Too Complex to Start?
