PHP Frontend mit Next.js modernisieren: Bestehende Webanwendung schrittweise ablösen

Das Szenario ist vertraut: Eine Webanwendung, vor Jahren mit PHP und klassischen Server-Side-Templates gebaut, läuft stabil — aber jede neue Anforderung wird teurer. Formulare lassen sich nicht ohne Seitenreload validieren, das Laden von Tabellen blockiert die gesamte Seite, und neue Entwickler brauchen Wochen, um die verschlungene Template-Logik zu verstehen. Das Backend-Team kennt die Daten und die Geschäftslogik in- und auswendig. Trotzdem wächst der Wunsch: ein moderneres Frontend, das sich wie eine echte Anwendung anfühlt.

Der reflexartige Gedanke lautet dann oft: alles neu bauen. Aber ein vollständiger Neuaufbau bedeutet parallele Entwicklung zweier Systeme, monatelanger Testaufwand und ein Go-live-Datum, das mit jedem Sprint weiter in die Zukunft rückt. Es gibt einen pragmatischeren Weg: das PHP Frontend mit Next.js modernisieren — Seite für Seite, Bereich für Bereich, ohne den laufenden Betrieb zu gefährden.

Was diese Strategie wirklich bedeutet

Viele Unternehmen verstehen „Modernisierung" als Synonym für Komplettersatz. Das ist selten notwendig und noch seltener ratsam. Die Kernfrage lautet nicht: „Werfen wir PHP raus?" sondern: „Wo erzeugt PHP heute Schmerzen, die ein modernes JavaScript-Frontend lösen kann?"

Next.js ist ein auf React aufbauendes Framework, das serverseitiges Rendering (SSR), statische Seitengenerierung (SSG) und clientseitige Interaktivität in einem Paket vereint. Es ersetzt das Frontend — also alles, was der Browser rendert. Es ersetzt nicht automatisch die Datenbank, die Geschäftslogik, die Authentifizierung oder bestehende Integrationen. Diese Trennung ist der entscheidende Ausgangspunkt.

Ein PHP-Backend kann weiter Daten verarbeiten, Bestellungen abwickeln, E-Mails versenden und in ERP-Systeme schreiben — solange es seine Funktionen über eine definierte Schnittstelle bereitstellt. Next.js konsumiert diese Schnittstelle und übernimmt die Darstellung. Schicht für Schicht. Seite für Schritt.

Der aktuelle PHP-Sicherheitskontext: kein guter Zeitpunkt für Stillstand

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt zwei kritische Sicherheitsupdates: CVE-2026-109618 und CVE-2026-109619. Beide erreichen einen CVSS-v4.0-Basiswert von 9,2 und erlauben unter bestimmten Bedingungen nicht authentifizierte Remote-Code-Ausführung — CVE-2026-109618 etwa durch manipulierte Multipart-Anfragen, CVE-2026-109619 durch Use-after-free im globalen Worker-Zustand.

Betroffen sind alle PHP-Versionen unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Wer noch PHP 8.1 oder älter einsetzt, erhält vom PHP-Projekt keine offiziellen Patches mehr — nur minimale Quell-Backports, deren Verfügbarkeit je nach Hoster variiert. Das PHP-Security-Team hat solche Backports für 7.4, 8.0 und 8.1 veröffentlicht; für PHP 5 gibt es keinen Patch.

watchTowr meldete nach eigenen Angaben beobachtete Ausnutzung im eigenen Honeypot-Netz ab dem 21. Oktober 2026. In Fachmedien kursiert der Name „PHP2Shell" für entsprechende Exploits. Die einzige vollständige Abhilfe laut PHP-Projekt ist das Update auf eine gepatchte Version mit anschließendem Neustart aller PHP-Worker.

