OCPP 1.6 to 2.0.1 Migration: A Field-Tested Runbook

Why OCPP 2.0.1 Is No Longer Optional

Broad regulatory shifts have a way of catching operators off guard. The year 2025 marks a hard turning point for charge point networks. Here is why putting this migration off is no longer defensible:

• The Protocol Shift: For nearly a decade, CPOs held on to OCPP 1.6 as a durable long-term standard. Its flat two-tier device model served simple AC deployments well. Modern high-power DC hubs with centralized power cabinets and localized energy management systems have completely outgrown it.
• Financial Exposure: Networks like EvnetNL still process over 10,000 weekly transactions consuming 80,000 kWh of energy entirely on legacy 1.6 networks. Every one of those transactions now falls outside the qualifying criteria for major public funding mechanisms.
• Procurement Reality: Only 3 percent of charge networks currently run on a single unified platform, leaving massive structural room for improvement. IEC 63584:2024 has made the remaining fragmentation legally and commercially untenable. The planning takes work, but the payoff shows up fast when carried out correctly.

What Is IEC 63584:2024 and What It Changed for Procurement

• From Consortium to International Standard: Before IEC 63584:2024, OCPP was a consortium specification. Public sector tenders heavily favor standards published by recognized global bodies like the IEC to prevent vendor lock-in, making the ratification a hard procurement gate, not a soft recommendation.
  
• Regulatory Codification: The Dutch NTA 8043:2024 already states that IEC 63584:2024 requirements prevail entirely over OCPP 1.6 mandates. The EU AFIR regulation calls for seamless local payment and ad-hoc charging across European corridors. IEC 63584 meets these requirements natively. OCPP 1.6 cannot.
  
• Subsidy Exclusion in Practice: Procurement officers are now using IEC 63584 as a hard filter. Hardware that fails to meet the standard is being shut out of public subsidy eligibility, closing the loophole that previously let vendors ship fragmented OCPP dialects under vague open standard compatibility language.

2025 RFP Language We're Now Seeing in the US

• NEVI-Driven Specificity: Driven by the National Electric Vehicle Infrastructure (NEVI) Formula Program, state agencies and utility companies are rolling out highly specific, legally binding contractual language designed to keep stranded assets out of public charging networks.
  
• The No Site Visit Mandate: Documents from the California Energy Commission explicitly require vendors to show that hardware can move to OCPP 2.0.1 and ISO 15118 without additional fees, tools, or site visits. This pushes OEMs to build solid OTA update mechanisms with enough edge-compute headroom for mTLS and complex JSON parsing.
  
• Hardware Eligibility Cutoff: Older AC and DC chargers without the volatile memory, processing cores, or hardware security modules needed to clear this bar are now locked out of public funding. The financial risk of firmware obsolescence has shifted entirely from the network operator back onto the hardware manufacturer.

The 9 Capability Deltas to Look Out for in Production

A solid migration depends on fully grasping what has changed at the architectural level. In 2025, these deltas mark a clear break from every assumption baked into the legacy 1.6 stack. Picking the right ones to prioritize spells out the full scope of your engineering effort.

Device Model and DataTransfer Cleanup

OCPP 1.6 worked with only two operational tiers: Station and Connector. This flat layout fell apart for modern DC fast-charging hubs where centralized power cabinets dynamically route liquid-cooled current to multiple dispensed terminals. 

1. Under 1.6, restarting a single faulty power module without rebooting the entire station and cutting off all active sessions was not possible.
   
2. OCPP 2.0.1 swaps this out for a rigid three-tier hierarchy: Station, EVSE, and Connector. Operators can now pinpoint and act on specific sub-components without touching other live sessions.
   
3. At the same time, 2.0.1 shuts down the DataTransfer loophole OEMs exploited to push proprietary unstructured JSON through custom frames.
   
4. All telemetry must now map into the extended Device Model. This strict schema check knocks out significant portions of most legacy codebases.

