OCPP 1.6 and OCPP 2.0.1 are not two flavors of the same protocol - they're different message formats with a different underlying data model. If you're operating chargers today, or buying new ones, the version question isn't academic: it determines what your hardware can do and how a migration will actually go. This is a practical guide for charge point operators (CPOs), not a spec walkthrough. For the basics of the protocol itself, see What Is OCPP?
The short version
OCPP 1.6 (in practice, almost always the JSON variant, OCPP 1.6J) is the version most currently-deployed commercial and workplace chargers speak. It's mature, widely supported, and “good enough” for straightforward station management, remote commands and basic smart charging. OCPP 2.0.1 is the current generation of the standard: a substantially reworked data and security model that adds native support for Plug and Charge, device management, and more granular tariff and cost signaling - at the cost of being a bigger lift for hardware vendors to implement and for operators to migrate to.
Key differences
| Area | OCPP 1.6 | OCPP 2.0.1 |
|---|---|---|
| Data model | Fixed set of message types and configuration keys | Component/variable model - devices expose structured, extensible data points |
| Security | Basic auth or TLS, added in later 1.6 profiles | Certificate-based security built in from the base spec, including TLS 1.3 support |
| Plug and Charge (ISO 15118) | Not supported | Native support - vehicle and charger authenticate and authorize automatically, no card or app tap |
| Smart charging | Supported via the Smart Charging profile, coarser control | More granular charging profiles and better support for local energy management |
| Tariffs & cost display | Not part of the protocol - handled entirely by the CSMS/back office | Native cost and tariff messaging, so a compatible charger can display running cost during a session |
| Device management | Limited - firmware updates and diagnostics via dedicated messages | Structured device management model covering monitoring, configuration and diagnostics uniformly |
| Hardware availability | Very broad - most chargers shipped in the last decade support it | Growing - increasingly the default on new charger models, less common on older installed hardware |
Why this isn't a drop-in upgrade
OCPP 2.0.1 is not backward compatible with 1.6 at the message level. A charger built for 1.6 cannot simply be pointed at a 2.0.1 endpoint - the firmware itself has to implement the new protocol version, which for many devices means a firmware update from the manufacturer, and for older hardware may not be possible at all. That's the real constraint behind any migration plan: it's gated by what your installed chargers - not just your software - can support.
A practical migration approach
For an operator with an existing network, a version migration is best treated as a phased infrastructure change, not a cutover event:
- Assess. Inventory installed chargers, firmware versions and current OCPP version per site, and confirm which units have a 2.0.1-capable firmware path from the manufacturer.
- Map. Identify which chargers, tariffs and integrations move first - typically newest hardware and highest-value sites, not the whole fleet at once.
- Validate. Test connectivity, remote commands and billing behavior against the new protocol version in a non-production environment before touching live sessions.
- Migrate in waves. Move chargers in controlled batches, keeping the rest of the network on 1.6 throughout - which only works if your CSMS can run both versions side by side.
- Cut over. Once a wave is validated in production, retire the old configuration for those chargers rather than running parallel systems indefinitely.
The step that trips up most migrations isn't any single stage above - it's discovering mid-project that the CSMS itself only speaks one OCPP version, which forces an all-or-nothing hardware refresh instead of a phased one. A platform with genuine multi-version OCPP support - CarChargeOS supports OCPP 1.6J, 2.0.1, 2.0.1 Ed3 and 2.1 concurrently - lets a mixed fleet run on one back office indefinitely, so migration happens on your operational timeline rather than your software vendor's.
Frequently asked questions
Do I have to migrate to OCPP 2.0.1 at all?
Not immediately. OCPP 1.6 remains widely supported and isn't being deprecated overnight. The decision usually comes down to whether you need what 2.0.1 adds - Plug and Charge, finer-grained smart charging, or native tariff signaling - badly enough to justify a hardware and firmware review now.
Can I run OCPP 1.6 and 2.0.1 chargers on the same network at the same time?
Yes, as long as your CSMS supports both versions. This is the normal state for most growing networks - older sites on 1.6, newer installs on 2.0.1 - rather than a brief transitional phase.
Does upgrading to OCPP 2.0.1 require replacing my chargers?
Not always. Some hardware can be upgraded via a manufacturer firmware update. Older units, or those the manufacturer no longer supports, may only be able to stay on 1.6 - which is exactly why an assess-and-map step before migrating matters.