All das ist kein direktes Argument für eine Frontend-Migration — aber es unterstreicht, dass ein PHP-Stack, der auf veralteten Versionen läuft und keine saubere API-Schicht besitzt, mehrere Probleme gleichzeitig erzeugt: Sicherheitsrisiko, Modernisierungsblockade und operativen Druck. Wer heute die API-Schicht sauber trennt, vereinfacht morgen das Patchen und übermorgen die Frontend-Ablösung.

Weiterführende Details zu den aktuellen Schwachstellen finden Sie im Artikel PHP-System sicher und schrittweise modernisieren.

Was Next.js und React im Unternehmenseinsatz leisten

Bevor die Architektur erklärt wird, lohnt ein kurzer Blick auf die Substanz. React ist eine komponentenbasierte UI-Bibliothek: Eine Schaltfläche, ein Datentabellen-Widget, ein Formular mit Echtzeit-Validierung — all das entsteht als eigenständige, wiederverwendbare Komponente. Komponenten können unabhängig getestet, versioniert und ausgetauscht werden.

Next.js baut darauf auf und löst die Fragen, die React allein offen lässt: Wie wird eine Seite beim ersten Aufruf schnell geladen? Wie funktioniert serverseitiges Rendering für SEO-kritische Inhalte? Wie werden Routen definiert? Wie können API-Endpunkte direkt im Frontend-Projekt liegen?

Gerade der letzte Punkt ist für die PHP-Migration relevant: Next.js-API-Routes erlauben es, eine dünne Backend-Schicht direkt im Next.js-Projekt zu betreiben. Diese Schicht kann Anfragen des Browsers entgegennehmen, Authentifizierung prüfen, Daten aus dem PHP-Backend abrufen und sie transformiert an den Client zurückgeben. Das PHP-Backend muss dafür nicht umgebaut werden — es bekommt lediglich eine neue, kontrollierte Schnittstelle.

Mehr zu den Einsatzszenarien von Next.js im Unternehmensumfeld lesen Sie im Artikel Next.js für Unternehmen: Wann lohnt sich das Framework wirklich?.

Die vier Architekturebenen einer hybriden Migration

Eine schrittweise Migration teilt sich in vier klar trennbare Ebenen auf. Diese Trennung ist nicht akademisch — sie bestimmt, in welcher Reihenfolge Teams arbeiten können und wo Risiken entstehen.

1. API-Schicht: PHP als Datenlieferant

Der erste Schritt ist die Einführung einer sauberen API-Schicht im PHP-Backend. Das kann eine REST API sein, mit JSON-Antworten für alle Datenzugriffe, die das neue Frontend benötigt. In vielen PHP-Anwendungen existiert diese Schicht nicht — Datenabfragen und HTML-Erzeugung sind in denselben Dateien vermischt.

Die API-Schicht muss nicht alle Endpunkte auf einmal umfassen. Es reicht, mit den Bereichen zu beginnen, die das neue Frontend als erstes ablöst — zum Beispiel die Kundenliste, das Dashboard oder eine bestimmte Formularstrecke. PHP-Frameworks wie Laravel oder Symfony erleichtern diesen Schritt erheblich, weil sie saubere Controller-Strukturen und Authentifizierungslogik bereits mitbringen.

Wer kein modernes PHP-Framework einsetzt, kann die API-Schicht auch als separate Schicht vor dem Altsystem aufbauen. Entscheidend ist: Die PHP-Seite kommuniziert über definierte Endpunkte, nicht über gemeinsam genutzten Session-State oder direkte Datenbankzugriffe aus dem neuen Frontend.

2. Authentifizierung: Sitzungen gemeinsam oder getrennt führen

Authentifizierung ist das häufigste Stolperstein bei Frontend-Migrationen. PHP-Anwendungen nutzen typischerweise serverbasierte Sessions, die in Cookies gespeichert werden. Ein React-Frontend erwartet dagegen Token-basierte Authentifizierung — meistens JWT oder OAuth 2.0.

Es gibt zwei praxistaugliche Ansätze:

