Charge points live longer than backend contracts.
A public charge point is planned for a decade or more of operation, including civil works, grid connection and permits. Backend contracts run considerably shorter, and the market behind them is anything but stable: providers get acquired, discontinue products or change pricing models. Choosing a CPMS today does not decide the lifetime of the infrastructure – only one chapter of it. The architecture should reflect that difference.
Regulatory dynamics add to this. AFIR has required ad-hoc payment and data provision since 2024, ISO 15118 has been mandatory for new public AC charge points in the EU since January 2026, and ISO 15118-20 puts Plug&Charge and V2G on many operators' roadmaps. Each of these topics creates backend requirements that were often not even foreseeable when the contract was signed. Whether the current provider delivers them in time is outside the CPO's control – unless switching is technically possible at any moment.
Across projects we regularly see the backend decision treated as a one-off procurement: tender, select, connect, done. The more robust view is a different one: the charging infrastructure backend is a replaceable component, while the charge points are the lasting asset. From that perspective, the ability to switch moves from nice-to-have to a core architectural requirement.
Lock-in rarely lives in the OCPP protocol – it lives in the layers around it.
On paper, a backend switch is trivial: OCPP is standardized, so changing the WebSocket URL in the charge point should suffice. In practice, exactly this fails regularly – not because of the protocol, but because of everything that has accumulated around it. Lock-in is rarely a single mechanism; it is a sum of small dependencies that look harmless in isolation. Together they make switching so expensive that it never happens.
The first layer is configuration: over the years, parameters are set via ChangeConfiguration or SetVariables, firmware versions are managed and vendor-specific quirks are compensated inside the backend – often with no documentation anywhere except in the provider's own system. The second layer is data custody: CDRs, historical MeterValues, calibration-law-relevant OCMF (Open Charge Metering Format) records and customer data live in the provider's data model. The third layer is contracts: roaming frequently runs through the backend provider's OCPI connections and Hubject account, not through the CPO's own agreements.
- Charge point configuration and firmware states exist only in the old backend, not as independent documentation.
- Historical charging data and OCMF-signed meter values cannot be exported, or only incompletely.
- EVSE IDs, OCPI connections and the Hubject link are tied to the provider's contracts.
- Authentication, tariffs and load management rely on proprietary features outside the OCPP standard.
Multi-backend architecture: a broker makes backends interchangeable.
The core of a multi-backend strategy is a decoupling layer between charge points and backends. An OCPP broker terminates the charge point connections and routes messages to one or more target systems. The charge points permanently point to a URL under the CPO's control – which backend answers behind it becomes a routing decision instead of a rollout project. That changes the balance of power in every contract negotiation.
In practice this often starts small: running test and production environments in parallel by having the broker mirror messages. The next step is a second provider for part of the fleet, for example new sites or a pilot cluster. A full switch then runs as a gradual migration: cutting over charge point by charge point or site by site, with a way back if the new backend shows problems. The risky big bang becomes a controlled process with measurable intermediate steps.
A broker layer also helps with the protocol question. OCPP 1.6 and 2.0.1 are not compatible with each other, many existing fleets are mixed, and OCPP 2.1 is backwards compatible with 2.0.1 but not with 1.6. A broker handles these differences in one place and gives downstream systems a consistent picture, instead of carrying every protocol variant into every backend.
Exit capability belongs in the tender, not in the crisis.
The worst time to think about a backend switch is the moment it becomes necessary. Whoever starts planning the exit only after an insolvency, a price increase or a discontinued roadmap negotiates from the weakest position and migrates under time pressure. Exit capability is therefore a procurement criterion like price or feature scope. It can be specified concretely in a tender and tested before signing.
Besides OCPP on the southbound side, the northbound side of the CPMS decides how switchable a backend really is: documented APIs (for example as an OpenAPI specification), a disclosed data model and a complete export of transactions, tariffs and user accounts. Whether connected in-house systems such as customer portals, ERP or analytics survive a backend switch depends on exactly these interfaces – not on the protocol towards the charge point.
Exit capability also has a commercial side. B2B billing via XRechnung or ZUGFeRD must remain reproducible from the operator's own data after a switch, for example when invoices are questioned or audited. And roaming should run through the CPO's own agreements: a direct Hubject account, or at least transferable OCPI 2.2/2.3 connections, prevents the roaming reach from disappearing together with the backend.
- Complete, machine-readable data export (CDRs, MeterValues, OCMF records, configuration) – contractually guaranteed and actually tested.
- Own roaming agreements or demonstrably transferable OCPI connections and EVSE IDs.
- Charge point configuration as a documented state outside the backend.
- A dry run before contract renewal: moving one charge point to a second system as a test.
Data sovereignty is the foundation of any ability to switch.
In the end, one simple question decides between lock-in and freedom: where does the raw data live? Whoever holds the complete OCPP message stream, the signed meter values and the configuration states can switch any backend without losing history. This also matters under German calibration law: MID-compliant meters produce the readings, and OCMF signatures keep them verifiable with transparency software independently of the backend – but only if the CPO actually possesses the records. Data sovereignty is therefore not an abstract principle but a concrete operations and compliance requirement.
A broker layer creates this sovereignty almost as a by-product: it sees every message between charge point and backend and can build its own journal, an up-to-date configuration state and an independent archive from it. Backends come and go; the operator's data foundation remains. This is exactly what a broker layer should be designed for: connect charge points once, route backends flexibly and keep the data permanently in the operator's hands. Switching then stops being an emergency and becomes the normal state of the architecture.