Odoo UAT for Odoo 19 and 20: Scenarios, Sign-Off and Defect Triage

Most Odoo projects that fail at go-live did not skip testing. They tested the wrong things, with the wrong people, on the wrong data. Our Odoo implementation services treat Odoo UAT as a formal gate with written exit criteria.

This guide is for project owners, finance leads and operations managers preparing for an Odoo 19 or Odoo 20 go-live. It stays focused on testing; for the full project plan, see our Odoo implementation checklist.

What is Odoo UAT and why does it decide go-live?

Odoo UAT (user acceptance testing) is the final test stage, where the people who will use Odoo every day confirm that it supports their real work. It is a business decision, not a technical one.

Earlier tests check that a setting saves or a custom module installs. UAT asks a harder question: can your warehouse lead receive a partial delivery, can your accountant close a month, and can your sales team quote, deliver and invoice without a workaround?

Odoo's own upgrade guide warns that going live without testing can lead to users failing to adjust, business interruptions and poor customer experience. Read the testing section of the Odoo upgrade documentation for its basic checklist.

When should Odoo user acceptance testing start?

Odoo user acceptance testing starts only after configuration is complete, data has been migrated into a test copy and the project team has passed its own system tests. Starting earlier wastes your key users' time on known gaps.

Test stage	Who runs it	What it checks	Exit gate
Configuration testing	Consultant	Each setting, field, report and rule works	All configured items checked
Custom module testing	Developer	Custom code installs and behaves as specified	No failing tests on the module
System integration testing	Consultant and IT	Apps and outside systems pass data correctly	Integrations run end to end
UAT	Key users	Real flows on migrated data, by real roles	Written sign-off
Cutover rehearsal	Whole team	Data load, timings and the go-live runbook	Rehearsal completed on time

In a typical project, UAT takes one to three weeks inside the overall timeline. On our published ranges, a small Odoo project runs 4 to 8 weeks and a mid-size one 8 to 14 weeks, so UAT needs its own protected slot in the plan.

Where should you run Odoo UAT: staging, duplicate or test database?

Run Odoo UAT on a neutralized copy of production with your migrated data, never on the live database and never on demo data. Which copy you use depends on your hosting.

Environment	How you get it	What is switched off	Limits to plan around
Odoo Online duplicate	Duplicate from the database manager	External actions such as emails, payments and delivery orders	Expires after 15 days; five duplicates per database
Odoo.sh staging branch	Staging branch built from production	Scheduled actions, outgoing emails, IAP services, live payments and shipping	Not backed up automatically; deleted after one month
Upgraded test database	Requested on Odoo's upgrade platform	Scheduled actions, mail servers, payment and carrier live mode, bank sync	Request a fresh one before go-live
On-premise copy	Restored backup on a test server	Whatever your team neutralizes	You must disable mail, crons and payments yourself

The Odoo Online database manager guide explains the 15-day expiry and the five-duplicate limit. On Odoo.sh, the staging branch documentation lists what neutralization disables.

Neutralization matters for your scenarios. If scheduled actions are off, a test of automatic reminders or reordering will fail unless you trigger them by hand. Write that into the scenario, or testers will log false defects.

How do you write Odoo UAT test scenarios?

A good Odoo UAT scenario describes one business outcome, step by step, with test data and an expected result that a key user can check without the consultant. Build them from your process maps and your requirements document.

Use this structure for every scenario:

1. ID and flow: for example OTC-04, order-to-cash, partial delivery with backorder.
2. Owner and tester: the process owner who signs it off, and the user who runs it.
3. Preconditions: the customer, product, price list and stock that must exist first.
4. Steps: short actions in Odoo, one per line, in the user's own words.
5. Expected result: the document, quantity, journal entry or report value that should appear.
6. Actual result and evidence: pass or fail, plus a screenshot or record reference.
7. Defect link: the issue ID if it failed, so triage can trace it.

Pull each scenario back to a written requirement. If you never documented requirements, our guide to an ERP requirements document for Odoo shows how to capture them with priorities.

