Odoo 的主文档说明，旧版 RPC 数据库服务已在 Odoo 20 中移除。更广泛的 XML-RPC 和 JSON-RPC API 自 19.0 版本起已被弃用，但 Odoo 20 并未移除所有旧版服务。Odoo 文档指出，common 和 object 服务将保留到 Odoo 22。 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 因此，集成团队需要识别每个外部连接所使用的服务，而不是把旧版 RPC 支持视为一个只有单一移除日期的功能。
Odoo 美洲活动页面称，Odoo 20 将在 2026 年 9 月 2 日至 3 日于旧金山活动期间发布。 (Oxp26 Americas Introduction) 升级规划现在可以考虑文档中所述的数据库服务移除，但生产环境决策仍应以 Odoo 20 最终发布文档为准。
移除仅适用于特定服务
Odoo 将 `/xmlrpc`、`/xmlrpc/2` 和 `/jsonrpc` 列为自 19.0 版本起弃用的旧版端点。在这些 API 中，数据库服务已在 Odoo 20 中移除，而 common 和 object 服务计划保留到 Odoo 22。 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 使用保留服务的集成在升级到 Odoo 20 后可能仍可运行，但仅凭端点并不能确认兼容性。
同一系统可以通过旧版 RPC 接口使用不同服务。因此，集成审查应同时记录端点和所调用的服务。仅将应用描述为 XML-RPC 或 JSON-RPC 集成，并不能说明它是否依赖于 Odoo 20 中已移除的操作。 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
common 和 object 服务的继续可用只是暂时的。Odoo 计划在 Odoo 22 中移除这两个服务。 (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) 团队可以将数据库服务调用的紧急工作与保留服务的迁移分开处理，但两者都需要计划。
JSON-2 改变了请求契约
Odoo 将 JSON-2 记为替代 API。其端点格式为 `/json/2/<model>/<method>`，模型和方法包含在 URL 中。 (Odoo master Docs: Reference External API) 因此，迁移不仅仅是替换现有 RPC 客户端中的基础路径。每个操作都必须映射到相应的模型和方法路由。
JSON-2 要求在 JSON 请求体中使用命名参数，而不是位置式 RPC 参数。 (Odoo master Docs: Reference External API) 现有的封装层、中间件和生成客户端可能假定参数顺序决定含义。这些组件都需要逐一审查。如果客户端仍然构造位置参数，那么把旧请求重定向到新端点将无法工作。
对于每个已迁移的操作，团队应记录 JSON-2 所需的目标模型、方法和命名参数。 (Odoo master Docs: Reference External API) 然后应在相关的 Odoo 20 环境中测试这些请求，尤其是在共享集成库为多个应用构造调用时。静态负载对比无法确认服务器或客户端如何处理完整请求。
身份验证也必须更改
JSON-2 使用 bearer API key 认证。 (Odoo 主文档：参考外部 API)迁移工作应涵盖密钥创建、安全存储、授权头处理和密钥替换。还应检查代理、网关和客户端库，确保在转发请求时保留该头信息。也应审查日志记录、监控和错误处理，避免泄露凭据。
文档规定了认证方法，但每个组织都必须确定 API 密钥如何纳入其凭据控制。 (Odoo 主文档：参考外部 API)这包括指定密钥责任人、控制其可使用的位置，以及定义密钥替换后受影响的集成将如何更新。
二进制字段有单独的兼容性变更
Odoo 的 ORM 变更日志记录了另一项 Odoo 20 RPC 变更，二进制字段的表示增加了 `BinaryValue.filename`。 (Odoo 主文档：ORM 变更日志)这与数据库服务移除是分开的，因为它改变的是返回数据，而不是服务可用性。读取、转换或验证包含二进制字段响应的应用，应纳入兼容性测试。
变更日志确认已添加 `filename` 成员，但其实际影响取决于客户端。 (Odoo 主文档：ORM 变更日志)测试应检查严格模式的架构、序列化器、响应比较和下游转换是否接受该新增成员。忽略未知字段的客户端可能无需调整，但应进行验证，而不是假定如此。
如何界定集成审计范围
先识别使用 `/xmlrpc`、`/xmlrpc/2` 或 `/jsonrpc` 的连接，Odoo 将其标记为已弃用端点。 (Odoo 主文档：参考外部 API; Odoo 主文档：参考外部 RPC API)清单应涵盖内部开发的应用、中间件、计划任务以及在可获取配置或源代码的情况下的第三方连接器。为每个连接指定负责人，以便验证其用途和状态。
接着，按旧服务对每个连接分类。使用数据库服务的连接需要为 Odoo 20 进行修正，而常规服务和对象服务的使用则在文档中仍标明可用，直到 Odoo 22。 (Odoo 主文档：参考外部 API; Odoo 主文档：参考外部 RPC API)这支持分阶段计划：先处理 Odoo 20 的不兼容问题，再为其余已弃用调用安排迁移日期。
对于迁移到 JSON-2 的集成，请记录 `/json/2/<model>/<method>` 路由、命名请求参数，以及替代接口所需的 bearer API key 认证。 (Odoo 主文档：参考外部 API)测试用例应覆盖成功请求、被拒绝的认证、无效的命名参数，以及应用对返回数据的处理。凡出现二进制字段的地方，都应加入二进制字段用例。
确认 Odoo 20 的最终行为
移除细节取自 Odoo 的主开发者文档，而公布的发布时间来自一个活动页面，该页面说明 Odoo 20 将于 2026 年 9 月的美洲活动期间发布。 (Odoo 主文档：参考外部 API; Odoo 主文档：参考外部 RPC API; Oxp26 Americas Introduction)部署前，团队应重新核对已发布的 Odoo 20 版本文档，以及他们计划使用的具体版本和构建。
使用已弃用的 RPC 端点并不能单独证明某个集成会在 Odoo 20 中停止工作，因为常规服务和对象服务在文档中仍标明可用，直到 Odoo 22。相反，在较早版本上运行成功，也不能证明数据库服务调用在被移除后仍兼容。 (Odoo 主文档：参考外部 API; Odoo 主文档：参考外部 RPC API)
升级决策清单
在批准 Odoo 20 升级之前，决策者应要求提供一份集成登记表，列出每个已弃用端点、所调用的服务、负责人和计划中的修正措施。数据库服务依赖项应有经过测试的替代方案。仍使用常规服务或对象服务的集成应有单独的迁移日期，以反映其在 Odoo 22 中的计划移除。 (Odoo 主文档：参考外部 API; Odoo master 文档：参考外部 Rpc API)
审查应确认 JSON-2 实现将模型和方法放在 URL 中，使用命名 JSON 参数，并通过 bearer API key 进行身份验证。如果存在二进制字段，测试还应考虑添加 `BinaryValue.filename`。 (Odoo master 文档：参考外部 API; Odoo master 文档：Orm 变更日志) 这些检查用于区分 Odoo 20 中数据库服务的立即移除，与随后弃用其余旧版服务。