René Passmann’s Odoo roadmap overview identifies JSON-2 and the planned replacement of older XML-RPC and JSON-RPC interfaces. It signals change, but does not establish exact affected endpoints or removal dates. Treat that as a reason to audit dependencies, not as authorization to rewrite every connector.
Approve remediation when a documented incompatibility or applicable support deadline affects a necessary workflow. Where exposure is plausible but unproven, commission a bounded compatibility test. Where no relevant incompatibility is verified, monitor against an explicit review trigger. The deliverables should be an evidence-backed integration register and a scoped test brief, not an undifferentiated migration estimate.
Establish which lifecycle notice applies
The roadmap overview describes a technical direction, and Passmann cautions that a roadmap is an intention rather than a guarantee. For budgeting, replace the broad label “RPC deprecation” with the endpoint, service and deployment concerned.
Odoo’s RPC lifecycle notice identifies /xmlrpc, /xmlrpc/2 and /jsonrpc as deprecated. It states that the db service was removed in Odoo 20, while common and object are scheduled for removal in Odoo 22, fall 2028, and Odoo Online 21.1, winter 2027. Other controllers using @route(type='jsonrpc') are expressly excluded from this notice. A custom controller should not be assigned migration work solely because someone describes it as JSON-RPC.
JSON-2 is documented as new in Odoo 19.0, rather than something to assume first arrives with the next upgrade. Record source and target releases separately, including hosting context. Recheck the applicable notice before committing spend, distinguishing a scheduled removal from a failure demonstrated on the target deployment.
Build a register around workflows, not connector names
In a webinar on ERP digital sovereignty, the speakers identify the operating model and concentration of dependencies around ERP as important considerations. The practical implication is to map what the business depends on, including who can maintain it, rather than merely list connected applications.
For each integration, ask the business owner and technical maintainer to complete this register. Attach configuration extracts, code references or maintainer documentation wherever possible.
- Business responsibility: process owner, required outcome, critical operating periods and acceptable fallback.
- Deployment: current and target Odoo versions, hosting model, edition, subscription and relevant support terms.
- Actual interface: endpoint, RPC service or custom controller, calling application, connector version and authentication method. Record credential ownership, not secrets.
- Operations: representative reads, creates, updates and business actions, including required fields, custom methods and dependent modules.
- Maintenance: connector maintainer, released compatibility statement, supported-version matrix and responsibility for defects.
- Failure paths: rejected updates, missing responses and repeated requests; who detects, reconciles and authorizes recovery.
The ERP customization approval worksheet separates the process owner’s acceptance of the business change from the technical owner’s responsibility for implementation, dependencies and support. Here, the trigger is an external interface change rather than a requested customization. Ask whether the workflow remains necessary before deciding how to preserve it.
Reject “the connector supports Odoo” as insufficient evidence. Request the applicable released connector version, target deployment and operations covered. If the answer is only a planned release, keep compatibility unresolved and assign an owner to obtain a testable build or evaluate an alternative.
Commission a bounded compatibility test
Odoo’s JSON-2 documentation specifies API-key bearer authentication and named arguments rather than positional arguments. Available models, fields and methods are database-specific and discoverable through that database’s /doc page. Inspect required custom methods on the target database; do not infer compatibility from a successful generic read.
Verify entitlement too. Odoo’s documented commercial-plan restriction makes external API access available on Custom plans, not One App Free or Standard. Confirm the terms applicable to the target deployment rather than treating that statement as a determination of Community-edition licensing.
The test brief should name the environment, integration account, connector build, representative data, expected business results and acceptance owners. Require representative reads and writes, permitted and denied access checks, custom-method execution and observable error handling. Capture resulting business records as well as request and response evidence.
Hypothetical acceptance scenario: an external application submits an order update but receives no usable response. Ask the team to establish whether the update committed, demonstrate recovery, repeat the request under controlled conditions and reconcile both systems. Passing means the agreed business state is established and exceptions have an accountable owner, not merely that another request succeeds.
Scrutinize multi-step writes. Each JSON-2 call runs in its own SQL transaction, committed on success and discarded on error; multiple calls cannot be chained into a single transaction. Ask what happens if an earlier call succeeds and a later call fails. Transaction rollback does not prove that repeated requests are safe or that the old and new interfaces behave equivalently.
Separate monitoring, testing and confirmed remediation
Monitor when the register establishes no relevant incompatibility. Record why, and set review triggers such as a target-release change, revised lifecycle notice or maintainer support change. An unidentified endpoint is not evidence of compatibility.
Test when the endpoint, authentication pattern, custom methods or maintainer position creates plausible exposure. Approve a bounded investigation with named workflows and an evidence deliverable, rather than an open-ended rewrite.
Remediate when a documented incompatibility or applicable support deadline affects a required workflow. Compare a supported connector upgrade, a targeted adapter change and replacement against the same acceptance criteria. A rewrite is justified only when its scope follows from affected dependencies and alternatives do not meet the requirement.
Before approving spend, review the register with each process owner and maintainer, separating confirmed changes from unresolved assumptions. If you need functional and development support to scope that work, discuss the affected workflows and compatibility tests with Digiventi’s Odoo specialists.
