Odoo 20 Integration Migration: Six Decisions Before Cutover

Answer first

An Odoo 20 integration migration needs decisions about transport, identity, arguments, response shape, business effects and evidence. Replacing an endpoint is only one part. A partner should be able to explain which contract changed, which policy remains authoritative, and which representative workflows passed on the candidate being released.

The Odoo 20 AI overview covers release features. The native MCP guide and native MCP versus ERPipe comparison cover connection architecture. This article concentrates on the API and acceptance decisions behind an existing gateway integration.

Evidence status: the reviewed ERPipe candidate uses core 0.1.4 and XMLRPC 0.1.3, with local pinned Odoo 20 Community qualification. Independent implementation review 03 passed the exact 77-file candidate. The reviewed package pair is available in the public GitHub release, and the hosted gateway passed authenticated production smoke against the pinned Community 20 lab. These receipts are separate from the broader local workflow matrix. This is not certification of every edition or custom addon.

1. Separate deprecated services from missing services

Avoid a migration plan built on “Odoo 20 removed XML-RPC.” The pinned official documentation distinguishes the database service, removed in 20, from common and object services, scheduled for removal in 22. The replacement is JSON-2. Custom JSON-RPC controllers are outside that specific retirement notice. Official RPC migration notice.

Inventory actual calls: record reads, grouping, authentication, version detection and database administration. A surviving legacy business call does not justify relying on a removed database-discovery service. Conversely, an unavailable discovery route does not prove that every business endpoint disappeared.

ERPipe's qualified routing retains legacy regression coverage while using JSON-2 for20. That is a tested adapter decision, not a recommendation to rewrite every customer integration simultaneously.

2. Match the credential to the execution path

The migration lab initially rejected a key generated with an empty scope. The qualified 20 path uses an active Odoo user and RPC-scoped key. The pinned source checks exact scope as part of credential validation. Official credential implementation.

A native MCP credential is a separate setup. Keep the native endpoint, ERPipe workspace OAuth grant and gateway-to-Odoo credential distinct in the partner's handover. A successful client login establishes neither the Odoo user's business permissions nor the correct database.

Test the intended restricted identity before the administrator. Record expiry and rotation ownership without recording the key itself. If authentication fails, investigate that boundary before changing model access.

3. Translate arguments explicitly

JSON-2 calls address /json/2/<model>/<method> and pass named parameters. Model-level methods can omit record IDs. Each request has its own transaction; several calls do not become one atomic business operation. Official JSON-2 contract.

For example, a staging company-contact read can use this body for res.partner/search_read:

{
  "domain": [["is_company", "=", true]],
  "fields": ["id", "name"],
  "limit": 5
}

This is an illustrative direct API body, not an ERPipe tool payload or a complete authenticated request. Inspect the actual target method signature before translating an old positional call, particularly an optional companion capability. A transport adapter should reject an unsupported shape rather than guess which argument became an ID.

4. Normalize results without relaxing policy

An HTTP success is insufficient when the consumer expects the old aggregation or binary shape. The ERPipe candidate qualifies both formatted and raw grouping paths. A migration check should compare the returned structure and one known total, not merely assert that a response arrived.

Attachments expose another contract change. The pinned 20 source defines file content as raw and removes the old datas field. Official attachment implementation.

The adapter must preserve the meaning of restrictions across that rename. ERPipe treats datas and raw as one protected content pair: denying either denies both, and a restrictive allow policy requires both. Test a denied read through both names before accepting the positive binary result. Compatibility mapping must not introduce a second route to forbidden bytes.

5. Review the full mutation surface

A sales confirmation, chatter note and connection lifecycle change are different operations. Generic methods and named verbs also have their own gates. Enabling a structured write approval path does not establish that every available action waits for a person.

Odoo's security guidance treats public method parameters as untrusted and distinguishes method calls from CRUD permission checks. Inspect the executing logic and the gateway's allowlist or policy for the actual workflow. Official method-security guidance.

In the hosted qualification, unlink remained denied with no record effect. It was not an approved deletion. For a write that is permitted, retain the proposal, decision, final outcome and verification read. Reconcile an uncertain outcome before replaying a mutation.

6. Bind acceptance to the released candidate

The local Community 20 matrix passed 29 common checks and 11 restricted-user checks. Each legacy version 16–19 passed 29 common and 16 restricted checks. The optional companion passed 39 fresh-install, 30 base-only and 37 upgrade tests. These are separate suites with separate scopes.

Record the source versions, installed modules, actor, company, request and expected effect alongside the result. An upgrade test should also inspect retained state and replay behavior. A green fixture cannot establish compatibility for a customer's custom report or business method.

Use the qualification field note to turn those boundaries into acceptance cases. Keep the previous deployment available until the main release's production receipts establish the new path.

Validate one workflow before cutover

Open your ERPipe workspace and qualify a bounded staging read with your intended Odoo identity. Start from a known result, preserve its evidence, and add write or report requirements only when their specific contracts have been checked.