Odoo UAT scenario templates by business flow

Most Odoo UAT plans need 30 to 80 scenarios grouped by end-to-end flow, not by app. The figure is our working estimate for small and mid-size projects; your count depends on scope.

Flow	Example scenario	Pass condition
Order-to-cash	Quote, confirm, partial delivery, invoice, customer payment	Backorder created, invoice matches delivered quantity, payment reconciled
Procure-to-pay	Request for quotation, purchase order, receipt, vendor bill	Bill matches receipt, tax correct, stock valued
Make-to-order	Sales order triggers manufacturing order and component purchase	Bill of materials consumed, finished goods valued correctly
Inventory	Transfer between warehouses, cycle count, scrap	Quantities and valuation agree with the stock report
Record-to-report	Bank reconciliation, accruals, month-end close	Trial balance agrees with the legacy system for the test period
Point of Sale and eCommerce	Store sale, refund, online order through checkout	Session closes cleanly, order and payment reach Odoo
Returns	Customer return, credit note, restock	Credit note posted, stock returned to the right location

Odoo's documentation gives a useful end-to-end example: take one product, compare test and production data, buy it, receive it, sell it, ship it, invoice it and credit the invoice. Extend that pattern to every flow your business runs.

What changes in Odoo UAT for Odoo 20?

Odoo UAT for Odoo 20 needs extra scenarios for integrations, AI features, user roles and changed screens. Whether you start fresh on Odoo 20 or upgrade from Odoo 19, test these areas on purpose.

• Integrations: XML-RPC and JSON-RPC are deprecated in Odoo 20 and their removal is planned for Odoo 22, per the Odoo 20 external API documentation. Test every connector and plan its move to JSON-2.
• AI features: Odoo 20 AI runs on Odoo AI IAP credits, and Odoo.sh staging disables IAP services, so test AI flows deliberately and record what could not run.
• User roles: check that each role, including Light Users, can do its job and cannot see what it should not.
• Changed screens: compare key views, reports and search filters with what users expect.

Our Odoo 20 release notes list changes app by app, which helps you pick scenarios. For integration rework, see our guide to Odoo JSON-2 API migration.

Who should run Odoo testing before go-live?

Odoo testing before go-live should be run by the people who will own each process after go-live, supported by the consultant, never by the consultant alone. A consultant knows how Odoo should work; your staff know how the business actually works.

Pick testers by role, not by availability:

• Process owners: a finance lead, a warehouse lead, a sales lead; they sign off their flows.
• Power users: the people who will train others; they run most scenarios.
• Edge-case holders: the person who handles returns, intercompany or exports.
• A sceptic: someone who liked the old system; they find what others accept too quickly.

Block real calendar time for them. Testers squeezing UAT around a full workload is a common reason defects slip through. Our Odoo change management playbook covers how to free up key users.

How should you triage Odoo UAT defects?

Odoo defect triage means classifying each issue by type first and severity second, then agreeing an owner and a fix date the same day. Many UAT "bugs" are configuration gaps or training needs.

Type	What it means	Typical owner
Bug	Odoo or custom code does not behave as designed	Developer
Configuration	A setting, rule, route or access right is wrong	Consultant
Data	Migrated record is missing or incorrect	Data migration lead
Training gap	Odoo works; the user expected a different way	Trainer or power user
Change request	A new need, not in the agreed scope	Project owner decides

Then rate severity. Our working scale: critical stops a core flow with no workaround; high stops a flow but a workaround exists; medium slows work; low is cosmetic. Hold a 15-minute triage call every UAT day.

Keep change requests out of the go-live path. Log them, estimate them and schedule them after go-live unless the business cannot run without them.

What are good UAT sign-off criteria for Odoo?

UAT sign-off criteria are written conditions, agreed before testing starts, that decide whether Odoo goes live. Agreeing them early stops the go-live debate from turning into opinions.

The criteria we propose to clients, adjusted per project:

