Symfony-Rewrite oder Refactoring? Eine Entscheidungshilfe für Legacy-Systeme

Eine Entscheidung, die oft zu früh und zu emotional fällt

Wenn ein gewachsenes Symfony-System an seine Grenzen stößt, fällt der erste Impuls häufig auf denselben Satz: "Lasst uns das richtig neu bauen." Die Idee klingt verlockend, weil sie einen klaren Schnitt verspricht, weg von historischen Altlasten, hin zu einer sauberen Architektur ohne Kompromisse.

Aus eigener Erfahrung mit Legacy-Projekten zeigt sich jedoch ein anderes Bild. Ein Rewrite-Team betrachtet gewachsenen Code meist als Komplexität, die beseitigt werden muss. In der Praxis ist diese Komplexität aber oft angesammeltes Wissen über echte Geschäftsregeln, das erst verstanden und dann erhalten werden muss, nicht einfach weggeworfen. Dieser Artikel zeigt, wie sich diese Entscheidung strukturierter treffen lässt.

Die Ausgangslage: Welche Entscheidung ansteht

Wenn ein System aus fachlichen oder technischen Gründen an Grenzen stößt, sind grundsätzlich zwei Wege denkbar. Der komplette Rewrite ersetzt das System durch eine Neuentwicklung mit definiertem Stichtag für die Umstellung. Das schrittweise Refactoring modernisiert das bestehende System in kleinen, kontrollierten Schritten, während es weiterläuft.

Beide Wege sind grundsätzlich berechtigt, sie passen aber zu unterschiedlichen Ausgangslagen. Ein Rewrite konzentriert das Risiko auf einen einzigen Stichtag der Umstellung. Ein schrittweises Vorgehen verteilt dasselbe Risiko auf viele kleine, einzeln rückgängig machbare Schritte. Diese unterschiedliche Risikoverteilung ist der eigentliche Kern der Entscheidung, nicht die Frage, welcher Code hübscher aussieht.

Optionen mit wirtschaftlicher Einordnung

Für ein gewachsenes Symfony-System, das modernisiert werden soll, ergeben sich im Kern drei Wege.

Kompletter Rewrite. Das System wird von Grund auf neu gebaut, meist mit aktuellem Symfony-Stand und bereinigter Architektur. Der Vorteil liegt in der sauberen Ausgangslage ohne historische Kompromisse. Der Nachteil: Bis zur Umstellung liefert das neue System keinen Geschäftswert, während das alte System parallel weiterläuft und gepflegt werden muss. Fehlt dabei eine vollständige Erfassung der bestehenden Business-Logik, gehen Funktionen unbemerkt verloren, die im alten System nur implizit existierten.

Schrittweises Refactoring nach dem Strangler-Fig-Muster. Statt das gesamte System auf einmal zu ersetzen, wird eine Routing-Schicht vor das bestehende System gelegt. Einzelne, klar abgrenzbare Funktionsbereiche werden nacheinander neu implementiert und über diese Schicht schrittweise auf die neue Implementierung umgeleitet. Das alte System schrumpft dabei kontinuierlich, bis es vollständig abgelöst werden kann. Der Vorteil liegt darin, dass zu jedem Zeitpunkt ein funktionierendes System existiert und einzelne Migrationsschritte bei Problemen zurückgerollt werden können, ohne das Gesamtsystem zu gefährden.

Punktuelle Modernisierung ohne strukturierten Plan. Einzelne Problemstellen werden bei Gelegenheit verbessert, ohne übergeordnete Strategie. Das kostet wenig im Voraus, führt aber häufig dazu, dass sich technische Schulden an anderer Stelle unbemerkt weiter aufbauen, während die sichtbaren Symptome behandelt werden.

Entscheidungskriterien: Woran Sie die richtige Option erkennen

Vier Fragen helfen bei der Einordnung, welcher Weg zur eigenen Situation passt.

Lassen sich klare Komponentengrenzen ziehen? Das Strangler-Fig-Muster setzt voraus, dass sich einzelne Funktionsbereiche des Systems identifizieren und schrittweise herauslösen lassen. Ist die Architektur so eng verzahnt, dass keine sinnvollen Schnitte möglich sind, braucht es zunächst eine vorgelagerte Restrukturierung, bevor ein schrittweises Vorgehen überhaupt greift.

Kann das Unternehmen einen längeren Übergangszeitraum organisatorisch tragen? Ein schrittweises Vorgehen bedeutet, dass für eine gewisse Zeit zwei Systeme parallel existieren und die Routing-Schicht gepflegt werden muss. Fehlt die organisatorische Disziplin dafür, bleibt ein begonnenes Refactoring leicht auf halbem Weg stehen, mit doppeltem Wartungsaufwand als Ergebnis.

Wie kritisch ist ein fester Umstellungstermin? Muss ein System zu einem bestimmten Datum vollständig ersetzt sein, etwa aus regulatorischen Gründen, kann ein sorgfältig geplanter Rewrite trotz höherem Risiko die richtige Wahl sein. Ohne einen solchen harten Termin spricht wenig dafür, das Risiko unnötig zu konzentrieren.

Wie gut lässt sich der bestehende Code heute mit KI-gestützten Analysewerkzeugen erschließen? Moderne Codeanalyse-Tools verändern seit 2026 spürbar, wie schnell sich Business-Logik in unbekanntem Legacy-Code nachvollziehen lässt. Das senkt die Einstiegshürde für Refactoring-Projekte, ersetzt aber nicht die eigentliche Entscheidung über Komponentengrenzen und Migrationsreihenfolge.

Ein ehrlicher Punkt dazu, auch wenn er nicht für jedes Projekt für die aufwändigere Option spricht: Nicht jedes Legacy-System braucht ein strukturiertes Strangler-Fig-Vorgehen. Ein kleines, überschaubares System mit wenigen Abhängigkeiten lässt sich mitunter tatsächlich schneller und günstiger neu bauen, als es schrittweise zu modernisieren. Die Frage ist immer, ob der organisatorische Aufwand des schrittweisen Vorgehens im konkreten Fall gerechtfertigt ist.

Aus der Praxis

Wie die Entscheidung tatsächlich getroffen wird

Am Ende lässt sich die Wahl zwischen Rewrite und Refactoring nicht allein aus dem Alter oder der Unübersichtlichkeit eines Systems ableiten. Entscheidend ist das Zusammenspiel aus Systemgröße, vorhandenen Komponentengrenzen, organisatorischer Kapazität für einen längeren Übergang und der Frage, ob ein fester Stichtag unumgänglich ist.

Ein strukturiertes Vorgehen beginnt deshalb nicht mit der Wahl der Methode, sondern mit einer ehrlichen Bestandsaufnahme des Systems. Erst danach lässt sich beurteilen, welcher Weg für das konkrete Projekt tatsächlich der wirtschaftlichere ist.

Wie sich diese Entscheidung intern quantifizieren und begründen lässt.

Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler mit Fokus auf die Modernisierung gewachsener Legacy-Systeme für Agenturen und KMU im DACH-Raum. Mehr zur Zusammenarbeit als Symfony-Entwickler finden Sie auf der Leistungsseite.