Legacy-Software retten: Wenn die Hardware ausläuft, muss die Software nicht sterben

Eine spezialisierte Software läuft seit fast zwei Jahrzehnten zuverlässig. Sie steuert ein Messgerät, verrechnet die Messwerte nach fachlich exakten Regeln und liefert verlässliche Ergebnisse. Alles gut, bis das Messgerät abgekündigt wird. Der Hersteller stellt das Modell ein, der Nachfolger spricht ein anderes Protokoll. Von einem Tag auf den anderen steht die Frage im Raum: Muss jetzt die ganze Software neu gebaut werden?

In den allermeisten Fällen lautet die Antwort: nein. Und genau darum geht es in diesem Beitrag. An einem realen Projekt zeige ich, wie man bewährte Software an neue Hardware anbindet, ohne den wertvollen Kern anzufassen und ohne das Risiko eines Neubaus.

Warum Neubau selten die Antwort ist

Der erste Reflex bei alter Software ist oft: weg damit, komplett neu. Das klingt sauber, ist aber meistens die teuerste und riskanteste Option. Der Grund liegt in dem, was in so einer Anwendung wirklich steckt.

Der sichtbare Teil, die Oberfläche und die Geräteanbindung, ist selten das Problem. Das Wertvolle ist die Rechenlogik: die über Jahre gewachsenen, fachlich geprüften Formeln, die aus rohen Messwerten korrekte Ergebnisse machen. Diese Logik ist getestet und in der Praxis bewährt.

Ein Neubau wirft genau das weg. Jede neu geschriebene Formel muss neu geprüft werden. Jede Abweichung um die zweite Nachkommastelle ist ein potenzielles Problem. Man tauscht ein bekanntes, funktionierendes System gegen ein neues, unbewiesenes, und bezahlt dafür auch noch das Vielfache. Der wirtschaftlich und fachlich richtige Weg ist meistens der umgekehrte: das Bewährte erhalten und nur das anfassen, was sich wirklich geändert hat, nämlich die Hardware darunter.

Die eigentliche Aufgabe: das Wertvolle isolieren

Bevor man eine Zeile Code schreibt, klärt man eine Frage: Welcher Teil darf sich auf keinen Fall ändern, und welcher Teil muss sich ändern?

In diesem Fall war die Trennung klar. Der Rechenkern, der die Messwerte in fertige Ergebnisse umrechnet, war unantastbar. Er verkörpert das eigentliche Know-how. Änderbar war dagegen nur die Schicht darunter: die Art, wie die Messwerte vom Gerät ins Programm kommen. Früher über eine serielle Schnittstelle, künftig über das moderne SDK des Nachfolgegeräts.

Diese Trennung ist der ganze Trick. Sobald klar ist, dass der Kern eine Blackbox bleibt, in die vorne saubere Messwerte hineingehen und hinten korrekte Ergebnisse herauskommen, wird aus einem Neubau eine gezielte Anbindung.

Der Ansatz: anbinden statt neu bauen

Das Zielgerät ist ein aktuelles Messgerät von Konica-Minolta, das ein modernes SDK mitbringt. Statt den alten seriellen Weg zu ersetzen, kommt der neue Weg additiv daneben:

Der alte Weg bleibt vollständig erhalten. Nichts wird gelöscht. Die serielle Anbindung funktioniert weiter wie bisher.
Der neue Weg liegt parallel und ist umschaltbar. Ein Schalter entscheidet, welcher Weg aktiv ist. Erkennt die Software das neue Gerät, nutzt sie die SDK-Anbindung, sonst den alten Pfad.
Die neuen Messwerte fließen in den unveränderten Rechenkern. Das SDK liefert die Rohdaten, ein schmaler Adapter bringt sie in genau die Form, die der Kern erwartet. Der Kern selbst merkt nicht, woher die Daten kommen.

Der Vorteil dieser Bauweise ist Sicherheit. Solange der neue Weg nicht bewiesen ist, kann man jederzeit auf den alten zurückschalten. Es gibt keinen Stichtag, an dem alles funktionieren muss. Man baut das Neue neben dem Alten auf und schaltet erst um, wenn es sich am realen Gerät bewährt hat.

Das größte Risiko zuerst klären

Bei so einem Projekt gibt es immer eine Frage, an der alles hängt. Hier war es die: Liefert das neue Gerät überhaupt die Daten, die der alte Rechenkern braucht, in der richtigen Struktur und im richtigen Format? Wenn das neue Gerät das nicht hergibt, ist die ganze Idee tot.

