Upgrade or migrate? A decision framework for moving Odoo versions
"Upgrade" and "migrate" are not the same project. One carries everything forward; the other is a fresh build that brings your data along. Here is how we decide which one a business actually needs.
Teams use “upgrade” and “migrate” interchangeably, but they describe two very different engagements. Choosing the wrong one is how a six-week project turns into a six-month one — or how a clean opportunity to shed years of accumulated mess gets thrown away.
The two paths, defined
- Upgrade — carry the existing database and its customizations forward to a newer major version. Same data, same modules, same configuration, adjusted to run on the new release. The goal is continuity.
- Migrate (re-implement) — stand up a fresh database on the target version, rebuild the configuration deliberately, and bring across only the data that still earns its place. The goal is a clean start with history preserved where it matters.
Both end with you on a newer version. What differs is how much of your past comes with you.
When an upgrade is the right call
- Your configuration is sound and your team is happy with how Odoo is set up today.
- Customizations are documented, maintained, and still needed.
- You are one to three majors behind and the data is healthy.
- You need to minimize change-management — the business cannot absorb a re-training cycle right now.
In this case, an in-place Odoo upgrade is faster, cheaper, and lower-risk than rebuilding.
When a re-implementation wins
- The current setup is the problem: workarounds on workarounds, abandoned modules, fields nobody can explain.
- You have dozens of custom modules and only a handful are still used.
- You are five or more majors behind — the cumulative breaking changes make a straight upgrade nearly as much work as a rebuild.
- The business has changed shape (new entities, new processes) and the old model no longer fits.
Here, dragging the mess forward costs you twice. A re-implementation lets you keep the data and drop the debt.
The questions we ask first
- How many custom modules exist, and how many are actually used this quarter?
- When did anyone last read the manifest files?
- How many majors behind are you, and is anything in the path a known breaking jump?
- Can the business absorb re-training now, or is continuity the priority?
- What history is legally or operationally required — and what can be archived instead of migrated?
The answers usually point clearly one way. When they don’t, we run a short discovery and a test migration to settle it with evidence rather than opinion.
A middle path
Sometimes the answer is “upgrade now, clean up later” — get onto a supported version quickly, then retire dead customizations in a follow-up. The version compatibility matrix helps you see how far the jump really is before you commit.
Not sure which path fits? The project estimator walks you through the same questions we do and gives you a complexity read in a few minutes.