Operators running OCPI 2.2.1 today are not standing still. They are paying a migration tax they have not yet recognized. The 2.3 release of the Open Charge Point Interface looks, from the outside, like a routine protocol upgrade. In practice it is a rewrite of the tariff object, a rearrangement of AFIR obligations, and a renegotiation with every bilateral roaming partner. The version you choose to stay on is also a version your partners are choosing to leave.

The Silent Cost of Staying on 2.2.1

Deferral feels safe. A roaming stack that has been stable for eighteen months, passing CDRs cleanly and reconciling monthly with two or three hubs, is not a problem that screams for attention. Engineering backlogs are full, the 2.3 specification is recent, and nobody loses a customer on Monday because the version banner reads 2.2.1. That logic holds until the first counterparty in the roaming agreement announces a 2.3 cutover date.

At that point deferral stops being free. Every month a Charge Point Operator (CPO) or an e-Mobility Service Provider (eMSP) spends on a 2.2.1-only platform while partners are shipping 2.3 pulls the operator into a compatibility mode that nobody sized for. Tariff fields that exist in 2.3 get flattened into 2.2.1 shapes on ingestion, then flattened again on CDR egress. Each translation is a place where a commercial term loses fidelity: a peak tier that rounds, a grace period that collapses, an idle fee that surfaces in the wrong currency. These are not protocol bugs. They are the cost of running a codebase one version behind the contract.

The same pattern surfaces on the reporting side. AFIR price-transparency obligations in the European Union assume the richer 2.3 tariff object; publishing that data from a 2.2.1 platform means assembling it in a parallel layer and keeping the two in sync, permanently, until migration happens. Operators who treat 2.3 as optional are quietly funding a shadow stack whose only purpose is to keep 2.2.1 viable.

None of this appears in a 2026 budget. All of it shows up in reconciliation rates, support tickets, and the hours senior engineers spend on maintenance that a one-time migration would have closed.

OCPI 2.3 as a Tariff-Object Migration, Not a Protocol Upgrade

Reading the 2.3 changelog on the EVRoaming Foundation documentation gives a misleading impression. The module list is familiar. The endpoints look largely unchanged. The wire format is still JSON over HTTPS. An architect skimming the delta can conclude the upgrade is a weekend of adapter work.

The real change lives inside the tariff object. OCPI 2.3 restructures how price elements are declared, extends metadata for ad-hoc (contract-free) charging, and adds the fields AFIR demands for public price transparency at the socket. The Charge Detail Record (CDR) inherits that richness: a 2.3 CDR can carry per-component pricing, calibration-law references, and session-level tax structure that a 2.2.1 CDR either omits or embeds in a free-text field.

A 2.2.1 codebase that was built around a simpler tariff model will not extend quietly. Tariff ingestion, CDR generation, and the internal settlement pipeline all touch the same object. Migrating one without the others produces a platform that looks 2.3-compliant on the inbound side while quietly corrupting outbound reconciliation. The work is not large because endpoints moved. It is large because every place the tariff object lives in the platform has to accept a richer shape without losing the older one during transition.

This reframing matters commercially. A migration described as a protocol upgrade stays inside engineering. A migration described as a tariff-object rewrite pulls in product, finance, and compliance, which is the right room for the conversation and the one most operators are avoiding. The Codibly OCPI protocol guide walks the module architecture in depth; the 2.3 migration question is where that architecture meets the CFO.

Every Bilateral Partner Sets the Migration Date for You

OCPI version adoption cascades. The GitHub release history is the easy surface, but the real signal sits one layer deeper, in the implementation announcements from hubs and major counterparties. Gireve moved its platform to OCPI 2.2.1 and is now rolling partners onto 2.3 in phases. Hubject, whose native interface is proprietary, has been extending its OCPI translation surface to handle 2.3 inbound because the demand came from its members, not from the spec. Direct bilateral partners announce cutovers individually, often with ninety days of notice.

An operator does not need all of its partners to migrate to be pulled in. It needs two or three of the ones carrying the most volume. At that point the version matrix stops being a roadmap item and starts being a forcing function. Partner A on 2.3 running peak-tier tariffs against a 2.2.1 counterparty produces CDRs that neither side fully trusts. Partner B on 2.3 using ad-hoc price transparency fields produces AFIR-grade data that the 2.2.1 counterparty cannot publish. Partner C, finally, sends a formal notice that 2.2.1 support will be deprecated on a date six months out, and the migration becomes a quarter-end problem instead of a roadmap item.

