Introduction
Upgrading Odoo across a major version is already a significant technical project. When the database contains multiple companies, the complexity increases considerably. Each company may have its own accounting configuration, warehouses, taxes, currencies, users, workflows and integrations, while products, contacts and other master data may be shared across the organization. A change that works correctly for one entity can therefore create unexpected consequences for another.
The risk becomes even greater when the multi-company environment has been running for several years and contains custom modules, automated actions, historical transactions and integrations with external systems. Simply upgrading the database and checking whether the applications open successfully is not enough. The migration must prove that each company can continue its financial and operational activities accurately after the upgrade.
This is why a staged migration strategy is often more effective than treating the upgrade as one large technical event. Instead of attempting to validate every company, application and workflow simultaneously, organizations can break the migration into controlled stages. Each stage provides an opportunity to identify issues, validate results, correct problems and improve the migration approach before moving forward.
The objective is not merely to move a multi-company database from one Odoo version to another. The objective is to preserve data integrity, accounting accuracy, operational continuity and company-level functionality while taking advantage of the capabilities available in the target Odoo version.
Why Multi-Company Odoo Migrations Are More Complex
A multi-company Odoo environment contains both shared and company-specific information. Odoo allows multiple companies to operate within the same database while controlling access to company-dependent records. Products and contacts, for example, can be shared across companies, while accounting documents, warehouses and other operational records may be associated with specific companies.
This creates several migration dependencies that do not exist in the same way within a single-company database.
A typical multi-company implementation may include different:
- Charts of Accounts
- Tax configurations
- Fiscal Positions
- Currencies
- Accounting journals
- Warehouses
- Stock locations
- Pricelists
- Sales teams
- Purchase workflows
- User access rights
- External integrations
- Custom modules
The migration team must therefore understand which records are shared, which are company-specific and which processes connect multiple companies.
This distinction becomes particularly important when companies conduct inter-company transactions. A sales transaction in one company may create a corresponding purchase transaction in another. Inventory movements, invoices, taxes and accounting entries can therefore cross company boundaries.
A migration that validates each company independently but ignores these relationships can still produce operational problems after go-live.
Why a Staged Migration Strategy Is Safer
A major-version migration can involve database changes, custom-module updates, configuration adjustments, data transformations and extensive testing. Attempting all of these activities simultaneously increases the concentration of risk.
A staged approach separates the work into manageable phases.
The process generally begins with an assessment of the existing environment, followed by customization analysis, test migration, data validation, business testing and controlled deployment. Companies or business units can then be introduced to the upgraded environment in planned waves.
The biggest advantage is feedback.
If a problem is identified during an early migration stage, the team can correct the migration methodology before applying it to the remaining companies. This is particularly valuable for multi-company environments because the first migration wave can reveal issues involving shared data, company-dependent configuration, security rules or inter-company workflows.
A staged migration therefore changes the project from a single high-risk event into a controlled sequence of validation cycles.
Stage 1 : Assess the Existing Multi-Company Environment
The first step is to establish a detailed understanding of the current Odoo database.
The assessment should go beyond identifying installed applications. The migration team should document how each company uses Odoo and how those companies interact with one another.
Important areas include:
| Area | What to Review |
|---|---|
| Companies | Legal entities and company relationships |
| Users | Company access and security groups |
| Accounting | Accounts, journals, taxes and fiscal positions |
| Inventory | Warehouses, locations and routes |
| Sales | Pricelists, teams and sales workflows |
| Purchase | Vendors and procurement rules |
| Products | Shared and company-specific configuration |
| Contacts | Shared and restricted records |
| Integrations | APIs and external applications |
| Customizations | Modules, fields, views and business logic |
The outcome should be a current-state inventory that identifies the dependencies between companies and provides a baseline for migration planning.
This stage is also the right time to identify business-critical processes that cannot tolerate extended downtime.
Stage 2 : Audit Custom Modules and Customizations
Custom development is one of the most important factors affecting Odoo version migration.
A custom module developed for an older Odoo version may depend on models, fields, methods, views or APIs that have changed in the target version. Some customizations may also have been implemented differently across companies.
The migration team should classify custom functionality according to business importance and technical condition.
| Customization Category | Recommended Action |
|---|---|
| Business-Critical | Migrate and fully test |
| Still Required | Review and migrate |
| Replaceable by Standard Odoo | Consider removing |
| Obsolete | Retire |
| Duplicate | Consolidate |
| High-Risk Core Modification | Refactor |
This review prevents organizations from automatically carrying unnecessary technical debt into the new version.
The target version may already provide standard functionality that previously required customization. Removing obsolete code can reduce future upgrade costs while making the resulting environment easier to maintain.
Stage 3 : Create a Company-Specific Configuration Baseline
Each company should have a documented configuration baseline before the migration begins.
For every entity, record important settings such as:
- Company currency
- Fiscal localization
- Chart of Accounts
- Taxes
- Fiscal Positions
- Accounting journals
- Warehouses
- Stock locations
- Pricelists
- Payment terms
- User access
- Sales and purchase configurations
This baseline acts as a reference during testing.
For example, if Company A uses USD while Company B operates in EUR, the migration team must verify that both company currencies and their related accounting behavior remain correct after the upgrade.
Similarly, a warehouse configured for one company should not accidentally become available to another company because of an incorrect company assignment.
Stage 4 : Validate Shared Master Data
Shared master data requires special attention in a multi-company database.
Products, contacts and other records may be intentionally shared between companies. Other records may need to remain restricted to a particular company.
Before migration, organizations should review:
- Product templates
- Product variants
- Product categories
- Customers
- Vendors
- Units of Measure
- Payment terms
- Pricelists
- Taxes
- Fiscal Positions
Duplicate records should also be identified before migration.
For example, two companies may have separate customer records for the same corporate customer because of historical processes. The organization must determine whether these records should remain separate or be consolidated.
Data cleansing should therefore happen before the final migration rather than after users begin working in the new version.
Stage 5 : Perform a Test Migration
A production database should never be the first environment used to discover whether an upgrade works.
A test copy of the database should be upgraded first. The test environment should contain the relevant custom modules, configuration and data required to reproduce the production environment accurately.
The test migration should evaluate:
- Database upgrade compatibility
- Custom-module compatibility
- View and workflow behavior
- Scheduled actions
- Automated processes
- User access
- Reports
- Integrations
- Performance
Odoo's upgrade guidance recommends testing upgraded databases before production and highlights the importance of having compatible custom modules available for customized databases.
The test migration should be repeated whenever significant migration issues are corrected. Multiple test cycles are often preferable to attempting to resolve every problem during the final production cutover.
Stage 6 : Validate Accounting Company by Company
Financial validation should be performed separately for every legal entity.
Even if all companies share one database, each company's accounting results must reconcile independently.
The migration team and finance department should compare:
- Trial Balance
- Accounts Receivable
- Accounts Payable
- Bank balances
- Tax balances
- Inventory valuation
- Fixed assets
- Outstanding invoices
- Outstanding vendor bills
- Opening balances
A balanced consolidated Trial Balance does not necessarily prove that every company is correct.
For example, an error in one company may be offset by another accounting difference elsewhere. Company-level reconciliation is therefore essential.
Financial validation should be formally signed off by the appropriate finance owner before each company is considered ready for production.
Stage 7 : Validate Multi-Currency Configuration
Multi-company environments often involve multiple currencies, making currency configuration another critical migration dependency.
The migration team should verify:
- Company currencies
- Transaction currencies
- Exchange rates
- Bank accounts
- Currency gains and losses
- Foreign-currency receivables
- Foreign-currency payables
- Inter-company currency transactions
Testing should include real-world scenarios rather than simply checking whether the currencies exist in the database.
For example, the team should create representative customer invoices, vendor bills and payments in foreign currencies and compare the resulting accounting entries with expected results.
Stage 8 : Test Inter-Company Transactions
Inter-company transactions require end-to-end validation because they involve more than one company.
A typical process may involve a sales order in one company and a corresponding purchase transaction in another company. Depending on configuration, related documents may be generated automatically.
Testing should cover:
- Inter-company sales
- Inter-company purchases
- Customer invoices
- Vendor bills
- Credit notes
- Product receipts
- Product deliveries
- Taxes
- Fiscal Positions
- Currency conversion
- Accounting entries
The test should verify both sides of the transaction.
It is not sufficient to confirm that Company A generated the expected sales document. The migration team must also confirm that Company B received the correct corresponding transaction and that both sides remain financially consistent.
This is one of the most important areas where multi-company migration differs from a single-company upgrade.
Stage 9 : Validate Inventory and Warehouse Configuration
Inventory migration requires company-level and warehouse-level validation.
Each company's warehouses, locations, routes and operation types should be reviewed.
The migration team should verify:
- Warehouse ownership
- Stock locations
- Inventory quantities
- Product availability
- Routes
- Operation types
- Reordering rules
- Inventory valuation
- Internal transfers
- Inter-company stock movements
Opening inventory should be reconciled against approved migration figures.
However, checking only opening quantities is not enough. The team should also execute complete workflows such as purchase receipts, internal transfers, deliveries, returns and inventory adjustments.
This confirms that migrated inventory data behaves correctly when normal business transactions resume.
Stage 10 : Test User Access and Company Security
Multi-company access rules can become a significant source of post-migration issues.
Users may have access to multiple companies but should only see the records appropriate to their assigned companies and security groups.
Testing should include:
- Company selection
- Default company
- Allowed companies
- Accounting access
- Warehouse access
- Sales access
- Purchase access
- Manager permissions
- Record visibility
- Reports
Testing should be performed using representative user accounts rather than administrator access alone.
An administrator may be able to see everything, while an operational employee may encounter access errors or missing records.
Stage 11 : Run a Pilot Migration
After technical testing, select a representative company or business unit for the first controlled migration wave.
The pilot should be complex enough to expose real problems but manageable enough to support intensive monitoring.
The pilot should validate the complete operational lifecycle, including:
- Login and user access
- Sales
- Purchase
- Inventory
- Accounting
- Reporting
- Integrations
- Inter-company transactions
- Custom functionality
The migration team should document every issue found during the pilot and update the migration checklist accordingly.
The objective is to make subsequent migration waves more predictable.
Stage 12 : Deploy Remaining Companies in Controlled Waves
Once the pilot is stable, additional companies can be migrated according to a predefined sequence.
The sequence should consider:
- Company complexity
- Transaction volume
- Number of users
- Number of integrations
- Customization level
- Inter-company dependencies
- Business criticality
A simple deployment structure could be:
| Wave | Scope |
|---|---|
| Pilot | Representative company |
| Wave 2 | Lower-complexity companies |
| Wave 3 | Medium-complexity companies |
| Wave 4 | High-complexity companies |
| Final Wave | Most integrated or business-critical entity |
Not every company needs to be migrated independently. Where companies are tightly connected through inter-company workflows, they may need to be deployed within the same migration window.
Stage 13 : Establish Go/No-Go Criteria
Each migration wave should have measurable acceptance criteria.
| Area | Required Validation |
|---|---|
| Accounting | Company-level reconciliation completed |
| Inventory | Opening stock reconciled |
| Custom Modules | Critical workflows validated |
| Integrations | End-to-end testing completed |
| Security | User access verified |
| Reports | Key reports reconciled |
| Inter-Company | Counterpart transactions tested |
| Users | Training completed |
A migration should not proceed simply because the technical upgrade completed successfully.
If a critical accounting discrepancy or inventory mismatch remains unresolved, management should have the authority to postpone the deployment.
Stage 14 : Plan Cutover and Rollback
The production cutover should be rehearsed during the test phase.
A typical cutover includes:
- Announce transaction freeze.
- Take the required database backup.
- Capture final changes.
- Perform the production upgrade.
- Deploy compatible custom modules.
- Validate configuration.
- Perform critical business checks.
- Obtain business approval.
- Enable users and integrations.
- Begin hypercare.
A rollback strategy should be documented before the cutover begins.
The plan should specify who can authorize rollback, how the previous environment will be restored and how transactions created during a failed deployment will be handled.
Stage 15 : Establish Post-Go-Live Hypercare
The migration team should monitor each company closely after deployment.
The hypercare period should focus on:
- Accounting transactions
- Inventory movements
- Sales orders
- Purchase orders
- Inter-company workflows
- Scheduled jobs
- Email notifications
- External integrations
- User access
- Reporting
Issues should be prioritized according to business impact.
Critical financial or operational issues require immediate resolution, while minor usability improvements can be documented for later optimization.
Lessons from one company's hypercare period should also be incorporated into the next migration wave.
Common Multi-Company Migration Risks
| Risk | Mitigation |
|---|---|
| Incorrect company assignment | Validate company-specific records |
| Shared data becomes restricted | Review shared master data |
| Accounting discrepancies | Reconcile every company separately |
| Inter-company workflow failures | Perform end-to-end testing |
| Custom-module incompatibility | Upgrade custom modules before deployment |
| Inventory mismatch | Reconcile stock by company and warehouse |
| Currency errors | Test foreign-currency transactions |
| User access problems | Test representative user roles |
| Integration failures | Conduct integration testing |
| Reporting differences | Compare critical reports before and after migration |
How BrowseInfo Helps With Multi-Company Odoo Migration
A multi-company Odoo migration requires a combination of technical expertise, functional understanding and structured project management. BrowseInfo can help businesses assess their existing Odoo environment and create a migration roadmap based on company complexity, customizations, integrations and operational dependencies.
The migration process can include database assessment, custom-module analysis, data validation, accounting reconciliation, inventory testing, inter-company workflow validation and production cutover planning.
BrowseInfo can support organizations with:
- Odoo version migration consulting
- Multi-company migration planning
- Custom-module migration
- Data cleansing and transformation
- Accounting migration and reconciliation
- Inventory migration
- Warehouse configuration validation
- Inter-company transaction testing
- Third-party integration migration
- User access and security testing
- Migration rehearsals
- Cutover and rollback planning
- Post-go-live support
The focus should be on creating a repeatable migration process where each stage has defined validation criteria and business ownership.
Best Practices for a Staged Odoo Migration
Start with a detailed inventory of companies, applications, custom modules and integrations. This provides the foundation for estimating risk and determining migration dependencies.
Treat each legal entity as a separate validation scope even when all entities share the same Odoo database. Accounting, inventory, security and operational workflows should be verified independently.
Review customizations before migrating them. If the target Odoo version already provides standard functionality for an old customization, replacing it can reduce technical debt and future upgrade costs.
Pay particular attention to shared master data. Products, contacts and other records may be intentionally shared across companies, while company-specific records require appropriate company assignments.
Perform multiple test migrations for complex environments. Each test should improve the migration process and reduce uncertainty before production.
Finally, establish clear go/no-go criteria. A scheduled migration date should never take priority over unresolved issues that could affect financial integrity, inventory accuracy or business continuity.
Frequently Asked Questions
1. Why is a multi-company Odoo migration more difficult than a single-company upgrade?
Multiple companies can have different accounting, tax, currency, warehouse, security and operational configurations while still sharing common master data. Inter-company transactions add another layer of dependency.
2. Can multiple companies remain in the same Odoo database after migration?
Yes. Odoo supports multi-company environments within a single database, allowing organizations to manage shared and company-specific records according to their configuration.
3. Should each company be migrated separately?
Not necessarily. Companies can remain within the same upgraded database. However, each company should have its own validation and acceptance process. Companies with strong inter-company dependencies may need to be migrated and tested together.
4. What should be validated first?
Start with the database and customization assessment, followed by master data, company configuration, accounting, inventory, user access, integrations and inter-company workflows.
5. How should custom modules be handled during an Odoo version migration?
Custom modules should be reviewed against the target Odoo version and updated before production migration. Unused or obsolete modules should be removed rather than carried forward unnecessarily.
6. Why is company-level accounting reconciliation important?
A consolidated balance can hide discrepancies between individual companies. Each legal entity should therefore reconcile its Trial Balance, receivables, payables, taxes, inventory valuation and other critical balances independently.
7. How important is a pilot migration?
A pilot provides a controlled environment for discovering data, configuration, integration and workflow problems before they affect additional companies.
8. What is the biggest benefit of a staged migration?
The primary benefit is risk control. Problems can be identified and corrected during earlier stages instead of affecting the entire multi-company organization at once.
Conclusion
Transitioning a multi-company Odoo environment across major versions requires considerably more than a successful database upgrade. Organizations must preserve company-specific accounting, inventory, taxation, security and operational configurations while ensuring that shared master data and inter-company workflows continue to function correctly.
A staged migration roadmap provides a controlled way to manage this complexity. By beginning with a detailed assessment, auditing custom modules, validating shared and company-specific data, performing repeated test upgrades and introducing companies through controlled deployment waves, businesses can reduce the operational and financial risks associated with a major Odoo migration.
The most important principle is to avoid making the entire organization the testing environment. Pilot, validate, reconcile, learn and then expand. Each successful migration wave should strengthen the methodology for the next one.
With disciplined planning, strong business ownership and comprehensive testing, organizations can move to a newer Odoo version while maintaining financial accuracy, operational continuity and multi-company visibility. A carefully staged migration does more than reduce upgrade risk it creates an opportunity to simplify legacy customizations, standardize processes and establish a stronger foundation for future Odoo versions.