Session-Proxy über Next.js: Die Next.js-API-Routes übernehmen die Kommunikation mit dem PHP-Backend inklusive Session-Cookie. Der Browser spricht nur mit Next.js, Next.js reicht Anfragen mit dem gültigen PHP-Session-Cookie weiter. Aus Nutzersicht gibt es eine einzige Anmeldeseite.

Parallele Token-Ausstellung: PHP stellt nach erfolgreicher Anmeldung ein kurzlebiges Token aus, das Next.js zur Authentifizierung gegenüber der PHP-API nutzt. Dieser Ansatz ist sauberer, erfordert aber Änderungen im PHP-Backend.

Beide Ansätze funktionieren in der Praxis. Der erste ist schneller umgesetzt, der zweite ist langfristig wartbarer. Die Entscheidung hängt davon ab, wie viel PHP-Backend-Zeit im Projekt verfügbar ist.

3. Caching und Datenkonsistenz

Ein Next.js-Frontend kann PHP-Daten auf mehrere Arten cachen: im serverseitigen Cache von Next.js (Revalidation durch next/cache), in einem separaten Redis-Cache oder clientseitig über React Query. Das reduziert Last auf dem PHP-Backend und verbessert die wahrgenommene Geschwindigkeit erheblich.

Für Unternehmensanwendungen ist die Cache-Strategie entscheidend: Produktionsdaten, die sich minütlich ändern, dürfen nicht für Stunden gecacht werden. Statische Referenzdaten wie Produktkategorien oder Länderlisten hingegen können aggressiv gecacht werden. Next.js erlaubt es, diese Strategien pro Route und pro Datenabruf granular zu konfigurieren.

Ein häufiger Fehler: Das Frontend wird neu gebaut, der Cache aber nicht an die Invalidierungslogik des PHP-Backends angebunden. Das Ergebnis sind veraltete Anzeigen trotz frischer Datenbank. Die Lösung ist eine Webhook-Struktur oder ein Cache-Tag-System, das PHP-seitige Änderungen an den Next.js-Cache kommuniziert.

4. Schrittweise Seitenmigration: das Strangler-Pattern in der Praxis

Das Strangler-Fig-Pattern beschreibt die schrittweise Ablösung eines Altsystems durch ein neues — Bereich für Bereich, ohne Unterbrechung des Betriebs. Für PHP-zu-Next.js-Migrationen bedeutet das konkret:

Ein Reverse Proxy — typischerweise Nginx — steht vor beiden Systemen. Anfragen für /app/kunden werden an Next.js geleitet, alle anderen Pfade noch an PHP. Sobald ein weiterer Bereich in Next.js fertig und getestet ist, wird die Proxy-Konfiguration angepasst. Das PHP-System läuft weiter, verliert aber schrittweise Aufgaben.

Dieser Ansatz erlaubt echte Parallelentwicklung: Das Team, das den neuen Kundenbereich in React baut, blockiert nicht das Team, das am PHP-Backend weiterarbeitet. Deployments können unabhängig voneinander stattfinden. Und wenn ein neuer React-Bereich Probleme zeigt, reicht eine Nginx-Konfigurationsänderung, um den alten PHP-Bereich temporär zurückzuschalten.

Einen tieferen Einblick in das Strangler-Pattern und seine Anwendung auf PHP-Systeme bietet der Artikel Altseiten schrittweise mit dem Strangler-Pattern ablösen.

Praxisbeispiel: Buchungsbereich einer Unternehmensanwendung

Das folgende Beispiel ist hypothetisch, orientiert sich aber an typischen Projektkonstellationen, wie wir sie bei SW Business Solutions antreffen.

Ein mittelständisches Unternehmen betreibt eine PHP-Webanwendung für Ressourcenbuchungen — Maschinen, Räume, Fahrzeuge. Das Backend verwaltet Buchungsregeln, Verfügbarkeiten und Nutzerrechte. Das Frontend ist eine klassische Multi-Page-Anwendung mit vollständigen Seitenreloads bei jeder Aktion.

