PHP-Legacy auf den TypeScript-Stack migrieren: Der Weg ohne Big Bang

Fast vier von zehn PHP-Websites erhalten keine Security-Patches mehr: 29,7 Prozent laufen noch auf PHP 7, weitere 8,1 Prozent auf PHP 5 (W3Techs, Stand Juli 2026). Wenn Ihre Anwendung dazugehört, verantworten Sie kein Modernisierungsthema für irgendwann, sondern ein ungepatchtes System in Produktion — und bei 70,6 Prozent PHP-Anteil an allen Websites mit bekannter Server-Sprache ist das kein Nischenproblem, sondern der Normalfall im Bestand. Die gute Nachricht: Der Ausweg verlangt keinen Big Bang. Dieser Leitfaden beschreibt den Weg, den wir mit mittelständischen Kunden gehen — Modul für Modul, bei laufendem Betrieb.

Typ 1: Die Alt-PHP-Individualanwendung. Gebaut zwischen 2008 und 2018, oft von einem Dienstleister, der nicht mehr existiert oder dessen Wissensträger gegangen sind. Hier zählt zuerst die Versionsfrage: Alles vor PHP 8.2 ist End-of-Life. PHP 8.2 erhält Security-Fixes nur noch bis zum 31. Dezember 2026, PHP 8.3 bis Ende 2027 — seit der Policy-Änderung vom März 2024 gilt: zwei Jahre aktiver Support plus zwei Jahre Security-only (endoflife.date, Stand Juli 2026). Ein reines Versions-Upgrade ist bei diesen Anwendungen selten trivial, weil Extensions und Abhängigkeiten mitwandern müssen.

Typ 2: Das gewachsene Custom-Framework. Ein Eigenbau aus der Zeit vor Composer, mit eigenem Routing, eigenem ORM, eigener Template-Engine. Diese Systeme sind die teuersten im Betrieb: Jeder neue Entwickler lernt erst das Framework, dann die Fachlichkeit. Ein Upgrade auf moderne PHP-Versionen ist hier faktisch ein Rewrite im eigenen Haus — womit die Frage auf den Tisch gehört, ob dieses Budget nicht besser in einen Stack fließt, für den Sie auch 2030 noch Personal finden.

Typ 3: Die WordPress-verwachsene Anwendung. Begonnen als Marketing-Site, über Jahre mit Plugins und Custom Code zur Geschäftsanwendung geworden — Kundenkonten, Bestellprozesse, Schnittstellen. Das Problem ist hier weniger PHP als die Architektur: Geschäftslogik lebt in einem CMS, das dafür nie gedacht war, und jedes Plugin-Update ist ein Risiko fürs Kerngeschäft.

Wie konzentriert das Problem ist, zeigt der Vergleich zweier Datenquellen: Im aktiv gepflegten Composer/Packagist-Ökosystem laufen nur 11 Prozent der Installationen auf EOL-Versionen, PHP 8.4 führt mit 32 Prozent (stitcher.io, erhoben Juli 2026). Bei W3Techs sind es über alle Websites hinweg rund 38 Prozent. Die Lücke zwischen beiden Zahlen ist die eigentliche Diagnose: PHP-Legacy ist kein Sprachproblem, sondern ein Wartungsproblem — es konzentriert sich in Codebasen, die niemand mehr aktiv pflegt. Und selbst das gepflegte Ökosystem trägt Altlasten: Nur 352 der 1.000 wichtigsten Packagist-Pakete verlangen als Minimum eine PHP-Version, die noch Security-Updates erhält (stitcher.io, Juli 2026).

Bevor über Zielarchitektur gesprochen wird, gehört eine unbequemere Frage auf den Tisch: Muss es überhaupt ein Stack-Wechsel sein? Der naheliegende Weg ist die Modernisierung innerhalb des PHP-Ökosystems, typischerweise Richtung Laravel. Dieser Pfad funktioniert — er hat nur einen Takt, den man kennen sollte: Pro Major-Version gibt es 18 Monate Bugfixes plus 24 Monate Security-Fixes. Laravel 13, erschienen im März 2026, verlangt PHP 8.3 bis 8.5 und erhält Bugfixes bis September 2027; der Security-Support für Laravel 12 endet bereits im Februar 2027 (endoflife.date, Stand Juli 2026). Wer bleibt, kauft also keine Ruhe, sondern einen dauerhaften Upgrade-Rhythmus — der mit einem eingespielten Team gut beherrschbar ist.

Für den Stack-Wechsel spricht eine strukturelle Rechnung: Ein TypeScript-Stack mit Next.js und Node führt Frontend und Backend in einer Sprache zusammen — ein Team, ein Typsystem, geteilte Datenverträge. Laut State of JS 2025 schreiben 40 Prozent der Befragten nur noch TypeScript — ein deutlicher Hinweis, wohin sich der Talentpool im Web-Umfeld bewegt. Entscheidend ist aber nicht die Sprachmode, sondern Ihre Situation — und die lässt sich an fünf Kriterien festmachen.

Unsere ehrliche Einordnung: Trifft überwiegend die linke Spalte zu, bleiben Sie in PHP — ein Laravel-Upgrade mit eingespieltem Team ist der günstigere und risikoärmere Weg, und keine Agentur sollte Ihnen etwas anderes verkaufen. Trifft überwiegend die rechte Spalte zu, lohnt der Wechsel. Wie er ohne Betriebsunterbrechung gelingt, ist der Rest dieses Leitfadens.

