Upgrading EV Charger Firmware to a Newer OCPP Version
Moving from OCPP 1.6J to 2.0.1 is not a version bump. The message set, the data model and the device model are different enough that most of the protocol layer is rewritten rather than extended. The useful first question is not how, it is whether your installed hardware can carry it at all.
Migrating an existing charger product to a newer OCPP version: what changes in the firmware, what the installed fleet can absorb, how both versions are run side by side during a transition, and the cases where the honest recommendation is to leave 1.6J where it is.
Plan an OCPP 2.0.1 moveFor A manufacturer or operator whose product speaks OCPP 1.6J and whose customers or tenders are now asking for a newer version.
What actually changes between 1.6J and 2.0.1
The two are related in intent and different in construction. Treating 2.0.1 as 1.6J with more messages is the assumption that makes these projects overrun.
Swipe to compare
| Area | OCPP 1.6J | OCPP 2.0.1 |
|---|---|---|
| Device model | Implicit. Connectors and a charge point | Explicit component and variable model that must be declared |
| Configuration | Flat key and value list | Structured variables with attributes and characteristics |
| Transactions | Start and stop with a transaction id | Event based, with a defined lifecycle and richer reasons |
| Security | Optional, largely deployment specific | Defined profiles including certificate based authentication |
| Smart charging | Basic profiles | Substantially extended, with clearer limits and hierarchy |
| Diagnostics | Log upload | Structured monitoring, event and reporting model |
The device model is the item most often underestimated. It is not a formatting change, it is a requirement to describe the product in a structured way that many existing firmware designs have no internal representation for.
The question to settle first
Before any firmware work is scoped, establish whether the hardware in the field can carry the new stack at all. Three constraints decide it.
- Flash and RAM headroom. A 2.0.1 stack with security profiles is materially larger than a 1.6J one, and many deployed controllers were specified with little room left
- Cryptographic capability. Certificate based security needs both the code space and enough processing to complete a handshake within the timeouts, and on some older controllers it does not fit
- A working update path. If the fleet cannot be updated remotely and verified, a protocol migration is a manufacturing change rather than a fleet upgrade
Where the installed hardware fails any of these, that is not a failed project. It means the upgrade applies to new production and the installed base stays on 1.6J, which is a perfectly workable position and much cheaper than discovering it halfway through.
Running both versions during the transition
No real fleet migrates in a weekend. The practical arrangement is a charger that can speak either version, with the version settled at connection time rather than assumed.
OCPP negotiates the version through the WebSocket subprotocol header before any OCPP message is exchanged, so a unit can offer both and let the backend choose. That lets hardware move ahead of platforms, or platforms ahead of hardware, without either side waiting for the other. It costs firmware size, which loops back to the headroom question above.
How the migration runs
- 1
Feasibility
Headroom, crypto capability and update path assessed against the actual controller. This is a short piece of work and it decides everything after it.
- 2
Device model design
Describing the product in the 2.0.1 component and variable model. Done early, because it constrains the firmware architecture rather than sitting on top of it.
- 3
Stack integration
The protocol layer built or ported, with the hardware abstraction kept intact so existing charging behaviour is not disturbed.
- 4
Interoperability testing
Against the specific platform and release you will run, not against the specification alone. Compliance and interoperability are different properties.
- 5
Staged fleet release
A pilot group, monitored, with a defined rollback, before anything goes fleet wide.
When we would tell you not to do it
There are good reasons to migrate and a common bad one, which is that a tender document asked for a version number without anyone establishing why.
- If nothing in your operation needs what 2.0.1 adds, and no customer contract requires it, 1.6J is a supported and widely deployed protocol that will not stop working
- If your installed controllers cannot carry the stack, migrating new production only is usually the right answer rather than a hardware refresh justified by protocol alone
- If the real requirement is better security, some of that is achievable on 1.6J deployments through transport and network design, at a fraction of the cost
We build these stacks, so recommending against one costs us the work. It is still the right advice when the driver is a line in a specification rather than something the operation actually needs.
Want this applied to your own site?
Plan an OCPP 2.0.1 moveRelated
Technically reviewed by Deepu Joy, Director of Products and Delivery. Last reviewed 2026-09-10.
Frequently asked questions
Can our existing chargers be upgraded, or only new ones?
It depends on flash and RAM headroom and on whether the controller can do certificate based crypto within the protocol timeouts. That assessment is short and should come before anything else is scoped.
Can a charger support 1.6J and 2.0.1 at the same time?
Yes. The version is negotiated in the WebSocket subprotocol header before any OCPP message is exchanged, so a unit can offer both and let the backend choose. It costs firmware size.
What about OCPP 2.1?
Our own 2.1 work is in development. Where a project needs it, the migration path from 2.0.1 is considerably shorter than the one from 1.6J, because the device model is already in place.
How long does a migration take?
It depends almost entirely on how the existing firmware is structured. Firmware with a clean separation between protocol and hardware layers migrates far faster than firmware where protocol handling is spread through the application.
Is OCPP 1.6J obsolete?
No. It is the installed base across most of the world and it is not being switched off. New procurement increasingly specifies 2.0.1, which is a commercial reason to support it rather than a technical one to abandon 1.6J.
Considering a move to OCPP 2.0.1?
Start with the feasibility question. Tell us your controller, your flash and RAM headroom, and whether the fleet updates remotely today.
Plan an OCPP 2.0.1 move