Big bang
All charge points move on the same cut-over date: a single error in configuration or in the target system immediately hits the entire charging park – and the way back is just as painful as the way there.
Zero-downtime migration
Switch backends without your charging park noticing.
Big-bang migrations are the project every CPO dreads. With the NeLeSo OCPP Broker they become routine operation – run as a planned project with strategy, trial run and a clear way back: the switchover happens per charge point, per group or per site, with no downtime, no cut-over date, and rollback available at any time.
The problem
Why classic migrations fail.
Anyone switching backend or CPMS is fighting on three fronts at once – and any one of them can sink the project.
Firmware variety
Every manufacturer reconnects differently: different configuration paths, reconnect behavior and firmware levels turn one switchover into a thousand special cases – many of them only solvable on site.
Sessions in progress
Charging continues during the switchover: interrupted sessions cost revenue, generate support tickets and damage the trust of drivers and site partners.
Process
How a migration with the broker works.
Shadow connection The broker takes over the charge point connections – backend A stays in charge, nothing changes in operation.
Comparison operation Backend B receives the same data stream in parallel; discrepancies surface before they matter.
Group-by-group switchover Control moves to backend B per charge point, group or site – rollback stays open at any time.
Completion Backend A is retired; the event journal documents every step of the migration.
Comparison
Classic migration vs. broker migration.
The difference is not a tool but the architecture: the broker decouples charge points from the target system – and the cut-over date, downtime and field visits disappear from the project plan.
| Classic migration | Broker migration | |
|---|---|---|
| Downtime | Hours to days | 0s |
| Risk | Everything at once – one error hits the whole park | Contained per group and observable |
| Rollback | Difficult to practically impossible | At any time, per charge point |
| Time pressure | Fixed cut-over date for everyone | Your own pace, site by site |
| Firmware reconfiguration | Every charge point individually, often on site | Once, onto the broker – then never again |
Regulation 2026
2026 is the year existing charging parks have to catch up.
Since January 2026, ISO 15118 has been mandatory for new AC charge points, OCPP 2.1 is available – and the OCPP 1.6 installed base needs a migration path towards 2.0.1. The broker normalizes OCPP 1.6 ↔ 2.0.1 in both directions and buys you the time to bring the installed base along at your own pace – instead of under deadline pressure.
FAQ
Frequently asked questions about OCPP migration.
How long does a migration with the OCPP Broker take?
Typically weeks rather than months – depending on the number of sites and the condition of the installed base. Because the switchover happens per charge point, group or site, the migration can be planned site by site: shadow connection and comparison operation run beforehand, and the switch only happens once the data matches.
Do the charge points have to be reconfigured?
Once: each charge point is pointed at the broker a single time. After that, never again – no matter how often the backend or CPMS behind it changes. The broker holds the connection, and the target system is selected by routing rule.
What happens to charging sessions in progress?
They keep running. The broker’s session stabilization – reconnect logic, message queue and auto-resync – bridges the switchover, so no charging session is interrupted and no transaction data is lost.
Does migration from OCPP 1.6 to OCPP 2.0.1 work too?
Yes. The broker normalizes OCPP 1.6 ↔ 2.0.1 in both directions. Existing OCPP 1.6 hardware can be migrated to a backend that expects OCPP 2.0.1 – without a firmware update and without changes to the target system.
Next step