Eine Anwendung ist über Jahre gewachsen, jede Änderung dauert länger, und im Raum steht die Frage: Legacy Software modernisieren oder alles über Bord werfen und neu bauen? Die Antwort darauf hat sich in 25 Jahren Projektgeschäft grundlegend verändert: Die schrittweise Modernisierung gewinnt fast immer.

Warum die grüne Wiese so verlockend wirkt

Ein Neubau klingt gut. Von null anfangen, alles auf dem aktuellen Stand, keine Altlasten. Im ersten Projekt finden das fast alle überzeugend. Spätestens beim dritten Anlauf ist davon wenig übrig.

Der Grund ist einfach. Hinter jeder Altanwendung steckt mehr Unternehmenswissen, als man annimmt. Die grüne Wiese setzt voraus, dass man weiß, was die alte Software alles leistet. In der Praxis weiß das selten jemand vollständig.

Vier Erfahrungen aus 25 Jahren

1. Fast jedes Team unterschätzt, wie viel der alte Code tatsächlich leistet. Versteckte Funktionen und über Jahre angesammelte Behelfslösungen stehen in keiner Dokumentation.
2. Ein Neubau auf der grünen Wiese dauert oft doppelt so lange wie geplant. Er kostet am Ende deutlich mehr, weil das Wissen aus dem Altsystem fehlt.
3. Im Alltag geht Know-how verloren. Kaum jemand weiß noch, warum frühere Generationen Regeln oder Abläufe so gebaut haben. Wer das Altsystem abschaltet, verliert dieses Wissen mit.
4. Schrittweise Modernisierung schont Nerven und schützt dieses Wissen.

Welche Falle bei Ablöseprojekten schon in der Anforderung lauert, beschreibt der Beitrag So wie die alte Software. Er behandelt die Frage, was ein Nachbau leisten muss. Hier geht es um die Entscheidung davor.

Legacy Software modernisieren: Schritt für Schritt statt Big Bang

Bei der schrittweisen Modernisierung bleibt die fachliche Logik erhalten, und die Technik wird Teil für Teil ausgetauscht. Kunden und Anwender merken davon wenig, das Risiko bleibt klein. Jede Änderung ist klein genug für einen schnellen Erfolg. Das Team wächst beim Umbau mit und versteht das System Stück für Stück besser. Das Herz der Anwendung bleibt konstant, die Arbeit überschaubar.

Für die Budgetplanung hat das einen Vorteil. Statt einer großen Summe, die erst am Ende Nutzen bringt, entstehen mehrere kleinere Posten, von denen jeder für sich bewertet werden kann. So haben wir für eine Reihe von Unternehmen über Jahrzehnte gewachsene Anwendungen modernisiert, ohne teure Komplettabschaltung. Das Know-how bleibt im Unternehmen, und die Software läuft danach noch viele Jahre.

Ein Praxisfall: das Laborsystem von Generatio

Wie das aussieht, zeigt unser Kunde Generatio, ein Labor für Tiergenetik. Seine Laborsystem-Anwendung lief viele Jahre auf GWT (Google Web Toolkit), einem Framework, mit dem sich Weboberflächen in Java schreiben lassen. Tausende Aufträge wurden damit zuverlässig verarbeitet. Kaputt war nichts. Trotzdem war die Anwendung an ihre Grenzen gestoßen:

• lange Build-Zeiten und ein schwerfälliger Entwicklungsprozess
• mühsame Anpassungen an moderne Anforderungen an Oberfläche und Bedienung
• Sicherheitslücken in GWT, die sich immer schwerer kontrollieren ließen
• kaum Weiterentwicklung des Frameworks

Für Entscheider übersetzt: Jede Änderung kostete mehr als nötig, die Sicherheit ließ sich schwerer garantieren, und die technische Grundlage hatte keine Zukunft mehr.

Gemeinsam mit Generatio haben wir entschieden, die Oberfläche auf Vue.js zu migrieren, statt das System neu zu erfinden. Die Entwickler arbeiten jetzt mit leichtgewichtigen Komponenten, schnellen Entwicklungsschleifen und einer großen Community. Generatio bekommt bessere Wartbarkeit und günstigere Weiterentwicklung. Die Labormitarbeitenden arbeiten mit einer Oberfläche, die unmittelbar auf Eingaben reagiert und die Erfassung und Bearbeitung der Aufträge effizienter macht.

Seitdem kann sich Generatio wieder auf die eigentliche Aufgabe konzentrieren: Züchter und Zuchtvereine bei der Gesundheitsprüfung ihrer Tiere zu unterstützen.

Wann ein Neubau trotzdem richtig ist

Die schrittweise Modernisierung ist kein Dogma. Wer die Sanierung zu lange verschiebt, kann einen Punkt erreichen, an dem sie wirtschaftlich nicht mehr möglich ist. Das beschreibt der Beitrag Technische Schulden. Und manchmal ist die Frage falsch gestellt, weil der Anwendungsfall in wenigen Jahren ohnehin wegfällt. Dafür lohnt der Blick in Software am Lebensende.

Vor der Entscheidung helfen vier Fragen:

• Wer im Unternehmen weiß noch, warum die Regeln im Altsystem so sind, wie sie sind?
• Lässt sich ein Teil der Anwendung herauslösen und getrennt modernisieren, etwa zuerst die Oberfläche?
• Wie lange laufen zwei Systeme nebeneinander, und wer bezahlt das?
• Müsste ein Neubau dieselben fachlichen Regeln noch einmal erfinden?

Wer die letzte Frage mit Ja beantwortet, sollte den Neubau besonders kritisch prüfen.

Der beste Zeitpunkt für die Modernisierung liegt, solange die Anwendung noch zuverlässig läuft. Dann kennt das Team das System noch gut, und die Umstellung lässt sich ohne Zeitdruck planen. Wer wartet, bis ein Sicherheitsvorfall den Zeitpunkt vorgibt, hat diese Wahl nicht mehr.

Fazit

Wer Legacy Software modernisieren will, fährt in den meisten Fällen mit kleinen Schritten besser als mit dem großen Wurf. Die Software behält ihr Wissen, das Risiko bleibt klein, und das Team lernt das System beim Umbau kennen. Das Beispiel Generatio zeigt, dass auch eine stabile Anwendung eine neue technische Grundlage braucht, bevor sie zum Problem wird. Ein Neubau bleibt eine Option, sollte aber das Ergebnis einer Prüfung sein und nicht der Ungeduld mit dem Altsystem.