Legacy-Software-Modernisierung: Ein Leitfaden in einfacher Sprache für Unternehmer

Die meisten Unternehmen betreiben mindestens eine Software, die niemand anfassen will. Sie wurde vor Jahren gebaut, verarbeitet noch täglich Bestellungen oder Rechnungen, und die Person, die verstand, wie sie funktioniert, ist längst weitergezogen. Wenn diese Beschreibung auf etwas in Ihrem Unternehmen zutrifft, denken Sie bereits über Legacy-Software-Modernisierung nach, auch wenn Sie diesen genauen Begriff bisher nicht verwendet haben.

Dieser Leitfaden richtet sich an Unternehmer und Führungskräfte, nicht an Entwickler. Es gibt keine Abkürzungen zu entschlüsseln und keine Annahme, dass Sie wissen, was ein Framework ist. Er behandelt, was „Legacy" in der Praxis bedeutet, die drei realistischen Wege der Legacy-Software-Modernisierung, was jeder davon tendenziell kostet, und was passiert, wenn Sie sich entscheiden, noch ein weiteres Jahr zu warten.

Was Legacy-Software-Modernisierung tatsächlich bedeutet

Einfach ausgedrückt ist Legacy-Software jedes System, das noch echte Arbeit für Ihr Unternehmen erledigt, dessen Änderung aber schwierig, langsam oder riskant geworden ist. Alter allein macht etwas nicht zu Legacy. Ein zehn Jahre altes System, das ohne Drama kleine Updates bekommt, ist einfach alte Software, die funktioniert. Das Problem beginnt, wenn eines oder mehrere der Folgenden zutrifft: Der ursprüngliche Entwickler ist weg und niemand versteht den Code mehr vollständig, die zugrunde liegende Technologie wird vom Hersteller nicht mehr unterstützt, jede kleine Änderung dauert Wochen statt Tage, oder Sie vermeiden Änderungen grundsätzlich, weil Sie Angst haben, dass etwas kaputtgeht.

Das Letzte ist das deutlichste Zeichen. Wenn Ihr Team nicht mehr fragt „können wir dieses Feature hinzufügen", sondern „können wir es überleben, dieses Feature hinzuzufügen", verwalten Sie Legacy-Software, ob jemand im Haus dieses Wort benutzt oder nicht.

Ihre drei echten Optionen

Wenn ein System diesen Punkt erreicht, hören Inhaber meist drei Begriffe: behalten, refaktorieren, neu bauen. Jeder ist eine legitime Wahl. Keiner ist automatisch richtig.

Das System zu behalten, wie es ist, bedeutet, die aktuellen Kosten und Risiken zu akzeptieren, im Gegenzug dafür, jetzt nichts Neues auszugeben. Das ist eine vernünftige Wahl für ein System, das stabil ist, selten Änderungen braucht und nichts zurückhält, was Sie tun wollen. Es hört auf, vernünftig zu sein, in dem Moment, in dem die Software auf einer Technologie läuft, die der Hersteller nicht mehr patcht, denn jeder Tag, den Sie sie ungepatcht weiterlaufen lassen, ist ein Tag, an dem eine bekannte Schwachstelle offen für jeden liegt, der danach sucht.

Refaktorieren, was wir lieber Modernisieren nennen, da das Wort selbst den meisten Inhabern nichts sagt, ist der Prozess, das System von innen zu verbessern, während es weiterläuft. Ihre Mitarbeitenden nutzen es weiter. Kunden merken nichts, außer dass die Dinge besser zu funktionieren beginnen. Ein gutes Modernisierungsprojekt ersetzt zuerst die Teile, die die größten Schmerzen verursachen (den langsamen Bericht, der fünf Minuten zum Laden braucht, die Integration, die jeden Montagmorgen fehlschlägt), und arbeitet sich von dort nach außen vor. Wir haben ein ausführlicheres Entscheidungsframework für die Wahl zwischen Neuschreiben und Refaktorieren geschrieben, falls Sie diese spezielle Entscheidung vertiefen möchten.

Neu bauen bedeutet, mit aktueller Technologie neu anzufangen und meist mit einer saubereren Version derselben Geschäftsregeln. Das ist die richtige Wahl, wenn das bestehende System auf etwas läuft, das überhaupt keinen Upgrade-Pfad hat (ein Framework, das es nicht mehr gibt, zum Beispiel, oder individueller Code, den niemand mehr pflegt) oder wenn sich das Geschäft so verändert hat, dass das alte Design nicht mehr zu Ihrer heutigen Arbeitsweise passt. Ein Neubau gibt Ihnen ein sauberes Fundament, bedeutet aber auch, alles neu zu testen, was Ihr altes System über Jahre kleiner Korrekturen still richtig gemacht hat, was der Hauptgrund ist, warum Neubauten länger dauern und mehr kosten, als Inhaber zu Beginn erwarten.

Was jeder Weg tendenziell kostet

Die genauen Zahlen hängen stark von der Größe des Systems ab und davon, wie viel der ursprünglichen Logik dabei erst wiederentdeckt werden muss. Betrachten Sie die untenstehenden Spannen also als Ausgangspunkt für ein Gespräch, nicht als Angebot.

