Cloud, On-Premise oder hybrid ist eine Architektur-Entscheidung, keine Preisfrage.
Bei der Auswahl von Ladeinfrastruktur-Software wird meist über Funktionen diskutiert: Lastmanagement, Abrechnung, Roaming, Reporting. Die Frage nach dem Betriebsmodell fällt dagegen oft nebenbei – und ist doch die Entscheidung mit der längsten Wirkung. Ob die Software als Cloud-Dienst läuft, im eigenen Rechenzentrum oder als hybride Architektur, bestimmt für Jahre, wer die Daten hält, wer den Betrieb verantwortet und wie schwer ein späterer Wechsel wird.
Die drei Modelle sind schnell definiert. Cloud bedeutet: Der Anbieter betreibt die Software als Dienst, der Betreiber nutzt sie über Browser und Schnittstellen, und die Ladepunkte verbinden sich über das Internet mit dem Backend des Anbieters. On-Premise bedeutet: Die Software läuft auf eigener Infrastruktur – im eigenen Rechenzentrum oder auf Servern am Standort –, betrieben vom eigenen Team oder einem beauftragten Dienstleister. Hybrid kombiniert beides: zentrale Verwaltung und Auswertung in der Cloud, dazu eine lokale Komponente am Standort, die kritische Funktionen auch ohne Internetverbindung weiterführt.
Pauschale Empfehlungen helfen bei dieser Entscheidung nicht, denn die Modelle unterscheiden sich nicht in gut oder schlecht, sondern in ihrem Charakter. Vier Kriterien machen den Unterschied greifbar: der Kostenverlauf über die Jahre, die Hoheit über Betriebs- und Abrechnungsdaten, der laufende Betriebsaufwand und die Fähigkeit, den Anbieter später ohne Neuaufbau zu wechseln. Wer diese vier Punkte ehrlich bewertet, kommt fast immer zu einer klaren Präferenz.
Der ehrliche Vergleich: Kosten, Datenhoheit, Aufwand, Exit.
Der Kostencharakter unterscheidet sich grundlegend. Cloud-Modelle starten günstig und werden pro Ladepunkt und Monat abgerechnet – die Kosten wachsen linear mit der Flotte und laufen zeitlich unbegrenzt weiter. On-Premise dreht das Verhältnis um: Lizenz, Hardware und Einführung kosten vorab, dazu kommt ein Betriebsteam als Fixkosten, dafür steigen die Kosten mit wachsender Flotte deutlich flacher. Keines der Modelle ist pauschal günstiger; der Kipppunkt hängt an Flottengröße, Laufzeit und daran, ob ohnehin ein eigener IT-Betrieb existiert.
Bei der Datenhoheit liegen die Unterschiede offen. In der Cloud liegen Transaktionen, Messwerte und Nutzerdaten beim Anbieter – relevant werden dann Rechenzentrums-Standort, Auftragsverarbeitung und die Frage, wer administrativ zugreifen kann. On-Premise bleiben die Daten im eigenen Netz, was für Werksgelände, Betriebshöfe und Energieversorger mit strengen IT-Vorgaben oft den Ausschlag gibt. Der Betriebsaufwand verschwindet allerdings in keinem Modell: In der Cloud verlagert er sich auf Vertrags-, Schnittstellen- und Störungsmanagement, on-premise umfasst er Updates, Security-Patches, Zertifikate, Backups und Rufbereitschaft.
Die Exit-Fähigkeit wird am häufigsten unterschätzt. OCPP als offener Standard hilft: Ladepunkte lassen sich per Konfiguration auf ein anderes Backend umziehen, sofern der Anbieter das nicht künstlich erschwert. Der eigentliche Lock-in steckt woanders – in historischen Transaktionsdaten, Tarifmodellen, Nutzerkonten und proprietären Zusatzfunktionen, die sich nicht exportieren lassen. Exit-Fähigkeit ist deshalb weniger eine Eigenschaft des Betriebsmodells als eine Eigenschaft der Software und des Vertrags.
- Kostenverlauf: Cloud wächst mit der Ladepunktzahl, On-Premise mit Team und Infrastruktur.
- Datenhoheit: Rechenzentrums-Standort, Auftragsverarbeitung und Admin-Zugriffe vorab klären.
- Betriebsaufwand verschwindet nie – er verlagert sich nur zwischen Anbieter und eigenem Team.
- Exit-Fähigkeit hängt an offenen Schnittstellen und vollständigem Datenexport, nicht am Modell.
- OCPP macht Ladepunkte umziehbar – der Lock-in steckt in Daten, Tarifen und Sonderfunktionen.
Depot, öffentlicher CPO, Stadtwerk: drei Profile, drei Antworten.
Für Depot-Betreiber ist Laden Teil des Betriebsablaufs: Fahrzeuge müssen morgens geladen bereitstehen, sonst stehen Touren. Die Abrechnung ist meist intern oder einfach strukturiert, Roaming spielt selten eine Rolle – dafür ist die Toleranz für Ausfälle nahe null. Ein Ausfall der Internetverbindung darf weder das Lastmanagement am Netzanschluss noch die Freigabe der Fahrzeuge stoppen. Deshalb passt für Depots fast immer ein Modell mit lokaler Komponente: hybrid oder vollständig on-premise, je nach IT-Landschaft.
Öffentliche CPOs haben das umgekehrte Profil. Viele verteilte Standorte, Ad-hoc-Zahlung nach AFIR, Roaming über OCPI und eichrechtskonforme Abrechnung verlangen ein Backend, das schnell skaliert und ständig weiterentwickelt wird – dafür ist Cloud das natürliche Modell. Ein kurzer Backend-Ausfall ist ärgerlich, aber selten existenzbedrohend, weil Ladepunkte laufende Vorgänge lokal zu Ende führen. Kritisch sind hier eher SLAs, Störungsprozesse und die Exit-Frage, weil die Abhängigkeit vom Anbieter mit jedem Standort wächst.
Stadtwerke sitzen dazwischen: öffentliches Laden, eigene Betriebshöfe, Mitarbeiterladen und teils Ladeangebote für Geschäftskunden – in einer IT-Umgebung mit gewachsenen Systemen und regulatorischen Vorgaben für Energieversorger. Häufig existieren eigene Rechenzentren und ein IT-Betrieb, der On-Premise oder eine private Cloud realistisch macht. In der Praxis entscheiden sich viele für hybride Architekturen: zentrale Plattform unter eigener Kontrolle, lokale Resilienz an betriebskritischen Standorten und klar definierte Schnittstellen zu Abrechnung und Kundensystemen.
Hybride Muster: Steuerung aus der Cloud, Resilienz am Standort.
Das verbreitetste hybride Muster trennt Verwaltung und Echtzeit. Konfiguration, Reporting, Tarife und Nutzerverwaltung laufen zentral – in der Cloud oder im eigenen Rechenzentrum. Am Standort terminiert eine lokale Instanz die OCPP-Verbindungen der Ladepunkte und trifft alle Entscheidungen, die keine Rückfrage vertragen. Fällt die Verbindung zur Zentrale aus, ändert sich am Ladebetrieb vor Ort nichts.
Drei Funktionen gehören in einer solchen Architektur zwingend auf die lokale Ebene. Lastmanagement am Netzanschluss braucht kurze Regelzyklen und darf nicht an Latenz oder Verfügbarkeit einer Internetverbindung hängen – erst recht, wenn PV-Anlagen oder Speicher mitgeregelt werden. Autorisierung muss über lokale Listen offline funktionieren, damit bekannte Fahrzeuge und Ladekarten auch ohne Backend laden können. Und Messwerte samt Transaktionen werden lokal gepuffert und nach Rückkehr der Verbindung vollständig nachgeliefert, damit die Abrechnungskette lückenlos bleibt.
Ehrlicherweise ist hybrid auch das anspruchsvollste Modell. Zwei Software-Ebenen wollen versioniert, überwacht und getestet werden, und die Zuständigkeit muss eindeutig sein: Welche Entscheidung trifft die Zentrale, welche der Standort, und was passiert bei widersprüchlichen Zuständen nach einem Reconnect. Der Aufwand lohnt sich dort, wo ein Standort-Stillstand echte Betriebskosten verursacht – bei Logistik-Depots und Busbetriebshöfen ist das die Regel, bei einzelnen öffentlichen Ladesäulen die Ausnahme.
Auswahl-Checkliste: zehn prüfbare Fragen an Anbieter.
Die folgenden Fragen sind so formuliert, dass sich die Antworten überprüfen lassen – in einer Demo, auf einer Testinstanz oder anhand einer Referenzarchitektur. Ausweichende Antworten sind dabei ein ebenso nützliches Signal wie präzise. Wer die Fragen früh im Auswahlprozess stellt, sortiert das Feld schneller als über jeden Funktionsvergleich.
Ein Lackmustest verdient besondere Aufmerksamkeit: die Frage, ob Cloud-, On-Premise- und Hybrid-Variante wirklich derselbe Software-Stand sind oder ob on-premise eine abgespeckte Fassung geliefert wird. Wir haben unsere eigenen Bausteine – OCPP Broker, OCPP Server und CPMS-Baukasten – deshalb so gebaut, dass sie in allen drei Betriebsmodellen mit identischem Funktionsumfang laufen. Das Betriebsmodell sollte eine Infrastruktur-Entscheidung des Betreibers sein, keine Funktionsentscheidung des Anbieters.
- Läuft die Software in Cloud, On-Premise und hybrid mit identischem Funktionsumfang – nachweisbar aus demselben Release?
- Welche Funktionen laufen bei einem Internet-Ausfall am Standort weiter: Lastmanagement, Autorisierung, aktive Ladevorgänge?
- Über welche Schnittstellen und in welchem Format lassen sich Transaktionen, Messwerte und Konfiguration vollständig exportieren?
- Wo stehen die Rechenzentren, und wer hat administrativen Zugriff auf Betriebs- und Nutzerdaten?
- Wie werden Ladepunkte auf ein anderes Backend umgezogen – genügt eine OCPP-Konfigurationsänderung oder braucht es Hersteller-Tools?
- Welche OCPP-Versionen und Security Profiles werden unterstützt, und gegen welche realen Geräte wurde getestet?
- Wie läuft der Update-Prozess on-premise: Frequenz, Downtime-Fenster, Verantwortung für Patches?
- Welche SLAs gelten in der Cloud, und wie werden Ad-hoc-Zahlung und Roaming bei Störungen behandelt?
- Ist eichrechtskonforme Datenhaltung mit OCMF-signierten Messwerten in allen Betriebsmodellen durchgängig gewährleistet?
- Was kostet der Exit konkret: Datenexport, Parallelbetrieb während der Migration, Restlaufzeiten des Vertrags?