Next.js-Upgrade selbst machen oder beauftragen? Eine Entscheidungshilfe für KMU

Stellen Sie sich folgende Situation vor: Ihr Entwicklungsteam hat gerade die letzten Quartalslieferungen abgehakt, als ein Ticket aufpoppt – „Next.js 15 Upgrade auf 16 einplanen". Niemand widerspricht, aber niemand setzt sich freiwillig daran. Das Projekt läuft stabil. Die Breaking Changes klingen überschaubar. Und dann landet das Ticket im Backlog, wo es drei Wochen liegt.

Am 21. Oktober 2026 endete die zweijährige Maintenance-LTS-Phase von Next.js 15 laut der offiziellen Support-Policy. Ab diesem Punkt sind für Version 15 nach der Policy keine weiteren Sicherheitsupdates mehr zugesagt – auch wenn Vercel in seltenen Ausnahmen außerhalb der Policy patchen kann. Wer auf 15.5.28 (dem letzten veröffentlichten 15.x-Stand) bleibt, ist zwar gegen alle bis zum 14. Oktober 2026 bekannten Lücken geschützt. Gegen künftig entdeckte Schwachstellen gibt es aber keine Policy-Garantie mehr.

Das ist der eigentliche Druck hinter der Upgrade-Frage – nicht die Featurelist von Next.js 16.

Was auf dem Spiel steht: Sicherheit, nicht nur Technik

Die Sicherheits-Historie von Next.js zeigt, wie schnell sich das Bild ändern kann. Allein zwischen Mai und Oktober 2026 gab es Security-Releases in fünf verschiedenen Monaten – darunter eine kritische Remote-Code-Execution-Lücke in der Image-Optimization-API (GHSA-2464-fhr4-w9xw, gepatcht in 15.5.28 und 16.4.1) und einen kritischen RCE auf Windows-gehosteten Servern (GHSA-p293-qw3h-jr36, gepatcht in 15.5.24). Vercel hat in diesem Zeitraum ausdrücklich einen formalen Security-Release-Prozess eingeführt.

Der Punkt ist nicht, Angst zu machen. Der Punkt ist: Wenn die nächste kritische Lücke entdeckt wird, erscheint der 15.x-Patch nach Policy nicht mehr automatisch. Wer das Upgrade noch vor sich hat, sollte daher einen konkreten Plan haben – keinen Backlog-Eintrag.

Welche Variante passt: selbst, extern oder gemeinsam? Das hängt von vier Variablen ab, die dieser Artikel durchgeht.

Die vier Entscheidungsvariablen

1. Technisches Profil des Projekts

Next.js 16 bringt Breaking Changes, deren Aufwand stark vom Projekt-Setup abhängt. Die wichtigsten:

• Turbopack als Standard: next dev und next build nutzen jetzt standardmäßig Turbopack statt Webpack. Existiert eine webpack-Konfiguration in next.config.js, schlägt der Build fehl. Ausweg: --webpack-Flag oder tatsächliche Migration.
• Async Request APIs: Synchroner Zugriff auf cookies(), headers(), draftMode(), params und searchParams wurde vollständig entfernt. Wer das bisher synchron aufgerufen hat, bekommt beim Build-Run Fehler – in jedem betroffenen Server Component.
• Middleware wird Proxy: Die middleware.ts-Datei und ihr Export sind deprecated; der Nachfolger heißt proxy. Der proxy läuft nur noch auf Node.js, nicht mehr auf der Edge-Runtime.
• ESLint Flat Config: next lint als Befehl entfällt; next build lintet nicht mehr automatisch. ESLint Flat Config ist Standard.
• Weitere Änderungen: serverRuntimeConfig/publicRuntimeConfig wurden entfernt, AMP-Support fällt weg, revalidateTag braucht ein zweites Argument, Parallel-Route-Slots benötigen explizit default.js.
• Node.js 20.9.0 Mindestvoraussetzung: Node 18 wird nicht mehr unterstützt.

