A practical checklist for evaluating an Odoo 19.4 upgrade

Problem

Release notes answer “what did Odoo publish,” not “is this database ready.” In 19.4, the risk is not limited to new screens: access rights, field-update ordering, cache, HTTP, accounting matching, inventory, and manufacturing flows all create regression scope. [U1] [U4]

The upgrade path also depends on hosting. Odoo Online follows a rolling-release process, while Odoo.sh and on-premise environments have different code and scheduling mechanics. The checklist must therefore begin with the real system fingerprint, not the Upgrade button.

Evidence required

Odoo’s process calls for obtaining an upgraded test database, testing it thoroughly, resolving issues, and only then scheduling production. Test databases are neutralized: scheduled actions, outgoing mail, bank synchronization, and some providers are disabled or placed in test mode. The absence of a side effect is therefore not proof that the production flow is correct. [U2]

For custom modules, Odoo recommends freezing development, comparing custom features with the new standard capabilities, making modules work on an empty target-version database, and then testing and rehearsing on an upgraded database. Successful installation does not prove runtime behavior. [U3]

Ten-step checklist

1. Capture the fingerprint: hosting, edition, current version, installed apps and localizations, Studio, custom modules, integrations, cron jobs, mail, payment, carriers, and user groups.
2. Build the version delta: classify each relevant 19.4 release-note item as new, available from older version, relevant, not installed, or needs live verification. Do not turn the whole page into test scope.
3. Challenge duplicate custom code: identify custom logic that 19.4 may replace. Remove it only after the standard flow passes the same acceptance criteria.
4. Create the right environment: request the upgraded test database appropriate to the hosting type; for custom modules, first prove installation and execution on an empty target database.
5. Restore representative test data: for flows that need a filestore, attachments, or documents, confirm that the test copy has the corresponding data. Record every neutralized feature separately.
6. Run security regression: test regular users, managers, multi-company users, and portal users. Pay particular attention to domains and access because 19.4 merges ACLs and record rules in ir.access. [U4]
7. Run business flows: at minimum quotation → sale → delivery → invoice → payment; purchase → receipt → bill → reconciliation; inventory count and valuation; MO, BoM, work order, and traceability; plus website forms and checkout when installed.
8. Run technical regression: custom views, reports, email templates, computed fields, automated and server actions, exports, EDI/API, webhooks, and background jobs. Compare outputs; do not settle for “no traceback.”
9. Rehearse cutover: measure downtime, freeze window, backup, code/database deployment order, smoke tests, decision owner, and stop conditions. Request a fresh test upgrade if the project runs for long enough to drift.
10. Go live only with evidence: each critical flow has an expected result, actual result, approver, and linked log or screenshot; every high-risk issue is closed or explicitly accepted in writing.

Stop criteria

Stop the go-live if data-level permissions are unverified; a custom module only installs but has not completed its flows; accounting or valuation results differ without explanation; integrations have not run as their real service user; or the rehearsal has not demonstrated timing and recovery order.

Limit

This checklist does not certify a database as compatible with 19.4 and does not replace Odoo’s upgrade report. Only runtime testing against a copy of the system’s own data can confirm fields, permissions, custom code, and business outcomes. Release-note and changelog entries define test scope; they are not pass evidence.