Big Bang
Alle Ladepunkte werden am selben Stichtag umgestellt: Ein einziger Fehler in der Konfiguration oder im Zielsystem trifft sofort den gesamten Ladepark – und der Rückweg ist genauso aufwendig wie der Hinweg.
Zero-Downtime-Migration
Backend wechseln, ohne dass der Ladepark es merkt.
Big-Bang-Migrationen sind das gefürchtetste Projekt jedes CPO. Mit dem NeLeSo OCPP Broker werden sie Regelbetrieb – als geplantes Projekt mit Strategie, Probelauf und klarem Rückweg: Die Umschaltung erfolgt pro Ladepunkt, pro Gruppe oder pro Standort, ohne Downtime, ohne Stichtag, mit Rollback jederzeit.
Das Problem
Warum klassische Migrationen scheitern.
Wer Backend oder CPMS wechselt, kämpft an drei Fronten gleichzeitig – und jede einzelne kann das Projekt kippen.
Firmware-Vielfalt
Jeder Hersteller verbindet sich anders neu: unterschiedliche Konfigurationswege, Reconnect-Verhalten und Firmware-Stände machen aus einer Umstellung tausend Einzelfälle – viele davon nur vor Ort lösbar.
Laufende Sessions
Während der Umstellung wird geladen: Abgebrochene Ladevorgänge kosten Umsatz, erzeugen Support-Tickets und beschädigen das Vertrauen von Fahrern und Standortpartnern.
Ablauf
So läuft eine Migration mit dem Broker.
Schatten-Anbindung Der Broker übernimmt die Verbindungen der Ladepunkte – Backend A bleibt führend, nichts ändert sich im Betrieb.
Vergleichsbetrieb Backend B empfängt denselben Datenstrom parallel; Abweichungen werden sichtbar, bevor sie zählen.
Gruppenweise Umschaltung Pro Ladepunkt, Gruppe oder Standort wechselt die Führung zu Backend B – Rollback bleibt jederzeit offen.
Abschluss Backend A wird abgeschaltet; das Ereignisjournal dokumentiert jeden Schritt der Migration.
Vergleich
Klassische Migration vs. Broker-Migration.
Der Unterschied ist kein Werkzeug, sondern die Architektur: Der Broker entkoppelt Ladepunkte vom Zielsystem – damit verschwinden Stichtag, Downtime und Feldeinsätze aus dem Projektplan.
| Klassische Migration | Broker-Migration | |
|---|---|---|
| Downtime | Stunden bis Tage | 0s |
| Risiko | Alles auf einmal – ein Fehler trifft den ganzen Park | Pro Gruppe begrenzt und beobachtbar |
| Rollback | Schwierig bis praktisch unmöglich | Jederzeit, pro Ladepunkt |
| Zeitdruck | Fester Stichtag für alle | Eigenes Tempo, Standort für Standort |
| Firmware-Umkonfiguration | Jeder Ladepunkt einzeln, oft vor Ort | Einmalig auf den Broker – danach nie wieder |
Regulatorik 2026
2026 ist das Jahr, in dem Bestandsparks nachziehen müssen.
Seit Januar 2026 ist ISO 15118 für neue AC-Ladepunkte Pflicht, OCPP 2.1 ist verfügbar – und der OCPP-1.6-Bestand braucht einen Migrationspfad Richtung 2.0.1. Der Broker normalisiert OCPP 1.6 ↔ 2.0.1 in beide Richtungen und verschafft Ihnen die Zeit, den Bestand in Ihrem Tempo nachzuziehen – statt unter Stichtagsdruck.
FAQ
Häufige Fragen zur OCPP-Migration.
Wie lange dauert eine Migration mit dem OCPP Broker?
Typischerweise Wochen statt Monate – abhängig von der Zahl der Standorte und dem Zustand des Bestands. Weil die Umschaltung pro Ladepunkt, Gruppe oder Standort erfolgt, ist die Migration pro Standort planbar: Schatten-Anbindung und Vergleichsbetrieb laufen vorab, umgeschaltet wird erst, wenn die Daten stimmen.
Müssen die Ladepunkte umkonfiguriert werden?
Einmalig: Jeder Ladepunkt wird ein einziges Mal auf den Broker umgestellt. Danach nie wieder – egal wie oft dahinter das Backend oder CPMS wechselt. Der Broker hält die Verbindung, das Zielsystem wird per Routing-Regel bestimmt.
Was passiert mit laufenden Ladevorgängen?
Sie laufen weiter. Die Session-Stabilisierung des Brokers – Reconnect-Logik, Message-Queue und Auto-Resync – überbrückt die Umschaltung, sodass kein Ladevorgang abgebrochen wird und keine Transaktionsdaten verloren gehen.
Geht die Migration auch von OCPP 1.6 auf OCPP 2.0.1?
Ja. Der Broker normalisiert OCPP 1.6 ↔ 2.0.1 in beide Richtungen. Bestandsgeräte mit OCPP 1.6 können so an ein Backend migriert werden, das OCPP 2.0.1 erwartet – ohne Firmware-Update und ohne Anpassung am Zielsystem.
Nächster Schritt