Wann sollte man ein Legacy-System wirklich ersetzen?

Die Frage kommt meist mit einem Seufzen: "Das alte System nervt, sollten wir es nicht einfach neu bauen?" Die ehrliche Antwort lautet fast immer: wahrscheinlich nicht. Ein System, das seit acht oder zwölf Jahren im Produktivbetrieb läuft, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert, dass tausende Sonderfälle abgedeckt sind, die niemand mehr dokumentiert hat. Das Problem ist selten die Logik selbst, sondern der Code drumherum: veraltete Frameworks, fehlende Tests, PHP 7.1 auf einem Server, den keiner mehr anfassen will.

Trotzdem gibt es Situationen, in denen Sie ein Legacy System ersetzen sollten. Der Punkt ist, diese Situationen ehrlich von dem Frust zu trennen, der sich über Jahre angesammelt hat. Dieser Artikel gibt Ihnen konkrete Kriterien an die Hand.

Warum ist eine Neuentwicklung meistens die falsche Entscheidung?

Eine Neuentwicklung ist in der Regel die teuerste und riskanteste Option von allen. Der Grund ist der "Second System Effect": Sie kennen die Schwächen des alten Systems genau, unterschätzen aber massiv, wie viel implizites Wissen darin steckt.

Ein gewachsenes PHP-System enthält oft hunderte Geschäftsregeln, die nirgends aufgeschrieben sind. Der Rabatt, der nur für Bestandskunden aus einer bestimmten Region gilt. Die Rundungslogik in der Rechnungserstellung, die vor Jahren wegen einer Steuerprüfung angepasst wurde. Die drei If-Abfragen, die einen konkreten Datenfehler abfangen. Wenn Sie neu bauen, fangen Sie bei null an, diese Regeln wieder zu entdecken. Meist merken Sie es erst, wenn ein Kunde sich beschwert.

Dazu kommt: Während das neue System entsteht, muss das alte weiterlaufen und weiter gepflegt werden. Sie zahlen also doppelt. Und der Tag, an dem Sie umschalten, ist einer der riskantesten im Leben Ihres Unternehmens.

Woran erkenne ich, dass das Problem nur der Code ist und nicht das System?

In den meisten Fällen ist nicht das System kaputt, sondern nur seine technische Verpackung. Das ist eine gute Nachricht, denn diese Probleme lassen sich schrittweise lösen, ohne die bewährte Logik anzutasten.

Typische Symptome, die nach Modernisierung statt Neubau rufen:

• Veraltete PHP-Version: Ein Upgrade von PHP 7.x auf 8.3 ist Arbeit, aber ein überschaubares und gut planbares Projekt, oft mit Werkzeugen wie Rector automatisierbar.
• Kein Framework oder ein totes Framework: Alten Zend-1- oder Symfony-1-Code kann man kapseln und stückweise nach Symfony oder Laravel migrieren.
• Keine Tests: Fehlende Tests sind ein Grund, welche zu schreiben, kein Grund, neu zu bauen. Charakterisierungstests sichern das bestehende Verhalten ab, bevor Sie etwas anfassen.
• Unübersichtliche Struktur: Spaghetticode lässt sich refaktorieren. Die Fachlogik bleibt dabei erhalten.

Merkregel: Wenn Sie die Sätze "Es macht fachlich das Richtige, aber der Code ist eine Katastrophe" unterschreiben würden, dann ist Modernisierung fast immer der bessere Weg.

Wann sollte man ein Legacy System wirklich ersetzen?

Ein Legacy System ersetzen lohnt sich dann, wenn nicht der Code das Problem ist, sondern die fachlichen oder wirtschaftlichen Grundlagen nicht mehr stimmen. Diese Signale sind ernst zu nehmen:

1. Die Geschäftsprozesse haben sich grundlegend geändert. Wenn das System von einem Geschäftsmodell ausgeht, das es so nicht mehr gibt, kämpfen Sie gegen die Architektur an. Beispiel: Ein reines Einzelplatzsystem, das plötzlich mandantenfähig und mehrsprachig werden soll.
2. Eine zentrale Abhängigkeit ist am Ende ihres Lebens. Eine Datenbank, die es nicht mehr gibt, ein kommerzielles Framework ohne Support, eine Bibliothek mit ungepatchten kritischen Sicherheitslücken, für die es kein Update mehr gibt.
3. Jede Änderung dauert unverhältnismäßig lange. Wenn eine kleine Anpassung Wochen kostet, weil alles mit allem verwoben ist und niemand die Nebenwirkungen abschätzen kann, verliert die Wartung ihren wirtschaftlichen Sinn. Wichtig: Das gilt erst, wenn gezielte Refaktorierung bereits versucht wurde und nicht mehr greift.
4. Es gibt niemanden mehr, der das System versteht. Wenn die Technologie so exotisch ist, dass Sie keine Entwickler mehr finden und keine Dokumentation existiert, wird das Risiko schwer kalkulierbar.
5. Sicherheit lässt sich nicht mehr herstellen. Wenn Architektur oder Framework grundlegend unsicher sind, etwa SQL-Injection an tausend Stellen durch fehlende Prepared Statements, und eine Absicherung teurer wäre als ein Neubau.

Entscheidend ist: Diese Punkte müssen fachlich oder existenziell sein. "Der Code gefällt mir nicht" gehört nicht dazu.

Gibt es einen Mittelweg zwischen Neubau und Weiterwursteln?

Ja, und es ist fast immer der beste Weg. Der sogenannte Strangler-Fig-Ansatz ersetzt ein System schrittweise, während es weiterläuft. Sie bauen nicht alles neu, sondern schneiden einzelne Bereiche heraus und ersetzen sie kontrolliert.

Konkret heißt das: Sie legen einen Reverse Proxy oder Router vor die Anwendung. Neue oder besonders problematische Funktionen entstehen als eigenständige, moderne Services, etwa in aktuellem Symfony oder Laravel. Der Router leitet die passenden Anfragen dorthin, alles andere bleibt vorerst beim Altsystem. Stück für Stück wandert so mehr Funktionalität in die neue Welt, ohne dass es je einen riskanten Big-Bang-Umstieg gibt.

Der große Vorteil: Sie liefern von Tag eins an Wert, können jederzeit stoppen, und das Risiko bleibt in jedem Schritt klein. Die bewährte Fachlogik läuft weiter, während Sie die Verpackung erneuern.

Welche Fragen sollte ich vor der Entscheidung ehrlich beantworten?

Bevor Sie Geld in die Hand nehmen, klären Sie diese Punkte schriftlich:

• Was genau stört, die Fachlogik oder der Code drumherum?
• Haben wir eine gezielte Modernisierung überhaupt schon versucht?
• Gibt es eine harte Deadline von außen, etwa das Support-Ende einer Kernkomponente?
• Können wir das bestehende Verhalten mit Tests absichern, bevor wir etwas ändern?
• Was kostet ein Neubau realistisch, inklusive Parallelbetrieb und der Wiederentdeckung aller Sonderfälle?

Wenn Sie diese Fragen ehrlich durchgehen, landen die meisten Unternehmen bei Modernisierung statt Neubau. Und genau das ist meist die richtige, weil günstigere und sicherere Entscheidung.

Praxis-Tipp zum Schluss

Treffen Sie die Entscheidung nie aus dem Frust heraus, sondern nach einer nüchternen Analyse. Nehmen Sie sich zwei bis drei besonders schmerzhafte Änderungswünsche der letzten Monate und fragen Sie: Wären die mit sauberem, modernem Code drumherum trivial gewesen? Wenn ja, ist Ihr System gesund, nur seine Hülle ist alt. Falls Sie bei genau dieser Abwägung eine unabhängige Zweitmeinung möchten, ist das einer der Bereiche, in denen ich mit LegacyWerk unterstütze.