Deshalb wurde genau diese Frage zuerst beantwortet, noch vor jeder schönen Oberfläche. Am echten Gerät, mit einem kleinen Testprogramm, das nur eines geprüft hat: Kommen die benötigten Daten sauber heraus? Erst als das nachgewiesen war, ging es weiter. Das ist ein Prinzip, das sich immer auszahlt: das größte Unbekannte zuerst angehen, nicht das Angenehmste. Scheitert es, scheitert es früh und billig. Hält es, ist der Rest Fleißarbeit.

Korrektheit beweisen, nicht behaupten

Ein Messgerät ist nur so gut wie seine Kalibrierung. Für den Betrieb zählt nicht nur, dass eine Zahl herauskommt, sondern dass diese Zahl nachweisbar korrekt ist. Genau hier wird eine Portierung anspruchsvoll.

Die komplette Kalibrierkette wurde über das SDK abgebildet. Der entscheidende Nachweis war am Ende ein Vergleich mit einem Referenzstandard: gemessen am neuen Gerät, durch die Korrekturkette geschickt, und das Ergebnis traf die hinterlegten Sollwerte im Rahmen der geforderten Genauigkeit. Damit war belegt, dass der neue Datenweg die Genauigkeit nicht bricht, sondern erhält.

Das ist der Punkt, an dem sich die Blackbox-Strategie auszahlt. Weil der Rechenkern unverändert blieb, musste nicht die gesamte Fachlogik neu geprüft werden. Es genügte, den Dateneingang zu beweisen. Die Korrektheit dahinter war nie in Frage.

Was sich verallgemeinern lässt

Die konkrete Anwendung ist speziell, aber das Vorgehen ist es nicht. Diese Prinzipien tragen bei fast jeder Legacy-Rettung:

Alter Code ist gespeichertes Wissen, kein Ballast. In bewährter Software steckt jahrelange, geprüfte Fachlogik. Sie wegzuwerfen bedeutet, dieses Wissen noch einmal zu bezahlen.
Das Unantastbare hinter einer stabilen Schnittstelle isolieren. Wenn der wertvolle Kern eine Blackbox mit klarem Ein- und Ausgang bleibt, schrumpft das Projekt von einem Neubau auf eine Anbindung.
Additiv und umschaltbar statt ersetzen. Der neue Weg läuft parallel zum alten, per Schalter. Es gibt keinen riskanten Stichtag, und der Rückweg ist jederzeit offen.
Das größte Risiko zuerst. Die eine Frage, an der alles hängt, wird als Erstes am realen System beantwortet, nicht als Letztes.
Korrektheit beweisen, nicht behaupten. Genauigkeit zeigt sich in Zahlen, die die Sollwerte treffen. Dieser Nachweis ist das eigentliche Ergebnis.

Wann sich das lohnt

Nicht jede alte Software muss gerettet werden. Wenn eine Anwendung ohnehin abgelöst wird oder ihre Logik trivial ist, kann ein Neubau der richtige Weg sein.

Aber sobald einer dieser Punkte zutrifft, ist die Anbindung dem Neubau überlegen:

Bewährte, geprüfte Fachlogik: Die Rechenkerne sind in der Praxis validiert und schwer zu ersetzen.
Hardware am Lebensende: Nicht die Software ist das Problem, sondern das Gerät darunter.
Ein modernes SDK des Nachfolgegeräts: Der Hersteller bietet eine dokumentierte Schnittstelle an.
Kein Stillstand erlaubt: Der Betrieb muss währenddessen weiterlaufen, ein harter Umstieg ist keine Option.

In diesen Fällen spart die Anbindung nicht nur Geld, sondern bewahrt vor allem das, was die Software über Jahre wertvoll gemacht hat.

Fazit

Auslaufende Hardware ist kein Todesurteil für die Software, die darauf läuft. Wer den wertvollen Kern isoliert, ihn unangetastet lässt und nur die Geräteschicht additiv und umschaltbar erneuert, rettet nicht nur eine Anwendung, sondern auch das darin gespeicherte Fachwissen. Das ist fast immer schneller, billiger und sicherer als ein Neubau. Und es ist am realen Gerät nachweisbar, Zahl für Zahl.

Sie haben eine bewährte Software, deren Hardware ausläuft, oder ein Altsystem, das niemand mehr anfassen möchte? Vereinbaren Sie ein Erstgespräch, dann schauen wir gemeinsam, ob sich Ihr System anbinden statt neu bauen lässt.