What is the EV charging data problem?
The core problem is access: most CPMS deployments route every transaction, meter reading, and status event through a system you don't operate and into a database you can't query. A CPMS (Charge Point Management System) is the backend that controls your chargers and stores their data, so the data is technically yours, but the means to use it belongs to the vendor.
Your chargers generate genuinely valuable operational data: session duration, energy delivered, idle time, fault patterns, demand peaks. But to reach it, you depend on your CPMS vendor's reporting UI, which was built for their use cases, not yours.
Want to join charging data with your fleet telematics? Run your own demand-forecasting model? Feed real-time session data into your billing system? In most deployments, that data sits behind a fixed export or a rate-limited API, and the joins you actually need are impossible. This is the difference between holding data and owning it. The European Commission's data strategy frames data portability as a precondition for competition, and the same logic applies inside a charging stack: if you cannot move it, you cannot fully use it.
Why don't CPMS vendors solve data lock-in?
They rarely solve it because the incentives point the other way. Switching costs stay low when you can export cleanly and high when your data is trapped in a proprietary schema. Lock-in is good for retention, so most reporting layers are designed for viewing, not extraction.
This isn't malicious. It's the economics of the market. But it has real consequences for operators who need to build on top of their infrastructure. In mixed-fleet rollouts, the failure usually shows up late: a finance team needs eighteen months of session-level data for a tender, and the export tool only returns aggregated monthly totals with no charger or connector granularity. By then the leverage is gone.
The fix is to treat data access as an architecture decision, not a reporting feature. That means asking, before signing, where raw events land and who holds the keys to read them.
What does EV charging data ownership actually mean?
Real ownership means you can access, store, query, and export your core charging data without routing through a vendor-controlled reporting layer. Concretely, it comes down to four properties:
- Raw message access — every OCPP frame, with timestamps, in a format you can query
- Your own schema — not a vendor's reporting schema, but your operational data model
- No intermediary for analysis — direct database access, not an API with rate limits and predefined dimensions
- Portability — if you switch CPMS providers, your historical data comes with you
This sounds obvious. It's surprisingly rare.
To see how these properties map to common vendor patterns, compare the access models side by side:
| Access model | Raw OCPP events | Query layer | Migration export | Practical leverage |
|---|---|---|---|---|
| Vendor reporting UI only | No | Fixed dashboards | Aggregated CSV | Low |
| Rate-limited REST API | Partial | Predefined dimensions | Paged API pulls | Medium |
| Owned storage + read replica | Yes | Direct SQL | Full schema dump | High |
The pattern is consistent: the further down this table you sit, the more of your own operational intelligence you can reach without asking permission.
How an owned-data architecture works
In an owned-data design, every message that passes through the connectivity broker is written to a storage layer you control, rather than only into a vendor's internal database. In practice that means streaming events to your own Postgres database, a data warehouse, or an event stream as they arrive.
The schema is documented and stable. Sessions, transactions, meter values, and status events get normalized into tables you can join and query directly. A read-replica endpoint lets analytics tools connect to the data without an API layer, quotas, or asking permission to run a query. Because the OCPP message frames are persisted with timestamps, you can reconstruct any session end to end, not just read a pre-aggregated summary. If you also roam over OCPI, the CDR and session records land in the same store, so cross-protocol reconciliation stays in one place.
Securing read-replica access
Direct access cannot mean open access. A read replica should be exposed only over a private network or VPN peering, scoped to read-only roles, and limited to the specific tables analysts need. Row- and column-level controls keep sensitive fields out of reach for general reporting accounts, and every connection should be logged. The goal is the convenience of direct SQL with the access discipline of a production system, not a shared admin password handed around the operations team.
Handling GDPR and PII
Charging data is rarely anonymous. RFID tags, account identifiers, and even a home charger's session pattern can identify a person, which makes much of this data personal under the EU GDPR. Ownership therefore comes with obligations, not just freedom. Separate the operational telemetry (energy, faults, connector status) from identifying fields, apply pseudonymisation where you can, and set explicit retention windows so old session records are purged or aggregated on schedule. When you control the store, you can actually enforce a data-processing agreement and respond to access or erasure requests, which is far harder when the records live only inside a vendor's reporting product.
How data migration actually works
Migration is mechanical when the schema is yours and proprietary when it isn't. With owned storage, leaving a platform (or running a second one alongside it) means exporting the same documented tables you already query, then replaying or loading them into the next system. Nothing is locked in a hidden format.
The harder part is operational continuity. A clean migration typically follows three steps:
- Run both layers in parallel — keep the old and new connectivity layers live for a window so active sessions are not interrupted while chargers are re-pointed.
- Bulk-export history first — move historical session, transaction, and meter-value records into the new store as a one-time export before cutover.
- Cut over per site — switch live traffic site by site once the new path is verified, rather than flipping the whole estate at once.
Because the vendor comparison and contract terms decide whether this is even possible, push portability into procurement early rather than discovering an export ceiling mid-cutover. See the legacy CSMS migration plan for the sequencing detail.
The compounding value of clean data
Owned data compounds: operators who hold their own records tend to build better products over time. They catch fault patterns before they become incidents. They identify underutilized chargers before they become stranded assets. They negotiate better energy contracts because they can actually model their demand.
The value isn't in any single query. It's in the accumulation of operational intelligence over months and years. That only happens if the data is yours to begin with, with the schema, history, and access controls under your roof rather than rented from a reporting product.
How should buyers act on data ownership?
Treat data ownership as a first-shortlist criterion, not a late-stage legal review item. It belongs in the architecture and procurement conversation from the very first vendor call, scored alongside protocol support and pricing.
Use the OCPP platform buyer guide to score data portability next to protocol support. Then compare vendor models in the comparison hub and take the commercial discussion to the contact page when you need a migration-safe rollout path.
