From OCPP 1.6 to 2.0.1: The Migration No One Planned For
Most Charge Point Operators (CPOs) and e-Mobility Service Providers (eMSPs) built their platforms on Open Charge Point Protocol (OCPP) 1.6. It worked. Chargers connected, sessions logged, and networks grew. But when the International Electrotechnical Commission published OCPP 2.0.1 as IEC 63584:2024 — and then OCPP 2.1 as IEC 63584-210:2025 — the protocol that powered the first generation of EV charging infrastructure stopped being good enough. The migration that nobody planned for is now the migration nobody can avoid.
OCPP 2.0.1 Is Now an IEC Standard — What Changed
For years, OCPP was an industry convention maintained by the Open Charge Alliance (OCA). Adoption was voluntary. Procurement teams referenced OCA specifications, but without the weight of an international standards body behind them.
That changed in late 2024. OCPP 2.0.1 was published as IEC 63584:2024, giving it the same standing as any IEC-backed industrial standard. Months later, OCPP 2.1 followed as IEC 63584-210:2025, extending the specification with distributed energy resource (DER) control, bidirectional charging support, and full ISO 15118-20 compatibility.
The practical impact is already visible. Public tenders and government procurement programs — including those deployed under the US National Electric Vehicle Infrastructure (NEVI) program, which remains active despite significant congressional funding reductions in FY2026 — are beginning to reference IEC 63584 rather than OCA documentation alone. For CPOs competing for infrastructure contracts, OCPP 1.6 is increasingly a disqualifying factor, not a legacy they can quietly maintain.
And OCPP 2.1 is not a distant horizon. It is already published, already certified by the OCA, and already shaping the feature expectations of utilities and grid operators entering the EV charging space. The question is not whether to migrate — it is whether to step through 2.0.1 or leap to 2.1 directly.
What OCPP 1.6 Can’t Do (And Why It Matters Now)
OCPP 1.6 was designed for a simpler era: connect a charger, start a session, stop a session. It handles that workflow reliably. But the capabilities the market now demands — smart charging, Vehicle-to-Grid (V2G), Plug & Charge, and grid integration — expose fundamental gaps in the 1.6 specification.
| Capability | OCPP 1.6 | OCPP 2.0.1 | Why It Matters |
|---|---|---|---|
| Security | Optional: TLS available as extension but not mandatory; no defined security profiles | Mandatory: Three security profiles with TLS certificate management and secure firmware updates | Payment data and grid-critical operations require enforced encryption |
| Device Model | Rigid: Key-value configuration; backend cannot discover charger capabilities dynamically | Flexible: Hierarchical Device Model enables capability discovery, smart charging profiles, and V2G readiness detection | Smart charging and V2G require the backend to know what each charger can do |
| Transaction Handling | Basic: Single Start/Stop event per session; limited metering granularity | Rich: Mid-session updates, cost transparency, granular metering aligned with AFIR data requirements | Regulatory compliance (AFIR, NEVI) demands real-time data transparency |
| ISO 15118 / Plug & Charge | Not supported: No native mechanism for vehicle-to-charger authentication | Native support: ISO 15118 handshake integrated into protocol flow | Automaker expectations and driver experience require RFID-free authentication |
| Smart Charging | Limited: Basic charging profiles; no composite schedule support | Advanced: Composite schedules, priority-based profiles, external cost signals | Grid integration and demand response require dynamic charging control |
| IEC Standardization | None: OCA specification only | IEC 63584:2024: Published as international IEC standard | Public procurement increasingly references IEC designations |
Four gaps stand out.
Security. OCPP 1.6 has no mandatory Transport Layer Security (TLS) requirement. Security profiles were added as optional extensions, but the base specification does not enforce encrypted communication between charger and backend. OCPP 2.0.1 introduces three defined security profiles with mandatory certificate management — a prerequisite for any network handling payment data or grid-critical operations.
Device Model. OCPP 2.0.1 replaces the rigid key-value configuration of 1.6 with a flexible, hierarchical Device Model. This matters because the Device Model is how a Charging Station Management System (CSMS) discovers and controls the specific capabilities of each charger — including smart charging profiles, metering accuracy, and V2G readiness. Without it, the backend is blind to what the charger can actually do.
Transaction handling. OCPP 1.6 treats a charging session as a single Start/Stop event. OCPP 2.0.1 introduces a richer transaction model that supports mid-session updates, cost transparency for the driver, and the granular metering data that AFIR and other regulations now require.
ISO 15118 and Plug & Charge. The vehicle-to-charger authentication that eliminates RFID cards and mobile apps — the experience automakers are building toward — requires ISO 15118. OCPP 1.6 has no native mechanism to support this handshake. OCPP 2.0.1 does.
None of these are theoretical concerns. They are capabilities that regulators, utilities, and automotive OEMs now expect. A platform running OCPP 1.6 cannot participate in the markets those stakeholders are building.
The Migration Path: Dual-Stack, Not Big Bang
The instinct to replace OCPP 1.6 with 2.0.1 in a single cutover is understandable — and almost always wrong. OCPP 1.6 and 2.0.1 are not backward compatible. A CSMS built for 2.0.1 cannot communicate directly with a charger running 1.6 firmware, and vice versa.
The practical path is a dual-stack architecture: a backend that supports both protocol versions simultaneously, routing messages to the correct handler based on the charger’s reported version. New chargers deploy with 2.0.1 (or 2.1). Existing chargers receive firmware upgrades on a rolling schedule — where hardware permits.
That last caveat matters. Many older OCPP 1.6 chargers lack the memory and processing power to run 2.0.1 firmware. According to an OCA white paper on large-scale OCPP migration, implementations supporting both versions are expected to fit within 200 KB — but not every deployed unit can accommodate even that. Some hardware will need to remain on 1.6 until end of life.
A realistic migration timeline runs 6 to 12 months for a mid-size network: 2–3 months for backend architecture changes, 1–2 months for integration testing, and 3–6 months for phased charger firmware rollout. The backend work is the enabler — once the dual-stack CSMS is operational, charger upgrades can proceed at the pace hardware and field operations allow.
Five Migration Pitfalls That Derail OCPP Upgrades
Having supported OCPP implementations across multiple versions and hundreds of charger models, five failure patterns appear repeatedly.
1. Assuming charger firmware fully supports 2.0.1. Charger manufacturers may claim 2.0.1 compliance, but implementation depth varies. Some support the core transaction flow but omit smart charging profiles, security profile 2 or 3, or the full Device Model. Test against the actual firmware, not the spec sheet.
2. Ignoring security profile requirements. Moving to 2.0.1 without implementing proper certificate management — the chain of trust between charger, CSMS, and certificate authority — creates a technically upgraded but operationally insecure system. Security profiles are not optional in production.
3. Breaking existing integrations. OCPP 1.6 backends are typically connected to billing systems, fleet management platforms, energy management systems, and mobile apps. The migration must preserve these integrations. Map every downstream dependency before changing the protocol layer.
4. Underestimating the testing burden. OCPP 2.0.1 introduces more message types, more optional features, and more edge cases than 1.6. Testing a dual-stack system against a heterogeneous charger fleet — where each manufacturer implements the spec differently — requires dedicated test infrastructure and considerably more time than most teams allocate.
5. Skipping the Device Model implementation. The Device Model is the foundation for smart charging, V2G, and advanced diagnostics. Teams that migrate to 2.0.1 but implement only the transaction flow — essentially replicating 1.6 behavior on a 2.0.1 transport — miss the entire point of the upgrade.
How Accelerators Compress the Migration Timeline
The complexity above is real — but it does not require 12 to 18 months of internal development. Pre-built OCPP accelerators that ship with dual-stack support (1.6 backward compatibility built into a 2.0.1/2.1 architecture) compress the backend work from months to weeks.
When IMP PAN needed a scalable OCPP server for a Horizon 2020 V2G research project spanning three countries, the implementation delivered a production-ready OCPP 1.6J server with V2G capabilities and multi-site management. That foundation — pre-built protocol handling, tested at scale — is what an accelerator provides.
For a VC-backed CPO managing a network of 10,000 chargers, a similar approach reduced the path to a production-ready OCPP architecture from an estimated 12–18 months of internal development to under two months. The accelerator provided the protocol plumbing; the engineering team focused on the features that differentiate their platform — pricing algorithms, driver experience, fleet integrations.
The economics are straightforward. A perpetual license for an OCPP accelerator, plus implementation services, runs a fraction of the fully-loaded cost of building and certifying an OCPP stack internally. And the migration-specific benefit is that dual-stack support is an architectural feature of the accelerator, not a custom addition.
Migration Is the Starting Line, Not the Finish
Migrating from OCPP 1.6 to 2.0.1 solves the immediate compliance gap. But it is one layer of a multi-protocol architecture that now includes OpenADR for demand response, IEEE 2030.5 for grid-facing DER communication, and ISO 15118 for the vehicle-to-charger interface. Each of these protocols is separately mandated by regulations in the US, EU, and UK — and each benefits from the same architectural pattern: a shared foundation, not siloed implementations.
The OCPP migration is the place to start. The architecture decision you make during that migration — modular, event-driven, protocol-agnostic at the abstraction layer — determines whether the next protocol addition takes weeks or months.
Frequently Asked Questions
OCPP 1.6 handles basic charger-to-backend communication: session start/stop, metering, and configuration. OCPP 2.0.1 adds mandatory security profiles with TLS certificate management, a flexible Device Model for advanced charger capabilities, richer transaction handling with mid-session updates, and native support for ISO 15118 Plug & Charge. OCPP 2.0.1 was published as IEC 63584:2024, making it an international standard rather than just an industry convention.
Not universally — but increasingly in practice. Public procurement programs referencing IEC 63584, utility interconnection requirements demanding Device Model support, and automotive OEM expectations around Plug & Charge are all making OCPP 1.6 insufficient for competitive operation. In markets governed by NEVI, AFIR, or UK Smart Charge Point Regulations, the capabilities OCPP 2.0.1 provides are effectively required even where the protocol version is not explicitly named.
For a mid-size CPO network, a realistic timeline is 6 to 12 months: 2–3 months for backend architecture changes (or weeks with a pre-built accelerator), 1–2 months for integration testing across charger models, and 3–6 months for phased charger firmware upgrades. The backend dual-stack work is the critical path — once operational, charger upgrades proceed incrementally based on hardware capability and field logistics.