This guide covers the two Odoo Version Upgrade methods, realistic timelines by scenario, what drives cost, the three failure points that derail most projects, and how to prepare properly.
Written for Odoo users on an older version evaluating when and how to upgrade. You will leave with a clear picture of scope and effort before you engage anyone, plus a real project example.
Most businesses running an older version of Odoo know they need to upgrade. They put it off, not because the benefits are unclear, but because the scope feels uncertain. How much will this cost? How long will the system be disrupted? What happens to our customisations? These are the right questions, and they rarely get straight answers from vendors who quote before they audit.
An Odoo Version Upgrade is not a software update you schedule on a Tuesday night. It is a project with a defined scope, a timeline, a testing phase, and a go-live plan. Treating it like anything less is the reason most upgrades take twice as long as planned.
- →There are two upgrade paths. You can either carry the existing database forward or start fresh and migrate data selectively. The right choice depends on your customisation depth and data cleanliness, not on which option sounds simpler.
- →A clean instance with minimal customisation upgrades in 3–6 weeks. A heavily customised instance skipping multiple versions takes 8–16 weeks. The custom module count is the single biggest cost driver.
- →Three things consistently derail upgrades. These are custom module breakage, data migration complexity, and underestimated testing. All three are predictable, and none of them need to surprise you.
- →At Tatvamasi Labs, the preparation phase, which includes auditing modules, cleaning data, and defining UAT scope, consistently determines go-live success more than the technical migration itself.
Why Odoo Version Upgrade Is Different From Other Software Updates
An Odoo Version Upgrade is not a patch. Odoo releases a major version roughly every 12–18 months, and each one introduces architectural changes to the core, including new ORM behaviour, restructured modules, modified database schemas, and updated frontend frameworks. What worked cleanly in v17 does not automatically work in v19. Custom modules written for an older version are not forward-compatible by design.
This is not a flaw in Odoo. It is the cost of a platform that genuinely improves with each release. The eCommerce module in v19 is substantially more capable than in v18. The manufacturing module in v19 handles scenarios that required custom code two versions ago. You get real capability gains. But you pay for them through upgrade work, not through a setting toggle.
The practical implication is that every Odoo Version Upgrade has three components that all need to be planned for. These are the technical migration of your database to the new schema, the custom module audit and rewrite for compatibility, and the user acceptance testing of every critical workflow before go-live. Skip or compress any of these and you will pay for it post-launch.
Two Ways to Do an Odoo Version Upgrade and How to Choose Between Them
There are two fundamentally different approaches to an Odoo Version Upgrade, and the choice between them matters more than most vendors communicate upfront. They are not interchangeable. Each suits a different situation, and picking the wrong one adds significant scope.
Database upgrade (carry forward)
Your existing database, including all records, history, and configuration, is migrated to the new version's schema. Everything comes across. Full continuity.
- ✓Full historical data retained
- ✓All configuration carried forward
- ✓Best for large data volumes
- ✗Dirty data migrates with you
- ✗More complex with heavy customisation
Fresh install + data migration
A clean installation of the new version, with data imported selectively from the old system. You choose what comes across.
- ✓Clean starting point with no legacy debt
- ✓Opportunity to reconfigure from scratch
- ✓Better when processes have changed significantly
- ✗Historical data stays in old system
- ✗Re-configuration takes time
The decision framework is straightforward. If your business processes are largely the same as when you first implemented Odoo, your data is reasonably clean, and you have significant transaction history worth preserving, the database upgrade path is almost always right. If your business has changed substantially, your old instance has accumulated years of configuration debt, or you're also switching from Community to Enterprise, a fresh install lets you start clean and import only what you actually need.
⚠️ The mistake we see most often is choosing the fresh install path because it sounds cleaner, then discovering mid-project that five years of inventory valuation history needs to come across after all. Define your data retention requirements before choosing a method, not after.
How Long Does an Odoo Version Upgrade Take?
Timeline is determined by two variables above all others. The first is how many custom modules exist in your current instance, and the second is how many versions you are skipping. Everything else, including data volume, module count, and team availability, is secondary to these two. A clean instance with no custom code can move from any version to the latest in 3–4 weeks. The same jump with fifteen custom modules takes three to four times as long.
← Scroll to see all columns →
| Scenario | Typical timeline | Main driver |
|---|---|---|
| Clean instance, few or no custom modules, 1–2 versions | 3–6 weeks | UAT and data validation |
| Moderate customisation, skipping 2–3 versions | 6–10 weeks | Module rewrite + regression testing |
| Heavy customisation, skipping 3+ versions | 10–16 weeks | Full module audit + rewrite + UAT |
| Any version, fresh install + selective data migration | 6–12 weeks | Data mapping + re-configuration |
One thing these ranges do not capture is the time before the technical work begins. Getting your team to define UAT scenarios, produce a list of every custom module, and agree on data retention requirements can take 1–2 weeks on its own. That preparation time is part of the project whether it is planned for or not. The only question is whether it happens before the clock starts or partway through, when it causes delays.
What Does an Odoo Version Upgrade Cost?
There is no fixed price for an Odoo Version Upgrade, and any vendor who quotes one without an Odoo Consultation and proper audit of your instance first is guessing. The cost is a function of scope, and scope is almost entirely determined by what is in your current codebase. Three factors account for the majority of upgrade cost in every project we've run.
1. Custom module count and complexity
Every custom module needs to be audited against the new version's core, rewritten or refactored for compatibility, and tested independently before it goes into the upgraded instance. A simple module that adds a few computed fields takes a few hours. A module that extends core manufacturing logic or overrides accounting entries can take days. Multiply that across ten or fifteen modules and you have the majority of your upgrade budget.
2. Versions skipped
Jumping from v18 to v19 is not three times the work of a single-version upgrade. It is closer to five times the effort, because architectural changes compound across versions. Each version introduces schema changes, deprecated methods, and new module structures that need to be accounted for. The further you've drifted from the current version, the more of those accumulated changes your upgrade has to bridge in one project.
3. Testing scope
UAT is not a rubber stamp. A properly run upgrade test covers every business-critical workflow in a staging environment identical to production, with real users running real scenarios. The more complex the business, the longer this takes. Businesses that try to compress UAT to save budget routinely discover edge cases post-go-live, at a cost that far exceeds what the testing phase would have been.
Before engaging any partner, produce a list of every custom module in your instance, including its name, what it does, and which core models it extends. That document, combined with your current version and target version, is what a partner needs to give you a fixed-scope estimate. Without it, any quote is a guess.
The Three Things That Derail an Odoo Version Upgrade
Most Odoo Version Upgrade overruns come from the same three places. None of them are unpredictable. They are well-understood risks that become problems only when they are not identified and planned for during scoping.
Custom module breakage
The cost of every shortcut taken during the original build
Custom modules that were built quickly, without documentation, or by developers who didn't follow Odoo's module architecture guidelines are the hardest to upgrade. When a module overrides a core method that no longer exists in the new version, or depends on a database column that was renamed, the rewrite scope expands significantly. This is where the true cost of undocumented marketplace development surfaces, sometimes years after the original build.
The mitigation is a thorough module audit before any upgrade work begins. Every module should be reviewed against the target version's changelog. Modules with high override depth or missing documentation should be flagged before they appear as surprises mid-project. This is also why the guide on Odoo customization vs configuration emphasises that every line of custom code carries a maintenance cost, and upgrade time is when that cost is collected.
Data migration complexity
Years of accumulated data quality issues, surfaced all at once
Odoo's database schema changes meaningfully between major versions. Fields are renamed, models are restructured, relationships between records are handled differently. When your data migrates across these changes, inconsistencies that were harmless in the old schema, such as duplicate partner records, orphaned purchase lines, and products with missing required fields, become hard errors that block the Odoo Migration process. The bigger and older the database, the more of these surface.
The best preparation for this is data cleaning before the upgrade begins, not during it. Running a migration on dirty data means fixing data quality issues under time pressure, against an unfamiliar schema, while the project clock is running. Running it on clean data means the migration either works or surfaces a genuine structural problem, rather than a legacy data hygiene issue dressed up as a technical blocker.
Underestimated testing
The phase everyone shortens and everyone regrets
Testing is where upgrade projects gain or lose the business's confidence. A well-run UAT phase covers every critical workflow, including purchase order to goods receipt, sales order to invoice, manufacturing order to finished goods, and payroll run to payslip, with real users running real scenarios in a staging environment. It identifies edge cases that no developer would have anticipated, such as the specific combination of product category, tax rule, and warehouse that generates a wrong journal entry only visible in month-end reconciliation.
Businesses that compress UAT to hit a go-live date find those edge cases in production instead. The cost of fixing them live, under operational pressure and with real transactions at stake, is always greater than the cost of the testing time that would have caught them. Build UAT time into your project plan as a non-negotiable phase, not as a buffer you'll cut if the development runs long.
How to Prepare for an Odoo Version Upgrade
Preparation is where upgrade success is determined, not during the technical migration. The four steps below are what separate projects that go live on schedule from those that drag on for months.
-
01
Audit every custom module. Produce a documented list of every custom module that records what it does, which core models it extends, who built it, and whether documentation exists. This is the input your upgrade partner needs to give you a fixed-scope estimate, and it surfaces complexity before the project starts.
-
02
Clean your data before the upgrade. Archive unused products, merge duplicate partners, reconcile open transactions, and resolve any records with missing required fields. Data quality issues that are invisible in the current version become hard migration errors in the new one.
-
03
Define UAT scope in writing before development starts. List every critical workflow that must be tested, specifying the name, department, and scenario. This prevents UAT from becoming open-ended, keeps testers focused, and gives the project a clear exit criterion for go-live sign-off.
-
04
Plan go-live for a low-activity period with a rollback path. Schedule the production cutover at a period of lower transaction volume, such as end of month or beginning of a quarter. Maintain the old environment in read-only mode for at least two weeks post-go-live. Having a rollback path available changes the risk profile of going live entirely.
Real Example: Sawin Energy, v17 to v19 in Under 4 Weeks
Sawin Energy, a Hungary-based solar energy company, came to us on Odoo v17 and needed to reach v19, spanning three major versions, without disrupting their sales and project operations. The jump was significant on paper. In practice, it completed in under four weeks.
The reason it moved quickly was preparation, not luck. The main challenge on this project was data migration complexity. Sawin had accumulated several years of solar project records, customer data, and product configurations across their instance. Rather than attempting to carry everything forward and resolving issues mid-migration, we ran a data audit before any technical work began. Records were cleaned, incomplete configurations were resolved, and the migration scope was defined explicitly. This covered what came across, what stayed in the old system, and what was re-entered fresh.
With clean data and a defined scope, the migration itself ran without the data-quality surprises that typically extend these projects. UAT was focused on Sawin's core workflows, including quotation to project creation, project to invoicing, and their solar system configuration process, and completed within the planned window. Go-live was on schedule.
💡 The lesson from Sawin is that a three-version jump does not have to mean a four-month project. The gap between a 4-week upgrade and a 16-week one is almost never technical complexity. It comes down to preparation. Clean data, a scoped migration, and a defined UAT plan turn a daunting version gap into a manageable project.
Need an Odoo Version Upgrade scoped properly?
Tell us your current version and share your custom module list. We will audit the scope and give you a fixed estimate with no guesswork.
Frequently Asked Questions
Prefer a quick chat? WhatsApp our team and we will respond within the hour.
💬 Chat on WhatsApp