Case study: Migration
Two versions forward and off the cloud
A Saudi enterprise group needed to move two major Odoo versions forward and change hosting platform at the same time, with accounting and attendance live throughout.
Industry
Finance and HR operations
Region
Saudi Arabia
Odoo
Version 16 to 18
Scope
Migration, platform move
The challenge
What was not working.
Two things had to happen at once. The ERP had to move two major versions forward, and the platform had to move from Odoo.sh to on-premises infrastructure. Accounting, Invoicing and biometric attendance were all live and could not be paused, and every custom module had to survive the jump.
What we built
The work, in detail.
Planned the migration end to end
We steered the full migration rather than treating it as a database upgrade, so the version jump and the platform move were sequenced deliberately.
Upgraded every custom module
All custom modules were brought to v18 compatibility, which is where most migrations of this shape actually fail.
Monitored the data pipelines
The data migration was monitored through the cutover rather than validated only at the end.
Carried biometric attendance across
The biometric attendance integration was migrated and re-verified against the new platform.
Tuned after cutover
Performance and stability work continued after go-live, not just up to it.
The result
What changed.
Migration completed with data integrity maintained
All custom modules running on the new version
Platform moved from managed cloud to on-premises
System performance and stability improved after cutover
Stack
What it runs on.
- Odoo 16 to 18
- Odoo.sh to on-premises
- Accounting
- Invoicing
- Biometric attendance
Modules behind this
Productised from real work.
Work from engagements like this one becomes a published module, so the next client installs it instead of paying to build it again.
Questions
About work like this.
Can you migrate Odoo two versions in one project?
Yes, though the upgrade runs version by version underneath. The real work is the custom modules, which have to be brought forward through each version's changes.
Is moving from Odoo.sh to on-premises hard?
It is a separate project from the version upgrade, and doing both at once needs careful sequencing. On-premises means you own the server, backups and updates, which is a trade for control.
What usually breaks in an Odoo migration?
Custom modules, not standard data. Renamed fields and changed method signatures between versions are the common failure, which is why every custom module gets checked against the target version's source.
More work
Other things we have shipped.
Every engagement below was delivered by the same certified Odoo team.
From overselling to zero stock conflicts
Multi-company Odoo behind several WooCommerce storefronts, with shipping, tax and card payments automated end to end.
Read the case study Finance & AccountingReplacing the settlement spreadsheet
Vendor invoices parsed straight out of email, and multi-tier franchise payouts calculated inside Odoo instead of Excel.
Read the case study InsuranceQuoting rules that non-technical staff can change
A multi-region insurance ERP with a formula engine that moved rating logic out of spreadsheets and out of the developer queue.
Read the case studyReady to make Odoo work the way your business does?
Book a free callCODEerts is a team of certified Odoo experts and full-stack engineers. We implement, customise and support Odoo ERP, then build the software around it.