Most Odoo go-lives that go badly fail for a boring reason: nobody tested the system the way the business actually works. The configuration was reviewed screen by screen, a few demos were given, everyone nodded, and then on the first Monday an order could not be invoiced because the payment term the sales team uses every day was never set up. User acceptance testing, or UAT, is the phase that catches this. It is also the phase most often compressed into a two day formality at the end of a project, right when the budget is thin and everyone wants to be done.
Here is how to run it so it earns its place in the plan.
UAT is not a demo, and not a bug hunt
A demo is the consultant driving. UAT is your people driving, on their own processes, while the consultant watches and takes notes. That difference matters more than it sounds. Someone who built the configuration will unconsciously avoid the paths that break it. Your warehouse supervisor will walk straight into them on the first try.
It is also not system testing. Whether a computed field returns the right total is the implementation team's problem and should be closed before UAT opens. UAT answers a narrower and more important question: can this business run on this system next week?
Write scenarios from processes, not from modules
The most common mistake is a test plan organized as Sales, Inventory, Accounting, each with a checklist of screens to open. Real work crosses modules, and the breakages live at the seams. Write end to end scenarios instead:
- Quotation for a brand new customer, through delivery, invoice, partial payment, and a credit note.
- Purchase request through receipt of a short delivery, then the vendor bill matched against it.
- A month end close on test data: reconciliations, an accrual, the trial balance, the reports finance actually files.
- At least one exception path per process. A canceled order, a returned item, a price override that needs approval, an invoice paid twice.
Cover the transactions that make up most of your volume, plus the exceptions that hurt most when they break. Every scenario should name the role who runs it, the starting data, the steps, and the expected result. If nobody can state the expected result before running the test, the test cannot fail, and a test that cannot fail is not a test.
Test on migrated data, in a separate environment
Demo data is clean, and clean data hides the problems you are about to live with. Duplicate customer records, products missing a unit of measure, historical orders with a discount structure nobody remembers, opening balances that do not tie out. Those only surface when real records meet real processes.
Run UAT against your migrated data in a staging environment that mirrors what production will be, and never in production itself. Confirm before you start that the environment is neutralized: outbound email disabled or redirected, payment gateways in test mode, and nothing transmitting to an external tax or banking portal. A test invoice that reaches a real customer costs more goodwill than the whole UAT phase costs in hours.
Pick testers who will use the system daily
Managers approve the process; staff live in it. A department head signing off after a walkthrough tells you the design looks right, not that the work is possible. Put the people who will enter fifty transactions a day in front of the screens, and give them protected blocks of time to do it. UAT squeezed into the gaps of a normal working day produces a checklist of ticks and no findings.
Log findings in one place, and triage them honestly
One tracker, one format, no findings living in personal WhatsApp threads. Each entry needs the scenario, what happened, what was expected, and a screenshot. Then classify:
- Blocker: the business cannot transact. Fix before go-live, no discussion.
- Major: a workaround exists but it is expensive or error prone. Fix, or accept it in writing with a named owner and a date.
- Minor: cosmetic or low frequency. Batch it for after go-live.
- Change request: the system does what was specified, and someone now wants something different.
That fourth category is where timelines quietly die. It is legitimate, and it is not a defect. Log it, price it, and schedule it separately. Letting change requests enter the project through the UAT tracker is how a four month implementation becomes a seven month one without anyone deciding that it should.
Make sign-off mean something specific
"UAT complete" as a single line in a status report is not sign-off. A useful sign-off is per process, given by the person who owns that process, and it states: every blocker closed and retested, every major either closed or formally accepted with an owner, and every change request moved to a post go-live backlog with a date attached. If the process owner has not personally run the scenario, they are approving someone else's opinion.
Budget for the second round
UAT that finds nothing was not really run. Plan two rounds: the first surfaces the findings, the second confirms the fixes and, just as important, confirms that the fixes broke nothing else. Retesting the repaired scenario alone is not enough, because a change to a pricing rule or an approval flow rarely stays inside its own module.
The teams that go live calmly are almost never the ones with the fewest findings. They are the ones who found their problems in a staging environment three weeks early, with time to decide what to fix and what to live with. If you are planning that phase now, our Odoo implementation service outlines how we structure testing and handover around a go-live date.