Es gibt eine bestimmte Art von PHP-Anwendung, die ich besonders oft sehe: keine Composer-Abhängigkeiten, ein selbstgebauter Front-Controller, ein hausgemachtes ORM mit einer Database-Klasse, die überall eingebunden wird, und ein Templating-System aus verschachtelten include-Aufrufen. Entstanden irgendwann zwischen 2005 und 2015. Läuft bis heute. Wird von niemandem mehr vollständig verstanden. Wird von jedem im Team heimlich gefürchtet.

Warum es damals Sinn ergab

Frameworks wie Symfony und Laravel waren entweder noch nicht ausgereift oder dem Team unbekannt. Wer damals eine Anwendung baute, baute eben alles selbst. Das war kein Fehler – es war der Stand der Dinge. Viele dieser selbstgebauten Systeme leisten seit 15 Jahren zuverlässig ihren Dienst. Das ist sogar ein bisschen beeindruckend, wenn man ehrlich ist.

Wo die Probleme entstehen

Das Eigenframework ist für das ursprüngliche Team maßgeschneidert – und für alle anderen undurchsichtig. Neue Entwickler brauchen Monate, um es zu durchdringen. Es gibt keine Community, keine Dokumentation, keine Updates. Sicherheitslücken werden nicht gepatcht, weil es kein Patch-Konzept gibt. Und weil niemand das System vollständig versteht, wächst die Angst, irgendetwas anzufassen – bis niemand mehr irgendetwas anfasst, außer in absoluten Notfällen, mit zitternden Händen.

Das Eigenframework wird zur unsichtbaren Abhängigkeit: unverzichtbar, unwartbar, unersetzbar. Bis heute.

Der Migrationspfad

Schritt 1: Composer einführen

Auch ohne Framework ist Composer der erste sinnvolle Schritt. Autoloading ersetzt die verschlungenen include-Ketten. Externe Pakete können eingebunden werden. Das schafft die Grundlage für alles Weitere – und fühlt sich bereits nach einem kleinen Sieg an.

Schritt 2: Framework-Komponenten einzeln einführen

Symfony bietet seine Komponenten einzeln an: HttpFoundation für Request/Response, Routing für den Front-Controller, Twig für Templates. Diese Komponenten lassen sich schrittweise neben dem bestehenden Code einführen, ohne das gesamte System umzubauen. Man muss nicht alles auf einmal ändern – man muss nur aufhören, alles selbst zu bauen.

Schritt 3: Das eigene Framework aushöhlen

Mit jeder migrierten Komponente schrumpft das Eigenframework. Am Ende bleibt nur noch die Anwendungslogik – das Wertvolle. Alles andere ist durch etablierten, gewarteten, dokumentierten Code ersetzt.

Ein gutes Framework ist kein Luxus. Es ist der Unterschied zwischen einer Anwendung, die wächst, und einer, die schrumpft.

Fazit

Der Wechsel von einem Eigenframework zu einem etablierten Stack ist einer der lohnendsten Schritte in der Legacy-Modernisierung. Er reduziert die Einstiegshürde für neue Entwickler, öffnet den Zugang zur Community und macht das System für die nächsten zehn Jahre pflegbar. Und er befreit das Team von der kollektiven Angst vor dem einen Ordner, den niemand anfassen will.