Odoo moves your data. We move your system.

We have just upgraded a large manufacturing company from Odoo 19 Enterprise to Odoo 20. Accounting, stock, manufacturing, purchasing, sales, HR, a website and a set of integrations, all in one database the business runs on every day. Moving the data was the smaller part of the job. The larger part was making sure that on the first morning on Odoo 20, every person in the company could do exactly what they did the evening before, and nothing they should not.

That is the line we draw for every upgrade: Odoo moves your data, we move your system. Your modules, your settings and the way your people work, with proof that it all works the same.

What this upgrade involved

• 55 custom modules ported to Odoo 20 and installed on a test database before anything else.
• About 670,000 rows across roughly 600 data models carried over and proven equal to the original, model by model.
• About 20,000 attached files, from scanned documents to technical drawings, moved and checked.
• Every user account checked again on the new version: what each person sees, can change and can print.

None of these numbers come from a feeling that it went well. Each one is the result of a comparison between the old system and the new one.

Two ways to carry the data

There are two sound ways to bring a database to a new major version, and we use whichever fits the case.

The official Odoo upgrade service. When it covers your versions and your Enterprise subscription entitles you to it, Odoo's own service converts the database. It is the path Odoo maintains, and when it applies, we use it.

A full-history transfer into a new database. When the official path is not available, the data still has to move: on Community, on a version the official service does not handle yet, or when a company wants to start the new version on a clean database without years of leftover settings. Then we build a fresh Odoo 20 and carry the full history into it, not just the master data: accounting entries with their reconciliations, document numbering that continues where it stopped, stock and its valuation, manufacturing orders, the chatter on every record, attached files, and user accounts that keep their passwords. On the first morning nobody has to reset a password, and the next invoice gets the next number.

Either way, the data is only the beginning.

What an upgrade service does not do

An upgrade service converts a database. It does not know how your company uses it. Five things sit outside it, and on a real system they decide whether the upgrade succeeds:

• Custom modules. Every module written for your company has to be ported to the new version and installed on a test database. Odoo 20 changes the access model, so a module that installed fine on 19 may not install on 20 at all.
• Studio and database customizations. Fields, views and automations clicked together over the years live in the database, not in any module. They have to be found, carried across and checked.
• A test environment next to production. The new version runs on a copy of your real data while the old one keeps working, so people can try it without risk.
• Proof that the new system behaves like the old one. The same access for every user, the same settings, the same menus, the same reports.
• A go-live plan with a way back. A rehearsed switch, a known duration, and the old system kept ready until the new one has proven itself.

Test as real users, not as the administrator

The most useful lesson from this upgrade: a data check can pass while a screen fails. Row counts matched, balances matched, and some screens still would not open for an ordinary user. As administrator everything looked fine, because the administrator skips most of the rules ordinary users work under.

So we test the way people work. For each user we log in as that person, on the old version and on the new one, and compare what they get: the records in every list, the menus, the reports they can print, the actions they can take. Every difference is explained or fixed before go-live.

This caught the biggest change in Odoo 20 for any company with restricted roles. In 20, access rights granted by several groups add up. A salesperson who also belonged to a warehouse group suddenly saw, and could edit, every sales order in the company instead of their own. Nothing failed, no error appeared, and a data comparison would never show it. Testing as that salesperson showed it at once, and the new system now gives every person exactly the access they had on 19.

Small conventions, real consequences

Some differences live in conventions rather than features. Two examples from this upgrade:

• Exchange rate dates. The rates stored on 19 followed one dating convention, and Odoo 20 reads them with another. Carried over as they were, an invoice in a foreign currency would have used the rate of the previous working day, and for VAT the rate of the right day matters. We aligned the rates, so every invoice converts exactly as it did before.
• Numbering continuity. Invoices, orders, deliveries and manufacturing orders each have their own numbering. Every sequence continues from the last number used on 19, with no gaps and no duplicates.

The old system, running next to the new one

To prove continuity you need something to compare against. During this upgrade the old version ran next to the new one, on the same copy of the data, so every question had a measured answer: does this person see the same orders, does this report give the same totals, does this price list return the same price. When the answer was no, we found out why before anyone else noticed.

The result was a new system that matched the old one for every user checked: the same records, the same menus, the same operations allowed. Where Odoo 20 has a built-in way to get the behaviour of 19, we used it, and wrote custom code only where 20 has no equivalent.

Go-live with a way back

The final move is never the first attempt. The whole transfer was rehearsed on fresh copies of production until it ran cleanly and its duration was known. Production stays untouched until the switch, and after it the old system stays available as the way back. Scheduled jobs and outgoing integrations are switched on deliberately, once the new system is confirmed, so nothing sends a message or a document twice.

Checklist for a major Odoo upgrade

• Choose the data path: the official upgrade service if it covers your versions and your subscription, a full-history transfer otherwise.
• List every custom module and every Studio change. Port them and install them on a test database.
• Run the new version on a copy of real data, next to the old one.
• Compare the data model by model, including balances, stock and document numbering.
• Log in as real users on both versions and compare access, menus, reports and settings.
• Check conventions that changed between versions, such as exchange rate dates.
• Rehearse the switch, time it, and keep the old system as the way back.

For what changes in Odoo 20 itself (server requirements, API keys, the new access model, printing), read Odoo 20: what really changes before you move.

FAQ

Odoo will offer the upgrade. Why would I need anything else?

Odoo's upgrade service converts your database, and when it covers your case it is the right tool for the data. It does not port your custom modules, check your Studio changes, set up a test environment, prove that every user keeps the same access or plan the switch. That part is what makes the upgrade invisible to the people who use the system every day.

Can a Community database move to a new major version?

Yes. Odoo's upgrade service is part of the Enterprise subscription. A Community database moves through the community upgrade scripts where they exist for that version, or, as for 19 to 20, with a full-history transfer into a new database. Either way it is then compared with the original in the same way.

Will people need new passwords or lose their history?

No. Users keep their passwords, and records keep their chatter, attachments and numbering. The first morning on the new version should feel like any other morning.

The upgrade path, from the first assessment to the final comparison, is part of Zoxron MCP, so an AI agent can walk it with you on your own server. If you would rather have it done for you, talk to us.