odoo-upgrade-advisor
Step-by-step Odoo version upgrade advisor: pre-upgrade checklist, community vs enterprise upgrade path, OCA module compatibility, and post-upgrade validation.
- License 许可
- MIT
- 最近更新
- 2026-11-10
- Stars
- ★ 1
- Forks
- 0
01 前言 Front Matter
- name
- odoo-upgrade-advisor
- risk
- safe
- source
- self
- description
- Step-by-step Odoo version upgrade advisor: pre-upgrade checklist, community vs enterprise upgrade path, OCA module compatibility, and post-upgrade validation.
03 SKILL.md 正文
Odoo Upgrade Advisor
Overview
Upgrading Odoo between major versions (e.g., v15 → v16 → v17) requires careful preparation, testing, and validation. This skill provides a structured pre-upgrade checklist, guides you through the upgrade tools (Odoo Upgrade Service and OpenUpgrade), and gives you a post-upgrade validation protocol.
When to Use This Skill
- Planning a major Odoo version upgrade.
- Identifying which custom modules need to be migrated.
- Running the upgrade on a staging environment before production.
- Validating the system after an upgrade.
How It Works
- Activate: Mention
@odoo-upgrade-advisor, state your current and target version. - Plan: Receive the full upgrade roadmap and risk assessment.
- Execute: Get a step-by-step upgrade command sequence.
Upgrade Paths
| From | To | Supported? | Tool |
|---|---|---|---|
| v16 | v17 | ✅ Direct | Odoo Upgrade Service / OpenUpgrade |
| v15 | v16 | ✅ Direct | Odoo Upgrade Service / OpenUpgrade |
| v14 | v15 | ✅ Direct | Odoo Upgrade Service / OpenUpgrade |
| v14 | v17 | ⚠️ Multi-hop | v14→v15→v16→v17 (cannot skip) |
| v13 or older | any | ❌ Not supported | Manual migration required |
Examples
Example 1: Pre-Upgrade Checklist
BEFORE YOU START:
☑ 1. List all installed modules (Settings → Technical → Modules)
Export to CSV and review for custom/OCA modules
☑ 2. Check OCA compatibility matrix for each community module
https://github.com/OCA/maintainer-tools/wiki/Migration-Status
☑ 3. Take a full backup (database + filestore) — your restore point
☑ 4. Clone production to a staging environment
☑ 5. Run the Odoo Upgrade pre-analysis:
https://upgrade.odoo.com/ → Upload DB → Review breaking changes report
☑ 6. Review custom modules against migration notes
(use @odoo-migration-helper for per-module analysis)
☑ 7. Upgrade and test in staging → Fix all errors → Re-test
☑ 8. Schedule a production maintenance window
☑ 9. Notify users of scheduled downtime
☑ 10. Perform production upgrade → Validate → Go/No-Go decision
Example 2: Community Upgrade with OpenUpgrade
# Clone OpenUpgrade for the TARGET version (e.g., upgrading to v17)
git clone https://github.com/OCA/OpenUpgrade.git \
--branch 17.0 \
--single-branch \
/opt/openupgrade
# Run the migration against your staging database
python3 /opt/openupgrade/odoo-bin \
--update all \
--database odoo_staging \
--config /etc/odoo/odoo.conf \
--stop-after-init \
--load openupgrade_framework
# Review the log for errors before touching production
tail -200 /var/log/odoo/odoo.log | grep -E "ERROR|WARNING|Traceback"
Example 3: Post-Upgrade Validation Checklist
After upgrading, validate these critical areas before going live:
Accounting:
☑ Trial Balance totals match the pre-upgrade snapshot
☑ Open invoices, bills, and payments are accessible
☑ Bank reconciliation can be performed on a test statement
Inventory:
☑ Stock valuation report matches pre-upgrade (run Inventory Valuation)
☑ Open Purchase Orders and Sale Orders are visible
HR / Payroll:
☑ All employee records are intact
☑ Payslips from the last 3 months are accessible and correct
Custom Modules:
☑ Every custom module loaded without ImportError or XML error
☑ Run the critical business workflows end-to-end:
Create sale order → confirm → deliver → invoice → payment
Users & Security:
☑ User logins work correctly
☑ Access rights are preserved (spot-check 3-5 users)
Best Practices
- ✅ Do: Always upgrade on a copy of production (staging) first — never the live instance.
- ✅ Do: Keep the old version running until the new version is fully validated and signed off.
- ✅ Do: Check OCA's migration status page: OCA Migration Status
- ✅ Do: Use the Odoo Upgrade Service pre-analysis report to get a list of breaking changes before writing any code.
- ❌ Don't: Skip intermediate versions — Odoo requires sequential upgrades (v14→v15→v16→v17).
- ❌ Don't: Upgrade custom modules and Odoo core simultaneously — adapt Odoo core first, then fix custom modules.
- ❌ Don't: Run OpenUpgrade against production directly — always test on a staging copy first.
Limitations
- Covers v14–v17 only. Versions v13 and older have a fundamentally different module structure and require manual migration.
- Enterprise-exclusive module changes (e.g.,
sign,account_accountant) may have undocumented breaking changes not included in OpenUpgrade. - The Odoo.sh automated upgrade path has a separate workflow (managed from the Odoo.sh dashboard) not covered here.
- OWL JavaScript component migration (legacy widget → OWL v16+) is a complex front-end topic beyond the scope of this skill.
04 同仓库更多 Skills
vercel-sandbox
Run agent-browser + Chrome inside Vercel Sandbox microVMs for browser automation from any Vercel-deployed app. Use when the user needs browser automation in a Vercel app (Next.js, SvelteKit, Nuxt, Remix, Astro, etc.), wants to run headless Chrome without binary size limits, needs persistent browser sessions across commands, or wants ephemeral isolated browser environments. Triggers include "Vercel Sandbox browser", "microVM Chrome", "agent-browser in sandbox", "browser automation on Vercel", or any task requiring Chrome in a Vercel Sandbox.
slack
Interact with Slack workspaces using browser automation. Use when the user needs to check unread channels, navigate Slack, send messages, extract data, find information, search conversations, or automate any Slack task. Triggers include "check my Slack", "what channels have unreads", "send a message to", "search Slack for", "extract from Slack", "find who said", or any task requiring programmatic Slack interaction.
electron
Automate Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify, etc.) using agent-browser via Chrome DevTools Protocol. Use when the user needs to interact with an Electron app, automate a desktop app, connect to a running app, control a native app, or test an Electron application. Triggers include "automate Slack app", "control VS Code", "interact with Discord app", "test this Electron app", "connect to desktop app", or any task requiring automation of a native Electron application.
dogfood
Systematically explore and test a web application to find bugs, UX issues, and other problems. Use when asked to "dogfood", "QA", "exploratory test", "find issues", "bug hunt", "test this app/site/platform", or review the quality of a web application. Produces a structured report with full reproduction evidence -- step-by-step screenshots, repro videos, and detailed repro steps for every issue -- so findings can be handed directly to the responsible teams.
agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
shadcn
Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI, including chat interfaces. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", "switch to --preset", and for building a design system or applying a DESIGN.md or brand spec to shadcn/ui.