Odoo 20 已于2026年9月发布，我们的客户很快就提出了那些常见疑问：可以直接从16版本升级吗？OpenUpgrade 准备好了吗？预计耗时多久？
本指南提供迁移流程的初步参考，介绍必须确定的基础阶段与方案选择，方便大家在深入技术细节前评估工作量。根据我们的经验，数据库本身的迁移难点并不多见，大部分工作集中在自定义模块与第三方应用上。
从 16、17、18、19 版本升级
升级至20版的方式取决于你的 Odoo 版本类型。Odoo 企业版可通过 Odoo 升级服务，单次提交请求即可将数据库升级到目标版本，无论起始版本是哪一版。而社区版使用的 OpenUpgrade 只能跨一个版本逐级升级，因此每多跳过一个版本，就需要额外执行一轮升级与测试。
| 当前版本 | 企业版（官方升级服务） | 社区版（OpenUpgrade） |
|---|---|---|
| Odoo 19 | 一次请求 | 一轮升级（19→20） |
| Odoo 18 | 一次请求 | 两轮升级 |
| Odoo 17 | 一次请求 | 三轮升级 |
| Odoo 16 | 一次请求 | 四轮升级 |
但即便企业版是一次性迁移，数据库体量依然会变大。《如何在 Odoo 20 中安装自定义模块》这篇文档同样覆盖所有这些版本；因此，如果你的模块是基于16版开发的，该模块就要经历四轮迁移。同时务必检查服务器环境：Odoo 20 需要 Python 3.12 以及 PostgreSQL 16 或更高版本，很多本地部署环境需要先完成环境升级，才能继续进行 Odoo 版本升级。
选企业版还是社区版：走哪条迁移路线？
企业版用户的订阅包含 Odoo 官方升级服务。你可以在 Odoo Online 数据库管理面板、Odoo.sh 的升级标签页发起升级；本地部署则可通过 upgrade.odoo.com 服务或者 Odoo 命令行工具提交。但官方只负责修复标准数据库升级产生的问题，服务等级协议（SLA）并不包含自研模块、合作伙伴开发模块以及第三方应用，这些模块由你自行负责。
社区版用户使用 OpenUpgrade，它是 OCA 推出的开源升级项目，免费使用，但升级操作需要由你或者你的实施伙伴执行，超出其支持范围的问题，需要自行编写迁移脚本。每个标准模块、每一组版本之间都有对应的迁移状态清单。
截至2026年9月30日，两者均尚未支持20.0版本：Odoo官方升级表单与 Odoo.sh 最高仅支持到19.0，OpenUpgrade 的20.0版本还处于早期开发阶段（工单编号 #6044）。如果你使用社区版16或17版，无需暂缓动作，可以先升级到19版；等 OpenUpgrade 20.0 就绪后，你就只剩最后一步升级。
在隔离副本上执行升级测试
绝对不要在还能连通外网、可执行定时任务、会向真实客户发送邮件、向其他对接系统推送数据的生产副本上做升级测试，除非全程有人值守监控。
**环境隔离（neutralization）**就是用来规避这类风险的：它会禁用外发邮件、定时任务、在线支付网关以及其他外部对接通道，同时增加标识横幅，避免有人把这份测试库当成正式生产库。Odoo官方升级服务生成的数据库、数据库副本、Odoo.sh 的预发布环境会自动完成隔离。本地部署需要手动执行：
./odoo-bin neutralize -c /etc/odoo/odoo.conf -d prod_test
你自研的对接集成模块，只有自带 data/neutralize.sql 文件时才会被隔离脚本处理，所以所有自定义对接连接器都要补充该文件。项目期间要安排多轮升级测试，上线前还要做一次完整全流程演练。
用户验收测试（UAT）
数据库升级本身可能没有报错，但依然会影响员工日常业务；因此，实际使用对应业务流程的人员必须参与测试。开展UAT时，我们按部门划分范围，每个部门指定负责人、划定一小部分关键业务流程，并且在UAT开始前确认验收签字规则。
在我们一次从v18迁移到v19的项目里，在聊天面板使用完整编辑器打开邮件时，所有收件人会悄无声息丢失。前端界面看不出任何异常，这个问题直到发送测试邮件时才被发现。建议仔细查阅升级报告，报告里会列出升级过程中被禁用的视图。
使用 upgrade_code 移植自定义模块
自定义模块通常占用最多工作量。移植代码前，先对比每一项定制功能和 Odoo 20 的标准能力：如果v20原生已经支持该功能，直接移除这份定制，而不是继续移植。
对于需要保留的代码，Odoo 20 内置了 odoo-bin upgrade_code 工具。它依靠 odoo/upgrade_code/ 目录下的脚本自动处理常见变更，例如树形视图（tree view）改为列表视图（list view）、访问规则改用全新的 ir.access 格式、OWL 2 组件迁移至 OWL 3。先执行试运行，并且限定仅处理你的自定义模块：
./odoo-bin upgrade_code --addons-path /opt/custom-addons \ --script 19.4-00-ir-access --glob 'my_module/**/*' --dry-run
这类脚本只处理语法层面改动。业务逻辑、针对已变更元素的视图继承、数据迁移仍然需要开发人员处理；重命名的字段或模型，需要单独编写迁移脚本。
核查第三方应用适配情况
确定上线日期之前，整理全部非标准模块清单，标注模块来源、归属方、是否存在v20适配版本。前往Odoo应用商店查看20.0版本，同时去OCA代码仓库核对是否有20.0分支。新版本刚发布的阶段，大概率会有不少模块还没有适配版本。
针对每一个模块，确定方案：等待适配版本、寻找替代方案、自行移植，或者直接从系统移除。部分功能已经内置在 Odoo 20 标准模块中（例如批量调拨已经纳入库存模块），这种情况下寻找替代方案的成本并不高。
切换上线与回滚方案
分步编写上线切换流程，使用和生产体量一致的数据演练，记录每一步耗时。切换窗口期内冻结数据录入，因为最终备份之后录入的数据，不会出现在升级后的数据库里。典型流程如下：
- 通知停机时间以及数据录入冻结安排
- 暂停所有集成对接，停止Odoo服务
- 备份数据库与附件存储目录，并验证备份可正常恢复
- 执行生产环境升级，部署已经移植完成的模块
- 冒烟测试核心流程，核对试算平衡表、库存金额等关键数据，和原生产库比对
- 按照事先约定的判定条件，决定上线或者中止上线
- 保留旧服务器不做改动，直到v20稳定运行一段时间
如果升级失败，回滚就是让用户切回旧系统、恢复备份。必须设定回滚决策的截止时间。一旦用户已经在v20中开始操作，回滚就会丢失新增业务单据；这种情况下只能在新版本上修复问题。Odoo Online 的生产升级一旦完成，无法回退。
预计工期参考
下面时长范围来自常规项目。影响工期最关键的因素：自定义模块数量与质量、跨版本跨度、第三方应用是否已经适配完成。
| 阶段 | 少量定制 | 中等规模（5–20个自定义/第三方模块） | 重度定制或多公司架构 |
|---|---|---|---|
| 现状盘点与梳理 | 2–5天 | 1–2周 | 2–4周 |
| 升级测试 | 1–3天 | 1–2周 | 2–6周 |
| 自定义模块移植 | 0–3天 | 2–6周 | 2–4个月及以上 |
| 用户验收测试UAT | 1周 | 2–3周 | 4–8周 |
| 上线切换 | 一天或一个周末 | 一个周末 | 1–2个周末，额外安排一次演练 |
| 预估总周期 | 2–4周 | 1.5–3个月 | 3–6个月及以上 |
每多一轮 OpenUpgrade 逐级升级、或是需要升级服务器至 Python3.12 / PostgreSQL16，都要额外预留工期。
总结
规划升级最好的方式，是盘点现有全部模块、定制项和集成对接。梳理清楚这些信息后，更容易选定迁移路线，工期预估也会更贴合实际。.