OCPP 2.0.1 has been ratified since 2020, but the practical migration conversation only intensified in 2024 as hardware vendors started shipping chargers with firmware that defaults to the newer protocol. If you're running a charge point network on OCPP 1.6J today — which describes the majority of deployed CPO infrastructure — the upgrade question is no longer hypothetical. It's a timeline and budget conversation.
This guide is written for operators who already understand the basics of OCPP 1.6J and want a clear picture of what the migration actually involves at the platform and hardware layer. We're not covering every OCPP 2.0.1 feature in exhaustive detail; we're focused on what changes operationally, what breaks, and what you need to have in place before you flip the switch on a live network.
What 2.0.1 Actually Adds That 1.6J Doesn't
The marketing headline for OCPP 2.0.1 is "smart charging and plug-and-charge." That's accurate but incomplete. The more operationally significant additions are the device management model and the security architecture.
OCPP 1.6J has no native certificate management. Security is bolted on — TLS at the transport layer, but nothing in the protocol itself for certificate provisioning, renewal, or revocation. OCPP 2.0.1 introduces the Security profile (Profile A / B / C) and an explicit message for certificate installation and status requests (InstallCertificate.req, GetInstalledCertificateIds.req). If you're operating in a regulated environment or deploying in locations where tamper-resistance matters, this is the change that justifies the migration cost on its own.
The smart charging additions — SetChargingProfile with composite schedules, charging needs notification from the vehicle, and the ISO 15118 integration hooks — matter more for specific use cases: managed fleet depots, demand response deployments, and markets where grid tariffs are volatile. For a public L2 parking lot deployment, the smart charging uplift from 1.6J to 2.0.1 may be modest in practice.
The Multi-Version Gateway Problem
Most CPO networks don't migrate overnight. You have existing 1.6J hardware under maintenance contracts, new deployments arriving as 2.0.1, and a back-office CPMS that may have been built assuming 1.6J message structures. The result is a heterogeneous fleet that has to be managed simultaneously.
Consider a plausible scenario: a regional CPO in the US Southeast running around 280 charge points. Roughly 200 are legacy DC fast chargers deployed between 2020 and 2022 on 1.6J. The remaining 80 are newly procured units arriving from a hardware vendor whose latest firmware ships 2.0.1 by default. The CPMS back-end was written to 1.6J message schemas. The immediate problem isn't the new chargers — it's that BootNotification in 2.0.1 carries a different payload structure, and MeterValues has reworked measurand enumerations. The back-end will either reject the new charger connections outright or silently drop fields it doesn't recognize.
The standard architectural answer here is a protocol gateway — a middle layer that translates 2.0.1 messages from new hardware into 1.6J equivalents for the existing CPMS, or vice versa. This works for a transition period, but it has a hard ceiling: features that exist only in 2.0.1 (certificate management, ISO 15118 handshake, device model extensions) cannot be back-translated to 1.6J. A gateway gets you operational continuity; it doesn't get you the new functionality.
Where Migration Gets Technically Hard
The protocol change is the visible part. The less-discussed challenges are in your operational data model and your alerting logic.
OCPP 2.0.1 introduces a hierarchical device model: EVSE (the physical outlet) is now a distinct entity from Connector, and both have their own status state machines. OCPP 1.6J conflates EVSE and Connector — a single ConnectorId covers both. If your CPMS stores session data and fault history keyed on ConnectorId in the 1.6J sense, migrating to the 2.0.1 model requires either a schema migration or a translation shim. Neither is trivial when you have years of session history that needs to remain queryable.
The status notification messages have also changed in ways that affect monitoring thresholds. OCPP 1.6J has a flat list of ChargePoint statuses (Available, Preparing, Charging, SuspendedEVSE, SuspendedEV, Finishing, Reserved, Unavailable, Faulted). OCPP 2.0.1 replaces this with a two-dimensional status model across EVSE and Connector. Alerting rules that fire on a specific 1.6J status string need to be rewritten. Any ops team that has invested in runbooks tied to those status strings will feel this migration in their on-call workflow, not just in their codebase.
Hardware Firmware Readiness — The Variable You Can't Control
Hardware vendor firmware quality varies considerably. Some vendors have shipped OCPP 2.0.1 implementations that are conformance-tested by OCA (Open Charge Alliance); others have shipped partial implementations that advertise 2.0.1 but omit optional feature profiles like Smart Charging or Security. Before committing to a migration timeline, audit which feature profiles each hardware model in your fleet actually supports — not what the vendor datasheet says, but what the BootNotification response shows in your system logs when you actually connect a test unit.
We're not saying hardware vendors are deliberately misleading you. The OCPP conformance testing program is voluntary, and many vendors ship 2.0.1 hardware before their firmware implementation is fully stabilized. The OCPP 2.0.1 specification also has its own optional profiles, and vendors legitimately ship different profile combinations. The operational risk is that you plan a migration around 2.0.1 feature assumptions and discover post-deployment that 60% of your new hardware doesn't support the charging profile feature you needed for demand response.
What a Defensible Migration Timeline Looks Like
Based on the operational complexity above, a realistic migration for a network of 100–500 charge points looks like four distinct phases:
Phase 1 — Audit and inventory. Profile every charge point model in your fleet against its current firmware version and its OCA-tested feature profiles. Map which hardware can realistically receive a 2.0.1 firmware update vs. which requires hardware replacement.
Phase 2 — Platform gateway deployment. Stand up a protocol translation layer before touching any field hardware. Validate that your CPMS can receive translated 2.0.1 messages correctly on a test network of 5–10 units before any production exposure.
Phase 3 — Phased fleet rollout. Migrate one site at a time, starting with sites where you have physical access for rapid on-site response if something breaks. Monitor session success rate and fault notification volume closely for the first 72 hours post-migration on each site. A meaningful drop in session success rate (below your baseline) is the leading indicator of a protocol translation problem, not a hardware fault.
Phase 4 — CPMS native 2.0.1 upgrade. Once the full fleet is on 2.0.1 firmware, you can migrate the CPMS itself to native 2.0.1 message handling and decommission the gateway layer. Only at this point can you activate features that require the full 2.0.1 stack — certificate provisioning, ISO 15118 handshakes, and composite schedule profiles.
The ISO 15118 Question
Many operators ask about ISO 15118 plug-and-charge as a migration driver. The honest answer is that ISO 15118 readiness is a separate workstream from OCPP 2.0.1 migration, even though the two are related. OCPP 2.0.1 provides the transport and certificate management hooks that ISO 15118 requires, but the ISO 15118 certificate chain — involving the OEM, a contract certificate pool, and the CPO — requires additional backend integration work beyond OCPP itself. Vehicle-side ISO 15118 support is also still rolling out across OEM platforms. The migration value of OCPP 2.0.1 for most CPOs in 2025 is operational (device management, security, smart charging) rather than ISO 15118 plug-and-charge, which remains a mid-term objective for most North American deployments.
The migration is worth doing. The protocol improvements in 2.0.1 are real, and staying on 1.6J indefinitely creates compounding technical debt as new hardware ships with 2.0.1 as default. But "migration" here means a carefully sequenced infrastructure project, not a firmware toggle. Operators who treat it as the latter tend to discover that the complexity was real, just deferred.