Odoo Migration · intermediate · 10 min read
Testing an Odoo Migration
Structured UAT and technical testing for Odoo migrations: scenario scripts, regression scope, integration smoke tests, performance checks, and sign-off gates before cutover.
Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice
Table of contents
Migration testing proves business continuity on the target version: department UAT scenarios, financial reconciliation, integration smoke tests, report samples, and role-based access checks — executed on staging refreshed from realistic data.
Tests should map to inventory items and acceptance criteria from planning. Failed dry runs feed the porting backlog; passed dry runs with signed UAT unlock cutover rehearsal — not the other way around.
Automate repeatable checks where possible (trial balance, open document counts, API health). Reserve human UAT for judgment-heavy workflows and new UI muscle memory.
Teams often confuse a successful database upgrade with a tested migration. Upgrade success means the instance starts; migration success means operations can run the business on the new version.
This article defines testing layers and sign-off gates. Module-level unit tests are covered in the Development pillar; here the focus is programme-level UAT and cutover readiness.
Layer 1 — technical smoke: server starts, modules installed, no traceback on critical menus, cron manageable. Layer 2 — data reconciliation: aggregates match pre-upgrade baselines within defined tolerance. Layer 3 — department UAT: scripted workflows with expected outputs. Layer 4 — integration end-to-end: orders, shipments, invoices, and webhooks with external systems in staging.
Each layer has an owner and pass criteria documented before execution. Skipping layers compresses calendar time but transfers risk to production.
- ▸Smoke test checklist run after every staging -u
- ▸Reconciliation sheet signed by finance
- ▸UAT scripts with tester name and date
- ▸Integration test window with vendor notice
Scenarios are short stories: role, starting data, steps, expected result. Prioritize revenue, compliance, inventory accuracy, and payroll. Include edge cases discovered in past incidents — not only happy paths.
Attach scenarios to module inventory items so gaps trace to porting tickets. When a scenario fails, log reproduction on staging, link the fix PR, and re-run the full scenario — not only the single click that failed.
During stabilization, treat staging as the regression baseline. Any new porting merge or data script requires selective regression plus affected UAT scenarios. Uncontrolled last-minute changes are the leading cause of cutover night surprises.
Version staging database snapshots with Git tags for module releases so testers know which build they validated.
Test critical reports and list views on production-sized data. Migration can change query plans or remove indexes. Compare rough timings to pre-upgrade staging baselines; investigate regressions before go-live.
Optional load smoke — concurrent POS or warehouse sessions — when operational peaks matter. Schedule during agreed windows with monitoring.
Define explicit gates: Dry Run N passed, UAT signed by department heads, integration smoke passed, cutover rehearsal completed. Programme owner records sign-off with date and build reference.
Failed gate means date slip — not silent waivers. Document waivers with business risk acceptance when executives override a failed test.
- ✓Write UAT scripts during planning, not the week before cutover.
- ✓Refresh staging data so testers work with realistic volumes.
- ✓Automate reconciliation; use humans for workflow judgment.
- ✓Re-run full critical scenarios after each major porting merge.
- ✓Treat cutover rehearsal as a test deliverable with timed results.
- !Admin-only testing while warehouse staff never open staging.
- !Validating only new features instead of daily operations.
- !No signed UAT — endless informal feedback loops.
- !Ignoring integration tests until production webhooks fail.
- !Accepting pass when data reconciliations were never run.
Migration testing turns dry-run success into business confidence through layered checks, signed UAT, and hard gates before cutover.
Use the go-live checklist to translate passed tests into an executable cutover night runbook.
Unit / module tests
Critical business logic.
Integration tests
Connectors and jobs.
UAT scripts
Role-based scenarios.
Go-live smoke
First production hour.
- Owners named
- UAT scripts signed
- Rollback documented
- Hypercare roster ready
Frequently asked questions
How many dry runs need UAT?
At minimum, full UAT on the last two successful staging builds before cutover. Earlier dry runs may use subset scenarios to unblock porting.
Who signs off UAT?
Department champions or process owners who run the business — not only IT. Programme owner consolidates sign-offs for go/no-go.
Do automated module tests replace UAT?
No. Module tests catch regressions in code paths; UAT validates that real roles can complete real workflows with real data policies.
Related articles
Planning an Odoo Migration Project
How to plan an Odoo migration: inventory workshops, environments, milestones, RACI, acceptance criteria, and cutover sequencing for business owners and technical leads.
View →Database Migration Best Practices
Practical PostgreSQL and Odoo database migration practice: backups, anonymized copies, migration scripts, performance tuning, and validating data after dry-run upgrades.
View →Odoo Go-Live Checklist
A practical Odoo migration go-live checklist: pre-cutover freezes, backup verification, maintenance runbook steps, smoke tests, integration reopen, and hypercare handoff.
View →Post-Migration Support
How to run Odoo hypercare after go-live: triage rules, staffing models, defect vs training issues, stabilization metrics, and transition to steady-state support.
View →Related services
Need UAT structure stakeholders will actually sign?
We build scenario libraries, reconciliation checks, and sign-off gates tied to your inventory — so go-live means tested, not hoped.