ISO 15118 Hooks, Plug and Charge Readiness

ISO 15118 sets out the digital communication standard between the EV and the grid. Its primary feature, Plug and Charge, removes the need for RFID cards, apps, and credit card terminals entirely.

The vehicle and charger sort out mutual authentication on their own upon cable connection and kick off power transfer without any user input.

1. OCPP 1.6 cannot natively handle ISO 15118 payloads. Some operators got around this by reading unencrypted vehicle MAC addresses, a method that is easily spoofed.
   
2. OCPP 2.0.1 brings in native standardized message hooks to take care of the full Certificate Signing Request and Revocation List lifecycle directly over the WebSocket. 
3. For operators building net-new firmware, adding these hooks from the start is the only workable path to meeting public funding mandates.

Smart-Charging Profile Changes

By 2026, the main challenge for fleet depot operators managing 20 to 50 electric trucks at once is not peak charging speed. Cost-efficient power orchestration across concurrent sessions, to stay clear of punitive utility demand charges, is where the real pressure sits.

• OCPP 1.6 offered basic smart charging via static SetChargingProfile messages, capped at simple power limits and time windows wholly insufficient for BESS coordination or sub-second grid response.
  
• OCPP 2.0.1 brings in a multi-dimensional composite schedule engine that pulls together multiple competing profiles at once and applies the lowest value across all input sources to keep physical safety and grid compliance in check.
  
• Dynamic pricing signals can now be sent directly to the charger LCD display, something 1.6 could not do at all.

Security Profile 3 - Mutual TLS Expectations

OCPP 1.6 frequently ran over unencrypted HTTP or basic WebSockets using plaintext passwords and local RFID whitelists. This setup left networks wide open to spoofing, billing data tampering, and Man-in-the-Middle attacks across public charge points.

• OCPP 2.0.1 makes TLS 1.2 and 1.3 mandatory without exception and brings in three tiered Security Profiles.
  
• Security Profile 3 calls for Mutual TLS, meaning the CPMS also checks each EVSE identity via client-side X.509 certificates before any WebSocket connection goes through.
  
• Every charger must generate an asymmetrical keypair, store the private key in a hardware secure element, and swap out certificates via OTA without dropping live connectivity. Hardware without HSMs cannot clear this bar through firmware changes alone.

The Entrans 6-Phase OCPP Migration Runbook

A disciplined phase-gate structure is the difference between a controlled transition and a catastrophic production outage. Entrans has carried out this runbook across diverse fleet deployments, from urban AC networks to high-power DC highway corridors, and the phases below consistently deliver certified, revenue-safe migrations.

Phase 1 - Gap Audit and PICS Delta

Every migration kicks off with a full gap audit and a Protocol Conformance Statement (PICS) delta.

Engineering teams systematically work through the current 1.6 stack against Part 6 of the official 2.0.1 documentation, identifying every functional, cryptographic, and hardware gap.

This phase also checks raw hardware readiness. If an older AC EVSE cannot handle continuous mTLS and complex JSON parsing due to limited memory or processing cycles, the audit flags it for legacy network grandfathering before any engineering spend is committed.

Phase 2 - Dual-Stack Firmware Build

With the PICS delta in hand, development moves on to building a dual-stack architecture capable of holding up mixed-fleet operations through at least 2030. 

• This phase builds a routing proxy that picks up the protocol version during the initial WebSocket handshake and routes traffic accordingly.
  
•  In 1.6, managing a session lifecycle required over ten separate messages.
  
• OCPP 2.0.1 rolls this into a unified, continuous TransactionEvent loop, cutting data overhead and removing state desynchronization across the fleet.

Phase 3 - Staged Rollout With Shadow CSMS

Pushing a restructured protocol straight into a live revenue-generating environment is too risky. 

• Phase 3 runs a Shadow CSMS that passively mirrors telemetry from a beta-enrolled EVSE subset.
  
