Legacy-Software modernisieren

Warum der große Wurf fast immer scheitert

Der übliche Plan lautet: Wir schreiben das Altsystem neu, und in achtzehn Monaten schalten wir um. Dieser Plan geht selten auf.

Während der Neuentwicklung läuft das alte System weiter und wird weiter geändert. Das neue muss diese Änderungen nachziehen und rennt dem alten hinterher. Gleichzeitig zahlst du zwei Systeme und siehst bis zum Umschalttag keinen Nutzen.

Der Umschalttag selbst ist der gefährlichste Moment: Alles wechselt auf einmal, und es gibt keinen Weg zurück.

Wie wir stattdessen vorgehen

Wir schneiden das Altsystem in Stücke und ersetzen ein Stück nach dem anderen. Das neue und das alte System laufen dabei nebeneinander. Eine Schicht davor entscheidet, welche Anfrage an welches System geht.

Der Ablauf je Stück:

• Wir suchen einen Bereich, der klar abgegrenzt ist und oft Ärger macht.
• Wir bauen ihn neu und lassen beide Versionen eine Zeit lang parallel laufen.
• Wir vergleichen die Ergebnisse, bis wir sicher sind.
• Wir schalten den Verkehr um und nehmen den alten Teil aus dem Betrieb.

Geht ein Schritt schief, betrifft er einen Bereich und nicht das ganze Haus. Und du kannst zurückschalten.

Zuerst verstehen, dann anfassen

Bei einem Altsystem ist die Dokumentation meistens veraltet, und die Menschen, die es gebaut haben, sind nicht mehr da. Das Wissen steckt im Code und in den Köpfen derer, die täglich damit arbeiten.

Wir beginnen deshalb mit einer Bestandsaufnahme. Wir lesen den Code, messen, welche Teile überhaupt benutzt werden, und sprechen mit den Anwendern. Am Ende steht eine Karte: Was tut das System, welche Teile sind tot, wo liegt das Risiko.

Diese Bestandsaufnahme ist ein eigener Auftrag mit klarem Ende. Du kannst danach entscheiden, ob und wie du weitermachst, auch ohne uns.

Typische Ausgangslagen

Wir haben diese Fälle mehrfach gesehen:

• Eine Anwendung läuft auf einer Version, für die es keine Sicherheitsupdates mehr gibt.
• Der Betrieb hängt an einem Server, den niemand neu aufsetzen könnte.
• Jede Änderung dauert Wochen, weil keiner weiß, was sie noch kaputt macht.
• Eine Software wurde einmal von einem Dienstleister gebaut, den es nicht mehr gibt.

In allen Fällen ist die erste Frage dieselbe: Was passiert, wenn das System morgen ausfällt. Die Antwort bestimmt, wie eilig es ist.

Die Daten sind der schwierige Teil

Der Code eines Altsystems lässt sich ersetzen. Die Daten darin sind das eigentliche Vermögen, und sie sind fast immer in einem schlechteren Zustand als erwartet.

Typisch sind Felder, die über die Jahre eine zweite Bedeutung bekommen haben. Eine Spalte heißt "Kommentar" und enthält seit 2014 eine Statuskennung, weil damals niemand das Schema ändern durfte. Solche Fälle findet man nicht im Datenmodell, sondern nur im Gespräch mit denen, die das System benutzen.

Wir übernehmen Daten deshalb in zwei Schritten. Zuerst spielen wir sie auf ein Testsystem und lassen die Fachabteilung darin arbeiten. Erst wenn die Fachabteilung sagt, dass die Zahlen stimmen, wird übernommen.

Wann Neuschreiben doch richtig ist

Wir raten meistens vom kompletten Neubau ab. Es gibt aber Fälle, in denen er die günstigere Wahl ist:

• Das System ist klein genug, dass ein Neubau wenige Monate dauert.
• Die Fachlichkeit hat sich so verändert, dass vom alten Ablauf nichts übrig bleibt.
• Die Technik ist so alt, dass sich niemand findet, der sie noch anfasst.

Der Unterschied liegt im Umfang. Ein Neubau über zwei Monate ist ein Projekt. Ein Neubau über zwei Jahre ist eine Wette.

Wir sagen dir nach der Bestandsaufnahme, welcher Fall bei dir vorliegt. Auch dann, wenn die Antwort für uns der kleinere Auftrag ist.