OCPP 2.0.1 Migration Playbook for Indian Operators: When to Move, What Breaks, What's Worth It

Every Indian operator running an OCPP 1.6-J fleet eventually asks: when do we move to 2.0.1? Vendors push it because they sell new firmware. Standards bodies push it because it's the future. Your CFO pushes back because the existing fleet works fine. We've now done one full operator migration and a partial second; here's the practical answer.

The 60-second answer

• If your installed fleet is under ~50 chargers and growing: stay on 1.6-J for 12-18 more months. Migration ROI doesn't justify the engineering cost yet.
• If you're at 100+ chargers and signing fleet B2B contracts: start the dual-stack work now. Plan for a 12-18 month transition, not a flag-day cutover.
• If you're scoping a new operator from scratch in 2026: design the CSMS dual-stack from day one. The architecture cost is small early; painful later.
• ISO 15118 plug-and-charge in India is still 12-24 months away from being commercially load-bearing. Don't migrate just for plug-and-charge; you'll be early.

What 2.0.1 actually changes (the honest list)

Things that meaningfully matter

• Device data model — variable read/write via Get/SetVariables instead of bespoke ChangeConfiguration keys. Massively cleaner once you have multiple charger vendors. Pays off at ~10+ vendors.
• Security profiles — built-in TLS, key management, secure firmware updates. 1.6-J has these too, but as an afterthought; 2.0.1 makes them first-class.
• Smart charging improvements — better composite-schedule semantics, hierarchical charging profiles, support for solar/load-balancing scenarios that were possible-but-painful in 1.6.
• ISO 15118 plug-and-charge — driver authentication via certificate exchange when the cable is plugged in. No card, no app. Genuinely magical UX. Requires a certificate authority infrastructure that India is just starting to build.

Things vendors hype that don't matter much yet

• Reservation v2 — improved reservation semantics. Reservation usage in India is under 5% even on premium operators. Don't migrate for this.
• Display messages — operator can push messages to the charger LCD. Useful for outage notifications, but you can already do this via vendor-specific extensions in 1.6.
• ID Token Authorization — improved auth token handling. Marginal improvement over 1.6's IdTag mechanism unless you're doing something exotic.

Things that get harder in 2.0.1

• Spec complexity — 2.0.1 is roughly 4x the spec surface of 1.6. Your CSMS engineers need to read more, test more, and think more.
• Vendor maturity — even in 2026, most Indian charger firmware is more battle-tested on 1.6 than 2.0.1. Bug reports take longer to get fixes.
• Interop testing — every new firmware revision needs revalidation against your CSMS. The test matrix grows.

The dual-stack architecture (recommended)

Do not flag-day migrate. Do not plan a cutover weekend. The right architecture supports OCPP 1.6-J and 2.0.1 simultaneously, with each charger speaking whatever version it speaks today, and you upgrading individual chargers (firmware-update or replacement) at your own pace over 12-18 months.

How to structure it:

1. WebSocket gateway accepts both `ocpp1.6` and `ocpp2.0.1` sub-protocols, routes to per-version handlers
2. Per-version handler translates incoming OCPP messages into your internal Charging Event format — every downstream system (billing, admin, mobile app) only knows the internal format
3. Outgoing operator-initiated commands (RemoteStart, Reset, ChangeConfiguration) route through a per-version translator that emits the correct dialect
4. Charger version is recorded at BootNotification time and pinned to the connection — never assume mid-session
5. Your admin panel filters chargers by version so ops can plan upgrades

If your existing 1.6-J CSMS is well-architected, this is roughly 6-10 weeks of engineering. If it's not — if your billing engine reads OCPP messages directly, if your mobile app calls OCPP-specific endpoints — it's 12-20 weeks because you're untangling concerns first.

ISO 15118 plug-and-charge in India: real status

The big-bang reason vendors will push you to migrate is plug-and-charge. The reality in India in 2026: the certificate authority infrastructure that makes plug-and-charge work doesn't exist commercially yet. Hubject and Eonti operate the CA backbone in Europe; India has no equivalent operator. ARAI and BIS are reportedly in early discussions; nothing live as of mid-2026.

