Migrating Odoo from an old version to a recent one is not a formality, but it is not a leap in the dark either. With serious preparation, most problems are solved before going live. Here is the checklist we follow to prepare a migration.
Why migrate?
- Stay on a supported version: Odoo generally maintains only the latest three versions, and beyond that there are no official fixes.
- Close security gaps: an abandoned version stops receiving fixes, yet your ERP holds your most sensitive data.
- Get the improvements: interface, modules, integrations and performance get better with every release.
- Keep technical debt under control: migrating custom modules early costs less than migrating everything at once years later.
The most common mistakes
- Migrating without an inventory of custom and third-party modules.
- Working directly on the production database instead of a copy.
- Discovering too late that a third-party module does not exist in the target version.
- Not comparing accounting figures before and after the migration.
- Skipping user acceptance testing and discovering problems on cutover day.
- Having no rollback plan.
The 10-step checklist
1. Take inventory of your installation
The basis of everything: knowing exactly what you are migrating.
- Current version and edition (Community or Enterprise)
- List of installed modules: standard, community (OCA), paid third-party, custom
- External integrations: e-commerce, payment, carriers, accounting, APIs
- Custom reports, printed forms and automated actions
2. Choose the target version and the path
Data migration is generally done one major version at a time. Fix the target and the number of steps before you begin.
- Target version chosen (recent and supported)
- Migration path defined (version by version)
- New features of the target version that replace your customisations identified
3. Sort your custom modules
Every module costs time to migrate. The best module to migrate is the one you no longer need to maintain.
- Modules to keep and migrate
- Modules to replace with a standard feature or an OCA module
- Modules that are no longer useful and can be removed
4. Check third-party modules
A third-party module that does not exist in the target version blocks the migration.
- Availability of each third-party module in the target version
- Alternative identified for each abandoned module
- Licences and subscriptions up to date
5. Back up and create a working copy
Never migrate your production directly.
- Full backup of the database and attachments
- Working copy restored on a test environment
- Restore procedure tested
6. Migrate the specific code
Views, models, methods, JavaScript: every version changes APIs and conventions.
- Breaking points analysed in each module
- Python code, XML views, JavaScript and styles adapted
- Each module installs on the target version without errors
7. Migrate the data
Always on the working copy, never on production.
- Database migrated from source to target version
- Custom fields and models carried over
- Orphan records and duplicates identified
8. Check the numbers
"The module installs" does not mean "the figures are right". This is the step that protects your accounting.
- Trial balance identical before and after
- Customer and supplier balances identical
- Stock valuation and key record counts compared
- Main reports compared over the same period
9. Test and get user sign-off
- Essential business scenarios tested: sales, purchasing, inventory, invoicing, payroll
- Access rights and security groups checked
- Printouts, emails and integrations tested
- Acceptance signed off by key users
10. Prepare the cutover and follow-up
- Downtime window planned and users informed
- Rollback plan ready
- Users trained on the changes
- Follow-up after go-live: quick fixes during the first weeks
Frequently asked questions
How long does a migration take?
It depends on the number of custom modules, the data volume and the gap between versions. An upfront analysis makes it possible to give a realistic timeline.
Can you migrate without stopping the business?
Yes for the trials: they run on a copy. Only the final cutover requires a short interruption, planned with the teams.
What if a custom module cannot be migrated?
It happens when it depends on code that has disappeared from Odoo. The upfront analysis flags it and you choose between rewriting, replacing it with standard functionality or dropping the feature.
Should you get help?
Not necessarily, but it is useful as soon as you have custom modules or accounting to verify. An experienced partner avoids the mistakes listed above.
What now?
If you want to know where your installation stands and what a migration would involve, you can request an Odoo migration quote. We analyse your code first and then send a written quote. For any other question, contact us.
