An Odoo upgrade is not complete until the business can process an order, approve an expense, receive stock, close a period, and trust the resulting numbers. This Odoo 20 upgrade checklist helps teams assess business readiness before moving production, with evidence for data, custom modules, integrations, and user acceptance.
A demonstration database cannot expose every risk in a system containing years of transactions, customized approvals, scheduled jobs, and external connections. Use this checklist as your go-live acceptance framework. For the technical migration sequence, see our Odoo 20 upgrade guide.
1. Confirm the upgrade route and project scope
Record your current Odoo version, edition, hosting model, database size, active companies, installed applications, and third-party add-ons. Confirm that Odoo 20 is an available upgrade target for your particular database before committing to a production date. A released version does not establish eligibility for every environment.
Use the upgrade workflow for Odoo Online, Odoo.sh, or your on-premise deployment. Check service eligibility and contract coverage separately; do not assume Enterprise upgrade services apply to a Community database. Changing hosting or edition also requires separate planning.
Give each module an owner and a decision: retain, replace, redevelop, retire, or investigate. Include apparently unused modules; their fields, permissions, or dependencies may still affect the database.
Your scope record should cover:
- Business applications and processes that cannot tolerate interruption.
- Custom modules, Studio changes, reports, automated actions, and security rules.
- Payment, shipping, payroll, storefront, and reporting integrations.
- Accounting history, attachments, employee records, and data volumes.
Resolve newly discovered requirements through written change control, including any effect on scope, cost, and timing. Avoid treating an overlooked dependency as an unexplained invoice item.
2. Validate custom modules against Odoo 20
Separate configuration from custom code. Taxes, approvals, templates, and Studio changes need functional review; Python modules, controllers, views, and frontend assets also need compatibility work. Installing a module successfully is only the first check.
Odoo's customized-database upgrade guidance recommends making custom modules work on an empty target-version database before testing them against upgraded production data. This separates framework compatibility problems from historical data and configuration issues.
Review manifests, dependencies, access rules, reports, and business logic. Where models, fields, or identifiers change, use appropriate upgrade scripts to preserve their data. Test that the resulting module still enforces approvals, company boundaries, and financial or stock controls.
Consider replacing custom code where standard functionality now meets the requirement. Obtain process-owner approval before retiring behavior people depend on. Our custom Odoo module upgrade guide covers this work in more detail.
3. Rehearse with a recoverable production copy
Start from a verified backup and an isolated test environment. Record the backup timestamp, code revision, configuration, migration steps, and errors. Turn necessary corrections into repeatable scripts or documented steps instead of accumulating undocumented staging edits.
Attachments matter. For on-premise upgrades through Odoo's upgrade service, the returned database does not contain the original production filestore. Follow the documented procedure for combining the returned files with the matching production filestore before validating documents and images.
Rehearse again from a fresh production copy before cutover. Measure the complete window, including transfer, restoration, module updates, reconciliation, and business checks. Migration processing time alone is not a reliable downtime estimate.
4. Test integrations without triggering production actions
Odoo neutralizes upgraded test databases: scheduled actions and outgoing mail are disabled, payment and delivery providers switch to test settings, and bank synchronization is disabled. Consequently, a successful staging session does not establish that these connections work.
Inventory custom webhooks, queue workers, and external middleware separately. Confirm they cannot charge customers, book shipments, or send notifications. Re-enable selected flows only with controlled test credentials, recipients, and endpoints.
For a storefront order, test customer creation, taxes, stock reservation, invoicing, fulfillment, and status updates. Then exercise duplicate events, timeouts, invalid payloads, revoked credentials, and retries. A successful HTTP response is insufficient: confirm the correct business result and no duplicate transaction.
For Odoo 20 specifically, inspect legacy RPC usage. Odoo's external RPC documentation says the db service is removed in version 20, while common and object are scheduled for removal in version 22. Custom JSON-RPC controllers are outside that deprecation notice. Inventory actual endpoints before planning replacements.
5. Reconcile business data, not just record counts
Ask each department which totals and records prove continuity. Compare equivalent reports with matching company, currency, date range, and posting-state filters. Investigate differences before accepting them as harmless version changes.
Finance should review trial balances, receivables, payables, taxes, posted entries, and bank reconciliation status. Inventory should compare quantities, reservations, valuation, lots, serial numbers, and open transfers. Sales and service teams should check prices, active contracts, quotations, tickets, and attachments.
Record counts can flag omissions, but matching counts do not prove that relationships, approval states, or custom values survived. Combine targeted record comparisons with reconciliation of critical totals. Record expected differences, their causes, and the owner's acceptance.
Keep archival or retention changes separate from the upgrade unless explicitly scoped. Moving historical records elsewhere introduces additional validation requirements and should not become an improvised solution during downtime.
6. Obtain user acceptance and performance evidence
Give business owners end-to-end scenarios with expected outcomes. A warehouse lead can receive stock, assign a lot, complete a partial delivery, and process a return. Finance can invoice, receive payment, reconcile, and verify reports. Managers should test approvals using their actual permission boundaries.
Every test needs an owner, input data, expected result, actual result, evidence, and defect status. Include ordinary users as well as administrators; administrator access can conceal missing permissions. Test relevant company boundaries and restricted records.
Use realistic volumes for order confirmation, stock reservation, imports, scheduled jobs, and reporting. Agree acceptable response times and batch completion windows. A small demonstration dataset cannot establish performance on production-scale history.
Require written acceptance from accountable process owners. Unresolved critical defects should block go-live; enhancement requests belong in a separately prioritized backlog.
Capture evidence against the exact build being approved. If developers change a relevant module afterward, repeat the affected scenarios before sign-off. Otherwise, an approved test result may describe software that will never reach production.
7. Define cutover and recovery by hosting model
Create a timed runbook covering the final backup, transaction freeze, integration pause, responsibilities, validation, communications, and go/no-go authority. Prevent writes to the old database after the upgrade snapshot; those changes do not automatically appear in the upgraded system.
Recovery is hosting-specific. Odoo's production upgrade documentation warns that an Odoo Online upgrade cannot be reverted after completion. Odoo.sh automatically reverts a failed upgrade process; that is different from undoing business transactions after a successful go-live.
For self-managed hosting, rehearse restoration of the old application, database, and matching filestore. Define how transactions created after reopening would be handled. A backup alone does not provide lossless rollback.
8. Use a written go/no-go gate
Before authorizing production, require evidence that:
- The available upgrade route and required modules are confirmed.
- Critical business workflows pass with appropriate user permissions.
- Financial and inventory differences are resolved or accepted.
- Integrations handle failures and retries without duplicate records.
- The rehearsal fits the agreed downtime window.
- Recovery limits, decision owners, and support coverage are understood.
After launch, monitor errors, queues, scheduled jobs, integration activity, and key reports. Assign responders for a defined hypercare period and distinguish defects from new requirements. Recheck the first complete operational and reporting cycles before closing the project.
Odoo 20 upgrade checklist: common questions
How long should an Odoo 20 upgrade take?
There is no reliable universal duration. Database size, customizations, integrations, defects, and business testing affect the project. Estimate production downtime from a measured rehearsal, then include validation time and a contingency allowance.
Does a successful test upgrade guarantee production readiness?
No. It shows that a particular snapshot completed that process. You still need accepted workflows, reconciled data, integration evidence, and a repeatable runbook for the final production snapshot.
What should stop the go-live decision?
Unexplained accounting differences, duplicate transactions, blocked warehouse operations, or incorrect permissions are examples. Define critical blockers with business owners beforehand. Do not let schedule pressure replace the acceptance criteria agreed during planning.
An Odoo 20 upgrade is ready when those checks produce evidence. If you need help defining that evidence, explore Octivex's Odoo services and build an acceptance plan around your real business workflows.