Legacy-Software-Support: Ein altes System sicher halten, während du entscheidest, wie es weitergeht

Das System, das niemand anfassen will

Jedes Unternehmen mit Software, die älter als ein paar Jahre ist, hat irgendwann so ein System: Es trägt das Geschäft, niemand vertraut ihm vollständig, und niemand will derjenige sein, der es zum Absturz bringt. Ohne den richtigen Legacy-Software-Support während der langen Phase, in der die Führung entscheidet, was damit geschehen soll, bleibt dieses System nicht einfach stehen. Es sammelt ungepatchte Abhängigkeiten, undokumentierte Workarounds und stille Sicherheitslücken an, bis die Entscheidung für dich getroffen wird - meist durch einen Ausfall oder einen Sicherheitsvorfall. Das Datenbankschema ist seit einem Jahrzehnt seitwärts gewachsen. Die Person, die das Billing-Modul verstanden hat, hat das Unternehmen vor zwei Jahren verlassen. Jedes Mal, wenn jemand ein Ticket öffnet, um etwas zu ändern, kommt die Schätzung länger zurück, als irgendjemand erwartet.

An diesem Punkt stehen die meisten Verantwortlichen vor derselben Frage: Bauen wir das von Grund auf neu, oder refaktorisieren wir das Bestehende? Das ist eine echte Entscheidung mit echten Trade-offs, und sie verdient Zeit. Das Problem ist, was währenddessen passiert. Teams hören oft ganz auf, das System anzufassen, statt das Risiko einer falschen Entscheidung einzugehen.

Genau hier zahlt sich laufender Legacy-Software-Support aus. Er ersetzt nicht die Entscheidung zwischen Neubau und Refactoring. Er ist das, was das System sicher und betriebsfähig hält, während die Monate vergehen, die eine fundierte Entscheidung braucht - und er liefert genau die Belege, die diese Entscheidung benötigt.

Warum der Freeze passiert

Die Frage Neubau versus Refactoring ist wirklich schwer, und ein Freeze an Ort und Stelle ist eine rationale Reaktion auf eine Entscheidung ohne klar richtige Antwort.

Ein Neubau verspricht einen klaren Neuanfang, trägt aber echtes Risiko: Rewrites von Grund auf brauchen routinemäßig zwei- bis viermal so lange wie geplant, und das Geschäft muss die ganze Zeit über trotzdem auf dem alten System laufen. Ein Refactoring ist auf dem Papier günstiger und risikoärmer, bedeutet aber, mehr Geld in Code zu investieren, der später womöglich ohnehin verworfen wird. Keine der beiden Optionen wirkt sicher, solange du nicht weißt, wie schlecht die zugrunde liegende Codebasis wirklich ist, wie stark das Geschäft von undokumentierten Eigenheiten abhängt oder ob dein Team überhaupt die Kapazität hat, einen der beiden Wege umzusetzen.

Also bleibt das System liegen. Niemand will einen sechsstelligen Rewrite ohne Daten genehmigen, und niemand will Wartungsbudget in etwas stecken, das möglicherweise verworfen wird. Der verständliche Reflex ist, auf mehr Klarheit zu warten. Der unglückliche Nebeneffekt ist, dass das Warten ohne Support-Plan das System mit jedem weiteren Monat riskanter macht.

Was "sicher" für ein altes System wirklich bedeutet

Ein Legacy-System, das lediglich unberührt bleibt, ist nicht sicher. Sicherheit für eine alternde Codebasis hat eine konkrete, überprüfbare Form, und sie sieht anders aus als die Feature-Arbeit, für die die meisten Teams ihr Budget gewohnt sind.

Sicherheits-Patches müssen unabhängig von der Neubau-Entscheidung weiterlaufen. Framework- und Library-Schwachstellen werden nach ihrem eigenen Zeitplan veröffentlicht, nicht nach deinem, und ein System, das achtzehn Monate einfriert, während die Führung über seine Zukunft diskutiert, kann einen Rückstau an CVEs ansammeln, der aus einem routinemäßigen Patch-Zyklus ein mehrwöchiges Sanierungsprojekt macht. Backups müssen getestet werden, nicht nur geplant; ein nächtlicher Backup-Job, der seit Monaten stillschweigend fehlschlägt, ist einer der häufigsten Befunde bei einer externen Überprüfung eines vernachlässigten Systems. Monitoring und Alerting brauchen jemanden, der sie beobachtet, denn ein System, das niemand aktiv pflegt, ist auch eines, bei dem Alerts mit der Zeit stummgeschaltet und ignoriert werden. Und es braucht eine dokumentierte, eingeübte Reaktion für den Fall, dass um 2 Uhr nachts etwas kaputtgeht, denn die Person, die früher einfach wusste, wie man es behebt, arbeitet dort vielleicht nicht mehr.

Die Kosten des Nichtstuns

Verantwortliche, die auf eine Übergangs-Support-Lösung verzichten, gehen meist davon aus, dass der Nachteil sich auf "die Dinge bleiben etwas riskant" beschränkt. In der Praxis summieren sich die Kosten auf ein paar konkrete Arten.

