Cloud, on-premise, or hybrid is an architecture decision, not a pricing question.
Evaluations of EV charging software usually revolve around features: load management, billing, roaming, reporting. The deployment model, by contrast, often comes up as an afterthought – yet it is the decision with the longest half-life. Whether the platform runs as a cloud service, in the operator's own data center, or as a hybrid architecture determines for years who holds the data, who carries operational responsibility, and how difficult a later switch becomes.
The three models are quickly defined. Cloud means the vendor operates the software as a service: the operator works through a browser and APIs, and charge points connect to the vendor's backend over the internet. On-premise means the software runs on the operator's own infrastructure – in a company data center or on servers at the site – operated by an in-house team or a contracted service provider. Hybrid combines the two: central administration and analytics in the cloud, plus a local component at the site that keeps critical functions running even without an internet connection.
Blanket recommendations do not help here, because the models differ in character rather than in quality. Four criteria make the difference tangible: how costs develop over the years, who controls operational and billing data, the ongoing operational effort, and the ability to switch vendors later without rebuilding everything. Operators who assess these four points honestly almost always arrive at a clear preference.
An honest comparison: cost profile, data sovereignty, operations, exit.
The cost profiles are fundamentally different. Cloud models start cheap and are billed per charge point per month – costs grow linearly with the fleet and never stop. On-premise inverts the relationship: licensing, hardware, and rollout cost money upfront, and an operations team adds fixed costs, but expenses climb far more slowly as the fleet scales. Neither model is inherently cheaper; the tipping point depends on fleet size, time horizon, and whether an IT operation already exists.
On data sovereignty, the differences are plain. In the cloud, transactions, meter values, and user data sit with the vendor – which makes data center location, data processing agreements, and administrative access the questions that matter. On-premise keeps the data inside the operator's own network, which is often decisive for factory sites, bus depots, and utilities with strict IT policies. Operational effort, however, disappears in neither model: in the cloud it shifts toward contract, interface, and incident management; on-premise it covers updates, security patches, certificates, backups, and on-call duty.
Exit capability is the most underestimated criterion. OCPP as an open standard helps: charge points can be repointed to a different backend through configuration, as long as the vendor does not artificially obstruct it. The real lock-in lives elsewhere – in historical transaction data, tariff models, user accounts, and proprietary extras that cannot be exported. Exit capability is therefore less a property of the deployment model than a property of the software and the contract.
- Cost profile: cloud scales with the number of charge points, on-premise with team and infrastructure.
- Data sovereignty: clarify data center location, processing agreements, and admin access upfront.
- Operational effort never disappears – it only shifts between the vendor and the in-house team.
- Exit capability depends on open interfaces and complete data export, not on the model.
- OCPP makes charge points portable – the lock-in sits in data, tariffs, and proprietary features.
Depot, public CPO, municipal utility: three profiles, three answers.
For depot operators, charging is part of the operational schedule: vehicles must be charged and ready in the morning, or routes do not run. Billing is usually internal or simply structured, and roaming rarely plays a role – but tolerance for outages is close to zero. An internet outage must stop neither load management at the grid connection nor the release of vehicles. Depots therefore almost always call for a model with a local component: hybrid, or fully on-premise, depending on the IT landscape.
Public CPOs have the inverse profile. Many distributed sites, ad-hoc payment under AFIR, roaming via OCPI, and legally compliant billing demand a backend that scales quickly and evolves constantly – which makes cloud the natural model. A brief backend outage is annoying but rarely existential, because charge points finish active sessions locally. The critical topics here are SLAs, incident processes, and the exit question, since dependence on the vendor grows with every new site.
Municipal utilities sit in between: public charging, their own depots, workplace charging, and often charging services for business customers – inside an IT environment with long-established systems and regulatory requirements for energy suppliers. Many utilities run their own data centers and IT operations, which makes on-premise or a private cloud realistic. In practice, many settle on hybrid architectures: a central platform under their own control, local resilience at business-critical sites, and clearly defined interfaces to billing and customer systems.
Hybrid patterns: control from the cloud, resilience on site.
The most common hybrid pattern separates administration from real time. Configuration, reporting, tariffs, and user management run centrally – in the cloud or in the operator's data center. On site, a local instance terminates the OCPP connections of the charge points and makes every decision that cannot wait for a round trip. If the link to the central platform drops, charging at the site continues unchanged.
Three functions belong on the local layer in such an architecture, without exception. Load management at the grid connection needs short control cycles and must not depend on the latency or availability of an internet link – all the more when PV systems or batteries are part of the control loop. Authorization must work offline through local lists, so that known vehicles and charging cards can charge without the backend. And meter values and transactions are buffered locally and delivered in full once the connection returns, keeping the billing chain intact.
In all honesty, hybrid is also the most demanding model. Two software layers need versioning, monitoring, and testing, and responsibilities must be unambiguous: which decisions the central platform makes, which ones the site makes, and what happens with conflicting states after a reconnect. The effort pays off where a site standstill causes real operating costs – the rule for logistics depots and bus depots, the exception for individual public charging stations.
Selection checklist: ten verifiable questions for vendors.
The following questions are phrased so that the answers can be verified – in a demo, on a test instance, or against a reference architecture. Evasive answers are just as useful a signal as precise ones. Asked early in the selection process, these questions sort the field faster than any feature comparison.
One litmus test deserves particular attention: whether the cloud, on-premise, and hybrid variants really are the same software release, or whether on-premise ships as a stripped-down edition. This is why we built our own building blocks – OCPP Broker, OCPP Server, and the modular CPMS – to run in all three deployment models with an identical feature set. The deployment model should be an infrastructure decision made by the operator, not a feature decision made by the vendor.
- Does the software run in cloud, on-premise, and hybrid with an identical feature set – verifiably from the same release?
- Which functions keep running during an internet outage at the site: load management, authorization, active charging sessions?
- Through which interfaces and in which formats can transactions, meter values, and configuration be exported in full?
- Where are the data centers located, and who has administrative access to operational and user data?
- How are charge points moved to a different backend – is an OCPP configuration change enough, or are vendor tools required?
- Which OCPP versions and security profiles are supported, and against which real devices were they tested?
- How does the on-premise update process work: frequency, downtime windows, responsibility for patches?
- Which SLAs apply in the cloud, and how are ad-hoc payment and roaming handled during incidents?
- Is legally compliant metering data – such as OCMF-signed meter values under German calibration law – guaranteed across all deployment models?
- What does an exit actually cost: data export, parallel operation during migration, remaining contract terms?