Open-Linux-Gateway-Migration

Der Betreiber führte eine Flotte auf geschlossenen, proprietären Gateways mit gesperrter Firmware. Der Anbieter kontrollierte den Release-Takt, die unterstützten Integrationen und, weil die Firmware eine Blackbox war, die Sicherheitslage jedes Geräts im Feld. Preisdruck, End-of-Life-Signale des Anbieters und die Unmöglichkeit, ein echtes Audit durchzuführen, hatten die Migration von „nice to have" auf „dieses Quartal" verschoben.

Migrationsziel war ein offenes Linux-Gateway mit Embedded-Software, die vollständig dem Betreiber gehört, in einem schrittweisen Rollout mit Rollback-Pfad ausgerollt und mit Dokumentation übergeben, die den Betreiber in die Lage versetzt, den Stack ohne uns zu erweitern.

Vendor Lock-in. Die Firmware war eine Single-Vendor-Abhängigkeit für Updates, Support und jedes neue Feature. Wir benötigten einen Post-Migration-Stack, der über Hardware-Klassen hinweg portierbar und in der Software frei von Single-Vendor-Engpässen ist.

Sicherheits-Blindstellen. Die geschlossene Firmware konnte nicht auditiert werden. Der Ersatz musste reproduzierbar aus dem Quellcode gebaut, signiert und durchgängig verifizierbar sein, damit Security und Compliance ein echtes Artefakt zur Prüfung hatten.

End-of-Life-Risiko. Die alte Hardware war auf einem Auslaufpfad ohne Upgrade-Story. Wir haben die Migration so aufgebaut, dass der Betreiber neue Einheiten weiter ausrollen kann, ohne unseren Vertrag erneut zu öffnen.

Der neue Stack setzt auf offene Linux-Gateways von Owasys mit einem reproduzierbaren Image, das über alloy-it gebaut wird. Das Image bündelt die Erfassungsschicht, ein Pro-Asset-Telemetrieschema und den OTA-Agenten, den der Betreiber kontrolliert. Alles, was auf dem Gerät läuft, ist innerhalb des Betreiber-Accounts quelloffen einsehbar.

Die Telemetrie fließt über MQTT zu einem Broker, den der Betreiber selbst hostet, und von dort in das vorhandene Analyse- und Dispatching-Tooling des Betreibers. Die Closed-Vendor-Cloud war nach der Migration nicht mehr im Scope; die VPC des Betreibers ist die operative Heimat der Daten.

Entscheidend ist, dass das neue Image dieselben kanonischen Schema-Datensätze emittiert wie die Legacy-Einheiten, sobald beide parallel gelesen werden können, sodass Dashboards während des Rollouts nicht brechen. Die Schemaabgleichung erfolgt am Edge, nicht in zwölf Schichten Cloud-Transformationen.

Audit (Wochen 1–3): Wir haben jede Fähigkeit der Legacy-Firmware kartiert, Protokolle, Integrationen, Alerts, OTA-Kanäle, und eine Feature-Parity-Matrix erstellt, die vom Engineering-Lead des Betreibers abgezeichnet wurde, bevor irgendein Code geschrieben wurde.

Custom-Firmware (Wochen 4–10): alloy-it produzierte reproduzierbare Builds des neuen Images. Wir haben die Matrix Zeile für Zeile repliziert und zwei Fähigkeiten hinzugefügt, die die Legacy-Firmware nie hatte: Edge-Pufferung über mehrstündige Ausfälle hinweg und OTA-Rollback per Image-Hash.

Stufenweiser Rollout (Wochen 11–20): Migration in Wellen, mit Rollback auf die Legacy-Firmware in jedem Schritt. Jede Welle lief 72 Stunden im Dual-Emit, sodass Dashboards beide Streams sahen und der Betreiber vergleichen konnte.

IP-Übergabe (Woche 21): Der Betreiber erhielt den Quellcode des Gateway-Images, die alloy-it-Build-Pipeline, die OTA-Infrastruktur als Code und die Runbooks. Unser Vertrag endete; sein Stack lief weiter.

Die Schlagzeilen-Zahl, Flotte auf offener Hardware, kein Vendor Lock, ist wichtig, aber zwei operative Änderungen wiegen schwerer.

• Der Betreiber liefert seine Gateway-Updates jetzt selbst aus. OTA-Fenster werden vom eigenen Team geplant, nicht von der Roadmap des Anbieters. Neue Geräte-Features landen in Tagen, nicht Quartalen.
• Security hat endlich Artefakte. Reproduzierbare Builds, signierte Images, verifizierbare Supply Chain. Das Security-Team hat aufgehört, das Gateway-Estate als Blackbox zu beschreiben.

Dies ist die Standard-Migrationsform für jeden Betreiber, der geschlossene Gateway-Bestände führt, die ohne Störung des laufenden Betriebs offen werden müssen: Feature-Parity-Audit zuerst, reproduzierbarer Image-Build, Dual-Emit-Rollout, IP-Übergabe am Ende. Der Hardware-Anbieter ändert sich, der Betreiber bleibt, mit dem Stack, der ihm jetzt gehört.