Legacy-Risiko: was die Geschäftsführung wissen muss

Irgendwann steht der Satz im Raum: „Das alte System ist ein Risiko, wir müssen neu bauen." Meistens fällt er in einer Runde, in der keine Entwicklerin und kein Entwickler sitzt. Er klingt vernünftig, er klingt nach Verantwortung — und er führt regelmäßig zur teuersten und riskantesten Entscheidung, die eine Geschäftsführung im Bereich Software treffen kann. Bevor Sie diesen Weg gehen, lohnt ein nüchterner Blick darauf, worin das Legacy Risiko tatsächlich besteht und worin nicht.

Ein laufendes System ist ein Vermögenswert, kein Schuldschein

Eine Anwendung, die seit sieben, zehn oder fünfzehn Jahren produktiv läuft, hat etwas geleistet, das keine Präsentation ersetzen kann: Sie hat bewiesen, dass ihre Fachlogik funktioniert. Jeder Sonderfall im Rechnungslauf, jede krumme Ausnahme im Bestellprozess, jede regulatorische Eigenheit, die vor Jahren einmal mühsam abgestimmt wurde — all das steckt im Code. Oft undokumentiert, oft hässlich, aber es funktioniert.

Genau das wird bei einer Neuentwicklung unterschätzt. Sie ersetzen nicht eine Software, Sie ersetzen jahrelang erprobtes Fachwissen, das niemand mehr vollständig im Kopf hat. Das Problem an Legacy-Systemen ist fast nie die Fachlogik. Das Problem ist der Code drumherum: die Infrastruktur, die Abhängigkeiten, die Sicherheitslage. Diese Unterscheidung ist die wichtigste, die Sie als Geschäftsführung treffen müssen.

Wo das Legacy Risiko für die Geschäftsführung wirklich sitzt

Wenn wir über konkrete Gefahren sprechen, dann über diese — und sie sind messbar, nicht diffus:

• Nicht mehr unterstützte PHP-Versionen. Läuft eine Anwendung auf PHP 7.4 oder älter, erhält sie keine Sicherheitsupdates mehr. Jede neu entdeckte Schwachstelle bleibt offen. Das ist kein theoretisches Risiko, das ist eine offene Tür.
• Veraltete Abhängigkeiten. Alte Symfony- oder Laravel-Versionen, ein festgenageltes Composer-Setup, Bibliotheken ohne Wartung. Ein einziges Sicherheitsupdate kann dann eine Kaskade von Folgeänderungen auslösen — oder ist schlicht nicht mehr installierbar.
• Bekannte Angriffsflächen. SQL-Injection durch handgebaute Queries, fehlender CSRF-Schutz, im Klartext gespeicherte oder mit MD5 gehashte Passwörter. Solche Muster finden sich in alten Codebasen regelmäßig und sind bei einer Prüfung schnell sichtbar.
• Kein Wissensträger mehr im Haus. Der einzige Mensch, der das System verstand, hat vor drei Jahren gekündigt. Das ist ein reales Betriebsrisiko — aber eines, das man durch Analyse und Dokumentation adressiert, nicht durch Wegwerfen.
• Fehlende Tests und keine Deployment-Sicherheit. Wenn jede Änderung Bauchgefühl ist und ein Deployment ein Nervenspiel, wird das System künstlich unantastbar. Es läuft, aber niemand traut sich mehr, es anzufassen.

Das sind die Punkte, die in einer Risikobewertung stehen sollten. Auffällig ist: Keiner davon lautet „die Software macht fachlich das Falsche". Denn das tut sie in der Regel nicht — sonst wäre sie längst aufgefallen.

Warum Neuentwicklung das Legacy Risiko selten senkt

Die Intuition sagt: Neu bauen, dann ist alles sauber. Die Erfahrung sagt etwas anderes. Eine Neuentwicklung tauscht ein bekanntes, kalkulierbares Risiko gegen ein unbekanntes ein.

Beim Umbau eines bestehenden Systems wissen Sie ziemlich genau, was Sie haben. Bei einer Neuentwicklung starten Sie bei null — inklusive aller Fehler, die in den ersten Jahren des alten Systems schon einmal gemacht und behoben wurden. Die vielen kleinen Sonderfälle, die niemand mehr auf dem Schirm hat, tauchen erst auf, wenn sie im Neubau fehlen. Und während neu gebaut wird, muss das alte System weiterlaufen, weiter gepflegt werden und darf keine neuen Features bekommen, damit die Ziellinie nicht wegläuft. Diese Doppelbelastung ist der Punkt, an dem viele Projekte kippen.

Das heißt nicht, dass Neuentwicklung nie richtig ist. Wenn die fachlichen Anforderungen sich fundamental geändert haben und der Kern gar nicht mehr passt, kann sie der richtige Weg sein. Aber sie sollte die begründete Ausnahme sein, nicht der Reflex.

Der pragmatische Mittelweg: sichtbar machen, absichern, modernisieren

Zwischen „läuft schon irgendwie" und „alles neu" liegt der Weg, der fast immer der wirtschaftlichste ist. Er beginnt nicht mit Programmieren, sondern mit Klarheit:

1. Bestandsaufnahme. Welche PHP- und Framework-Version, welche Abhängigkeiten, welche bekannten Schwachstellen? Tools wie ein Security-Audit über Composer oder ein statischer Analyse-Lauf liefern in wenigen Tagen ein belastbares Bild. Danach diskutieren Sie über Fakten, nicht über Bauchgefühl.
2. Akute Sicherheitslücken zuerst schließen. Passwort-Hashing, SQL-Injection, veraltete PHP-Version — was direkt gefährlich ist, wird priorisiert behoben, nicht auf ein großes Projekt vertagt.
3. Ein Sicherheitsnetz einziehen. Tests für die kritischen Abläufe, ein reproduzierbares Deployment. Erst dann wird das System wieder anfassbar, ohne dass jede Änderung ein Risiko ist.
4. Schrittweise modernisieren. Framework-Versionen anheben, Code entwirren, Abhängigkeiten aktualisieren — in kleinen, jederzeit produktiv setzbaren Schritten. Das System bleibt die ganze Zeit lauffähig und liefert Wert.

Der Vorteil für Sie als Geschäftsführung: Sie behalten die Kontrolle über Budget und Risiko. Sie können nach jedem Schritt neu entscheiden. Und Sie verlieren nie die bewährte Fachlogik, die Ihr eigentliches Kapital ist.

Was Sie konkret tun sollten

Verlangen Sie vor jeder Grundsatzentscheidung eine unabhängige technische Bestandsaufnahme. Wer eine Neuentwicklung vorschlägt, sollte konkret benennen können, welches fachliche Problem der Neubau löst, das ein Umbau nicht löst. Kommt darauf keine klare Antwort, sondern nur „der Code ist alt" — dann sprechen Sie über ein Modernisierungsprojekt, kein Ersatzprojekt.

Ehrlicher Praxis-Tipp: Fragen Sie nie zuerst „Bauen wir neu?", sondern „Was genau ist heute das Risiko, in Zahlen?". Sobald das auf dem Tisch liegt, entscheidet sich die Frage oft von selbst — und meist gegen den Neubau.

Wenn Sie für Ihr bestehendes PHP-System genau diese nüchterne Einordnung suchen, bevor Geld in die falsche Richtung fließt, unterstützt LegacyWerk bei der Bestandsaufnahme und der schrittweisen Modernisierung.