A CMS migration is rarely blocked by the protocol. It is blocked by things nobody established before starting: whether chargers can be repointed at all, whether historic data can move, and what happens to drivers mid-transition.
Establishing those three first turns a risky project into a sequencing exercise.
Confirm the chargers can actually be repointed
The backend address is a configuration value, and whether you can change it yourself, remotely, without the incumbent vendor's cooperation, is the question that determines whether migration is possible at all.
Where the incumbent controls that value, the migration becomes a commercial negotiation before it becomes a technical project. Discovering this late is the most common reason migrations stall.
Test one charger before planning the fleet
Connect a single unit to the new platform and run the full compatibility set: boot, transactions, meter values, remote commands, firmware management and interrupted cases. Every difference found here is one you would otherwise find across the whole fleet at once.
Do this on the same firmware version the fleet actually runs, not the latest, because that is what will be migrating.
Decide what happens to history
History usually does not move cleanly. Planning for an archive with defined access is more realistic than assuming a clean import, and it is far better than discovering the gap during a billing dispute.
- Whether historic session data can be exported from the incumbent, and in what format.
- Whether the new platform can ingest it, or whether history stays behind in an archive.
- How long you retain access to the old platform after cutover for dispute resolution.
- Whether driver accounts, RFID credentials and tariffs transfer or are recreated.
Migrate in waves, not at once
Move a small group first, ideally at a site where you control access and can tolerate disruption. Operate it on the new platform long enough for interval-driven problems to appear, which usually means at least a full billing cycle.
Then move in waves sized so that a problem affects a manageable proportion of the fleet, with a defined rollback for each wave.
Drivers are the part that shows
Charger downtime during cutover is brief. Driver disruption is not, if their accounts, cards or app no longer work. That is what generates complaints, and it is a communication and identity problem rather than a protocol one.
Establish early whether existing credentials continue to work, and if not, plan the transition for drivers separately and ahead of the hardware.
Keep both paths alive during the window
Where a routing layer sits between chargers and backends, migration becomes a configuration change per charger and rollback is immediate. Without one, repointing is a firmware configuration change on each unit and rollback is the same work again.
This is the strongest practical argument for a routing layer, and it is worth considering before a migration rather than after one has hurt.
What good looks like at cutover
- A tested compatibility position on the actual firmware version.
- A wave plan with rollback defined per wave.
- An agreed answer on historic data and archive access.
- Driver credentials handled ahead of hardware.
- Monitoring in place on the new platform before the first wave, not after.