Next.js 15 verliert am 21. Oktober 2026 seinen offiziellen Support. Der konkrete Plan zum Audit, zur Migration und zur Sicherung Ihrer App.
Next.js 15 endet am 21. Oktober 2026 vollständig und wird nicht mehr von HeroDevs unterstützt. Das bedeutet konkret: Nach diesem Datum gibt es keine Sicherheitspatches mehr, selbst bei kritischen Sicherheitslücken. Wenn Ihre Anwendung noch darauf läuft, finden Sie hier einen Plan zum Audit, zur Migration und zum Vermeiden klassischer Fallstricke vor der Deadline.
Warum dieser termin wirklich wichtig ist
Eine Version mit beendeter Unterstützung funktioniert nicht von heute auf morgen nicht mehr. Sie läuft einfach weiter, stillschweigend, bis eine CVE bekannt wird und niemand sie für Sie patcht.
Das ist das echte Risiko: keine sofortige Störung, sondern ein Sicherheitsfenster, das sich unverhofft öffnet. Sicherheitsteams Ihrer Kunden oder B2B-Partner stellen bei Audits immer häufiger Fragen zum Support von Abhängigkeiten. Ein nicht mehr gewartetes Framework kann einen SOC2- oder ISO-27001-Audit fehlschlagen lassen, unabhängig von der Qualität Ihres Codes.
Next.js 15 befindet sich derzeit im LTS-Wartungsmodus, was bedeutet: nur kritische Sicherheitspatches, keine neuen Funktionen mehr. Nach dem 21. Oktober 2026 auch das nicht mehr. Sie haben zum Zeitpunkt dieses Artikels etwas weniger als drei Monate Zeit zu entscheiden.
Drei Monate klingen lang. Das sind sie nicht für ein Team von unter 5 Entwicklern, das auch noch seine Features des Trimesters ausliefern muss.
Audit vor der migration: was sie zuerst überprüfen müssen
Zu migrieren ohne vorheriges Audit ist der beste Weg, einen Breaking Change am Freitag abend in der Produktion zu entdecken. Bevor Sie an package.json rühren, überprüfen Sie diese Punkte.
Residuale Nutzung des Pages Router. Viele Next.js-Anwendungen sind nach vorne zum App Router migriert, behalten aber API-Routes oder Legacy-Pages auf dem alten System. Das sind die ersten, die bei einer Major-Version-Erhöhung kaputt gehen.
Abhängigkeiten Dritter im Zusammenhang mit Rendering. Bibliotheken, die das Rendering-Verhalten von Next.js patchen (bestimmte A/B-Testing-SDKs, bestimmte Personalisierungstools), publizieren kompatible Versionen oft zu letzt. Überprüfen Sie deren Changelog, bevor Sie sich zu einem Zeitplan verpflichten.
Server Actions und Daten-Caching. Das mit dem App Router eingeführte Caching-Verhalten hat sich seit Next.js 13 mehrfach geändert. Falls Ihr Team manuelle Umgehungslösungen für die Revalidation implementiert hat, sind das praktisch garantierte Reibungspunkte bei einer Major-Migration.
Node.js- und React-Version. Next.js 15 basiert auf React 19; eine Major-Version-Erhöhung des Frameworks geht fast immer mit einer Erhöhung der minimal unterstützten Node-Version einher. Überprüfen Sie Ihre Production-Runtime, einschließlich Preview-Umgebungen.
Erstellen Sie diese Bestandsaufnahme in einer einfachen Tabelle, Zeile für Zeile, mit einer Spalte „Risiko" und einer Spalte „Geschätzter Aufwand". Das dauert einen halben Tag. Das erspart Ihnen zwei Wochen unangenehme Überraschungen.
Die konkreten schritte einer migration ohne bruch
Nachdem das Audit erledigt ist, folgt die Migration selbst einem relativ klaren Pfad, vorausgesetzt, Sie überspringen keine Schritte.
Schritt 1: isolieren sie eine repräsentative test-umgebung
Migrieren Sie nie direkt auf einen Branch, der zur Prod zeigt. Erstellen Sie eine Spiegelumgebung mit realistischen Daten, nicht einer leeren Datenbank. Caching- und Revalidation-Bugs treten oft erst mit echtem Traffic und echten Daten auf.
Schritt 2: version für version erhöhen, nicht in einem sprung
Falls Sie noch auf Next.js 13 oder 14 sind, zielen Sie nicht direkt auf Next.js 16 in einem Commit ab. Gehen Sie erst zu Next.js 15, stabilisieren Sie, dann folgen Sie nach. Jeder isolierte Major-Version-Sprung ist leichter zu debuggen als ein kumulativer Sprung über drei Versionen.
Schritt 3: nutzen sie offizielle codemods, wenn sie existieren
Vercel veröffentlicht historisch Codemods, um einen Teil der Migrationen zwischen Major-Versionen zu automatisieren (Import-Umbenennungen, Config-Anpassungen). Das deckt nie 100 % der Arbeit ab, aber es vermeidet Schreibfehler über hunderte Dateien.
Schritt 4: testen sie einen production-build, nicht nur den dev-modus
Dev-Modus verdeckt bestimmte Probleme bei Static Generation oder Edge Runtime. Ein vollständiger next build, gefolgt von einem Deploy auf eine isolierte Preview-Umgebung, muss Teil der Checkliste sein, bevor Sie mergen.
Schritt 5: planen sie einen rollback vor dem deployment, nicht danach
Halten Sie die alte Version nach dem Switch mindestens zwei Wochen mit einem Click deployed. Die meisten Cache- oder SEO-Regressionen (Tags, Sitemap, Weiterleitungen) treten erst nach mehreren Tagen echten Traffics auf.
Ein Produktteam mit einer Anwendung von 200 Seiten und komplexen Server Actions wird mehrere Wochen Arbeit verteilt über zwei oder drei Sprints zählen. Ein einfaches Portfolio von 15 Seiten ohne schwere Business-Logik kann in einem einzigen Sprint wechseln. Der Arbeitsaufwand zwischen diesen beiden Fällen ist riesig, seien Sie vorsichtig mit generischen Schätzungen aus dem Internet, sie berücksichtigen fast nie die echte Größe des Projekts.
Auf next.js 15 bleiben oder jetzt migrieren: der vergleich
| Kriterium | Auf Next.js 15 nach 21.10.2026 bleiben | Vor der Deadline zu Next.js 16 migrieren |
|---|---|---|
| Sicherheitspatches | Keine nach End-of-Life-Datum | Aktiver Support, regelmäßige Patches |
| Kompatibilität mit Anbieter-Audits | Risiko der Nicht-Konformität (SOC2, ISO 27001) | Konform mit Wartungsanforderungen |
| Unmittelbare Kosten | Kurzfristig null | Dev-Zeit einzuplanen (Wochen bis Monate) |
| Mittelfristiges Risiko | Technische Schulden sammeln sich an, Migration morgen schwieriger | Code-Basis aktuell, zukünftige Migrationen einfacher |
| Zugriff auf neue Features | Keine | Ja, je nach Next.js Roadmap |
Diese Tabelle ist nicht neutral: In der überwiegenden Mehrheit der Fälle verschiebt eine Verzögerung das Problem nur und verschärft es. Die einzige legitime Ausnahme ist ein Projekt, das selbst am Ende seines Lebenszyklus ist, das man vor der Deadline stilllegen will, in diesem Fall stellt sich die Frage nicht einmal.
Was sie mitnehmen sollten
Drei Punkte zum Merken. Erstens ist der 21. Oktober 2026 kein Gerücht: das ist der offizielle End-of-Life-Plan für Next.js 15. Zweitens bestimmt das Vorab-Audit, Pages Router, Abhängigkeiten Dritter, Caching, Node-Version, zu 80 % den Erfolg der Migration, lange bevor Sie eine Zeile Code schreiben. Drittens bleibt eine Migration von Version zu Version mit einer repräsentativen Test-Umgebung die sicherste Methode, auch wenn sie länger dauert als ein direkter Sprung.
Falls Ihr Team noch beim Zeitplan oder Umfang des Vorhabens zögert, hatten wir eine ähnliche Herangehensweise zur Version-Erhöhung in unserem Artikel über TypeScript 7.0 und den nativen Compiler in Go beschrieben, die gleichen Audit- und Verschiebungs-Prinzipien gelten hier.
Häufig gestellte fragen
Was passiert konkret, wenn man nach dem 21. oktober 2026 auf next.js 15 bleibt?
Die Anwendung läuft normal weiter. Das Risiko besteht in der fehlenden Fehlerbehebung im Falle einer Sicherheitslücke nach diesem Datum und in möglicher Nicht-Konformität bei Audits von Anbietern, die den aktiven Support kritischer Abhängigkeiten überprüfen.
Wie lange dauert eine migration von next.js 15 zu next.js 16?
Das hängt ganz von Größe und Komplexität der Anwendung ab. Ein einfaches Portfolio kann in einem Sprint wechseln; eine Anwendung mit komplexen Server Actions und residueltem Pages Router kann mehrere Sprints über mehrere Wochen erfordern.
Sollte man direkt zu next.js 16 migrieren, wenn man noch auf next.js 13 ist?
Nein, gehen Sie erst zu Next.js 15, stabilisieren Sie, dann folgen Sie nach. Ein isolierter Version-Sprung ist leichter zu debuggen als mehrere Major-Erhöhungen auf einmal.
Reichen offizielle codemods für die migration ohne manuelle eingriffe?
Nein. Codemods automatisieren einen Teil der Arbeit, Import-Umbenennungen, Config-Anpassungen, aber decken nie geschäftsspezifische Fälle, besonders rund um Caching und Server Actions. Ein manueller Durchgang ist unverzichtbar.
Wie testet man eine next.js-migration ohne production zu riskieren?
Indem man eine isolierte Preview-Umgebung mit realistischen Daten erstellt, einen vollständigen Production-Build (next build) ausführt und die alte Version mindestens zwei Wochen nach dem Switch als Rollback-Option behält.