Die Sicherheitsexposition wächst, je länger ein System ungepatcht bleibt, und Angreifer scannen kontinuierlich nach bekannten Schwachstellen in veralteter Software - die Gefahr ist also aktiv, nicht theoretisch. Das Risiko durch Schlüsselpersonen verschlechtert sich, je länger ein System unberührt liegt, weil die Menschen, die noch wissen, wie es funktioniert, in andere Rollen oder andere Unternehmen weiterziehen und das Wissen mit ihnen verschwindet. Compliance-Pflichten, besonders im Umgang mit Daten, pausieren nicht nur, weil eine Modernisierungsentscheidung noch offen ist; ein ungepatchtes System mit Kunden- oder Finanzdaten ist ein Risiko, unabhängig davon, ob jemand über sein langfristiges Schicksal entschieden hat. Und die Entscheidung selbst wird schwerer, gut getroffen zu werden, weil ein System, das ein Jahr lang vernachlässigt wurde, auf jeder Kennzahl schlechter aussieht als zu Beginn der Debatte - was die Führung zu einem drastischeren (und teureren) Neubau drängen kann, als das eigentliche Problem rechtfertigt.

Keine dieser Kosten taucht auf einem Posten namens "Kosten des Nichthandelns" auf. Sie tauchen später auf - als Vorfall, als Prüfungsbefund oder als Budgetanfrage, die niemand kommen sah.

Was ein sinnvolles Legacy-Software-Support-Modell abdeckt

Eine Legacy-Support-Vereinbarung mit festem Umfang während einer Entscheidungsphase ist enger gefasst als ein voller Wartungsvertrag und deutlich enger als aktive Entwicklung. In der Praxis deckt sie meist vier Dinge ab: Sicherheits-Patches in einem festgelegten Rhythmus statt nur dann, wenn etwas kaputtgeht; Backup und Disaster Recovery, die nach Plan getestet werden, statt deren Funktionieren einfach anzunehmen; Uptime- und Error-Monitoring mit einer echten Person, die die Alerts prüft; und einen dokumentierten Incident-Response-Plan, damit ein Ausfall um 2 Uhr nachts ein bekanntes Verfahren hat, statt einer hektischen Suche nach irgendjemandem, der sich an das System erinnert.

Was sie bewusst nicht abdeckt, sind neue Features, architektonische Änderungen oder irgendetwas, das die spätere Neubau-oder-Refactoring-Entscheidung verzerren würde. Der Zweck dieser Phase ist es, sicher Zeit zu gewinnen - nicht, sich heimlich auf einen Weg festzulegen, bevor die Belege vorliegen.

Die Support-Phase in entscheidungsreife Informationen verwandeln

Das Nützlichste an einer gut geführten Übergangs-Support-Vereinbarung ist, dass sie fast als Nebenprodukt der Systemstabilität genau die Eingaben liefert, die die Neubau-versus-Refactoring-Entscheidung braucht.

Incident-Logs aus der Support-Phase zeigen, welche Teile des Systems tatsächlich ausfallen und wie oft - verlässlicher, als sich auf institutionelles Gedächtnis darüber zu verlassen, was "instabil" ist. Ein Audit der Abhängigkeiten und Schwachstellen, durchgeführt im Rahmen des laufenden Patchings, gibt ein konkretes Bild davon, wie tief die technischen Schulden reichen, statt eines vagen Gefühls von "es ist halt alt". Nutzungsdaten, die in diesem Zeitraum gesammelt werden, zeigen, auf welche Features das Geschäft tatsächlich angewiesen ist im Vergleich zu denen, die existieren, aber unberührt bleiben - was für die Abgrenzung eines Rewrites oder Refactorings enorm wichtig ist. Und eine grundlegende Kapazitätsbewertung, die ehrlich prüft, ob das aktuelle Team einen Rewrite stemmen könnte oder ohnehin externe Hilfe bräuchte, nimmt eine der größten Quellen von Wunschdenken bei diesen Entscheidungen aus dem Spiel.

Wenn die Support-Phase endet, ist die Wahl zwischen Neubau und Refactoring keine Vermutung mehr. Unser Entscheidungsrahmen für Legacy-Systeme erklärt im Detail, wie man diese Wahl bewertet, sobald diese Daten vorliegen - einschließlich Codebasis-Gesundheit, Geschäftsrisiko, Teamfähigkeit und zeitlicher Einschränkungen.

Übergangs-Support bekommen, ohne sich vorab auf einen Weg festzulegen

Der praktische Weg, das aufzusetzen, ist, es als kurzes, klar abgegrenztes Engagement zu behandeln statt als unbefristeten Vertrag. Definiere die vier oben genannten Abdeckungsbereiche, lege feste monatliche Kosten fest und setze einen Review-Termin in den Kalender - oft neunzig Tage später - an dem du dir ansiehst, was die Support-Phase ans Licht gebracht hat, und entscheidest, ob genug vorliegt, um die Neubau-oder-Refactoring-Entscheidung zu treffen.

Auch hier hilft es, jemanden hinzuzuziehen, der kein Eigeninteresse daran hat, in welche Richtung die Entscheidung geht. Ein externes Team mit Fokus auf Legacy-Code-Optimierung und Stabilisierung kann diese Art von Support-Vereinbarung führen, ohne das übliche Anreizproblem eines internen Teams, das möglicherweise ein System verteidigt, das es selbst gebaut hat, oder einer Agentur, die auf den Verkauf eines Rewrites hofft, unabhängig davon, ob einer gerechtfertigt ist.

Wenn du auf einem System sitzt, über das du noch nicht entscheiden möchtest, geht es nicht darum, die Entscheidung zu überstürzen. Es geht darum, sicherzustellen, dass das System noch in gutem genug Zustand ist, um das umzusetzen, was du entscheidest - sobald du entscheidest. Melde dich unter hello@wolf-tech.io, oder schau dir wolf-tech.io an, wenn du eine zweite Meinung dazu willst, was ein Übergangs-Support-Plan für dein spezifisches System abdecken sollte.