Why migrate now?
OCPP 1.6 has served the industry well, but it's showing its age. The protocol was designed when most charging stations had a single connector and firmware updates were rare. The modern charging landscape — with multi-connector stations, dynamic load management, ISO 15118 Plug & Charge, and complex tariff structures — demands more.
OCPP 2.0.1 isn't just a version bump. It's a fundamental rearchitecture of how charge points and central systems communicate.
The key differences
Message structure
OCPP 1.6 uses a flat message format. Every operation has a request and a response, and the data model is implicit. If you want to know the state of a connector, you piece it together from StatusNotification messages.
OCPP 2.0.1 introduces a component-variable model. Every configurable aspect of a charger is represented as a component (e.g., ChargingStation, EVSE, Connector) with variables (e.g., Available, Power). This makes the charger's state explicit and queryable.
Security profiles
OCPP 1.6 has no built-in security model. Most deployments use Basic Auth over WSS at best, plain WS at worst.
OCPP 2.0.1 defines three security profiles:
- Profile 1: Basic authentication over TLS
- Profile 2: TLS with client-side certificates (mutual TLS)
- Profile 3: Profile 2 + signed firmware updates
If you're handling payment data or operating public chargers, Profile 2 is the minimum you should target.
Smart charging
OCPP 1.6 supports basic charging profiles via SetChargingProfile. It works, but scheduling is limited and there's no way to express cost-based optimization.
OCPP 2.0.1 adds:
- Cost-based charging — the central system can communicate energy prices so the charger optimizes timing
- External constraints — grid operators can signal capacity limits
- Priority charging — different profiles for different use cases on the same station
Transaction handling
In OCPP 1.6, a transaction is implicitly tied to a connector via StartTransaction and StopTransaction. If the connection drops, you rely on MeterValues to reconstruct what happened.
OCPP 2.0.1 introduces explicit transaction events (TransactionEvent with Started, Updated, Ended triggers). Every state change is reported, making it far easier to build reliable billing systems.
Migration strategies
Strategy 1: Dual-stack gateway
Run both OCPP 1.6 and 2.0.1 endpoints simultaneously. New chargers connect via 2.0.1, existing chargers stay on 1.6. A translation layer normalizes both into a common internal format.
This is what EV Cloud provides out of the box. The gateway handles protocol translation transparently.
Strategy 2: Rolling firmware upgrades
If your charger vendor supports 2.0.1, upgrade firmware station-by-station. This works well for small fleets (fewer than 50 stations) where you can schedule maintenance windows.
Strategy 3: Big bang cutover
Replace the entire backend simultaneously. Only viable for greenfield deployments or when the existing system is being decommissioned anyway.
Common migration pitfalls
Don't assume 1:1 message mapping. Many OCPP 1.6 messages don't have direct equivalents in 2.0.1. StatusNotification becomes a combination of StatusNotification (for connector status) and the component-variable model (for charger state).
Test with real hardware. Charger firmware implementations of OCPP 2.0.1 vary significantly. What works in the OCTT (OCPP Compliance Testing Tool) may behave differently on production hardware.
Plan for mixed fleets. You'll likely run 1.6 and 2.0.1 chargers simultaneously for years. Your backend needs to handle both cleanly.
Don't skip security. If you're already migrating, implement at least Security Profile 2. Retrofitting security later is harder than building it in.
What EV Cloud does for you
EV Cloud's OCPP gateway accepts both 1.6 and 2.0.1 connections. It normalizes messages into a unified internal model, so your application logic doesn't need to know which protocol version a charger speaks.
The migration path is simple: point your chargers at the EV Cloud gateway. As you upgrade firmware, chargers automatically connect via 2.0.1. No backend changes required.
Migration planning resources
Once the protocol decision is clear, the next risk is rollout shape. Most teams do not fail because they misunderstand OCPP 2.0.1 features. They fail because they underestimate mixed fleets, rollback criteria, and how long coexistence will last in production.
Use these pages to move from technical reading into a real migration plan:
- Use the CPO migration checklist before you lock pilot scope, sequencing, or rollback rules.
- Use the EV charging software RFP template if you are comparing vendors during the migration decision.
- Review the rollout blueprint to frame pilot, coexistence, and full rollout phases.