Der Wunsch: Ein Buchungskalender, der Verfügbarkeiten in Echtzeit zeigt, Buchungen per Drag-and-Drop verschiebt und auf Mobilgeräten nutzbar ist. Das PHP-Backend kann diese Anforderung nicht erfüllen, ohne komplett umgebaut zu werden — die Template-Engine ist für diese Art von Interaktivität nicht ausgelegt.

Der Migrationsplan sieht so aus:

1. API-Endpunkte im PHP-Backend für Verfügbarkeiten, Buchungsregeln und Buchungsaktionen (POST/PUT/DELETE) schaffen — zunächst ohne Authentifizierungsänderung.
2. Next.js-Projekt aufsetzen mit einer API-Route, die als Proxy zwischen Browser und PHP-Backend arbeitet und den Session-Cookie weiterreicht.
3. React-Kalenderkomponente entwickeln, die Verfügbarkeitsdaten vom Next.js-Proxy abruft, lokal cacht (React Query, 60-Sekunden-Revalidation) und Buchungen über denselben Proxy schreibt.
4. Nginx-Konfiguration anpassen: /buchung/* wird an Next.js weitergeleitet, alle anderen Pfade weiterhin an PHP.
5. Schrittweise Ausweitung: Nutzerverwaltung, Reporting und Stammdatenpflege folgen in späteren Sprints.

Nach dem ersten Deployment läuft die Buchungsseite auf Next.js und React, das gesamte restliche System auf PHP — ohne dass Nutzer einen Unterschied merken, außer dass der Buchungskalender jetzt flüssig funktioniert.

Typische Projektphasen und Aufwände

Die folgende Übersicht zeigt realistische Phasen für eine solche Migration. Aufwände variieren stark je nach Systemkomplexität, Qualität des PHP-Codes und verfügbarer Dokumentation.

Diese Zahlen sind Orientierungswerte — kein Festpreisversprechen. Projekte mit gut dokumentierten PHP-APIs und klaren Datenbankschemas starten schneller; Projekte mit eng gekoppeltem Template-Code brauchen mehr Zeit für die API-Schicht.

Was Next.js nicht automatisch löst

Wer erwartet, dass das neue Frontend automatisch Geschäftslogikprobleme bereinigt, wird enttäuscht. Wenn PHP-seitig Berechnungen falsch sind, Berechtigungen nicht granular genug greifen oder Stammdaten inkonsistent sind — das alles bleibt im neuen Frontend sichtbar. Next.js ist kein Datenbankbereiniger und kein Compliance-Tool.

Außerdem: Ein hybrider Stack aus PHP-Backend und Next.js-Frontend erfordert zwei unterschiedliche Entwicklungskompetenzfelder. Teams, die bisher ausschließlich PHP entwickelt haben, brauchen Einarbeitung in TypeScript, React und das Next.js-Deployment-Modell — zum Beispiel auf Vercel oder per Container. Diese Lernkurve ist real und sollte in die Projektplanung einfließen.

Ein weiterer Punkt: Wenn das PHP-Backend absehbar ebenfalls abgelöst werden soll — etwa weil die Datenbankstruktur überholt ist oder eine neue ERP-Integration kommt —, dann lohnt es sich, die API-Schicht von Anfang an so zu gestalten, dass sie später auch gegen ein neues Backend ausgetauscht werden kann. Das ist kein Mehraufwand, wenn es von Beginn an gedacht wird, aber eine kostspielige Nacharbeit, wenn es vergessen wird.

Wann eine schrittweise Migration nicht sinnvoll ist

Es gibt Fälle, in denen das schrittweise Vorgehen mehr kostet als ein kontrollierter Neustart:

• Das PHP-System ist so stark veraltet (PHP 5, PHP 7 ohne Patches), dass kein sicherer API-Layer aufgebaut werden kann, ohne das Sicherheitsrisiko zu prolongieren.
• Die Datenbankstruktur ist so eng mit dem Template-Code verwoben, dass selbst das Schreiben von API-Endpunkten einen Großteil des Systems berührt.
• Die Anwendung ist klein genug (unter ~20 Kernseiten, keine komplexe Geschäftslogik), dass ein Neuaufbau in vier bis acht Wochen realisierbar ist.

In diesen Situationen kann ein sauber geplanter Neubau schneller und günstiger sein als eine aufwändige Umbauarchitektur. Diese Ehrlichkeit gehört zur Beratung dazu — und ist einer der Gründe, warum wir bei SW Business Solutions immer mit einer Analyse beginnen, bevor wir einen Migrationsweg empfehlen.

Technologiestack: Was in der Praxis funktioniert

Für eine hybride PHP-zu-Next.js-Migration hat sich in unserer Projekterfahrung folgender Stack bewährt:

• Frontend: Next.js 14/15, React 18/19, TypeScript, Tailwind CSS für Styling
• State & Datenabruf: React Query für serverseitig geholte Daten, Zustand für lokalen UI-State
• Formulare: React Hook Form mit Zod-Validierung
• Proxy & Routing: Nginx als Reverse Proxy vor PHP und Next.js
• Auth-Brücke: Next.js API Routes mit Cookie-Weiterleitung oder JWT-Ausstellung durch PHP
• Hosting Next.js: Vercel, Hetzner mit Docker oder Railway
• CI/CD: GitHub Actions für automatisierte Tests und Deployments

PHP bleibt im Stack — zunächst als vollständiges Backend, später gegebenenfalls als schlankere API-Schicht oder wird durch Node.js/NestJS abgelöst, wenn das Projekt es erfordert.

Projekterfahrung bei SW Business Solutions

Bei der Entwicklung der Plattform für MobiKart Funracing GmbH haben wir genau diesen Ansatz umgesetzt: ein Next.js-Frontend, das über eine sauber definierte NestJS-API auf Buchungs- und Kapazitätsdaten zugreift, während die bestehende Kassensoftware und das Vor-Ort-System weiter ihre Aufgaben erfüllen. Das Ergebnis war ein Buchungssystem, das ohne Ablösung des gesamten Betriebssystems ausgerollt werden konnte — und das die Auslastung der Kartbahn messbar verbesserte.

Die vollständige Geschichte dieses Projekts finden Sie in der Fallstudie Wie MobiKart in 30 Tagen vom Telefonchaos zu 80 % Online-Buchungen, ~90 % Auslastung und 20 % mehr Umsatz kam.

Das Prinzip ist übertragbar: Wer ein PHP-System hat, das funktioniert, aber an der Oberfläche nicht mehr zeitgemäß ist, braucht keinen Komplettabriss. Er braucht einen strukturierten Plan, der Frontend-Modernisierung von Backend-Stabilität trennt.

Nächster Schritt: Den richtigen Schnitt finden

Die schwierigste Frage bei jeder Migration ist nicht „Welches Framework?" sondern „Wo fangen wir an?" Das hängt davon ab, welcher Bereich die größten Nutzerschmerzen verursacht, welche PHP-Endpunkte bereits sauber genug für eine API-Schicht sind, und was das Team in welcher Reihenfolge leisten kann.

Wenn Sie wissen möchten, wo der sinnvollste Modernisierungsschnitt in Ihrer Webanwendung liegt — von der Bestandsanalyse über die API-Architektur bis zur ersten migrierten Seite —, sprechen Sie uns an. Wir analysieren Ihren Stack, benennen Abhängigkeiten und erarbeiten einen Migrationsplan, der den laufenden Betrieb nicht gefährdet.

Weiterführende Artikel zu verwandten Themen:

• Next.js vs. WordPress: Was ist besser für Ihre Unternehmenswebsite?
• React vs. Vue vs. Angular: Welches Framework passt zu Ihrem Projekt?
• Next.js Performance Optimierung: So wird Ihre Website schnell und rankingstark
• Individuelle Webanwendung entwickeln lassen: Der ehrliche Leitfaden für KMU