How This Calculator Works
An Odoo upgrade isn\'t a data migration: the model stays the same, but every intermediate version between your source and your target ships its own breaking changes. Odoo 12 to 13 was the accounting refactor; 14 to 15 was the OWL 2 transition; 15 to 16 was the modern JavaScript API; 16 to 17 was the new web client. Each jump has to be absorbed by your custom code and your OCA modules, one at a time.
The calculator turns that reality into a simple formula: 50 base hours plus 40 hours per version jump. An Odoo 16 to 17 upgrade therefore starts around 90 hours; an Odoo 8 to 19 upgrade starts at 490 hours. That base is then multiplied by four levers: how many custom modules need refactoring, OCA usage, database size, and your downtime tolerance. The output is converted to USD at a blended $175/hr rate that reflects a typical upgrade team: senior Python dev, Odoo DevOps engineer, and functional QA.
The low band sits at 80% of the midpoint (clean modules, well-tested code, internal team available), the high band at 130% (deep refactor, abandoned OCA modules to take over, near-zero-downtime blue-green cutover). Like our implementation calculator, we model a 30% upside rather than 20%, because that's where most projects actually land.
The Real Cost Drivers Behind an Upgrade
Across 80+ Odoo upgrades Octura has executed, one pattern repeats: the difficulty almost never comes from Odoo's core code. The difficulty is everything you have added around it. Here are the four levers that move the invoice.
Version Delta: The Accumulated Debt of Skipped Jumps
The longer you've waited, the bigger the debt. A single-version upgrade (n to n+1) absorbs one set of breaking changes. Skipping three versions (n to n+3) absorbs three sets stacked, because every intermediate migration has to be replayed, either module by module with OpenUpgrade, or in one bulk script that bundles every intermediate version's patches. The second path is faster but it flattens your code history into one giant commit, which makes regressions harder to isolate later.
Custom Modules: The Per-Module Refactor Cost
Every custom module has to be audited against the target version: new ORM hooks, deprecated APIs, view changes, test refactors. A simple module (10 models, few views, no JS) takes 8 to 15 hours per version jump to port. A complex module (multiple inheritance, JS view inheritance, overrides of critical methods) takes 30 to 60 hours per jump. The calculator multipliers (0.6x for 0 modules, up to 2.4x for 10+ modules) reflect both the per-module cost and the coordination cost when several custom modules touch each other.
OCA Modules: The Maintenance Nobody Quoted
OCA modules are free, they are not cost-free. For every upgrade, every installed OCA module has to be vetted: does the target-version branch exist, is it maintained, is it compatible with the other OCA modules you have installed, does it play with your customizations? When an OCA module hasn't been ported to your target version, you have three choices: wait for the community to do it (can be slow), port it yourself (and own its maintenance afterwards), or retire it and rebuild the functionality in your own module. The OCA multiplier climbs to 1.6x for heavy deployments because these decisions have to be made module by module.
Database Size: The Cutover Window
Odoo's migration script has to load every record, rewrite it under the new schema, and write it back. On a 5 GB database that takes an hour. On 500 GB it takes an overnight. Past 500 GB, you switch to incremental mode with staging, where the script runs against a production copy for days, then only the last day's deltas are replayed during the cutover window. The multiplier climbs to 2.0x for the "huge" bucket because incremental mode demands its own pipeline and its own monitoring.
Downtime Tolerance: The Cost of Zero-Downtime
A weekend upgrade with 24 hours of downtime is by far the cheapest, because you switch cold: stop production, run the migration script against live data, test, bring it back up. A 4 to 12 hour overnight window demands a more rigorous dry run, because there is no slack if something slips. A near-zero window (under 2 hours) demands a blue-green cutover: stand up the new version in parallel, sync writes via replication or logs, flip the router in one shot. The 1.7x multiplier covers the extra infrastructure (two production environments) and the additional QA rounds on the cutover mechanism itself.
Typical Upgrade Scenarios
Four anonymized projects from the 2024-2026 Octura archive, with the actual ranges and lived timelines.
Scenario 1: Odoo 16 to 17, Internal Dev Team, $7K to $10K
A tech SMB running Odoo 16 for a year, internal Python team, 2 small custom modules, no OCA. 3 GB DB, weekend OK. The version delta is small (16 to 17), all multipliers at the floor. Total billed: $8,200 for support and validation; the client ported the 2 modules themselves. Duration: 3 weeks including 2 spent waiting on client side.
Scenario 2: Odoo 13 to 17, Distributor, $28K to $42K
A multi-warehouse distributor in Vermont, Odoo 13 for 4 years, 6 custom modules (approval workflows, in-house Shopify integration, BI reports), 8 OCA modules (account_financial_report, web_responsive, etc.). 18 GB DB, overnight window accepted. Four cumulative version jumps including the accounting refactor at 13 to 14. Total billed: $34,600 across 9 weeks. Hypercare: 2 weeks included.
Scenario 3: Odoo 10 to 18, Manufacturer, $55K to $80K
A manufacturer in the Beauce region, Odoo 10 for 7 years, 8 custom modules including a critical extended MRP module, 12 OCA modules. 80 GB DB. Overnight window. Eight cumulative version jumps. The complexity came from the MRP module: 240 hours to port through 8 versions, because the ORM hooks used in v10 no longer existed in v18 and had to be rewritten via the new model-inheritance API. Total billed: $67,400 across 14 weeks. Extended hypercare: 4 weeks.
Scenario 4: Odoo 8 to 19, Zero-Downtime E-commerce, $90K to $140K
An online retailer, Odoo 8 for 11 years, 11 custom modules (custom cart, in-house payment integration, promotions engine, etc.), 14 OCA modules. 320 GB DB. Near-zero tolerance (under 2 hours) because the store sells 24/7. Eleven version jumps, blue-green cutover mandatory. We stood up Odoo 19 in parallel for two months, synced via WAL replication plus an in-house event bus, then flipped the HTTP router in 18 minutes at 3 AM on a Tuesday. Total billed: $112,800 across 18 weeks. Peak team: 4 people.
What This Calculator Does Not Cover
If you're migrating from QuickBooks, NetSuite, SAP, or any other non-Odoo system, use the Odoo migration cost calculator. The cost profile is very different there: the data-model gap between your system and Odoo becomes the dominant lever, not the version delta.
New features. If you want the upgrade to be the moment you activate new Odoo modules or redesign workflows, that work is implementation, not upgrade. Use the implementation cost calculator for that delta.
Odoo license subscription. You pay Odoo S.A. directly, per user per month. A version upgrade doesn't change your license bill unless you also change plan.
Hosting. Moving to Odoo.sh or changing your self-hosted instance is not an upgrade cost, it's an infrastructure cost billed separately.
Training on the new UI. A major jump (v15 to v17 for example) ships a new web client; we include one hour of rapid training per role during hypercare. In-depth training is billed separately.
Next Steps After Your Estimate
The next step is a 30-minute upgrade audit call with one of our senior Odoo engineers. We review your custom-module list, your OCA list, your DB, and send you a SOW within 48 hours with the cutover plan, milestones, and fixed price.
Book a Free Upgrade Audit →