1. Every core scenario has been run by its named tester and passed.
2. Zero open critical defects.
3. Every open high defect has a written, tested workaround and a fix date.
4. Migrated balances, stock and open documents reconcile with the legacy system.
5. Every integration has passed an end-to-end test.
6. Each process owner has signed their flows in writing.
7. A cutover rehearsal has run within the planned downtime window.

Sign-off is a named person and a date per flow, not a general "looks good" in a meeting. A partial sign-off with a dated plan for the gaps is better than a vague full one.

Odoo UAT focus by industry

The flows that break at go-live differ by industry, so weight your scenarios toward the costliest failure in your sector. The table shows where we concentrate testing.

Industry	Pain or cost driver	Odoo approach	How iVentureTeam helps
Manufacturing	Wrong costing or component shortages	Test bills of materials, work orders and valuation	Write make-to-order and costing scenarios
Distribution	Stock errors across warehouses	Test routes, barcode and landed costs	Reconcile stock before and after migration
Retail and eCommerce	Lost orders or payment gaps	Test POS sessions, checkout and refunds	Run order-flow tests across channels
Professional services	Missed or wrong billing	Test timesheets, milestones and invoicing	Build billing-rule scenarios
Multi-company groups	Intercompany and consolidation errors	Test intercompany flows and reports	Test each entity's close

Odoo go-live testing checklist for the final week

The final week of an Odoo go-live testing checklist is about repeating, not discovering: rerun key scenarios on fresh data and rehearse the cutover. New defects found that week should be rare.

• Request a fresh test copy or upgraded test database so you test the latest data and code.
• Rerun the critical scenarios and every scenario that failed earlier.
• Rehearse the full cutover, timing each step, and confirm it fits the downtime window.
• Confirm user access, printers, email servers and payment providers for production.
• Freeze configuration changes until go-live.

Odoo recommends fully rehearsing the upgrade the day before upgrading production. After go-live, check what testing cannot fully cover; our guide to Odoo upgrade verification explains the checks that surface at month-end.

Unsure whether your current setup is ready to test? Run the free Odoo health check for a quick view of risk areas.

How iVentureTeam helps with Odoo UAT

iVentureTeam runs Odoo UAT as a structured gate, with scenarios written with your key users and a daily triage rhythm. We have delivered 150+ ERP projects across 35+ countries with 40+ Odoo specialists over 13+ years.

• Scenario sheet: we turn your process maps into numbered scenarios with test data and expected results.
• Environment setup: staging, duplicate or test database prepared with migrated data and neutralization notes.
• Daily triage: every defect classified, rated and owned within a day.
• Upgrade testing: for Odoo 19 to 20 moves, our Odoo migration services include regression testing of custom modules.
• Sign-off and cutover: written exit criteria, a rehearsal and support through go-live.

Odoo UAT case study: EvoLogics

A German subsea technology company moved from Odoo 12 to Odoo 15 Enterprise with testing done before anyone touched production. The project ran for 12 weeks.

EvoLogics carried significant custom business-flow code, and as an operating manufacturer it could not absorb meaningful ERP downtime. Data loss or corruption was unacceptable for its complex product and project records.

We ported the custom code, applied compatibility fixes against the migrated database, and ran end-to-end testing on that database to validate data accuracy and workflow behavior before go-live, including a full regression pass.

Cutover downtime at go-live was under one day, with support through and after go-live. Read the EvoLogics Odoo 15 Enterprise migration case study.

The bottom line on Odoo UAT

Treat Odoo UAT as a written go-live gate run by your own staff on migrated data, with scenarios, daily triage and sign-off criteria agreed before testing starts. That is what separates a calm go-live from a rescue project.

Start with your highest-risk flows, test them in a neutralized copy, sort every issue by type and severity, and do not go live with an open critical defect. The extra week this can cost is far smaller than a failed month-end.

Ready to plan UAT for your Odoo go-live?

Get a UAT scenario sheet and sign-off plan built around your processes. Talk to us about testing your Odoo go-live, call +91-90235-15208, or email business@iventureteam.com.