What this means in practice: you can deploy a 2.0.1 + ISO 15118-capable charger today, but no Indian car can actually plug-and-charge against it because no CA-issued certificates exist for Indian VINs. The first Indian commercial PnC pilots will likely run in 2027-2028. Migrating in 2026 specifically for PnC is premature.

Hardware: which 1.6 chargers can be upgraded?

Most chargers shipped 2022 or later can be upgraded to 2.0.1 firmware in-place. Older chargers (2020 or earlier) often have insufficient flash/RAM headroom for the larger 2.0.1 stack and need either replacement or a controller-board swap.

• Tata Power EZ-Charge units (DLink-OEM hardware) — most 2023+ revisions support 2.0.1 firmware via OTA
• Servotech, Exicom, Mass-Tech — newer revisions OTA-upgradeable; older fleet may need replacement
• Delta, ABB, Siemens — generally upgradeable across the install base; expect ~₹15-50K firmware-update fee per charger from the vendor for in-place upgrades
• ChargeZone, EVRE in-house designs — vendor-specific; ask before assuming

Always test the upgrade on a single charger first. Always have a rollback plan. We've seen one upgrade brick a charger because the firmware-update package was for the wrong hardware revision — vendor support eventually shipped a recovery image, but the charger was offline for 6 days.

The migration sequence we'd recommend

1. Audit your fleet — record current firmware version, hardware revision, OCPP version, and last successful heartbeat for every charger. Build a migration spreadsheet.
2. Build the dual-stack CSMS — 6-10 weeks of engineering. Ship it behind a feature flag. Test against your 1.6-J fleet (it should be a pure pass-through).
3. Pick one site as pilot — preferably a low-traffic site you can take offline if needed. Upgrade one charger to 2.0.1, validate end-to-end (auth, transaction, billing, ops dashboard).
4. Add 5 more chargers to the pilot. Run for 30 days. Measure session success rate, MeterValues fidelity, billing accuracy. Compare against control 1.6-J chargers.
5. Roll out to 20% of fleet. Hold for another 30 days. Watch for vendor-specific quirks that didn't show up in pilot.
6. Remaining 80% rolled out over 6-12 months as scheduled site visits or natural firmware updates.

Total elapsed time for a 100-charger fleet: 9-15 months. CSMS engineering effort: 8-14 weeks. Per-charger upgrade time: 30-90 minutes including validation.

What this costs

• CSMS dual-stack engineering: ₹8-15L for a clean architecture, ₹15-30L if you're untangling existing concerns
• Per-charger firmware upgrade: ₹15-50K (vendor fee) + 30-90 min ops time per charger
• Hardware replacement (older units that can't be upgraded): ₹4-10L per charger depending on power rating
• Lost revenue during upgrade: typically 0 (chargers offline for under 2 hours)
• Testing & validation: 2-4 weeks of QA across the upgrade window

When NOT to migrate

• You have under 50 chargers and your roadmap is 'ship more chargers' for the next 12 months — focus on growth, not protocol upgrades
• Your CSMS architecture is currently OCPP-coupled (billing reads OCPP frames directly) — fix the architecture first, then migrate; doing both at once will hurt
• Your customer base is purely residential / B2C and doesn't need plug-and-charge or smart charging — there's no user-visible benefit to 2.0.1 in that profile
• You're 6 months from an exit event — protocol migrations are not what the acquirer is paying for

When to start now

• You're past 100 chargers and signing fleet B2B contracts where smart charging or hierarchical load management matters
• You're operating multi-vendor (3+ charger vendors) and the cost of vendor-specific OCPP quirks is becoming significant — 2.0.1's standardized device data model meaningfully reduces this
• You're scoping a new operator from scratch — design dual-stack from day one, even if you ship 1.6-J first
• You have a competitor positioning on plug-and-charge and you need to be 12 months ahead of when it goes commercial in India