Projektbericht — Industrieautomation
Condition Monitoring — Migration von C++ nach .NET Core
Eine Migration im laufenden Betrieb ist kein Neubau. Sie ist eine Folge von Schritten, nach denen das System jedes Mal wieder lauffähig sein muss.
- Branche
- Industrieautomation, selber Kunde wie die Datenplattform
- Systemtyp
- Condition-Monitoring-Backend
- Rolle von AereA
- Architektur, Migration, Implementierung
- Zeitraum
- 2 Jahre
Ausgangslage
Ein über Jahre gewachsenes C++-Backend, dessen Weiterentwicklung zunehmend teuer und dessen Datenzugriff mit der Fachlogik verflochten war.
Lösungsansatz
Schrittweise Migration nach .NET Core mit Entity Framework und einem Neuschnitt der Datenzugriffsschicht statt einer 1:1-Portierung.
Ergebnis
rund 1 Mio. Zeilen Code auf einen aktuellen Stack überführt, ohne das Produkt für die Umstellung anzuhalten.
Ergebnisse auf einen Blick
- rund 1 Mio. Zeilen Code migriert, ohne das Produkt anzuhalten
- 2 Jahre Migrationsdauer bei durchgehender Lauffähigkeit nach jedem Schritt
- Neuschnitt der Datenzugriffsschicht statt 1:1-Portierung der Altstruktur
- Testabdeckung vor der Migration aufgebaut, nicht danach — Voraussetzung statt Nacharbeit
- Containerisierter Betrieb über Docker gegen PostgreSQL
- Anschlussauftrag beim selben Kunden nach der industriellen Datenplattform
Ausgangslage
Das Condition-Monitoring-Backend war über Jahre gewachsen. Fachlich funktionierte es, aber jede Erweiterung kostete überproportional viel Zeit — vor allem, weil der Datenzugriff eng mit der Fachlogik verflochten war.
Aufgabenstellung
Migration auf einen aktuellen Stack, ohne das Produkt anzuhalten und ohne die strukturellen Probleme mitzunehmen.
Vorgehen
Statt einer 1:1-Portierung nach .NET Core haben wir die Datenzugriffsschicht neu geschnitten und auf Entity Framework aufgesetzt. Der Migrationsplan folgt fachlichen Grenzen: Nach jedem Schritt ist das System lauffähig und testbar. Der Betrieb läuft containerisiert über Docker gegen PostgreSQL.
Qualitätssicherung
Eine Migration ohne belastbare Testabdeckung ist ein Blindflug. Der Aufbau beziehungsweise die Ergänzung automatisierter Tests lief deshalb der Migration voraus, nicht hinterher.
Fazit
Der Auftrag folgte auf die industrielle Datenplattform beim selben Kunden — ein Muster, das sich bei uns wiederholt: Der zweite Auftrag kommt, weil der erste gehalten hat.
Technologien
Häufige Fragen
Warum keine 1:1-Portierung?
Weil sie die Probleme mitgenommen hätte. Der Datenzugriff war der Grund für den hohen Änderungsaufwand — ihn unverändert zu übernehmen hätte den Stack modernisiert und die Ursache belassen.
Wie bleibt das System während der Migration lauffähig?
Über einen Schnitt entlang fachlicher Grenzen und einen Migrationsplan, der nach jedem Schritt einen lauffähigen Zustand vorsieht. Die Testabdeckung ist dabei die Voraussetzung, nicht das Ziel.
Kontakt
Ansprechpartner
Softwarearchitektur & technische Projektleitung