• The primary legacy CSMS keeps handling live billing and authorization via 1.6, while the shadow backend checks Device Model mapping.
  
• It then tests telemetry compression, and puts the TransactionEvent lifecycle through its paces in real-world conditions without touching active customer sessions or financial transaction records.

Phase 4 - OCTT Pre-Test

Before formal certification, teams run thorough internal validation using the Open Charge Alliance OCPP Compliance Testing Tool. The OCTT checks firmware adherence across all 64 distinct OCPP 2.0.1 messages. 

• Because official OCTT access carries significant cost, Entrans builds schema validators into CI/CD pipelines and draws on community-built browser-based tools for draft-06 JSON schema validation.
  
• This phase specifically catches the muscle memory errors where developers carry over 1.6 logic into 2.0.1 payloads.
  
•  Skipping it guarantees lab failure and costly timeline delays.

Phase 5 - OCA Certification at DEKRA / DNV / KSGA

Formal certification is the final seal of interoperability and a legally binding prerequisite for NEVI funds and municipal utility contracts. 

• Phase 5 sends finalized hardware and firmware to an OCA-accredited laboratory such as DEKRA, DNV, or KSGA. Vendors must show up with complete OCTT self-test logs, Device Model architectural diagrams, and full PKI provisioning workflows.
  
• A severe global shortage of accredited labs is currently stretching out queue times. Teams that skip pre-test documentation push their wait time up significantly.

Phase 6 - Fleet Cutover and Rollback Policy

The final phase moves the production fleet over from 1.6 to 2.0.1. Because the protocols run on entirely different state machines, the cutover is a binary, all-or-nothing event for each individual EVSE. 

• A charger cannot communicate via both protocols over a single WebSocket connection at the same time.
  
• A failsafe A/B partition rollback policy built into the hardware bootloader automatically falls back to the stable 1.6 image if the 2.0.1 firmware cannot get through its mTLS handshake, keeping remote sites from going dark.

7 OCTT Failures We See Most Often

Moving from the loose structure of 1.6 to the rigid JSON schemas of 2.0.1 consistently brings to light the same architectural flaws in legacy codebases. These seven failure modes make up the vast majority of lab rejections Entrans catches during Phase 4 pre-testing.

1. Deprecated StartTransaction Calls. The most common muscle-memory error. Developers try to kick off sessions using the legacy StartTransaction message that was completely removed in 2.0.1. Firmware logic must be rewritten to use the unified TransactionEvent loop with the correct TriggerReason enumerator such as CablePluggedIn or Authorized.
   
2. Malformed idToken Types. In OCPP 1.6, the idToken was commonly passed as a plaintext string. In 2.0.1, a raw string triggers immediate schema rejection. Developers must set up the idToken as a JSON object with the correct type metadata such as ISO14443, Central, or Local.
   
3. Invalid chargingStation Object Structure. The OCTT frequently flags flat topologies in the BootNotification payload where legacy code maps a two-tier architecture. The database must be rewritten to set up the three-tier Device Model with Connectors correctly nested under their EVSE parent nodes.
   
4. Missing Variables in Device Model Initialization. Firmware often drops mandatory standard variables during boot database compilation, throwing missing property exceptions. A strict catch-and-aggregate function must run during the bootloader sequence so all physical sensors map to the mandatory 2.0.1 logical definitions.
   
5. Misuse of the DataTransfer Payload. Passing proprietary JSON structures through the DataTransfer mechanism throws immediate parsing errors during compliance checks. All proprietary telemetry must map into the extended Device Model variables rather than falling back on the now-closed legacy data loophole.
   
6. WebSocket Ping/Pong Disconnects. Under mTLS cryptographic load, lower-tier edge devices run into latency CPU spikes that cause them to miss WebSocket Ping/Pong heartbeat timeouts. The fix calls for trimming down the TLS handshake via session resumption and pulling the WebSocket keep-alive threads away from blocking I/O operations in the embedded application.
   
