The capability to update a charger remotely is straightforward. Doing it across a fleet without taking sites out of service, and knowing afterwards what actually ran, is the part that requires design.
Most fleets discover the gap between the two during their first significant rollout.
Stage the rollout
Updating everything at once means a defective release affects the entire fleet simultaneously. Start with a small group, ideally at sites you control and can attend, and expand once they demonstrate stability.
Define what stability means before starting, in terms of session success and fault rate over a period, rather than deciding afterwards whether it looked acceptable.
Never interrupt a session
An update applied while a vehicle is charging risks losing the session and the transaction record. The mechanism must defer until the connector is idle and handle a vehicle connecting while an update is pending.
On a busy site a charger may not be idle for a long time, so the process also needs a policy for how long it waits and what it does when the window never arrives.
Handle the units that are not there
A meaningful proportion of any fleet will be unreachable during a rollout. Treating the rollout as finished when it stops progressing is exactly how drift accumulates.
The process needs a retry queue that persists, so units updated when they reconnect weeks later, and reporting that distinguishes updated, pending and failed rather than collapsing them.
Verify what actually ran
An update reported as delivered is not an update confirmed as running. The charger's reported version after the fact is the evidence, and reconciling that against the intended state is what closes a rollout.
Without that reconciliation, a rollout's success rate is an assumption.
Rollback must be real
A rollback path that has never been exercised is a plan rather than a capability. It should be tested deliberately, including from a partially completed rollout, before it is needed under pressure.
The unit-level fallback, where a charger that cannot run a new image returns to the previous one automatically, is separate and equally important. It is what prevents a bad release requiring site visits.
Bandwidth and cost at scale
A firmware image multiplied across a large fleet on cellular connections is a real data cost, and simultaneous downloads can saturate a site's connection.
Throttling, scheduling downloads outside busy periods, and staggering across the fleet address both. These are operational considerations rather than technical ones, and they are usually discovered on the first large rollout.