If you operate EV chargers today, the odds are most of your fleet speaks OCPP 1.6J. The odds are also that your newest hardware arrived speaking OCPP 2.0.1 or 2.1, your procurement team is asking when you'll be "fully migrated", and nobody can give them a date.
Here's the uncomfortable truth the industry doesn't say often enough: you will run multiple OCPP versions side by side for years, and that's fine — if your backend is built for it.
Why the big-bang migration doesn't exist
OCPP 2.x is not an incremental update to 1.6. It changes the message model (Requests/Responses reorganised around device models), the security model (certificate management, security profiles), and the configuration model (Device Model variables replace the flat key-value GetConfiguration).
That means a "migration" isn't a software upgrade you schedule — it's constrained by:
- Hardware support. Many chargers in the field will never receive 2.x firmware. They work, they earn revenue, and ripping them out to satisfy a protocol version is money spent for zero driver benefit.
- Firmware maturity. Even where vendors advertise 2.0.1 support, implementations vary enormously in quality. The first firmware release that "supports" a protocol version is rarely the one you want in production.
- Certification cycles. Public-funding rules and tender requirements increasingly reference specific OCPP versions and profiles, and the paperwork lags the technology.
So the real question isn't "when do we migrate?" — it's "how do we operate a mixed-version fleet without doubling our operational burden?"
The architecture that makes mixed fleets boring
The pattern that works is a version-abstracting backend: chargers connect speaking whatever OCPP dialect they have, and everything north of the backend — your dashboards, billing, APIs, automations — sees one consistent model.
Rendering diagram…
Concretely, that means:
- Normalise transactions. A 1.6
StartTransaction/StopTransactionpair and a 2.xTransactionEventstream should land in the same sessions table with the same semantics. Your finance team should never know which protocol produced a charging session. - Normalise status. 1.6
StatusNotificationvalues and 2.x connector status need one vocabulary. "Is this connector available?" must have one answer, not one per protocol. - Normalise control. Remote start, stop, reset and availability changes should be one API call that the backend translates into the right message for each charger. (This is exactly how the AmpNexus remote command API behaves — the caller never specifies a protocol version.)
- Keep raw history anyway. Normalisation is for operations; the raw OCPP message log is for troubleshooting and vendor disputes. Keep both.
A staged migration plan that survives contact with reality
With that foundation, migration becomes a series of small, reversible steps rather than a cliff edge:
Stage 1 — Inventory honestly. For every charger model in the fleet, record: current firmware, best available firmware, and the OCPP version that firmware reliably supports (which is not always what the datasheet says). This list drives everything else.
Stage 2 — Onboard new hardware on 2.x from day one. New sites are your lowest-risk 2.x population: no drivers have habits there yet, and commissioning is already a supervised activity.
Stage 3 — Upgrade opportunistically, in cohorts. When a vendor ships trustworthy 2.x firmware for an existing model, treat the protocol move like any firmware rollout: canary a handful of chargers, watch reconnection behaviour and transaction integrity for a full billing cycle, then widen. (We covered our cohort rollout machinery in Safe, staged firmware rollouts at scale.)
Stage 4 — Let the long tail be a long tail. Chargers that will never speak 2.x keep working until their natural end of life. Because the backend abstracts the difference, their operational cost is the same as everyone else's.
What to watch during a version move
From operating mixed fleets, the failure modes worth explicit monitoring during any protocol transition:
- Reconnect storms. A charger switching protocol re-registers; a whole site doing it after a power event can hammer your backend. Rate-limit and queue.
- Transaction continuity. Sessions that start under one firmware and end after an update are where billing bugs live. Test this path deliberately.
- Clock drift and heartbeat cadence. 2.x devices negotiate differently; a "quiet" charger might be healthy but misconfigured. Alert on missing heartbeats, not just on errors.
- Security profile mismatches. A charger configured for a stricter security profile than your endpoint offers will simply fail to connect — often with a vendor-specific and unhelpful error. Validate certificates and profiles in staging first.
The takeaway
Mixed OCPP fleets aren't a transitional embarrassment — they're the steady state of a well-run network. Build (or buy) a backend that treats protocol versions as an implementation detail, migrate in cohorts where there's genuine benefit, and spend the money you saved on things drivers actually notice.
AmpNexus connects chargers across OCPP 1.6 through 2.1 on one backend with a single API — see OCPP Connect, or check what we've shipped recently on the changelog.