The Zero-Downtime CMS Migration Playbook

Five conditions decide whether a migration is clean. No single vendor controls all five.

When all five line up against you on the same charger, minutes-per-charger of downtime is the honest floor. Anyone quoting zero across a real mixed fleet is quoting the best case and calling it the guarantee.

• Mixed OEMs: a fleet built over years rarely runs one make and model, and each behaves differently against a new backend.
• SIM ownership: when the data SIM belongs to the retiring platform or a third party, connectivity is not yours to guarantee.
• Certificate rotation timing: chargers needing new trust material have to accept it, and older firmware does not always cooperate on schedule.
• Outgoing-CMS behaviour: how gracefully it releases a charger, and whether it stays reachable during your window, is a decision made by the platform you are leaving.
• Physical hardware that ignores remote commands: a unit with a hardcoded URL or a corrupt bootloader will not be talked into a new home over the air.

A good migration delivers controlled, minimal, per-charger downtime measured in minutes, not a fleet that never blinks. The distinction that matters, and the one that gets blurred in sales decks, is between two very different things:

A phased, remote-first cutover keeps network downtime close to nothing, because the fleet is never all offline at once. Individual units go quiet briefly and come back while the rest keep serving drivers.

The metric to actually track is not a binary “was there downtime.” It is the per-charger downtime distribution: how many units were offline, for how long, and whether any driver was left without a working option nearby. That number is honest, measurable, and something a vendor can be held to.

• Network downtime: drivers cannot find or use any charger on the network. Every driver feels this, and it is the outage to engineer hard against.
• Per-charger downtime: one plug is offline for a few minutes while it moves to the new backend. Usually no one notices, as long as there is another working unit nearby.

Most plans include a rollback paragraph. Far fewer include a rollback rehearsal, and the difference shows up under pressure. A real rehearsal means reverting a test charger to the old platform before cutover day, timing it, and confirming it comes back to full function. A rollback that has never been executed is a hypothesis.

Three things make a rehearsal real:

When those three exist and have been exercised once on real hardware, a rollback is a procedure. When they do not, it is a wish written into a plan.

• Named trigger criteria: heartbeats missing for a defined number of minutes, session failure rate above a set percentage, or driver complaints past an agreed threshold. Vague triggers like “if things look bad” produce hesitation at the worst moment.
• Clear ownership: one named person decides, on defined evidence, inside a defined time window, without assembling a committee.
• A proven path back: the rehearsal shows how long a revert takes per charger and whether it needs physical access.

Some downtime is not a process failure, it is physics. An honest plan names these units up front and sequences them deliberately.

None of these surprise a team that has migrated real fleets, which is why they belong in the plan from day one. The right move is to identify them during the readiness pass and tell the operator plainly which chargers will need a visit, rather than discovering them mid-cutover.

• SIM swaps: when connectivity depends on a SIM owned by the outgoing vendor, replacing it can mean a field visit. No remote tooling shortens a drive to a site.
• Firmware repair: a charger with a corrupt or locked bootloader may need hands-on recovery before it accepts anything, remote or otherwise.
• Hardcoded backend URLs: when the URL lives in hardware rather than a settable config key, the change cannot be pushed and has to be made at the unit.
• Certificate installation: a TLS upgrade on older firmware can require a manual step where the firmware will not rotate trust material on its own.

A single successful test session proves almost nothing commercially. One free test kWh confirms a charger can deliver energy and close a session. It does not confirm the money and records behind that session are correct, and those are what an operator runs on.

A session that looks fine at the plug can still skip:

Session-level validation means running the full chain end to end: authorize, charge, apply the correct tariff, calculate tax, generate a compliant receipt, debit the wallet, settle any roaming leg, then confirm each step landed. Here is why the timing matters: a migration that validated only the physical session looks successful on cutover day and starts failing weeks later in reconciliation, when the gap between “electrons flowed” and “the books are right” finally surfaces.

• Tariff routing: the driver charged the wrong rate, or none
• Tax calculation: a receipt that will not survive a filing
• Receipt generation, wallet debit, roaming settlement, and reconciliation: each a separate path a “start session” test never touches

Use these to separate experience from optimism.

A vendor who answers all six plainly, including where they cannot promise perfection, is describing a process. One who answers every question with a guarantee is describing a brochure.

We hold ourselves to the same test. The honest answer is that we control the process, not the firmware, and the plan is built around that line. If you want a migration scoped that way, that is what our EV charger CMS migration practice delivers.

• Can you show me a rollback rehearsal from a prior migration, with the timing and trigger criteria you used?
• What is your per-charger downtime distribution across your last three migrations, not your best single unit?
• What percentage of your migrations required unplanned field visits, and what caused them?
• How do you handle a charger whose firmware ignores a remote URL change?
• How do you validate a session commercially, beyond a single test kWh, so tariff, tax, receipt, and settlement are all confirmed?
• Who owns the rollback decision on cutover day, on what evidence, and in what time window?