Every fleet that has existed for more than a year is running more firmware versions than its operator believes. The gap between intended and actual is drift, and it quietly makes everything else harder to diagnose.
The reason it matters is not that old firmware is worse. It is that the same symptom has different causes on different builds, which makes fault patterns unreadable.
How drift happens
None of these is a mistake in isolation. Together they produce a fleet whose version distribution nobody chose.
- Units offline during a rollout that never received it and were never retried.
- Warranty replacements shipped from stock on whatever version was current then.
- Units commissioned from inventory that sat for months.
- Rollouts halted partway after a problem and never resumed.
- Field engineers reflashing units to resolve an issue, using whatever image they had.
Why it breaks diagnosis
Fault analysis depends on grouping similar events. If a symptom has one cause on one build and a different cause on another, grouping by symptom produces a mixture and the pattern disappears.
Teams then conclude the fault is random or environmental, when it is neither. It is two faults being counted as one.
It also breaks integrations
Protocol behaviour, configuration key support and error code mapping can all change between versions. A platform integration verified against one build may behave differently on another, and the difference appears as intermittent platform-side errors.
This is why an integration position should record the firmware version it was verified against, rather than the charger model alone.
Measure the actual distribution
The first step is knowing what is deployed, not what was intended. Chargers report their running version, and reconciling that against the rollout record is usually a surprising exercise the first time it is done.
Establishing this distribution is frequently the single most useful output of a network audit.
Converge deliberately
- Retry rollouts against units that were unreachable, rather than treating a rollout as complete when it stops.
- Update replacement stock before deployment, or update on first connection.
- Prevent field reflashing outside the managed process, or record it when it happens.
- Report version distribution routinely, so drift is visible while it is small.
Converged does not mean latest
The goal is a small number of known versions, not necessarily the newest. A fleet deliberately held on a validated build is manageable; a fleet spread across six builds nobody chose is not, regardless of how recent any of them are.
Deciding which versions are supported, and retiring the rest, is the practice that keeps this tractable as a fleet grows.