⚡ TL;DR – Making the move from OCPP 1.6 to 2.1
If you’re still on OCPP 1.6, you don’t need to drop everything and rebuild. Instead, you need a clear view of which 2.x capabilities matter to your product, a firmware architecture that keeps protocol logic separate from everything else, and a staged plan that lets 1.6 and 2.x coexist, often for longer than you’d expect.
The most common mistake is treating OCPP version choice as a single, all-or-nothing decision. It isn’t. Protect what works, layer in the capabilities your customers and tenders are actually asking for, and design your stack so you’re not rewriting everything every time the standard moves.
Should you move to OCPP 2.1, and how fast?
OCPP 1.6 is still deeply embedded across live charging networks and existing fleets.
However, more tenders and procurement specs now reference OCPP 2.0.1, 2.1, and ISO 15118, which leaves your product team trying to work out whether you’re behind, whether you need a full rewrite, and how much of the newer stack the market genuinely expects today.
That uncertainty has a cost. A bad protocol decision slows firmware delivery, complicates backend integration, bloats your test cycles, and ties you to a design that’s painful to change. For a CTO or Head of Product, the cost shows up in three places: time-to-market, ongoing maintenance, and, on some deals, your tender win rate.
We’ve already covered OCPP implementation basics and the wider UK EV charging standards picture. This goes a level deeper, into the question that actually matters: not “should we support OCPP 2.1?” in the abstract, but how to get there without your team disappearing into protocol work for two years.
What actually changes from 1.6 to 2.1
A lot of the noise around OCPP comes from the version label itself. Your team hears “2.1” and assumes everything needs rebuilding. That’s rarely the right frame.
What matters is the capability set, and whether those capabilities solve real problems for your customers. At a high level, OCPP 2.x delivers:
- Richer device model. A far more structured way to represent charger components, states, and configuration. For OEMs managing complex AC or DC products across multiple customer environments, this shows up as lower support cost and faster issue resolution. Poor observability in 1.6 deployments always catches up with you.
- Stronger security. Certificate handling, stronger authentication, and more disciplined security models are becoming expected, rather than optional. Yes, you can run security profiles on 1.6 and you should, but 2.x raises the baseline significantly. If you're staying on 1.6 for now, the OCA's own OCPP 1.6 Security Whitepaper and its ISO 15118 Plug and Charge application note let you add some of that ground without a full 2.x migration.
- Smarter charging and tariff handling. Not every team needs the full 2.x feature set on day one. OCPP 1.6 already gives you smart charging profiles. OCPP 2.0.1 builds on that by letting the EV feed its own charging needs back into the profile. OCPP 2.1 goes further again with more detailed tariff and cost handling and closer integration with your energy management system. Sort out interoperability, diagnostics, and secure comms before chasing every energy-management use case in the spec.
- Better firmware and diagnostics. Improved remote management, firmware update handling, and observability, things that make your chargers cheaper to support over their lifetime.
- Built for bidirectional charging (V2G). OCPP 1.6 assumes energy only flows from the grid to the vehicle. OCPP 2.0.1 lays the groundwork through ISO 15118 integration, while OCPP 2.1 adds support for bidirectional charging, price-aware scheduling, and closer integration with site energy management systems (EMS). These capabilities are becoming increasingly relevant as utilities, fleets, and commercial sites look to use EVs as flexible energy assets.
Stop asking “how quickly can we say we do 2.1?” Start asking “which 2.x capabilities solve genuine commercial or operational problems for this product line?”
Where teams get stuck
The most common mistake is letting the version number drive the engineering mandate.
Your team feels pressure from tenders, consultants, or end customers who’ve heard 2.1 is the future, and that pressure gets absorbed as a big-bang migration you didn’t need.
Big-bang migrations look neat on paper. In practice, you’re trying to move every charger variant, every feature, and every backend touchpoint in one sweep, test burden explodes, regression risk climbs, and the market doesn’t wait.
The second trap is letting OCPP logic leak through the whole firmware stack. Once protocol assumptions are woven through your charger state handling, diagnostics, and business logic, every change gets expensive. Updating a protocol module is manageable. Touching half the application because a message flow changed is not.
Your team will also underestimate two things consistently: interoperability complexity across live CSMS platforms, and the installed fleet problem. OCPP compliance on paper isn’t the same as reliable behaviour across different operator environments, country-specific requirements, and chargers with patchy comms or old firmware branches.
And the awkward questions usually aren’t about new products. Which chargers can realistically be upgraded? Which should stay on 1.6? Where does backend mapping make sense, and where does it just add technical debt? These are the questions that separate a roadmap that holds up commercially from one that looks good in a slide deck.
A cleaner architecture for the move beyond 1.6
Treat OCPP as a module with well-defined edges, not as something woven through the whole firmware. That sounds obvious. It’s still the discipline that gets dropped first when delivery pressure hits.
Your charger needs an internal state and command model that isn’t defined by whichever OCPP version is active. Your application logic should know what the charger is doing: what states it can enter, what measurements and alarms exist, what actions can be taken. The protocol layer translates between that internal model and the outside world of 1.6 or 2.x messages.
That separation pays off in two concrete ways. First, coexistence becomes realistic: most OEMs will need to support 1.6 and 2.x in parallel for years, not months. Second, the cost of change drops, because you can update protocol support without re-architecting the charger every time the market moves.
Adopting the OCA’s 1.6 whitepapers is a good forcing function here. When we implemented the security and ISO 15118 whitepapers on our own 1.6 stack, the work of pulling that behaviour out from anything version-specific made the later move to 2.x noticeably more straightforward.
A pre-tested OCPP stack can save your team significant time. Our OCPP software is tested against multiple back offices, which matters because protocol complexity is rarely where you want your best engineers’ attention. A good architecture also plans for uneven migration: some new products may justify starting on 2.1 from scratch, while others stay on 1.6 because of hardware constraints, field realities, or customer backend limitations.
Which migration pattern fits your situation?
There’s no single right route. A few patterns tend to work better than the rewrite-everything instinct:
- Keep legacy products on 1.6, build new products on 2.x. Move forward without destabilising your installed base. Legacy products stay stable, and where you need a specific capability, the OCA's 1.6 whitepapers let you add it without a full protocol migration. Your next generation gets the protocol capabilities future customers will ask for.
- Use gateway or backend mapping selectively. Not a magic fix, and it won't give you every benefit of a native 2.x implementation. But for some fleets it's a useful bridge while you work out where the deeper engineering effort actually belongs.
- Smarter charging and tariff handling. Not every team needs the full 2.x feature set on day one. OCPP 1.6 already gives you smart charging profiles. OCPP 2.0.1 builds on that by letting the EV feed its own charging needs back into the profile. OCPP 2.1 goes further again with more detailed tariff and cost handling and closer integration with your energy management system. Sort out interoperability, diagnostics, and secure comms before chasing every energy-management use case in the spec.
- Pilot first, then roll out. Put a subset of chargers or sites on the newer stack and use that to find the real friction: CSMS interoperability quirks, credential handling, the gap between what the standard says and what real operator environments do.
Which pattern fits depends on your fleet size, your ability to update chargers in the field, the maturity of the back-office systems you’re working with, and whether you’re chasing a specific tender or de-risking your next platform.
To help you work through it, we’ve built a free OCPP Migration Decision Matrix, a weighted scoring tool to compare your options against your actual constraints.
Turning standards pressure into a workable plan
Most “standards confusion” is really prioritisation confusion.
You know the direction, but haven’t translated it into a phased plan that engineering, product, and the business can all commit to.
Start with use cases instead of versions. Do you need stronger security for a target market? Better device modelling for remote diagnostics? Write those down in business terms, then map to the protocol capabilities you actually need. Don’t start with “we need to support 2.1” and work backwards.
Keep protocol stack and business logic separate, too: if every protocol decision ripples through billing logic, charger behaviour, and diagnostics, your speed to respond to customer demand drops and your team feels it first.
Define a good-enough roadmap, not a perfect one. Keep 1.6 stable on installed products, add targeted security improvements where they make sense, build the next platform with a path to 2.x, and pilot advanced features before wider release. That kind of staged plan is easier to fund, easier to test, and much easier to explain internally.
This is also where external support makes a genuine difference, particularly if you don’t want to build an OCPP stack from scratch. Our work spans OCPP software, hardware building blocks, and EV charger design support, all aimed at helping product teams move onto a realistic architecture path faster.
What a good outcome looks like
A future-proof charger roadmap doesn’t mean every product runs the newest protocol with every feature enabled. It means your business can respond to new standards, new customer expectations, and new backend realities without reopening the whole system each time.
Your firmware has well-defined boundaries, and your OCPP support stays modular as a result. Your team knows which products stay on 1.6, which move to 2.x, and why, and the migration plan reflects real constraints rather than anxiety about which version number is on the tin.
OCPP 2.1 itself isn’t the risk. Worrying about it is, when that worry causes you to stop shipping, commit to the wrong rewrite, or build a protocol architecture that ages badly. If you’re on a 1.6-based platform and not sure how to move, start with a review of your current architecture, installed fleet, target customers, and what you genuinely need next. The path usually becomes a lot clearer from there.
Work with Versinetic
If your team is deciding whether to stay on OCPP 1.6, move to 2.0.1, or build towards 2.1, we can help you map a realistic route based on your architecture, your fleet, and your commercial goals. That might mean OCPP stack support, Charging Blox hardware building blocks, or a design review that helps you avoid a costly dead end.
Get clarity on your OCPP roadmap
FAQs
No. It’s still widely deployed across live networks and existing fleets. 1.6 won’t vanish overnight, but new capabilities, new tenders, and longer-term roadmap expectations increasingly point towards 2.x. The question is when and how, not whether.
Almost certainly not. Most OEMs are better served by a staged approach where legacy products remain on 1.6 while new platforms, or a selected pilot fleet, move to newer protocol support first. Trying to move everything at once is where projects stall.
It extends DER and V2G-related capabilities, but the practical value for most OEMs is broader. The bigger gains usually come from improved device modelling, stronger security, better diagnostics, and smarter control options, things that make your chargers cheaper to support in the field.
If your current protocol logic is tangled up with charger firmware, then yes, often significantly so. A separate, tested stack reduces engineering risk, simplifies upgrades, and makes it much easier to support multiple back offices or run a staged migration without rebuilding everything. Your firmware engineers stay focused on the application logic that differentiates your product.
That depends on your fleet size, field upgrade capability, CSMS dependencies, and the commercial pressure you’re under. Our free OCPP Migration Decision Matrix is designed to help you score your situation and structure that conversation internally.
Ricardo is a Firmware Engineer at Versinetic, part of the specialist software team developing robust OCPP EV charging infrastructure software.
He is known as a unique engineer who demonstrates a relentless drive to find innovative solutions for complex problems.
Ricardo, a software engineering graduate, was a finalist at the UK’s 2022 BEAMA Awards in the Young Engineer of the Year category, where his professional maturity, engineering excellence and motivation to create a more sustainable future were commended.
Further reading
- https://openchargealliance.org/protocols/open-charge-point-protocol/
- https://openchargealliance.org/wp-content/uploads/2024/03/Whats-New-OCPP-2.1.pdf
- https://openchargealliance.org/wp-content/uploads/2025/11/migrating_charging_stations-v10-1.pdf
- Implementing OCPP Protocol in Your EV Charging Infrastructure
- UK EV Charging Standards 2026 Guide
- EV Smart Charging Software — OCPP & Software Licensing
- Charging Blox for Rapid EV Charging Solution Development
- Charging Points Solutions: OCPP & Software Licensing
.
