OCPP 2.0.1 is a protocol change, not a firmware update.
OCPP 1.6 and OCPP 2.0.1 are not compatible. A charge point speaks either one protocol or the other, visible as early as the WebSocket subprotocol during connection setup. Anyone planning the migration like an ordinary firmware update underestimates how fundamentally the message model, state logic, and security architecture change.
The most important differences sit below the surface. The transaction model moves from StartTransaction and StopTransaction to a continuous TransactionEvent stream. The flat configuration keys are replaced by a structured device model built from components and variables. And the security profiles with TLS, basic auth, and client certificates are no longer an optional extra but an integral part of the protocol, including certificate management via OCPP itself.
At the same time, the pressure to make the move is growing. Since January 2026, ISO 15118 has been mandatory for new public AC charge points in the EU, and features like Plug&Charge map far more cleanly onto OCPP 2.0.1 than onto 1.6 extensions. OCPP 2.1 is available and backward compatible with 2.0.1: migrating to 2.0.1 now creates a clear path to 2.1 without repeating the effort.
- TransactionEvent replaces StartTransaction/StopTransaction and changes the billing logic.
- Components and variables replace the flat configuration keys.
- Security profiles with TLS and certificate management are a mandatory part of the protocol.
- Distinct WebSocket subprotocols: a connection is either 1.6 or 2.0.1, never both.
- Status is reported per EVSE and connector, no longer only per connector.
Why the big-bang approach fails in practice.
Big bang means switching the backend and all charge points together on a single cutover date. In projects we see why that rarely works. Real fleets are heterogeneous, with multiple manufacturers and firmware versions, and some devices only support 2.0.1 on the datasheet. On top of that, the cutover drags along certificate rollout, backend mapping, and billing chains that cannot all be verified on the same day.
The real defects only show up under load. MeterValues arrive in a different structure, the status model behaves differently, and the German calibration-law data chain with OCMF-signed readings from MID-compliant meters must remain unbroken so transparency software can verify every charging session. A rollback is difficult after the cutover date because configurations, certificates, and backend assignments have already been switched.
Downtime is not just a technical problem either. Ad-hoc payment under AFIR and roaming via OCPI keep running in production, and every data gap resurfaces later in invoices, roaming reconciliation, or support cases. That is exactly why the migration needs a process that keeps a defined way back open at all times.
The proven process: four phases through an OCPP broker.
The core of the approach: charge points do not connect directly to the backend but to a broker layer in between. This layer keeps the connection to the charge points stable while everything behind it is being rebuilt. In phase 1, the shadow connection, the existing fleet stays unchanged on OCPP 1.6 against the old backend while the broker additionally mirrors and translates the message stream into the new 2.0.1 target system.
In phase 2, the comparison operation, both paths run in parallel and are reconciled systematically: transactions, MeterValues, status changes, and authorizations must produce the same picture in both worlds. Discrepancies at this point are almost always configuration or mapping issues that can be fixed without operational risk. Only then does phase 3 begin, the group-wise cutover: cohorts by manufacturer, firmware version, and site, starting with a small pilot group.
Phase 4 is the completion. The old path is decommissioned in a controlled way, monitoring is pointed at the new target system, and the cutover is documented per group. Until that point, the way back stays open per cohort: a group that shows problems can be switched back to the old path without touching the rest of the fleet. For that to work with transactions in flight, the broker must deduplicate messages during cutover and switch-back – for example via unique message and transaction IDs on reconnect – so nothing is booked twice, and keep meter readings consistent so the billing chain of start and stop values remains gapless across the switch.
- Phase 1 – Shadow connection: the fleet stays on 1.6, the broker mirrors into the 2.0.1 target.
- Phase 2 – Comparison operation: transactions and meter readings from both paths are reconciled.
- Phase 3 – Group-wise cutover: cohorts by manufacturer, firmware, and site.
- Phase 4 – Completion: the old path is decommissioned, the way back stays open until then.
What happens to active charging sessions.
No charging session should be aborted by the migration. That is why the broker switches at session boundaries: a group only moves once no active transaction is running there, typically during low-traffic time windows. Because the broker knows the session state of every charge point, this is not a hope but a verifiable condition before each cutover.
Reconnects and offline phases need a plan as well. Charge points buffer transaction data when the connection drops briefly and deliver it after reconnecting. The broker reconciles transaction IDs between the old and new world so that billing stays consistent. For sessions relevant under German calibration law, an additional rule applies: OCMF-signed meter readings belong unambiguously to one transaction and must remain assigned to the correct session even after the cutover.
For drivers, the best migration is the one nobody notices. RemoteStart, authorization, and ad-hoc payment keep working throughout because the charge point connection never breaks. And if something does stand out, support sees the complete message timeline of both paths in the broker instead of hunting for the cause across two backends.
A realistic timeframe and the first step.
A serious OCPP 2.0.1 migration is planned in weeks and months, not days. The shadow connection itself is quick because nothing changes on the existing fleet. The comparison operation, however, needs enough real charging sessions over several weeks to have genuinely seen weekly load patterns, offline phases, and edge cases. The cutover waves afterwards are easy to plan because every cohort follows the same verified pattern.
In our experience, the longest item is rarely the broker technology but the environment: firmware releases from manufacturers, certificate processes for the security profiles, and coordination with billing and roaming. It therefore pays off to build an honest device inventory early: which models demonstrably run 2.0.1 stably, which need a firmware update, and which stay on 1.6 for now.
This intermediate layer is exactly where an OCPP broker fits in migration projects, running 1.6 and 2.0.1 in parallel and making the comparison operation measurable. Whether this layer is built in-house or bought, four requirements are non-negotiable: availability at least on par with the backend, deployed redundantly, because the broker becomes a single point of failure in the message path; throughput for the full fleet including the load peaks of reconnect storms; latency on the order of low double-digit milliseconds so charge point timeouts do not trip; and an operating location with a short network path – close to the charge points or inside the operator network. Where backend functions are missing on top, modular CPMS building blocks can complement the transition without requiring a switch of the entire platform.