The cascade from 2.1.1 to 2.2.1 ran exactly this way between 2022 and 2025. The operators who migrated early controlled the timeline, sequenced the work, and absorbed the cost across two planning cycles. The operators who waited ran a compressed migration under partner pressure and paid a premium for it. The same pattern is now visible at the 2.2.1 to 2.3 boundary, with the additional wrinkle that the AFIR deadline sits on top of it in the EU and keeps a second clock ticking.

The 2.1.1 Operators Pay Twice

A smaller group sits on OCPI 2.1.1. Usually a legacy platform from 2018 to 2020 that was stable, profitable, and never prioritized for upgrade. For this group the 2.3 transition is not a single migration. It is two.

The 2.1.1 to 2.2.1 step introduced roles, message routing headers, hub client information, and a meaningfully different credentials handshake. A 2.2.1 platform cannot be simulated by patching 2.1.1; the data model changed. The 2.2.1 to 2.3 step then adds the tariff-object rewrite described above. Skipping the middle version, in principle attractive, fails in practice because partner ecosystems still require a working 2.2.1 interface during the transition window. The hubs speak 2.2.1 today and will continue to for at least the next year. An operator jumping 2.1.1 to 2.3 without a functioning 2.2.1 interface in between loses roaming connectivity during the gap.

The right sequence for 2.1.1 operators is a rebuild on a 2.2.1 baseline that is architected to accept 2.3 as a tariff-and-CDR extension, not a second migration. Done that way, the migration is longer but the second cycle is absorbed inside the first. Done the short way, the operator pays the upgrade cost twice and lives through two certification windows.

Version Comparison: 2.1.1 / 2.2.1 / 2.3 at the Data-Model Level

A version matrix is the clearest way to see where the real work lives. The specifications move on endpoint shape and module scope. The migrations hit the data model.

OCPI version matrix — 2.1.1 vs 2.2.1 vs 2.3 at the data-model level
Dimension OCPI 2.1.1 OCPI 2.2.1 OCPI 2.3
Module scope Core modules: Locations, Sessions, CDRs, Tariffs, Tokens, Commands, Versions, Credentials. No ChargingProfiles. Adds ChargingProfiles, refined Hub Client Info, message routing headers, role-based topology. Same module surface as 2.2.1. Substantive changes inside the objects, not in the module list.
Tariff object Simple tariff structure. Limited per-component pricing. No ad-hoc metadata. Extended price components, calibration-law support, VAT fields. Ad-hoc pricing partially addressed. Rewritten. Richer per-component pricing, ad-hoc (contract-free) metadata, AFIR price-transparency fields native.
CDR granularity Single-row billing detail. Tax and component split often embedded in free-text fields. Structured per-period pricing within a session. Credit CDR support. Calibration-law references. Inherits 2.2.1 CDR and extends with full 2.3 tariff shape, per-component pricing, session-level tax structure.
Smart Charging Profile Not defined. Defined; widely implemented on the CPO side. Refined based on operational feedback from 2.2.1 deployments.
Plug & Charge Token-based only. Token-based; Plug & Charge integration typically handled out-of-band. Ad-hoc and Plug & Charge flows first-class in the specification.
AFIR coverage Insufficient field coverage for price-transparency mandates. Parallel assembly layer typically required to meet AFIR publication rules. Native. Price-transparency fields and National Access Point (NAP) data structures built in.
Partner adoption (2026) Small legacy tail. Deprecated by most hubs during 2024-2025. Production default on most roaming platforms and both major EU hubs. Rolling out across Gireve and direct bilateral partners in phases; Hubject inbound translation extending to 2.3.
Recommended migration timing Do not stay. Rebuild on a 2.2.1 baseline architected to accept 2.3 as a tariff and CDR extension. Plan the 2.3 migration for 2026. Partner cascade closes the window during 2027. Target version for operators planning now. Full alignment with AFIR and the 2026 partner roadmap.

Two rows in that table carry most of the decision weight. The tariff-object row shows why a 2.3 migration is a product conversation, not a protocol one. The partner-adoption row shows why the window closes from the outside. Everything else is execution detail.

For a broader view of OCPI’s module model and the way each version extends it, the OCPI protocol architecture guide is the companion piece. For the protocol-rival question, OCPI versus OICP, especially for CPOs inside the Hubject network, the OCPI vs OICP comparison sits alongside this guide, and the OCPI vs OCPP reference clears up the most common scoping confusion inside engineering teams.

The Build That Runs the Roaming Department

A 2.2.1 to 2.3 migration on a production platform is a quarter of work, sequenced across four phases. That shape is predictable. The places where teams underestimate are predictable too.

