OCPP Migration

OCPP 1.6 to 2.0.1 migration: a practical guide for small CPOs

Most small and mid-size charge point operators are still running OCPP 1.6. AFIR and the shift to ISO 15118 plug and charge are ending that.

Why the industry is moving off OCPP 1.6

OCPP 1.6 has run the majority of Europe's public charging network for close to a decade. It is a stable protocol, and for a long time there was no urgent reason to replace it. That has changed. AFIR now requires ISO 15118-2 support on new and renovated public AC chargers from 8 January 2026, mandatory DATEX II data reporting from 14 April 2026, and card payment readers on chargers rated 50kW and above from 2027. None of those three requirements sit comfortably on a 1.6 stack. OCPP 2.0.1 is the first version of the protocol built with ISO 15118 in mind, with a security model built around TLS and certificate-based authentication, and a device management structure that 1.6 never had. That combination is why 2.0.1 has become the default migration target rather than one option among several.

What actually changes between 1.6 and 2.0.1

The differences are not cosmetic. Three matter most for a migration plan.

• Security. OCPP 1.6 typically runs over plain WebSocket or basic authentication. OCPP 2.0.1 is built around TLS and certificate-based security profiles, which is also the foundation ISO 15118 plug and charge needs to work.
• Device management. 2.0.1 introduces a structured model for configuration, firmware updates, and monitoring across a charger fleet, rather than the looser, vendor-specific approaches many 1.6 deployments accumulated over time.
• Smart charging. 2.0.1 carries a more capable smart charging profile model, useful for operators managing load across several chargers on a shared connection.

A realistic timeline

For a mid-size operator, a full migration typically runs 6 to 12 months, broken into five phases.

1. Discovery and audit (2 to 4 weeks). Inventory every charger, its firmware version, its OCPP support, and the hardware vendor's 2.0.1 roadmap. This step alone surfaces most of the risk in the project.
2. Central system upgrade (6 to 10 weeks). Your backend, whether a commercial CPMS or a custom system, needs to speak OCPP 2.0.1 alongside 1.6 during the transition, not instead of it.
3. Firmware coordination (8 to 16 weeks, runs in parallel). Every charger vendor ships 2.0.1 firmware on its own schedule. This is usually the longest pole in the project, and the one operators underestimate most.
4. Testing (4 to 6 weeks). Real sessions on real chargers, not a simulator, covering authorization, remote start and stop, firmware update flows, and failure recovery.
5. Phased rollout and decommission (4 to 8 weeks). Sites move in batches. Legacy 1.6 support stays live until the last site cuts over, then comes down.

Where migrations go wrong

• Firmware fragmentation. A fleet with five hardware vendors means five different 2.0.1 firmware timelines, and one laggard vendor can stall the entire rollout if it is not identified in week one.
• No rollback plan. Cutting a site over without a tested path back to 1.6 turns a firmware bug into a site outage.
• Payment integration bolted on late. Card reader integration for 50kW+ chargers gets treated as a separate project instead of part of the same central system work, which roughly doubles the integration effort.
• DATEX II reporting added after go-live. Building the reporting pipeline once the central system is already live and stable is far cheaper than retrofitting it under deadline pressure.
• Treating it as a firmware update. The hardest part of a 2.0.1 migration is rarely the firmware. It is the central system, the certificate management, and the testing discipline around them.

A practical checklist

1. Inventory every charger by hardware vendor, model, and current firmware version.
2. Get a written 2.0.1 firmware commitment date from each vendor.
3. Confirm your central system, or your vendor's roadmap, supports OCPP 2.0.1 and dual-protocol operation during transition.
4. Scope ISO 15118-2 certificate provisioning alongside the protocol upgrade, not after it.
5. Build the DATEX II reporting pipeline against the new central system before go-live, not after.
6. Plan card payment reader integration for every site rated 50kW and above in the same project.
7. Test on real hardware before the first production site cuts over.
8. Roll out in batches with a tested rollback path for each one.

Why AFIR sets the deadline, not the vendor

The three dated AFIR obligations, covered in full in our AFIR compliance guide, are what turns this from a nice-to-have upgrade into a project with a hard date. Operators who start the audit phase now have time to run a proper phased rollout. Operators who wait until the deadline is close end up compressing testing and rollback planning, which is exactly where migrations fail.

Digiton runs fixed-scope OCPP 1.6 to 2.0.1 migrations for small and mid-size charge point operators. See our EV charging and OCPP integration practice, or read our comparison of building a custom platform against buying an off-the-shelf CPMS if you are also weighing whether to migrate your existing system or replace it outright.

Frequently asked questions

Related