Ein Projekt ohne eigene Webpack-Konfiguration, ohne Middleware-Logik, ohne synchronen Zugriff auf Request-APIs und ohne AMP ist ein Upgrade-Kandidat für das interne Team. Die offiziellen Codemods decken einen großen Teil der mechanischen Umstellungen ab:

npx @next/codemod@canary upgrade latest
npx @next/codemod@canary next-async-request-api .

Als Alternative bietet der offizielle Upgrade-Guide auch einen Coding-Agenten-Ansatz:

npx next@canary upgrade --agent=latest

Dessen Output muss aber manuell geprüft werden. Der Agent kann Muster erkennen, aber keine Geschäftslogik verstehen.

Sobald Authentifizierung in Middleware steckt – und das ist ein häufiges Muster in KMU-Projekten –, wird die Migration aufwändiger. Der proxy-Wechsel ist keine reine Umbenennung; die Laufzeitumgebung ändert sich. Wer dort Token-Validierung, Session-Checks oder Role-Based-Access implementiert hat, muss jeden Pfad sorgfältig testen.

2. Testabdeckung

Das zweite Kriterium ist oft das ehrlichste: Wie viel Testabdeckung hat das Projekt wirklich?

Wenn Jest- oder Cypress-Tests die kritischen User-Journeys abdecken und ein CI/CD-Pipeline läuft, zeigt ein fehlgeschlagener Build nach dem Upgrade sofort, wo nachgebessert werden muss. Das macht die Eigenumsetzung kalkulierbar.

Ohne Tests ist das Upgrade eine Wette. Der Codemod läuft durch, der Build ist grün, aber im Produktivbetrieb reagiert eine bestimmte Seite nicht mehr richtig – weil searchParams jetzt async ist und niemand alle Stellen im Code kannte. Das ist kein theoretisches Szenario, sondern das typische Muster, das nach schlecht getesteten Major-Upgrades entsteht.

Hypothetisches Beispiel: Ein Shop-Frontend mit 40 Seiten und einem zentralen Produkt-Router, der params synchron verwendet, funktioniert nach dem Codemod auf den ersten Blick korrekt. Erst in der Produktions-Ansicht mit echten Produktdaten zeigt sich, dass drei verschachtelte Layouts betroffen waren, die der Codemod nicht vollständig umgeschrieben hat. Ohne Tests wurde der Fehler erst nach dem Deploy entdeckt.

3. Anzahl und Kritikalität der Projekte

Für ein einzelnes internes Tool mit geringem Traffic und einem Test-Deploy ist das Kosten-Nutzen-Verhältnis bei der Eigenumsetzung klar positiv. Für einen transaktionskritischen Webshop oder eine Buchungsplattform, bei der jede Minute Downtime Umsatz kostet, ändert sich das Bild.

Noch deutlicher wird es, wenn mehrere Next.js-Projekte parallel laufen: Unternehmenswebsite, Kundenportal, internes Dashboard. Jedes Projekt hat seinen eigenen Stand, seine eigene Konfiguration und seine eigenen Abhängigkeiten. Das gebündelte Upgrade aller drei Projekte – parallel zu laufenden Sprint-Lieferungen – ist ein realistischer Kapazitätsengpass.

4. Verfügbare Kapazität und Nachbetrieb

Ein Upgrade ist keine einmalige Aktion. Nach dem Merge folgen:

• Monitoring der Produktiv-Logs auf neue Fehlertypen
• Anpassung der Deployment-Pipeline (Build-Flags, neue Output-Verzeichnisstruktur)
• Aktualisierung der internen Dokumentation
• Rücklauf aus dem QA-Team oder Fachbereich

Wenn das Team diese Nacharbeit innerhalb des normalen Sprints abfedern kann, ist die Eigenumsetzung realistisch. Wenn der nächste Milestone drei Wochen nach dem geplanten Upgrade-Termin liegt und das Team bereits voll eingeplant ist, wird das Upgrade erfahrungsgemäß verschoben – oder halbherzig durchgezogen.

Wann die Eigenumsetzung funktioniert

Die Eigenumsetzung ist eine valide und oft wirtschaftlich sinnvolle Wahl, wenn folgende Bedingungen zutreffen:

In diesem Fall ist die Empfehlung klar: Den offiziellen Upgrade-Guide durcharbeiten, Codemods ausführen, Ergebnisse reviewen, testen und deployen. Ein erfahrener Entwickler mit Next.js-Kenntnissen sollte ein unkompliziertes Projekt in ein bis zwei Tagen durch das Upgrade führen können – das ist eine Einschätzung, kein Versprechen, weil der tatsächliche Aufwand stark vom Code-Stand abhängt.

Wann ein Dienstleister sinnvoll ist

Es gibt Situationen, in denen das Next.js Upgrade beauftragen nicht nur bequemer, sondern schlicht das Risiko-minimierendere Vorgehen ist:

Authentifizierung in der Middleware: Wer Session-Handling, JWT-Validierung oder Rollen-Checks in middleware.ts implementiert hat, muss die Logik vollständig auf proxy mit Node.js-Laufzeit umschreiben und jeden gesicherten Pfad testen. Das ist kein Codemod-Job.

Komplexes Caching oder ISR: Die revalidateTag-Änderung und die neuen Caching-Profile (cacheLife) betreffen Projekte, die auf inkrementelle statische Regeneration angewiesen sind – typisch bei Content-lastigen Seiten. Caching-Fehler nach dem Upgrade zeigen sich oft erst unter realer Last, nicht im Staging.

Kein internes Next.js-Team: Wenn die Webanwendung von einem externen Dienstleister gebaut wurde und das interne Team nur rudimentäre JavaScript-Kenntnisse hat, fehlt die Basis für eine sichere Eigenumsetzung. Das Projekt zu "irgendwie updaten" ohne Verständnis der Breaking Changes ist riskanter als die Alternative.

Fehlende Tests bei geschäftskritischen Funktionen: Buchung, Zahlung, Login, Checkout – wenn diese Pfade keine automatisierten Tests haben, ist ein externes Review nach dem Upgrade kein Luxus, sondern Risikomanagement.

Mehrere Projekte parallel: Drei Next.js-Projekte in unterschiedlichem Zustand auf einmal upgraden zu wollen, bindet ein internes Team über Wochen. Wer das geballt an einen erfahrenen Dienstleister übergibt, spart Koordinationsaufwand und hält das eigene Team für die Delivery frei.

Bei SW Business Solutions haben wir mehrere Next.js-Projekte mit NestJS-Backend aufgebaut und betreut – unter anderem die Buchungswebsite und das Admin-Dashboard für MobiKart (MobiKart Buchungswebsite – Next.js (MobiKart Funracing GmbH)) sowie die Website und das Dashboard für die HPS-Pitbike-Plattform (HPS Pitbike Website – Next.js Marketing & Booking (Motorradcenter Stralsund GmbH)). Diese Projekterfahrung fließt direkt in die Upgrade-Arbeit: Wir kennen typische Konfigurationsmuster, Testlücken und die Stellen, an denen ein Codemod nicht reicht.

Mehr zur Frage, warum Next.js für Unternehmensanwendungen gut geeignet ist, lesen Sie in unserem Artikel Next.js für Unternehmen: Wann lohnt sich das Framework wirklich?.

Die Mischform: Internes Team setzt um, externe Prüfung schließt ab

Zwischen "alles selbst" und "alles auslagern" gibt es eine dritte Option, die in der Praxis oft den besten Kompromiss darstellt: Das interne Team führt das Upgrade durch, und ein externer Dienstleister übernimmt Upgrade-Check, Code-Review und Abnahme.

Das bedeutet konkret:

1. Upgrade-Check vor der Umsetzung: Analyse des Projekts auf Betroffenheit durch die Breaking Changes – Webpack-Nutzung, Middleware-Muster, synchrone API-Zugriffe, Caching-Stellen, Parallel Routes.
2. Begleitung während der Umsetzung: Technische Beratung bei unklaren Migrationsstellen, Review von Codemod-Output auf Korrektheit.
3. Abnahme nach dem Upgrade: Prüfung des finalen Stands vor dem Produktiv-Deploy – Build-Output, Linter-Konfiguration, Deployment-Pipeline, kritische User-Journeys.