Der klassische Fehler ist der Big-Bang-Rewrite: zwei Jahre parallel entwickeln, dann an einem Stichtag umschalten. Schrittweise Ablösungen nach dem Strangler-Muster scheitern rund 40 Prozent seltener als Big-Bang-Ansätze (Security Boulevard, 2026). Auch dokumentierte PHP-zu-Node-Migrationsguides empfehlen den endpointweisen Cutover hinter Load-Balancer oder Reverse-Proxy (NextGen Digital Craft, Februar 2026). Transparent gesagt: Belastbare Fallstudien mit harten Zahlen sind für die PHP-Route rar — das Vorgehensmuster selbst ist dafür umso besser etabliert. Fünf Schritte haben sich bei uns bewährt.

Der erste Baustein ist eine Integrationsschicht: Ein Next.js-Frontend übernimmt die Nutzeroberfläche und spricht im Hintergrund mit dem PHP-Bestand. Nutzer sehen ab dem ersten Release eine moderne Anwendung, während dahinter noch das Altsystem arbeitet. Wie dieses Muster im Detail funktioniert, haben wir im Leitfaden Next.js als Integrationsschicht für Legacy-Systeme beschrieben. Der Effekt ist auch politisch wichtig: Das Projekt liefert sichtbaren Fortschritt, bevor die erste Zeile Backend abgelöst ist.

Damit die Fassade sauber arbeiten kann, braucht das Altsystem definierte Schnittstellen. In der Praxis heißt das: Die relevanten Funktionen des PHP-Monolithen werden hinter einer schmalen API-Schicht verfügbar gemacht — zunächst lesend, dann schreibend. Diese Verträge, typischerweise als OpenAPI-Spezifikation, sind später die Messlatte für jedes neue Modul: Der TypeScript-Nachfolger muss denselben Vertrag erfüllen, bevor Traffic umgeleitet wird. So bleibt jeder Umschaltschritt einzeln testbar und einzeln rückholbar.

Der pragmatische — und oft verschwiegene — Teil: In der Übergangsphase greifen Alt- und Neusystem auf dieselbe Datenbank zu. Das ist architektonisch unschön, aber betrieblich richtig, weil es die Datenmigration von der Modul-Ablösung entkoppelt. Wichtig sind klare Schreibhoheiten: Jede Entität hat genau einen schreibenden Eigentümer, alle anderen lesen. Die eigentliche Datenmigration folgt später, Modul für Modul, wenn der neue Eigentümer produktiv ist.

Nichts zerstört Nutzerakzeptanz schneller als doppelte Logins während der Migration. Eine zentrale Identity-Lösung wie Keycloak sitzt vor beiden Systemen: Nutzer melden sich einmal an, Alt- und Neusystem validieren dieselben Tokens. Der Nebeneffekt zahlt sich doppelt aus: Rollen und Berechtigungen werden einmal zentral modelliert — eine Investition, die jedes weitere Modul wiederverwendet.

Jetzt beginnt die eigentliche Ablösung: Das erste Modul — fachlich gut abgegrenzt, mit hohem Änderungsdruck — wird in TypeScript neu gebaut und über die Fassade in Betrieb genommen. Danach wiederholt sich das Muster, priorisiert nach Geschäftswert. Das Prinzip entspricht der Two-Speed-Strategie, die wir für Java-Kernsysteme beschrieben haben; für Spring-Boot-Teams gibt es den analogen Migrations-Leitfaden Richtung NestJS. Das PHP-System wird dabei nicht abgeschaltet, es wird bedeutungslos — bis der letzte Cron-Job umgezogen ist.

Konkrete Zahlen statt Ausweichfloskeln — das sind die Spannen aus unseren Projekten. Sie hängen vor allem am Integrationsgrad und an der Datenqualität des Bestands:

Stand: Juli 2026. Alle Preise netto. Spannen aus realen Projekten der happycoding.agency; verbindlich wird es nach der Discovery-Phase.

Sie haben ein eingespieltes PHP-Team und einen gangbaren Laravel-Pfad. Dann ist Bleiben die wirtschaftlich bessere Entscheidung. Ein Team, das sein Framework beherrscht und den Upgrade-Takt diszipliniert mitgeht, schlägt jeden Stack-Wechsel — eine Migration löst Technologie-Probleme, keine Team-Probleme.

Die Anwendung hat weniger als drei Jahre Restlebensdauer. Wird das System ohnehin durch Standardsoftware ersetzt oder mit dem Geschäftsbereich eingestellt, reicht Absichern: Upgrade auf eine unterstützte PHP-Version, Härtung, notfalls Isolation hinter WAF und VPN. Das ist unspektakulär — und genau richtig.

Das System ist stabil und ohne Änderungsdruck. Ein internes Tool, das seit Jahren zuverlässig läuft und zwei Anpassungen pro Jahr braucht, rechtfertigt keinen Neubau. Hier gilt: aktuelle PHP-Version, gepflegte Dependencies, Monitoring — mehr nicht.

Ihre Anwendung ist im Kern eine Content-Website. Eine WordPress-Site, die primär Inhalte ausspielt, bleibt in WordPress gut aufgehoben. Kritisch wird es erst, wenn Geschäftslogik ins CMS eingewachsen ist — dann ist nicht PHP das Problem, sondern der Ort der Logik.

Der belastbare Einstieg ist keine Grundsatzentscheidung im Lenkungskreis, sondern eine kompakte Bestandsaufnahme: Welche Module hat der Monolith, wo ist der Änderungsdruck, was hängt an welcher PHP-Version, welches Modul eignet sich als erster Kandidat? Genau das leistet unser Modernisierungs-Assessment zum Festpreis — die Details finden Sie auf der Seite Software-Modernisierung. Und wenn Sie vorab klären wollen, ob Ihr Fall eher nach Laravel-Upgrade oder Stack-Wechsel aussieht: Ein 30-minütiges Erstgespräch reicht für eine erste ehrliche Einschätzung.