Weg	Typischer Zeitrahmen	Was die Kosten treibt
So behalten, wie es ist	Jetzt keine, später steigend	Wachsende Wartungsstunden, Notfallkorrekturen, Sicherheitsrisiko
Vor Ort modernisieren	Ein paar Monate bis etwa ein Jahr, in Etappen	Wie viel vom System angefasst werden muss und wie gut die Geschäftsregeln dokumentiert sind
Vollständiger Neubau	Sechs Monate bis zwei Jahre oder länger	Größe des Systems, wie viel individuelle Logik von Grund auf neu geschrieben werden muss, Datenmigration

Die Zeile, die die meisten Inhaber übersehen, ist die erste. „So behalten, wie es ist" ist nie kostenlos. Es zeigt sich in steigenden stündlichen Wartungsrechnungen, in der langsamen Anhäufung von Workarounds, die Ihre Mitarbeitenden bauen, um die Teile zu vermeiden, die kaputtgehen, und schließlich in den Kosten einer Notfallkorrektur unter Druck, wenn schließlich etwas im Produktivbetrieb ausfällt. Das sehen wir am deutlichsten bei Systemen, die gute Kandidaten für einen schrittweisen Ansatz wie das Strangler-Fig-Pattern sind, bei dem Teile einzeln statt alle auf einmal ersetzt werden, was die tatsächlichen Kosten oft näher an die Modernisieren-Zeile rückt, als Inhaber zunächst annehmen.

Was passiert, wenn Sie nichts tun

Am ersten Tag geht nichts kaputt. Genau deshalb wird diese Entscheidung immer weiter aufgeschoben. Die tatsächlichen Folgen bauen sich langsam auf und treten meist in dieser Reihenfolge ein.

Erstens wird Wartung pro Stunde teurer, weil weniger Entwickler bereit sind, in alten Codebases zu arbeiten, und diejenigen, die es tun, dafür tendenziell mehr verlangen. Zweitens wird Einstellung schwieriger: Ein neuer Entwickler, der die Codebase öffnet und keine Dokumentation und keine Tests findet, braucht Wochen länger, um produktiv zu werden, als jemand, der einem modernen, gut strukturierten Projekt beitritt, und manche Kandidaten werden die Stelle einfach ablehnen, sobald sie sehen, womit sie arbeiten würden. Drittens wird das Geschäft selbst langsamer. Wettbewerber liefern neue Features in Wochen, Sie brauchen Monate, weil jede Änderung manuell gegen ein System getestet werden muss, dem niemand mehr vollständig vertraut.

Irgendwann erzwingt etwas die Entscheidung trotzdem. Ein Hosting-Anbieter beendet die Unterstützung für den Server. Der Softwarehersteller hört auf, Sicherheitslücken zu patchen. Ein Auditor, ein Investor oder der Sicherheitsfragebogen eines neuen Kunden stellt eine Frage, die Sie nicht ehrlich beantworten können. An diesem Punkt entscheiden Sie nicht mehr selbst, wann gehandelt wird. Sie reagieren nach dem Zeitplan eines anderen, meist zu einem schlechteren Preis, als wenn Sie das Projekt selbst geplant hätten.

Wie Sie jetzt entscheiden

Sie brauchen keinen technischen Hintergrund, um diese Entscheidung zu treffen. Stellen Sie sich drei ehrliche Fragen.

Kann Ihr aktuelles Team erklären, ohne zu raten, was kaputtginge, wenn Sie einen bestimmten Teil des Systems änderten? Wenn die Antwort für irgendetwas Kundenbezogenes oder Umsatzrelevantes Nein lautet, ist das ein Risiko, unabhängig davon, welchen Weg Sie letztlich wählen.

Hält die Software etwas zurück, das Sie tun möchten, wie ein Feature hinzufügen, das Wettbewerber schon haben, eine neue Zahlungsmethode unterstützen oder eine Sicherheitsprüfung bestehen, die ein größerer Kunde verlangt? Wenn ja, sind die Kosten des Wartens nicht hypothetisch. Es ist das Geschäft, das Sie gerade jetzt nicht gewinnen.

Wird die zugrunde liegende Technologie noch von demjenigen unterstützt, der sie gebaut hat? Wenn die Unterstützung bereits beendet ist oder ein Enddatum hat, das Sie nachschlagen können, ist die Option „so behalten, wie es ist" effektiv ausgelaufen. Sie wählen zwischen Modernisieren und Neubauen, nicht zwischen drei Optionen.

Wenn Sie eine zweite Meinung dazu möchten, wo Ihr eigenes System auf diesem Spektrum liegt, schauen wir uns das gerne an. Unsere Arbeit zur Legacy-Code-Optimierung beginnt meist genau mit einer solchen Bewertung in einfacher Sprache: was Sie haben, was es kosten würde, zu modernisieren im Vergleich zu neu zu bauen, und eine realistische Schätzung, bevor sich jemand für eine Richtung festlegt. Wenn Sie diese Überlegung an einem vollständigen Fall angewendet sehen möchten, führt unser Leitfaden zur Modernisierung von Legacy-Systemen für Unternehmen im deutschen Mittelstand durch fünf typische Legacy-Szenarien im Detail.

Melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io, wenn Sie besprechen möchten, wie das für Ihr konkretes System aussieht. Ein erstes Gespräch ist unverbindlich, und Sie gehen mit einem klareren Bild heraus, als Sie zuvor hatten, selbst wenn Sie sich entscheiden zu warten.