7. eventNotificationType Optionality Mismatches. Marking fields as mandatory instead of optional, such as setting eventNotificationType as required in NotifyMonitoringReport, triggers strict schema rejection. The schema validation engine must line up with the draft-06 JSON schema optionality rules to avoid nullability constraint failures.

Realistic Timeline and Team Shape

• Phase 1 - Gap Audit (4 to 6 weeks): Requires one senior protocol architect and one embedded firmware engineer. The audit cannot be handed off to engineers who have not worked closely with the full 2.0.1 specification. Errors at this stage carry forward through every subsequent phase and push migration costs up sharply.
  
• Phase 2 - Dual-Stack Build (8 to 16 weeks): The most engineering-intensive phase. Requires two to four firmware developers, a backend CSMS engineer for the routing proxy, and a QA engineer building schema validation into CI/CD. Teams that understaff this phase consistently fall behind on their certification window by months.
  
• Phase 3 - Shadow CSMS (4 to 8 weeks): Requires a DevOps engineer keeping the parallel backend running alongside the firmware team for edge case debugging, specifically offline transaction buffering and network blackout simulation before any public exposure.
  
• Phase 4 - OCTT Pre-Testing (2 to 4 weeks): Iterative testing cycles whose depth directly determines Phase 5 lab time. Teams that cut this phase short consistently end up paying for it in certification rework at DEKRA, DNV, or KSGA and have to go back to the end of the queue.
  
• Phase 5 - OCA Certification (6 to 12 weeks): Currently stretched by a severe global shortage of accredited testing labs. This timeline cannot be shortened by engineering effort alone. Submit documentation early and confirm OCTT logs are complete before joining any lab queue.
  
• Phase 6 - Fleet Cutover (4 to 8 weeks rolling): Rolled out geographically across low-utilization windows. Never try a simultaneous full-fleet cutover regardless of confidence in the OTA mechanism or the Shadow CSMS validation results from Phase 3.

When to Migrate to 2.1 Instead: A Decision Tree

• If your network serves public highway corridors or urban retail AC charging: Move to 2.0.1 now. IEC 63584:2024 compliance is required for public funding access. Do not hold off for 2.1. 2.1 is not yet ratified as an IEC standard, and bypassing 2.0.1 means giving up every current public funding mechanism available.
  
• If your network is a commercial fleet depot planning V2G by 2027 or later: Start the 2.0.1 gap audit and dual-stack firmware build right away, but lay out the firmware with modular protocol handlers that can take on the 2.1 state machine as a phased extension rather than a full second rewrite.
  
• If your OEM roadmap targets bidirectional charging and OpenADR 3.0 demand response natively: Engage with OCA 2.1 working groups now while also working through the 2.0.1 migration. These are not competing timelines. 2.1 is tomorrow's competitive advantage, but 2.0.1 is today's non-negotiable compliance baseline.
  
• If your existing hardware lacks the HSMs or processing overhead for 2.0.1 mTLS: The hardware refresh decision must be made now regardless of whether the target is 2.0.1 or 2.1. Firmware cannot work around a hardware constraint, and no phase in any migration runbook changes that engineering reality.

Partnering With Entrans for OCPP 1.6 to 2.0.1 Migration

Entrans engineers work through the full Phase 1 gap audit against your existing 1.6 stack, producing a structured PICS delta that maps every functional, cryptographic, and hardware gap to a prioritized remediation plan with hardware eligibility decisions included upfront.

Entrans handles the submission process with DEKRA, DNV, and KSGA, including queue management and documentation preparation, significantly cutting down the extended wait times driven by the current severe global shortage of accredited testing facilities.

See how we delivered a certified OCPP 2.0.1 migration for a real EV charging network. Read the Case Study.

Want to know exactly where your current 1.6 stack stands? Book a free gap audit call with Entrans.