OCPI 2.2.1 to 2.3 migration phases — typical duration and where teams underestimate
Phase Typical duration Core work Where teams underestimate
1. Scope and tariff analysis 2-3 weeks Inventory every market-specific tariff construct in production. Map peak tiers, idle fees, grace periods, subscription discounts, and ad-hoc pricing into the 2.3 tariff-object shape. Secure finance and product sign-off. Treating the phase as a developer exercise. Tariff design is where the business case is made or lost; skipping it pushes the failure into reconciliation.
2. Data-model extension 3-4 weeks Extend the tariff object, the CDR object, and any internal settlement or billing pipeline that consumes them. Add ad-hoc and AFIR price-transparency fields. Maintain backward compatibility with 2.2.1 during the transition window. Patching the inbound side only and leaving outbound CDR generation on the old model, creating a shadow-stack that corrupts reconciliation.
3. Partner certification 4-6 weeks Bilateral testing against each significant counterparty. Session-linking, token authorisation (RFID, app, Plug & Charge), CDR versioning, and hub-specific routing all revalidate. Open Charge Alliance tooling covers common paths. Assuming partners share a common interpretation of the new tariff shape. They do not. The long tail of partner-specific assumptions only surfaces in integration testing.
4. Cutover and reconciliation 2-3 weeks Run 2.2.1 and 2.3 interfaces in parallel for roughly ten days. Close the older interface. Hold a CDR reconciliation window of another fortnight to validate the new reporting shape against finance expectations. Cutting the 2.2.1 interface before the CDR reconciliation window closes. The rollback cost if a tariff mapping error surfaces on day twelve is materially higher than the parallel-run cost.

The first phase, scope and tariff analysis, is where the business case is either made or lost. Every market-specific tariff construct in production has to be re-expressed in the 2.3 object shape without losing commercial intent. Peak tiers, idle fees, grace periods, subscription discounts, and ad-hoc pricing all survive the move if the mapping is designed carefully, and all break quietly if it is not. Finance sits in this phase for a reason.

The second phase, data-model extension, is the engineering core. The tariff object, the CDR object, and any internal settlement or billing pipeline that consumes them all extend together. Teams that patch one and defer the others create the shadow-stack problem described earlier. The work is mostly mechanical. The surprise is its width: the object touches more of the platform than its size in the JSON suggests.

The third phase, partner certification, runs bilaterally. Each significant counterparty has to test against the new interface, and each brings slightly different assumptions about session-linking, token handling, and CDR versioning. Tooling from the Open Charge Alliance covers most of the common cases; the long tail is partner-specific and only surfaces in integration testing.

The fourth phase, cutover and reconciliation, is where 2.3 either holds or rolls back. Running 2.2.1 and 2.3 in parallel for thirty days, then closing the older interface, is the pattern that fails least often. A recent engagement with a European eMSP on a 2.2.1 codebase needed roughly eleven weeks end-to-end from scope lock to closed 2.2.1 interface, with a ten-day parallel run and a CDR reconciliation window of a further fortnight. The protocol work took four weeks. Everything else was tariff mapping, partner-by-partner certification, and finance sign-off on the new reporting shape. An operator starting from the Codibly OCPI Accelerator compresses the engineering half of that schedule, but not the tariff or certification work, which scales with counterparty count rather than codebase maturity.

The Migration Window Is a Commercial Decision, Not a Technical One

OCPI 2.2.1 is not broken, and 2.3 is not urgent in any week considered on its own. Both statements are true, and both are misleading. The silent cost of staying on 2.2.1 compounds quietly, the 2.3 tariff rewrite pulls product and finance into a conversation engineering cannot resolve alone, and the partner cascade sets a migration date that the operator does not own. Taken together, the question is not whether to migrate but when, and the answer is earlier than most plans assume.

Operators who move in 2026 on their own timeline control the sequencing. Operators who move in 2027 under partner pressure inherit one. For the second group, the migration costs the same to build and more to plan, because a quarter-end deadline set by a counterparty does not accept “next planning cycle” as an answer. The 2026 AFIR interoperability framing covered in our earlier AFIR brief is the same dynamic on the regulatory axis: the platforms built for it keep optionality; the platforms retrofitted to it lose it.

For operators ready to start the version ladder conversation with a real plan rather than a roadmap bullet, Codibly offers OCPI and OICP interoperability services and the OCPI Accelerator as the engineering baseline. The rest — tariff design, partner certification, reconciliation — is where the migration is won or lost.