Duration: 53:41
PART 1 — Analytical Summary 🚀
Context 💼
This session at Odoo Experience targets both customers and partners and walks through how to confidently plan and execute an Odoo upgrade—from the theory to a live demo. The presenter demystifies upgrade fears by showing a practical migration of an Odoo 16 on‑premise database (with a small customization) to Odoo 18, while explaining timelines and expectations for Odoo 19 upgrades. The talk doubles as a field guide: what an upgrade really does, how it differs by hosting model, what’s new or changing around support, and how to test and plan upgrades without disrupting operations.
Core ideas & innovations 🧠
Odoo releases a major version annually and, for SaaS users, running releases (minor versions) in between. The first production database that’s upgraded every year is odoo.com—a 5,000+ user system covering most apps—acting as a “crash test” that informs fixes before broader rollout. In simple terms, an Odoo database combines source code and data. If new versions require only code changes, you don’t need a script; if the data model changes, you need upgrade scripts to transform data safely. Some past versions required heavy scripts (e.g., Subscriptions merged into Sales in v16, Analytic accounting distribution JSON change in v17), but many migrations are smaller.
Hosting model determines the upgrade path. On Odoo Online, you get running releases and test upgrades by duplicating the database; upgrades are launched via odoo.com. On Odoo.sh, you test on a staging branch and commit code changes, using major versions only. On on‑premise, you upgrade via command line or through upgrade.odoo.com (form or CLI). There is no downgrade in Odoo; planning matters.
The live demo upgrades a 16→18 database that tracks budgets. Between versions, budgets evolved from models like crossover_budget and crossover_budget_line to budget.analytic and budget.line. The presenter adapted a custom module that adds a “responsible” field to budget lines: updating the model/view targets for v18 and adding a minimal migration script to rename a field using the upgrade_utils library’s rename_field helper. The code branches are switched to 18.0 via Git; then the database is upgraded with the upgrade CLI (valid subscription required). After launching, Odoo shows release notes, a double confirmation of v17→v18 upgrades, and a new summary panel that highlights which custom views were disabled during the upgrade, making it easier to spot what needs attention.
What’s “new” around upgrades? Functionally, upgrades continue to support old versions, but support policy is refined by hosting: - Odoo Online: unchanged; stay within the last 3 major versions (running releases apply automatically). - Odoo.sh: can extend support up to 5 years, on demand. - On‑premise: all versions are supported, but there’s a fee if you stay beyond the last 3 major versions.
Also, Odoo 19 upgrade scripts are typically released a few weeks after the product launch. The internal target is to upgrade odoo.com first (planned around October), then roll out to others (expect late-year availability). For highly customized Online projects that may later move to Odoo.sh, it’s wise to create the database on the latest major version (e.g., via the trial URL parameter that forces a major version) to avoid being stuck on an intermediate SaaS minor version with no downgrade path.
Impact & takeaways ⚙️
The session drives home that upgrades are a discipline of “testing, testing, testing.” Plan them, test technically (code, scripts, logs, deactivated elements) and functionally (new UX, changed flows), and train users. You can begin adapting custom code to the new version as soon as the source code is public, even before upgrade scripts are available. For Studio users: customizations are records (not code), so fixes are often reactive during testing; Odoo’s support team provides Studio upgrade scripts and can help adjust deactivated or broken views. For partners, upgrades should be budgeted explicitly—options include upfront inclusion, time & materials, or regularized invoicing—because migrations incur real effort.
Key reminders: - Use upgrade.odoo.com, Odoo support, and official documentation (including the upgrade_utils library). - The upgrade team can collaborate flexibly (including limited data-access setups) if compliance or data sensitivity demands it. - Stick to Odoo’s standard design when you customize; reduce long‑term technical debt and make future upgrades predictable. - For SaaS projects that might move to Odoo.sh, prefer creating databases on major versions to avoid waiting cycles later.
In short: frequent, well‑planned upgrades lower cost and risk, and unlock features sooner. One test a day keeps the upgrade pains away. 💬
PART 2 — Viewpoint: Odoo Perspective
Disclaimer: AI-generated creative perspective inspired by Odoo’s vision.
Upgrades shouldn’t feel like a leap of faith; they should feel like a routine checkup. Our job is to make each release smaller in friction and bigger in value. The more customers stay close to standard and integrate natively across apps, the more upgrades become a button, not a project.
We’re committed to a simple equation: one codebase, tight integration, and a community that gives feedback early—starting with our own odoo.com deployment. When we ship, it’s because we’ve used it, broken it, and fixed it. The result is a platform where innovation and stability can coexist without trade‑offs.
PART 3 — Viewpoint: Competitors (SAP / Microsoft / Others)
Disclaimer: AI-generated fictional commentary. Not an official corporate statement.
Odoo’s annual cadence and integrated suite are compelling, especially for mid‑market teams that want speed and a modern UX. Their emphasis on testing and a visible post‑upgrade summary for deactivated customizations is smart change‑management. The community feedback loop—upgrading odoo.com first—helps shake out issues early.
The challenges will be in regulated and highly complex environments: long‑term support expectations, strict compliance, auditability, and large‑scale change control. Studio-led customizations help speed, but they also require governance to avoid drift. For enterprises with deep legacy integrations, the “no downgrade” posture and minor‑version dynamics on SaaS will demand careful planning. Still, Odoo’s momentum on simplicity and breadth keeps raising the UX bar for the category.
PART 4 — Blog Footer Disclaimer
Disclaimer: This article contains AI-generated summaries and fictionalized commentaries for illustrative purposes. Viewpoints labeled as "Odoo Perspective" or "Competitors" are simulated and do not represent any real statements or positions. All product names and trademarks belong to their respective owners.