Diese Variante ist sinnvoll, wenn das interne Team Next.js kennt und das Upgrade grundsätzlich stemmen kann, aber bei einem oder zwei kritischen Punkten unsicher ist – oder wenn das Projekt so wichtig ist, dass ein externer Augen-Pair vor dem Deploy-Tag Sicherheit gibt.

Was das Upgrade konkret umfasst

Unabhängig davon, wer das Upgrade durchführt, sind die Arbeitsschritte ähnlich. Zur Einordnung des Aufwands eine strukturierte Übersicht:

Die Codemods decken einen echten Teil der mechanischen Arbeit ab. Was sie nicht können: die Absicht hinter dem Code verstehen, Authentifizierungsflüsse rekonstruieren oder Caching-Strategien bewerten.

Was nach dem Upgrade folgt

Ein Upgrade auf Next.js 16.x ist kein abgeschlossenes Ereignis. Die aktuelle stabile Version ist 16.4.2 (Stand 15. Oktober 2026), und der Entwicklungszyklus läuft weiter – 16.5.0-canary.25 ist bereits in Vorbereitung.

Wer das Upgrade-Intervall strukturieren möchte, braucht eine klare Update-Strategie: welche Patch-Versionen automatisch eingespielt werden, wann ein manuelles Review stattfindet und wie der nächste Major vorbereitet wird. Dazu gibt es in der Content-Serie einen eigenen Artikel: nach dem Upgrade: Wartung und Update-Strategie.

Die Frage, was das Support-Ende von Next.js 15 konkret für den Betrieb bedeutet, und was kurzfristig zu tun ist, beleuchtet der Ausgangsartikel dieser Serie: Next.js 15 Support-Ende und nächste Schritte.

Wer wissen will, was ein professionelle Webentwicklung abseits des Upgrade-Themas für KMU leisten kann, findet im Artikel Webentwickler oder Agentur beauftragen: So wählen KMU den passenden Partner für ihre Website eine strukturierte Orientierungshilfe.

Die Entscheidung: Drei Fragen

Wer am Ende dieses Artikels noch unsicher ist, hilft eine einfache Selbsteinschätzung mit drei Fragen:

Frage 1 – Projektprofil: Hat mein Projekt eine eigene Webpack-Konfiguration, Authentifizierung in der Middleware oder synchronen Zugriff auf Request-APIs an mehr als fünf Stellen?
→ Ja: Externe Unterstützung prüfen.
→ Nein: Eigenumsetzung realistisch.

Frage 2 – Testabdeckung: Habe ich automatisierte Tests auf den geschäftskritischen Pfaden (Login, Buchung, Checkout, Hauptnavigation)?
→ Nein: Mindestens externes Abnahme-Review einplanen.
→ Ja: Eigenumsetzung kalkulierbar.

Frage 3 – Kapazität: Kann mein Team das Upgrade in den nächsten vier Wochen mit dedizierten Tagen abschließen, ohne laufende Delivery-Pflichten zu verschieben?
→ Nein: Beauftragung prüfen.
→ Ja: Mit Zeitpuffer planen und starten.

Wer auf alle drei Fragen eine klare positive Antwort hat, sollte selbst upgraden – mit dem offiziellen Guide und den Codemods als Grundlage.

Wer bei einer oder zwei Fragen unsicher ist, sollte das Gespräch mit einem erfahrenen Dienstleister suchen. Nicht wegen des Upgrades selbst, sondern um zu klären, welche der drei Varianten – Eigenumsetzung, Beauftragung oder Mischform – zum Projekt und zur Situation passt. Das kostet kein Commitment, spart aber unter Umständen Wochen nachträglicher Fehlersuche.

Der nächste Schritt bei SW Business Solutions ist genau das: ein unverbindliches Gespräch, in dem wir gemeinsam klären, was Ihr Projekt für das Upgrade braucht – und welche Rolle wir dabei sinnvoll spielen können.