How to test an Odoo migration before the cutover

In a thread on Odoo’s official forum, a company that had migrated from 17 to 19 in production got an answer that sums up this post: it is not possible to go back to the previous version. After the cutover, a version migration has no undo.

So testing comes first: Odoo itself recommends running the upgrade on a copy before production. Below is the roadmap I would follow.

Start with a copy, never with production

The first test runs on a full copy of the database, and full means database and files. I insist on the files because Odoo stores attachments, invoice PDFs and images in the filestore, outside the database, and it is common to migrate one and forget the other. In a report on Odoo’s forum, a company had 1.5 GB of files on version 14 and got back 44 MB after the migration.

What to check on the migrated copy

Seeing the system open proves nothing. Check item by item:

• Files and attachments. Does the filestore size match the original? Do the PDFs of old orders and invoices open?
• Reports and document templates. Do the order, the invoice and the printed invoice come out with the fields your company customized?
• Studio customizations. Are the fields and views created in Studio still there and working?
• Fiscal. Issue invoices in the tax authority’s test environment, check the taxes on real orders and see whether the tax filings close. In Brazil, with NF-e and SPED, this is the part that cannot fail.
• Integrations. Everything that talks to Odoo, from banks to e-commerce, needs to be tested against the new version.
• Volume. Count customers, products, invoices and journal entries before and after. The numbers have to match.

Run more than one rehearsal

The first rehearsal shows what breaks, and you fix it. The second, on a fresh copy of production, confirms the fixes work and measures how long the migration really takes. That measured time defines the downtime window on cutover day.

The cutover is a planned event

On the day, operations stop for a few hours. Decide beforehand: the window, ideally outside peak hours; the moment after which nobody enters anything in the old version; the backup, taken right before; and the acceptance criteria, meaning what has to be working for the migration to count as done. At KMEE, this acceptance is explicit and documented with the client during user acceptance testing.

One item is missing, the one most often forgotten: who decides to roll back to the backup if something critical fails. Since the migration can’t be undone, rolling back means restoring the backup of the old version. That decision has to be agreed beforehand, not in the middle of the night during the cutover.

Next post

Testing well has a cost, and this is where many people get scared by the budget. The last post in the series is about how much it really costs to migrate an Odoo.

KMEE’s free migration assessment hands back a plan with these steps already laid out for your database.