Planning an Odoo version upgrade
When an upgrade is worth it, how to take stock of your customizations, and how to upgrade without stopping sales for a single day.
Odoo releases a new major version every year, and every release brings a reasonable question from management: do we need to move? Sometimes the answer is yes, urgently. Sometimes it can wait a year. What decides it is rarely the list of new features. It is how long your current version is still supported, and how much custom code sits on top of it.
This guide covers how we decide whether an upgrade is worth it, how we take stock of what has to move, and how we plan the switchover so the company keeps selling throughout.
When an upgrade is worth it
Odoo supports the three most recent major versions. Once your version drops out of that window, it stops receiving bug fixes and security patches from Odoo, and new third-party apps stop being published for it. That date, not the release date of the new version, is your real deadline.
Within that window, an upgrade is worth planning when at least one of these is true:
- Support is ending. Your version will leave the supported window within the next year.
- A feature solves a real problem. Something in the new version replaces a customization you maintain, or a manual workaround your team does every day.
- A legal or tax requirement changed. Localization updates, such as changes to e-invoicing with the Egyptian Tax Authority, are often delivered in recent versions first.
- A third-party app you depend on has moved on. Its vendor no longer publishes fixes for your version.
If none of these applies, waiting is a legitimate decision.
How an Odoo upgrade works
An upgrade is not an installation of the new version followed by a data import. Your existing database is converted, structure and data, to the target version. For Enterprise customers, Odoo’s upgrade service does that conversion for the standard apps, whether you host on Odoo Online, Odoo.sh or your own servers. You can upgrade across several versions in one go; the service handles the intermediate steps.
What the upgrade service does not do is rewrite your own code. Custom modules, whether written by us, by another partner or in-house, must be ported to the new version by a developer, along with any scripts needed to migrate their data. The same goes for apps bought from the Odoo Apps Store: you need the vendor’s release for the target version.
Community users don’t have access to Odoo’s upgrade service. The usual route there is OpenUpgrade, the community-maintained migration project, or a migration carried out by a partner. It works, but it takes more testing time, and you should plan for that.
Take stock of your customizations
The size of an upgrade is set by what sits on top of standard Odoo. Before we estimate anything, we build a full inventory of it. It’s common for a company to believe it has “a few small changes” until the inventory turns up modules nobody remembered installing.
What to list
Go to Apps, remove the default filter, and list everything installed that isn’t a standard Odoo app. For each item, record what it does, who uses it, and who wrote it. Then sort every item into one of the categories below.
| Category | Example | Usual effort |
|---|---|---|
| Configuration | Approval rules, taxes, warehouse routes | Carried by the upgrade; check that it still behaves the same |
| Studio customizations | An added field on the sales order, a modified form view | Usually carried by the upgrade; test every screen that uses them |
| Reports and document layouts | A custom invoice or delivery slip | Often needs adjusting when the standard layout changes |
| Third-party apps | A connector or extra report from the Apps Store | Depends on the vendor publishing a version for the target release |
| Custom modules | A commission calculation or a specific approval workflow | Ported by a developer, with data migration scripts where needed |
| Integrations | E-invoicing, payment gateways, an online store | Retested end to end, and sometimes reworked |
Remove what the new version already covers
Every upgrade is a chance to delete code. Compare each custom module with what the target version does out of the box. If standard Odoo now covers the need, even at 80%, retiring the module is usually cheaper than porting it, and it keeps future upgrades lighter. The same logic as a gap analysis applies: ask whether the process could change before you decide to carry the code forward.
Also look for modules that are installed but no longer used: uninstall them before the upgrade rather than paying to port them.
Test on a copy of your data
The core of a safe upgrade is a test database: a copy of production, upgraded to the target version, that your team uses before anyone touches the real system. Odoo’s upgrade service produces this copy on request. It is neutralized, meaning outgoing emails, scheduled actions and connections to live services are disabled, so testing doesn’t send invoices to customers or documents to the tax authority.
Plan at least two test rounds. The first finds the problems; the second confirms the fixes, on a fresh copy upgraded with the ported modules in place.
Plan the switchover so sales don’t stop
The production upgrade itself runs on your live database, and the system has to be unavailable while it runs. How long depends mostly on the size of the database, which is why the test rounds matter: they tell you the real duration rather than a guess.
Choose the window
Schedule the switchover outside working hours: overnight, or over the weekend if your business is closed. Avoid the last days of the month, the quarter-end close, VAT filing dates and your peak season. Agree the date with sales, the warehouse and finance early.
The day itself
- Freeze changes: no new configuration or development in production from a set date.
- Take a full backup of the database and the filestore, and confirm you can restore it.
- Run the production upgrade and install the ported modules.
- Run a short smoke test: create a quotation, confirm a delivery, post an invoice, send one e-invoice.
- Open the system to users, with key users on hand in each department.
Decide the rollback rule in advance
Write down, before the day, what would make you roll back to the backup and who makes that call. A clear rule, such as “if invoices can’t be posted by a set hour, we restore”, prevents a long night of improvised fixes on a live system.
The first weeks after the upgrade
Expect questions, not because anything broke, but because screens and menus move between versions. Short refresher sessions per role, focused on what changed in each person’s daily work, settle this faster than a general demo of new features.
This is also the moment to agree on who keeps the system current from now on. A support agreement that includes a yearly upgrade review means the next upgrade starts with an inventory that’s already up to date.
If you’d like us to plan your upgrade, see how we handle version upgrades or request an upgrade plan.
Key takeaways
- Your deadline is the end of support for your version, not the release date of the next one.
- Odoo’s upgrade service converts the standard apps for Enterprise customers; custom modules and third-party apps must be ported separately.
- An inventory of every customization sets the real size of the upgrade, and the best customization to upgrade is the one you retire.
- Test at least twice on an upgraded copy of your data, with real processes run by the people who do them.
- Switch over outside working hours, away from month-end, with a backup and a rollback rule agreed in advance.
