At some point every charge point operator faces a version conversation: a mixed fleet of OCPP 1.6 and 2.0.1 chargers, a hardware vendor pushing 2.1, or a CPMS migration that touches the protocol layer. The fear is always the same — that the cutover means an outage, and an outage means stranded drivers.
It does not have to. But avoiding it takes planning in three areas: the gateway, the data, and the cutover itself.
The gateway is the part that cannot blink
Chargers hold a persistent connection. If that connection drops during a deployment, every charger has to reconnect — and a few thousand simultaneous reconnections is its own incident.
The fix is architectural. The component that terminates OCPP connections should be isolated from the rest of the platform and deployable on its own. When the gateway is separated from the application database and its state is externalised, you can drain connections gracefully and bring up a new version behind them — a blue-green deployment for chargers. The application can restart, migrate, and redeploy without a single charger noticing.
If your gateway and your business logic share a process or a database, every application change is a charger risk. Decoupling them is the single most important precondition for downtime-free operations.
Migrating the data is where networks actually get hurt
A CPMS migration is rarely about chargers. It is about everything attached to them: sites, tariffs, historical sessions, users, partners, and fleets. Move that badly and you do not get an outage — you get something worse, a network that is online but wrong. Sessions priced against the wrong tariff. Partners missing from settlement. Duplicate assets.
A safe migration has four properties:
- Dry-run first. Run the entire import without committing it, and read the result before anything is live.
- Conflict detection. Surface duplicates and mismatches for a human decision rather than guessing.
- Readiness scoring. Know, before cutover, what is a blocker and what is a warning.
- Rollback. If the cutover goes wrong, be able to reverse it.
A migration without a dry-run and a rollback is not a migration. It is a bet.
The cutover
With the gateway decoupled and the data verified, the cutover is the easy part. Point chargers at the new gateway, let the old connections drain, and reconcile. A reconciliation export afterwards — comparing the source system to the new one — turns “we think it worked” into “we can show it worked.”
How Sparqly approaches it
Sparqly captures the OCPP version at commissioning and supports 1.6, 2.0.1, and 2.1 on a gateway that is database-isolated from the application and built for zero-downtime, blue-green deployment. The migration toolkit moves sites, assets, sessions, users, and partners with dry-run mode, conflict detection, readiness scoring, rollback, and reconciliation exports.
Switching platforms is the single biggest risk in the CPMS market. The way to remove the fear is not to promise nothing will go wrong — it is to make every step reversible and every result verifiable.