Overview
An enterprise ERP upgrade should not begin when an old system finally becomes impossible to maintain. By that point, custom modules may depend on outdated framework behavior, integrations may use retired APIs and users may rely on undocumented processes that nobody wants to change. What should have been a planned modernization becomes an urgent recovery project.
Sasmar Pharmaceuticals provides a different perspective. According to the official Odoo Experience session, Choosing Odoo Over SAP: The 10-Year Transformation Journey of a Global Pharmaceutical Group, the group’s Odoo journey developed from Odoo 7 to Odoo 19 Enterprise across more than ten years. During the same period, Sasmar expanded from 6 to 22 companies across Europe, Asia-Pacific, North America and Latin America. Its ERP landscape grew to support manufacturing, distribution, finance and more than 25 Shopify stores alongside Amazon and other sales channels.
This is not a step-by-step guide for installing Odoo 19. It is a long-term Odoo enterprise upgrade strategy for keeping one operational platform useful across multiple major versions while the business itself continues to change.
The full selection and growth story is covered in the complete Sasmar transformation. This article focuses on what must happen between versions: deciding when to upgrade, reducing customization debt, migrating data, validating critical workflows, controlling cutover and preparing for the next upgrade before the current one is complete.
Why Long-Running ERP Systems Need an Upgrade Strategy
An ERP accumulates history. New companies are added. Products, customers, vendors and financial records grow. Employees develop workarounds. Custom modules solve requirements that standard software could not support at the time. External platforms connect through APIs, scheduled imports, webhooks and connectors. Reports become part of management and compliance routines.
Every major Odoo version introduces functional improvements and technical changes. Models, fields, views, assets, accounting logic and user-interface components may evolve. An implementation that remains on one version for too long creates a widening gap between its current architecture and the target release.
The upgrade problem can be expressed as:
Version gap + data volume + customization complexity + integration dependencies + organizational change = upgrade risk
Waiting longer does not automatically make an upgrade safer. It may allow the business to skip an intermediate version but it also gives technical debt more time to grow. A long-term strategy manages that balance deliberately.
The objective is not to install every version immediately. The objective is to maintain a predictable path through which the company can move to a supported and strategically useful release without placing critical operations at unnecessary risk.
Sasmar’s Journey from Odoo 7 to Odoo 19 Enterprise
Sasmar’s version journey happened while its business became more complex. The original Odoo environment supported 6 companies. The wider enterprise now includes 22 companies across four regions and a large digital commerce landscape. This means each upgrade had to preserve more than data. It had to preserve a growing operating model.
Browseinfo’s existing Sasmar pharmaceutical case study documents one major modernization stage from Odoo 8 to Odoo 16. That implementation connected multi-company and multi-country operations with manufacturing, external vendor job work, inventory, sales, purchasing, accounting, HR, approvals, website operations and reporting. The official Odoo Experience talk places this stage inside the broader Odoo 7-to-19 journey.
Across a multi-generation program, the upgrade scope changes each time. An early migration may focus on core sales, inventory and accounting. A later upgrade may also include 22-company security, intercompany automation, marketplace connectors, custom manufacturing, consolidated reporting and a much larger historical database.
This is why a ten-year upgrade program cannot be managed as several unrelated technical projects. Each version decision must consider the architecture that will be inherited by the next version.
When to Upgrade and When to Wait
Upgrading simply because a new release exists can create unnecessary disruption. Waiting only because the current system still opens can create a larger future problem. The decision should use business, support and technical criteria.
An upgrade becomes more urgent when the current version approaches the end of its practical support window, security and maintenance options narrow, critical third-party tools stop supporting it or required business capabilities exist only in newer versions. It may also be justified when current customizations are expensive to maintain or when a planned expansion would be easier on a modern architecture.
Waiting may be reasonable when the target release or required third-party applications are not yet stable, a critical localization is incomplete or the organization is entering a business period where change risk is unacceptable. A short wait should have a review date and a defined condition for proceeding. It should not become an open-ended delay.
| Decision area | Upgrade sooner when | Wait with a defined review when |
|---|---|---|
| Support | Current version is becoming difficult to support | Current version remains supportable and stable |
| Business value | New features remove important customizations or constraints | Target features offer limited current value |
| Integrations | External platforms are dropping old API support | Critical connectors are not ready for the target version |
| Localization | Required local functionality is available and validated | Statutory localization is incomplete or unproven |
| Operations | A controlled cutover window is available | Peak season or regulatory deadlines make change unsafe |
| Technical debt | Delay will materially increase remediation effort | A short preparation period will reduce known risks |
The decision should be made through an upgrade steering group that includes business operations, finance, IT, security and implementation leadership. Version selection affects all of them.
For teams focused specifically on one target release, Browseinfo’s guide on How to migrate to Odoo 19 covers the release-level migration process. The strategy here is broader: how to remain upgradeable across the next several versions.
Audit Custom Modules Before Every Upgrade
Custom modules are often the largest source of uncertainty in an enterprise Odoo migration. The correct first step is not converting code. It is building a complete inventory of what exists and why.
The audit should include installed custom applications, small utility modules, custom reports, integrations, automated actions, scheduled jobs, frontend assets and third-party add-ons. Each item needs a business owner and a technical owner. If nobody can explain why a module exists, it should not be migrated automatically.
A useful classification is:
| Decision | Meaning | Upgrade action |
| Retain | Function remains necessary and design is maintainable | Port and test it |
| Refactor | Business requirement remains but architecture is weak | Redesign for the target version |
| Replace | New standard Odoo functionality covers the requirement | Migrate configuration and retire custom code |
| Consolidate | Several modules solve related requirements | Merge into a cleaner modular design |
| Retire | Process or feature is no longer needed | Preserve required data then remove it |
The audit should examine manifests, dependencies, inherited models, method overrides, XML views, access controls, record rules, reports, JavaScript or Owl components, controllers, APIs and data structures. It should also identify direct core changes, hard-coded record IDs, copied standard methods, duplicated views and uncontrolled SQL.
The output is not merely a list of broken modules. It is a business-approved migration scope.
Replace Old Customizations with Improved Standard Functionality
A customization created for Odoo 7 may solve a gap that no longer exists in Odoo 19. Carrying it forward can duplicate standard functionality and increase future upgrade costs.
Before refactoring a module, the team should compare four elements:
Original requirement → current custom behavior → target-version standard behavior → remaining gap
Only the remaining gap should become new custom code. If standard Odoo covers the complete requirement, the custom module should be retired after its configuration and data consequences are handled. If the standard version covers most of the workflow, the extension should be reduced to the smallest maintainable layer.
This review can also reveal that the business process itself has changed. Users may insist on preserving an old screen or approval simply because it is familiar. Upgrade discovery should ask whether the requirement is still valuable rather than rebuilding historical behavior automatically.
The result should be fewer unnecessary overrides and a greater share of operations handled through standard configuration. That reduces regression risk in the current upgrade and makes the next one easier.
Data Migration and Compatibility Planning
Database conversion is only one part of enterprise data migration. Historical records must remain meaningful after models, fields and business rules change.
The migration team should profile master data, open transactions, historical transactions, attachments, accounting records and custom-model data. It should identify duplicates, invalid references, obsolete states, missing company values and inconsistent currencies before rehearsing the upgrade.
Custom modules may also require explicit data transformations. A text field in an old version may become a relation in the target version. A custom status may map to a new standard workflow. Several legacy models may be consolidated into one target structure. Migration scripts should transform and validate this information instead of abandoning it or relying on manual correction after go-live.
The end-to-end data flow should be:
Production copy → profiling → cleanup rules → standard database upgrade → custom migration scripts → module installation → reconciliation → business validation
Every rehearsal should produce measurable results. Record counts, financial balances, stock quantities, open-order totals, lot records and company ownership should be compared before and after migration. Exceptions should be documented and resolved through repeatable scripts wherever possible.
Test Finance, Inventory, Manufacturing and Integrations
An upgraded database that starts successfully is not proof of a successful enterprise migration. Business workflows need end-to-end validation.
Finance testing
Finance teams should reconcile trial balances, general ledgers, receivables, payables, bank accounts, tax reports, assets, retained earnings, exchange differences and opening positions for every company. Historical reports should be compared using agreed dates. Posting, payment, reconciliation, reversal and period-close workflows must be tested in the target version.
Inventory testing
Inventory validation should compare on-hand quantities, reserved quantities, valuation, lots, serial numbers, packages and warehouse locations. The team should test receipts, internal transfers, deliveries, returns, dropshipping, replenishment and inventory adjustments. Where valuation is automated, stock activity must produce the expected accounting entries.
Manufacturing testing
Manufacturing tests should cover bills of materials, work centers, production orders, material consumption, by-products, scrap, subcontracting and costing where used. Sasmar’s environment also requires attention to external job work involving semi-finished and finished goods. The complete traceability path should remain intact after the upgrade.
Integration testing
Every external connection should be tested from authentication to reconciliation. This includes APIs, webhooks, scheduled synchronization, field mapping, error handling, retries and duplicate prevention. Testing only a successful request is insufficient. The team must confirm how failures become visible and how they are safely reprocessed.
Regression Testing for Multi-Company Workflows
Sasmar’s 22-company environment increases the number of contexts in which the same process can behave differently. A sales workflow may pass in one company and fail in another because of currency, localization, security, warehouse or accounting configuration.
Regression tests should be designed as a matrix rather than a single happy path. The matrix should combine critical workflows with representative company types and user roles.
| Workflow | Company context | Critical validation |
| Sale to cash | Local seller and foreign-currency seller | Tax, delivery, invoice, payment and exchange result |
| Procure to pay | Local purchase and imported purchase | Vendor tax, receipt, bill, landed cost and payment |
| Intercompany trade | Supplying company and buying company | Linked SO/PO, delivery, receipt, invoice, bill and balances |
| Manufacturing | Internal production and external job work | Materials, lots, outputs, vendor movement and costing |
| Reporting | Individual company, region and group | Access, account mapping, currency and consolidated totals |
| Security | Local user, regional user and global user | Allowed actions and prohibited cross-company access |
Negative testing is essential. Users should be unable to post in unauthorized journals, access restricted companies or confirm transactions beyond their approval level. Automated jobs should run in the correct company context. Custom record rules must be tested with several active companies.
Validate Shopify, Amazon and Marketplace Connectors
Sasmar’s digital landscape includes more than 25 Shopify stores alongside Amazon and other channels. This creates a high-risk integration surface during an Odoo upgrade.
A connector may technically authenticate while still producing incorrect operational results. Product variants may map differently. Taxes may use a new structure. Warehouse selection may change. An order can import successfully but fail during fulfilment or invoicing. Inventory updates may reach the wrong store or repeat after a retry.
Connector validation should cover:
Product and variant mapping
Channel-specific identifiers
Customer creation and duplicate control
Price lists, discounts, taxes and currencies
Order import and company assignment
Warehouse and fulfilment routing
Inventory publication and reservation
Shipment and tracking updates
Cancellations, refunds and returns
Payment and settlement mapping
Retry behavior and duplicate prevention
Error queues, alerts and reconciliation reports
The complete channel flow is:
Marketplace order → connector queue → validation and mapping → Odoo sales order → stock reservation → fulfilment → invoice and payment mapping → channel status update → reconciliation
Testing should include volume as well as functionality. More than 25 Shopify stores can create synchronization peaks that affect scheduled jobs, API limits and database load. Performance and recovery must be tested with realistic transaction batches.
Plan Cutover and Rollback Together
A cutover plan describes how the target system becomes production. A rollback plan describes how the organization returns to a controlled state if agreed success criteria are not met. They must be designed together because data can continue to change during the transition.
The cutover plan should define:
Change freeze and final transaction deadlines
Full database, filestore, custom code and configuration backups
Final migration sequence and expected duration
Validation owners for each business area
Integration shutdown and restart order
User access activation
Financial and operational reconciliation
Go or no-go authority
Communication and support coverage
Rollback requires a decision deadline. Once users and integrations create significant new transactions in the target system, returning to the old environment becomes more difficult because the new activity must be preserved or recreated. The team should define which failures justify rollback, which can be repaired during stabilization and who makes that decision.
A tested restore is more valuable than an unverified backup. Before production cutover, the team should prove that the database, filestore, code and configuration can be restored together in a recovery environment.
Manage Technical Debt Between Upgrades
Technical debt should not be assessed only when the next migration begins. By then, the most expensive decisions may have been embedded for years.
The organization should maintain an upgrade-readiness register covering custom modules, integrations, unsupported third-party applications, core changes, performance issues, missing tests and undocumented processes. Each item should have a risk rating and a remediation owner.
Technical debt grows through ordinary change requests. A local team needs a new approval. A connector requires another field. A report copies complex business logic. A quick fix bypasses the normal architecture review. Individually these changes may appear small but together they determine the cost of the next version transition.
A quarterly or release-based review can identify customizations that are obsolete, now available in standard Odoo, too tightly coupled or inadequately tested. Removing one unnecessary module today avoids migrating and testing it in every future version.
Keep Custom Modules Upgrade-Safe
Upgrade-safe development does not mean custom modules will never require changes. It means they are designed so changes remain understandable, isolated and testable.
Core principles include:
Keep proprietary code separate from Odoo core
Use model and view inheritance instead of copying standard components
Override the smallest necessary behavior
Keep dependencies explicit and limited
Store business rules in backend logic rather than only in views
Avoid database-specific hard-coded IDs
Use configuration and stable references
Apply migration scripts when schemas or data structures change
Add automated tests for critical workflows
Document purpose, ownership and dependencies
Version-control code and deployment configuration
A custom module should be reviewed as a product with a lifecycle. Someone should own its business value, architecture, test coverage and retirement decision.
Browseinfo’s detailed article on upgrade-safe custom modules explains how to classify legacy add-ons as retain, refactor, replace or retire before moving them to a new Odoo version.
Train Users After Major Interface and Process Changes
An upgrade can preserve business outcomes while changing how users reach them. Menus, list views, forms, filters, dashboards and approval interactions may differ across major Odoo generations. Standard functionality may replace custom screens. A redesigned workflow may remove steps that users previously considered mandatory.
Training should focus on role-based tasks rather than a general product tour. Sales teams should follow quotation-to-order scenarios. Warehouse users should complete receipts, picking, packing, delivery and returns. Finance teams should post, reconcile, close and report. Manufacturing teams should process production and exception scenarios.
Users also need to understand what changed and why. If a legacy customization is replaced by standard Odoo, the team should explain the new control rather than presenting the difference as a missing feature.
Training should begin in user acceptance testing so operational experts can identify gaps before cutover. Updated job aids, short process guides and support ownership should be ready before production access begins.
Lessons from Multiple Odoo Generations
The first lesson is that an ERP upgrade is also a process review. Recreating every old behavior preserves technical and operational debt.
The second lesson is that custom-code reduction is a measurable upgrade outcome. The target should not merely be that all modules install. The implementation should finish with a cleaner and better-justified customization portfolio.
The third lesson is that data validation must follow business meaning. Record counts matter but so do financial balances, stock valuation, traceability and document relationships.
The fourth lesson is that multi-company regression cannot be assumed from one successful company. Localization, currency, security and warehouses create different paths through the same application.
The fifth lesson is that connectors are operational systems. Shopify, Amazon and other channels require reconciliation, monitoring and failure recovery after every major change.
The sixth lesson is that cutover success is created through rehearsal. Each test migration should make the next run more predictable by turning manual corrections into scripts and documented steps.
The seventh lesson is that the next upgrade begins immediately. Code standards, automated tests, architecture records and technical-debt reviews created after go-live determine how difficult the next version will be.
Long-Term Upgrade Governance Checklist
| Governance area | Required control |
| Version roadmap | Review support, target releases and business timing at least annually |
| Custom portfolio | Maintain module inventory, owners, classification and risk ratings |
| Standard comparison | Reassess whether new Odoo functions can replace custom code |
| Architecture | Review dependencies, core changes, data models and integration patterns |
| Testing | Maintain automated tests and documented end-to-end scenarios |
| Data | Profile quality, ownership, retention and transformation requirements |
| Multi-company | Test representative companies, currencies, localizations and user roles |
| Integrations | Monitor APIs, credentials, queues, retries and reconciliation |
| Infrastructure | Track performance, capacity, backup and recovery readiness |
| Change management | Prepare role-based training, communications and support |
| Cutover | Rehearse migration, validation, go or no-go and rollback |
| Post-go-live | Monitor exceptions then update the upgrade-readiness register |
Build an ERP That Can Continue Moving
Sasmar’s Odoo 7-to-19 journey demonstrates that enterprise modernization is not one migration event. The system had to evolve while the business expanded from 6 to 22 companies and developed a complex global operational and digital commerce environment.
Long-term upgradeability depends on decisions made between versions. Custom modules must be controlled. New standard capabilities should replace unnecessary legacy code. Data needs continuous ownership. Multi-company workflows and integrations require repeatable tests. Backups, cutover and rollback must be rehearsed rather than assumed.
The best result of an upgrade is not simply reaching Odoo 19. It is reaching the target version with a cleaner architecture, verified business data and a more predictable path to the version that follows.
Browseinfo’s Odoo migration and upgrade services help organizations assess legacy databases, custom modules, data, integrations and enterprise workflows before moving to a newer Odoo environment.
For migration-service positioning, Sasmar’s decade-long journey can be introduced under a “Real long-term upgrade experience” section. The message should focus on sustained modernization across multiple Odoo generations rather than presenting the work as a single version conversion.
Frequently Asked Questions
1. Did Sasmar migrate directly from Odoo 7 to Odoo 19?
The official Odoo Experience session describes a wider ten-year journey from Odoo 7 to Odoo 19 Enterprise. It should not be presented as one direct technical migration. Browseinfo’s existing Sasmar case study separately documents a major Odoo 8-to-16 modernization stage.
2. How often should an enterprise upgrade Odoo?
There is no single schedule for every organization. The decision should consider support, security, business value, localization, custom-module compatibility, connector readiness and operational timing. Enterprises should review their version roadmap regularly even when they choose not to upgrade immediately.
3. Should every custom module be migrated to the new version?
No. Each module should be classified as retain, refactor, replace, consolidate or retire. If the target version provides the required functionality through standard Odoo, unnecessary custom code should normally be removed.
4. What data should be validated during an Odoo enterprise upgrade?
Validation should cover master data, open documents, accounting balances, taxes, inventory quantities, valuation, lots, serial numbers, manufacturing records, attachments, company ownership and custom-model information. Business totals should be reconciled before and after migration.
5. How should multi-company workflows be tested after an upgrade?
Tests should cover representative companies, regions, currencies, localizations, warehouses and user roles. Intercompany sales, purchases, stock movements, invoices, bills, payments, reporting and prohibited cross-company access should all be validated.
6. What should be tested in Shopify and Amazon connectors?
Testing should include authentication, identifiers, products, variants, prices, taxes, currencies, company assignment, inventory, order import, fulfilment, tracking, refunds, returns, payments, retries, duplicate prevention and reconciliation.
7. What makes an Odoo custom module upgrade-safe?
An upgrade-safe module remains separate from Odoo core, uses supported inheritance, limits dependencies, avoids hard-coded records, contains migration logic for data changes and includes tests for critical behavior. It may still require adaptation but that work remains controlled.
8. Why is rollback planning important during an ERP upgrade?
Rollback provides a controlled recovery path if critical validation fails. The plan should include verified backups, restore procedures, decision criteria, authority and a deadline because returning to the old system becomes harder after users and integrations create new target-version transactions.
