An Odoo 20 Migration is a project, not a button. This guide shows businesses on Odoo 16, 17, 18 or 19 exactly how to plan the move, from auditing modules and customisations to choosing an upgrade path, testing real data, training users and going live with a rollback ready. Teams that plan well switch over a single weekend. Teams that do not spend months fixing reports and reconciling balances.
Key Takeaways
- With Odoo 20 released, Odoo 16 and 17 sit outside standard support, while 18 and 19 still have time on their window
- Standard data can often jump several versions at once, but custom code must be rewritten for Odoo 20 either way
- The audit of modules, customisations and data quality decides timeline and budget more than anything else
Table of Contents
- Why Plan Your Odoo 20 Migration Now
- Upgrade vs Migration and What Changes When You Jump Versions
- Auditing Your Current Version, Modules and Customisations
- Choosing a Path With a Direct Jump or a Stepwise Upgrade
- Data Cleanup and Migration Scope
- Custom Module and Third Party App Compatibility
- Environment Setup and Test Migration
- User Acceptance Testing and Training
- Cutover and Go Live Plan for Your Odoo 20 Migration, With Rollback
- After Go Live Checklist, Risks, Timeline and Budget
- FAQs
Why Plan Your Odoo 20 Migration Now
Support windows, app availability and porting effort all move against you the longer you wait. If you would rather hand the project to a partner, our Odoo migration and upgrade services cover every stage below.
- Support windows have moved. Odoo maintains the three most recent major versions, which now means 18, 19 and 20. Databases on 16 or 17 no longer receive standard bug and security fixes.
- The gap only grows. Each year adds more framework changes to port.
- Planning takes longer than the upgrade itself. Audit, porting and testing take more calendar time than the technical run.
Upgrade vs Migration and What Changes When You Jump Versions
Two words, two different projects
- An upgrade moves a mostly standard database to the next version.
- A migration jumps several versions, ports custom modules, replaces abandoned apps, cleans data, and sometimes changes hosting or edition at the same time.
What a jump across several versions adds
- Accumulated framework changes. Moving from Odoo 16 means absorbing four years of changes to fields, views, security and screens in one go.
- Renamed and restructured features. Menus, statuses and workflows users know by heart may have moved.
- Changes specific to Odoo 20. Record rules give way to a domain on access rights, stored tracking values are removed, account groups become parent accounts, and Field Service moves into Planning. Our Odoo 19 vs Odoo 20 comparison explains the functional side.
Auditing Your Current Version, Modules and Customisations
The audit is the foundation of every Odoo 20 Migration plan. Skip it, and every estimate after it is a guess.
- Version, edition and hosting. Record the exact version, edition, and whether you use Odoo Online, Odoo.sh or your own server.
- Installed apps. Export the full module list and mark each one as standard, third party or custom.
- Customisations. List every custom module, Studio change, automated action and custom report, along with the business process each one supports.
- Integrations. Document every external connection, including payment gateways, electronic invoicing, marketplaces, banks and shipping.
Choosing a Path With a Direct Jump or a Stepwise Upgrade
- Direct jump. For Enterprise databases, the Odoo upgrade service generally handles standard data across several versions in a single request.
- Stepwise upgrade. Community databases typically use OpenUpgrade from the Odoo Community Association, which moves one version at a time.
- Custom code goes straight to the target. Whatever the data path, custom modules are rewritten once for Odoo 20 rather than ported through every intermediate version.
| Starting Version | Support Status | Typical Approach | Main Effort |
|---|---|---|---|
| Odoo 19 | Supported | Direct in a single step | Security and accounting changes |
| Odoo 18 | Supported | Direct for Enterprise data | Two versions of code changes and retraining |
| Odoo 17 | Outside standard support | Direct for Enterprise, stepwise for Community | Code porting, app replacement and data checks |
| Odoo 16 | Outside standard support | Review it like a fresh implementation | Largest code, process and training gap |
Data Cleanup and Migration Scope
Clean before you move, not after
- Archive what you no longer use. Old products, inactive contacts and obsolete price lists slow every test run.
- Merge duplicates. Duplicate contacts and products multiply problems in reports and integrations on the new version.
- Close open items. Reconcile bank statements, clear stuck draft invoices and settle pending stock moves before the final run.
- Review the chart of accounts. Parent accounts replace account groups in Odoo 20, and a tidy chart makes that change far easier.
- Plan any history you bring from outside Odoo. Our guide to moving master and transactional data covers imports from legacy systems that often run alongside an upgrade.
Custom Module and Third Party App Compatibility
Odoo 20 changes that hit custom code hardest
- Access rights. Every module that ships record rules needs its security rewritten and retested.
- Mail tracking. Tracking messages are now generated on the fly, so code reading stored tracking values must change.
- Chart of accounts. Modules and reports built on account groups must move to parent accounts.
- Field Service. Customisations built on field service must be checked against the new Planning structure.
Handling third party apps
- Check that every installed app has a published Odoo 20 version from the same author.
- Where an app is abandoned, find a maintained replacement or rebuild the feature in a custom module.
- Review custom module compatibility module by module, so porting estimates rest on real code rather than guesses.
Environment Setup and Test Migration
- Set up a separate staging environment. Use a staging branch on Odoo.sh or a separate instance that mirrors production.
- Use a recent copy of production. Real volumes and edge cases expose problems that sample data hides.
- Neutralise the copy. Disable outgoing email, scheduled actions, payment providers and electronic invoicing so the test cannot reach customers or tax authorities.
- Install ported modules. Deploy the Odoo 20 versions of custom and third party modules from your code repository.
- Reconcile key figures. Compare trial balance, receivables, payables, stock valuation and open orders between the old and new databases.
- Record timings. The duration of each step becomes your cutover window.
User Acceptance Testing and Training
Make testing about real work
- Write test scripts from daily tasks. Cover quote to cash, procure to pay, manufacture to ship, payroll and the monthly close.
- Assign testers by department. Each team tests its own processes with its own data.
- Test reports and documents. Invoices, delivery slips, GST reports and dashboards must match what users and auditors expect.
- Track issues in one list. Log every defect with an owner, priority and status.
- Get written sign off. Each department head approves before the cutover date is confirmed.
Training that sticks
- Train each role on what changed, using the staging database so users practise with familiar data.
Cutover and Go Live Plan for Your Odoo 20 Migration, With Rollback
Plan the switch and the way back together. For a detailed sequence, see our weekend cutover playbook.
A typical cutover sequence
- Announce a transaction freeze. Tell users when the old system stops accepting entries.
- Take final backups. Back up the production database and file store, and keep them untouched.
- Run the final upgrade. Use the same steps and scripts proven in the last test run.
- Validate the result. Reconcile key balances, open documents and stock, then run a short check in each app.
- Reconnect integrations. Switch on email, payment providers and electronic invoicing one by one, testing each.
- Make the go or stop call. Compare results against criteria agreed in advance.
Rollback plan
- Define the exact conditions that trigger a rollback, such as unbalanced ledgers or a blocking invoicing defect.
- If rollback is needed, reopen the old database, notify users and reschedule after fixing the root cause.
- Never let users enter data in both systems at once.
After Go Live Checklist, Risks, Timeline and Budget
First two weeks after go live
- Monitor logs and slow screens daily, and fix performance issues quickly.
- Check that scheduled actions, email delivery and integrations run as expected.
- Archive the old database securely once the first monthly close is complete.
- Reconcile bank and key accounts at the end of the first week and the first month.
| Migration Profile | Typical Timeline | Biggest Budget Driver |
|---|---|---|
| From 19, mostly standard | 3 to 6 weeks | Testing and training |
| From 18 or 19, moderate customisation | 6 to 12 weeks | Porting custom modules |
| From 16 or 17, heavy customisation | 3 to 6 months | Code porting, app replacement and retraining |
Risks to watch
- Hidden customisations. Studio changes missed in the audit surface late in testing.
- Data quality. Duplicate and inconsistent records produce reconciliation gaps after the upgrade.
- Limited user time. Testing slips when key users cannot step away from daily work.
- Abandoned apps. A single app with no Odoo 20 version can delay the whole project.
Ready to Plan Your Odoo 20 Migration?
Tatvamasi Labs audits your current Odoo setup, ports custom modules, replaces abandoned apps and runs tested upgrades from Odoo 16, 17, 18 and 19 with a clear cutover and rollback plan.
Get a Migration Assessment →
