You probably need this if…
- You're several versions behind and the upgrade keeps getting deferred.
- Your ERP is hosted by a vendor and you want it on your own infrastructure.
- A big-bang cutover weekend has been proposed and it makes you nervous.
- Your systems don't talk to each other, so someone re-keys data every day.
- Heavy customisation means the standard upgrade path doesn't apply to you.
What's in scope
Pre-migration audit
A full inventory of what you're actually running: database size and growth, custom modules, Studio changes, custom reports, scheduled actions, live integrations, and the infrastructure baseline. Every risk gets a severity and an owner before any work starts.
Cleanup
The work that makes migration faster and safer — archiving closed fiscal years, moving oversized attachment data out of the database, trimming tracking messages, deactivating dormant users, and uninstalling modules nobody uses.
Parallel-run migration
We stand up the new system alongside the old one. A routing layer sends each group of users to old or new as they're moved. Data is copied one way, so nothing duplicates and nothing is lost. Your current system keeps running normally throughout.
Custom module porting
Rebuilding custom modules, Studio customisations and QWeb reports against the new version's ORM and API changes — the part standard upgrade tools don't handle.
Integrations
Mail and Exchange, SMS gateways, bank feeds, invoice OCR, payment providers, e-commerce storefronts, logistics and third-party APIs — rebuilt and tested against the new version.
Cutover and rollback
Per-company switchover at a sensible boundary (fiscal period for accounting waves), with a tested path back to the old system for each wave independently.
How we approach it
- 1
Audit
Inventory the source system and grade every risk.
- 2
Cleanup
Shrink and simplify before moving anything.
- 3
Parallel environments
New system stood up beside the old, with routing.
- 4
Wave migration
Lowest-risk company or module first, riskiest last.
- 5
Stabilisation
Decommission the old system only once every wave is proven.
Yours at the end of the engagement
- A migration runbook
- Per-wave rollback procedures
- Data reconciliation reports
- Rebuilt custom modules in your repository
- Integration documentation
- The pre-migration audit as a permanent record of what changed
Relevant experience
Moved a live Odoo system from vendor hosting to the client's own on-premise servers with no data loss (Germany).
Ran multiple Odoo versions in parallel during a controlled transition — the same parallel-run method we propose as standard (Germany).
Migrated Odoo from VM hosting to a cloud-native container deployment using Docker, Kubernetes and Terraform.
Planned a three-version Odoo jump for an eleven-company group with a 6.6 GB database, five custom modules and five live integrations.
Common questions
How much downtime should we plan for?
Minutes per company, not a weekend for the whole group. The parallel-run model means switchover is a routing change, not a data load.
What if a wave goes wrong?
The old system is still live and unchanged. We route that company back to it and fix forward. This is why we migrate in waves rather than all at once.
Can you use the official Odoo upgrade service?
For standard data, often yes — and we'll use it where it's the cheaper path. It doesn't cover custom modules, Studio changes or custom reports, which is where most of the real work sits.
Do we need new hardware?
Usually some. Newer Odoo versions need newer PostgreSQL, Python and OS versions, and those have real resource floors. We size it during the audit so there are no surprises.