CMS Migration for EV Charging Networks.
For CPOs and installers moving mixed-brand fleets without losing sessions, revenue, or drivers.
Why operators migrate
Most CMS migrations do not start with a plan. They start with a trigger. When Enel X Way announced its North American shutdown in October 2024, the hardware kept passing current, but scheduling, monitoring and app control were at risk. Migration is how you keep control before that happens to your network.
It is an infrastructure move, not a settings change.
The CMS controls charger communication, authentication, pricing, payments, monitoring, remote commands and reporting. Change it and you touch every charger and every active user, along with the systems behind them.
"OCPP-compatible" is only the starting line. Two 1.6J systems can still disagree on commands, config keys, status transitions and error codes. The surface area is firmware, SIM connectivity, certificates, payment terminals, QR codes, RFID users, tariffs, history and field operations, all at once.
We treat it as a full engineering project with field discipline at every step, because that is what it is.
Controlled waves, with exit criteria.
One large cutover is a gamble. We migrate in controlled waves with defined entry and exit criteria, and advance only when a wave meets them. Each wave is smaller than the next, so the process itself is validated before the risk grows.
Cutover, and the rollback that has to work.
We redirect chargers one at a time, then in validated batches. The old platform stays live until the new one is proven. Rollback is not a plan on paper. It is a rehearsed switch with clear ownership.
- 01Pre-register the charger in the new CMS
- 02Confirm identity, credentials and certificates
- 03Test the endpoint under real network conditions
- 04Confirm a working rollback method
- 05Migrate one charger, wait for boot and heartbeat
- 06Run a real charging session end to end
- 07Only then migrate the batch
A wave is not ready until every one of these has a defensible answer.
- Can the charger reconnect to the old CMS?
- Is the old account and credential set still valid?
- Can the URL be changed remotely after a failure?
- Is the previous firmware image available?
- What happens to sessions during the failed window?
- Who authorises rollback, and at what downtime threshold?
What actually has to travel: chargers, revenue, drivers.
A charger showing "online" is only the first sign of a complete migration. Three things have to land together. If any one of them is late, revenue slips or drivers leave.
Connectivity
- Firmware and OCPP profile alignment
- Backend URL and charger identity
- TLS certificates and trust store
- SIM / APN / network access
- Remote command validation
Commercial
- User accounts and RFID whitelists
- Tariffs, wallets, payment tokens
- Invoices and charging history
- QR / app charger IDs
- Roaming and merchant configuration
Driver
- Accounts, logins and identity
- Wallet balances and payment methods
- Saved chargers, favourites, history
- Receipts, plans, promo credits
- QR codes and deep links resolving
Why RIOD runs it.
RIOD owns the whole EV charging stack, from firmware and OCPP handling to cloud platforms and driver apps. That vertical depth is what this kind of migration actually needs. When a mid-cutover charger refuses a URL change, when a rollback command hits a firmware quirk, when a payment terminal loses its merchant token, the fix is a cross-stack decision made by one team rather than a routing between three vendors.
We run migrations remote-first. Field visits get isolated to known exceptions, so the cost curve does not explode with fleet size. What we do not know, we say we do not know, and we cost the exposure honestly rather than promising a number we cannot hold.
Before you commit.
Can you guarantee zero downtime?
No, and we would be careful of anyone who does across unknown OEMs, firmware, SIM ownership, certificates, and outgoing-CMS restrictions. We aim for controlled, minimal downtime per charger through remote-first cutover, session-level validation, and a tested rollback path. The readiness assessment gives you a realistic picture for your specific fleet.
Will this need field visits?
Some chargers can be migrated entirely remotely. Others need physical access, for example when a SIM must be replaced, a certificate installed locally, firmware repaired, or a backend URL changed on hardware that will not accept it remotely. We estimate this exposure in the assessment and isolate field visits to known exceptions.
What happens to our historical data?
Charger, user, session, and payment data move as part of the migration. Structures differ between platforms, so we migrate essential active data cleanly, archive full history separately, and reconcile financial records independently. Fields that cannot be mapped are documented rather than silently dropped.
What if the old CMS will not cooperate?
It is a real constraint. The outgoing platform may block API access, refuse continued service, or shut down on a fixed date. We plan the rollback window around what is technically and contractually possible, and where cooperation is limited we rely on charger-side reconfiguration and field work.
Does OCPP version matter?
Yes. OCPP 1.6 and 2.x behave differently, and even two 1.6 systems can differ on configuration keys, status transitions, and error handling. We validate each charger model and firmware family against the target CMS rather than assuming compatibility from the version number.
How do you handle payment migration?
Payments are validated end to end before a wave is signed off: authorisation, tariffs, tax, receipts, wallets, roaming, and settlement. A free test session is not enough, because it skips the exact billing logic most likely to fail. We test with real payment methods.
Move your network. Protect your uptime.
Tell us about your fleet. Let's get on a call.
Book a migration readiness assessment