An Odoo upgrade is not an update you click through. Moving to Odoo 20 — released on 24 September 2026 — means migrating your database through Odoo's upgrade platform, re-testing every workflow your business depends on, and absorbing real changes in how the system behaves: a stricter bank consistency rule in accounting, access rights rebuilt around domains, XML-RPC deprecated, and the Field Service app folded into Planning. The teams that upgrade well treat it as a small project with phases, owners, and a rollback plan. This checklist is that project, in order. Work through it top to bottom and do not skip the test phase — almost every upgrade horror story is a skipped test phase.
Phase 1: Audit what you have
Before touching the upgrade platform, inventory the database you are actually running. List every installed app, every custom module, and every Studio customisation — fields, views, automated actions, scheduled actions, and server actions — because each one is something the migration must carry or something you must deliberately retire. List every integration: anything connecting over XML-RPC must be flagged in red, because the XML-RPC db service is removed in Odoo 20 and the remaining endpoints are deprecated ahead of removal in Odoo 22 — anything still depending on them belongs on a migration plan to the JSON-2 API. Review your security setup with fresh eyes: record rules no longer exist as a separate concept in 20, replaced by a domain defined on each access right (the ir.access model now merges access control lists and record rules), so every custom record rule needs to be re-expressed as an access-right domain and re-tested with real user accounts. Finally, note the workflows that changed shape in 20 — approved expenses now generate draft bills, Field Service features live in Planning, and accounting's payment statuses are renamed (“In Process” becomes “Paid”; “Paid” becomes “Reconciled”) — and assign each one a business owner who will test it.
Phase 2: Back up, then run a test upgrade
Take a full backup of the production database and verify you can restore it; an untested backup is a hope, not a plan. Then request a test upgrade through the Odoo upgrade platform. Self-hosted and on-premise databases can drive the process from the command line on the machine hosting the database:
python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t 20.0
The same tool with the production command is used later for the real run; an upload form on the upgrade platform is the alternative if you prefer not to use the command line. For Odoo Online databases, the request starts in the database manager: open the database, click Manage, then Upgrade, choose the target version and the email that should receive the upgraded test database link, and confirm — the purpose is set to Test for a first request. When the upgrade completes, read the upgrade report that comes with it: it is attached to the confirmation email and available in the Discuss app for users in the Administration/Settings group, and it summarises what the new version changed in your database. Restore the upgraded dump into a staging environment — never over production — and hand it to the testers. You can request multiple test databases, so plan on at least two rounds: one to find the problems, one to confirm the fixes.
Phase 3: Test like a user, not like an installer
Testing an upgrade means running the business, not checking that pages load. Give each department its real scripts: sales raises a quotation and converts it; the warehouse receives, picks, and delivers; accounting encodes a vendor bill (bill line prediction in 20 will suggest the product, account, tax, and analytic distribution from history — confirm the suggestions are sane on your data); finance reconciles the bank under the new rules. The bank consistency rule deserves its own test block: in Odoo 20, every journal entry affecting a bank account must originate from a bank transaction, so any habit of posting manual entries directly to a bank account is now blocked by design — find every place your team does it and agree the new way of working before go-live. Test permissions by logging in as the restricted roles, not as admin, because access-right domains behave differently from the old record rules. Test the edge cases that only happen monthly or quarterly — payroll, month-end closing, tax reports, landed costs — because those are the failures that surface three weeks after everyone has relaxed. Log every discrepancy, however small, and report upgrade defects through Odoo's support with the upgrade-specific issue category so they reach the right team.
Phase 4: Fix, configure, and retrain
Work the discrepancy list to zero or to a documented workaround. Fix custom code against 20's technical changes: the frontend is now OWL 3, push notifications moved from Firebase to Odoo's own service, and module translation files now live with the modules themselves. Configure the new things you intend to use rather than letting them surprise people: the new reconciliation flow and its summary report, parent accounts (which replace account groups in the chart of accounts, with account codes now optional), and — if you plan to use them — AI agents, remembering that all AI features consume IAP credits that no plan includes, so someone must own that budget. Rewrite the affected standard operating procedures, especially for expenses (now draft bills), field service work (now in Planning), and bank reconciliation. Train in the upgraded test database, not on slides: people remember what their hands have done.
The checklist at a glance
| Phase | Key tasks | Done when |
|---|---|---|
| 1. Audit | Inventory apps, custom modules, and Studio changes; list integrations and flag XML-RPC; document custom record rules; assign a business owner per workflow | A written inventory exists and every customisation has an owner |
| 2. Backup & test upgrade | Full backup with a restore test; request a test upgrade via the upgrade platform or database manager; read the upgrade report; restore the upgraded dump to staging | An upgraded copy of your real database is running in staging |
| 3. Functional testing | Run department scripts end to end; dedicated test block for bank consistency and reconciliation; test restricted user roles; cover monthly and quarterly processes | Every discrepancy is logged; no critical workflow is untested |
| 4. Fix & retrain | Fix custom code (OWL 3, access-right domains); configure parent accounts and the new reconciliation flow; budget IAP credits if using AI; update SOPs and train users in the test database | A second test upgrade confirms the fixes; users have practised the new workflows |
| 5. Production cutover | Freeze changes; take a fresh production dump; submit it with the Production purpose promptly after the final test upgrade; restore the upgraded database and reconfigure Odoo to use it; smoke-test | Production runs on Odoo 20 and core transactions post correctly |
| 6. Post-go-live | Verify opening balances and bank feeds; check scheduled actions and automated actions fire; monitor IAP credit use if AI is enabled; hold a two-week hypercare window | Two clean weeks with no severity-one issues open |
Phase 5: Production cutover
Choose a quiet window — a weekend outside month-end — and freeze changes to production configuration and custom code. Take a fresh dump of the production database and submit it to the upgrade platform with the purpose set to Production; the platform's guidance is to proceed with the production upgrade within about three days of the successful test upgrade, while the test results still describe the database you actually have. When the upgraded dump comes back, restore it, point your Odoo instance at the upgraded database, and run a short smoke test before releasing users: log in, open the main apps, post one invoice, one payment, and one stock move. Keep the pre-upgrade backup untouched and labelled — restoring it is your rollback, and it stays viable only until new transactions in 20 make going back meaningless, which is exactly why the smoke test happens before general release, not after.
Phase 6: The two weeks after
Hypercare is part of the upgrade, not an optional extra. Verify that opening balances tie to the old system's closing balances and that the balance sheet shows the new auditable Cumulative Translation Adjustment line correctly if you run multi-currency. Confirm bank synchronisation is flowing and the first real reconciliation matches the summary report. Watch scheduled actions and automated actions for the first cycles — including any that now call AI agents — and confirm digest emails and reports arrive. Keep the discrepancy log open for two weeks, triage daily for the first few days, and only then close the project. An upgrade that ends with a verified bank, correct balances, and users who have practised the new flows is a boring upgrade — and boring is the goal.
