Next.js-Upgrade: Wovon Aufwand und Kosten abhängen und wie Sie realistisch planen

Das Budget-Meeting ist fertig, der Termin steht — und dann fragt die Geschäftsführung, was das Next.js-Upgrade auf Version 16 kostet. Eine valide Frage, für die es ohne Codeanalyse schlicht keine ehrliche Antwort gibt. Wer trotzdem eine Zahl nennt, riskiert entweder einen unterschätzten Aufwand, der Zeit und Budget sprengt, oder eine überhöhte Schätzung, die das Vorhaben auf die lange Bank schiebt — bis die Maintenance-Phase von Next.js 15 abgelaufen ist und das Projekt ohne zugesagte Sicherheitsupdates weiterläuft.

Dieser Artikel erklärt, welche konkreten Faktoren den Aufwand eines Upgrades von Next.js 15 auf 16 bestimmen, welche Risiken das Aufschieben mit sich bringt und wie ein belastbares Angebot entsteht — ohne Pauschalpreise zu erfinden, die für Ihr Projekt ohnehin nicht stimmen würden.

Was Next.js Upgrade Kosten wirklich bedeuten: kein Pauschalbetrag, sondern eine Codeanalyse

„Was kostet das Upgrade?" ist die falsche Einstiegsfrage. Die richtige lautet: „Was steckt in unserem Code, das beim Upgrade Arbeit macht?" Denn Next.js 16 bringt eine ungewöhnlich hohe Dichte an Breaking Changes — mehr als die meisten Minor-Updates der letzten Jahre. Ein Projekt, das die betroffenen APIs nicht nutzt und eine saubere Abhängigkeitsliste hat, lässt sich in wenigen Stunden migrieren. Ein Projekt mit tief integrierter Webpack-Konfiguration, dutzenden synchronen cookies()-Zugriffen und einer veralteten Node.js-Version auf dem Hosting kann ein mehrtägiges Vorhaben sein.

Die Spanne ist real — und sie ergibt sich ausschließlich aus dem Ist-Zustand des Codes.

Die Aufwandstreiber im Einzelnen

Turbopack als neuer Standard-Bundler

Next.js 16 macht Webpack nicht mehr zum Standard. Sowohl next dev als auch next build laufen jetzt mit Turbopack. Wer eine eigene webpack-Konfiguration in der next.config-Datei hat — etwa für Custom-Loader, Aliases oder spezielle Plugin-Ketten — wird nach dem Upgrade feststellen, dass der Build fehlschlägt. Der Codemod npx @next/codemod@canary upgrade latest stellt die Konfiguration automatisch um, soweit möglich. Was er nicht auflösen kann: Webpack-Plugins ohne Turbopack-Äquivalent, Custom-Loader für proprietäre Dateiformate oder Build-Skripte, die auf Webpack-interne Strukturen zugreifen.

Wer einen solchen Setup hat, braucht Zeit für Analyse, Äquivalenzsuche und Test. Wer keine eigene Webpack-Konfiguration hat, ist hier mit null Aufwand durch.

Synchroner Zugriff auf cookies(), headers(), params und searchParams

Das ist erfahrungsgemäß der häufigste Aufwandstreiber in produktiven Next.js-Projekten. Next.js 16 entfernt vollständig den synchronen Zugriff auf cookies(), headers(), draftMode(), params und searchParams. Wer in Server Components oder Route Handlers noch const cookieStore = cookies() schreibt, statt auf das asynchrone await cookies() umzusteigen, bekommt einen Build-Fehler.

Der Codemod npx @next/codemod@canary next-async-request-api . wandelt diese Stellen automatisch um. Aber er kann nur umwandeln, was er findet und eindeutig zuordnen kann. Bei komplexen verschachtelten Aufrufen, dynamisch komponierten Middleware-Ketten oder Utility-Funktionen, die intern auf diese APIs zugreifen, muss ein Entwickler manuell prüfen.

Entscheidend ist die Anzahl der Stellen: Ein Projekt mit 5 Server Components, die headers() auslesen, hat einen klar abgrenzbaren Aufwand. Ein Projekt mit 80 Seiten, von denen viele auf searchParams oder params zugreifen, kann trotz Codemod mehrere Stunden Nacharbeit erzeugen.

Das Gleiche gilt für Metadaten-Dateien: opengraph-image, twitter-image, icon, apple-icon und sitemap bekommen mit Next.js 16 ebenfalls async-Anforderungen, wenn sie auf diese APIs zugreifen.

Middleware wird zu proxy

Die bisherige middleware.ts ist in Next.js 16 deprecated; der neue Mechanismus heißt proxy. Der Codemod benennt Datei und Export automatisch um. Was er nicht löst: proxy läuft nur auf der Node.js-Runtime, nicht auf der Edge-Runtime. Wer seine Middleware bisher auf Edge laufen ließ — etwa für geoblocking, Auth-Checks oder Feature-Flags — muss die Laufzeit-Strategie überdenken. Das ist kein trivialer Codemod-Schritt, sondern eine architektonische Entscheidung.

revalidateTag, runtimeConfig und Cache-Features

revalidateTag braucht in Next.js 16 ein zweites Argument: das cacheLife-Profil, zum Beispiel 'max'. Wer ISR oder On-Demand-Revalidation mit Tags einsetzt, muss alle Aufrufe anpassen.

serverRuntimeConfig und publicRuntimeConfig sind vollständig entfernt. Wer diese bisher für environment-spezifische Konfiguration genutzt hat, muss auf Umgebungsvariablen umstellen — das ist meist unkompliziert, aber es kostet Zeit, wenn es viele Stellen betrifft.

Die experimentellen Cache-Features experimental.dynamicIO, experimental.useCache und experimental.ppr existieren nicht mehr. Der Ersatz ist cacheComponents. Wer bewusst mit diesen experimentellen APIs gearbeitet hat, hat entsprechenden Umbaubedarf.

AMP-Support entfernt

AMP-Seiten werden von Next.js 16 nicht mehr unterstützt. Wer AMP nie eingesetzt hat: kein Aufwand. Wer AMP-Seiten betreibt, muss entscheiden, ob ein Ersatz gebaut wird oder ob die Seiten entfallen.

next/image-Konfiguration und neue Defaults

Die Defaults von next/image ändern sich mit Next.js 16 spürbar: minimumCacheTTL steigt von 60 Sekunden auf 4 Stunden, qualities umfasst nur noch [75], imageSizes verliert den Wert 16, und lokale Bilder mit Query-Strings brauchen künftig images.localPatterns.search. next/legacy/image und images.domains sind deprecated.

Für die meisten Projekte sind das Defaults, die stillschweigend wirken — aber wer eine durchdachte Image-Optimierungsstrategie mit eigenen imageSizes-Werten oder speziellen TTL-Einstellungen hat, muss prüfen, ob die neuen Defaults das gewünschte Verhalten noch liefern. Das ist kein Codemod-Thema, sondern eine Konfigurationsentscheidung.

Parallel Routes und default.js

Wer Parallel Routes nutzt, muss für jeden Slot eine explizite default.js-Datei anlegen, sonst schlägt der Build fehl. Bei wenigen Slots ist das eine Sache von Minuten. Bei komplex aufgebauten Layout-Architekturen mit vielen Slots kann das mehrere Stellen betreffen, die einzeln geprüft werden müssen.

Lint-Setup

next lint ist in Next.js 16 entfernt. next build lintet nicht mehr, und die eslint-Option in der Next.js-Konfiguration wurde gestrichen. Standard ist jetzt ESLint Flat Config. Wer noch eine klassische .eslintrc-Konfiguration hat, muss migrieren — oder zumindest sicherstellen, dass das Lint-Setup weiterhin im CI-Prozess läuft, auch wenn es nicht mehr in den Build eingebettet ist.

Der Codemod npx @next/codemod@canary next-lint-to-eslint-cli . hilft bei der Umstellung, deckt aber nicht alle individuellen ESLint-Konfigurationen ab.

Node.js-Version des Hostings

Next.js 16 erfordert mindestens Node.js 20.9.0. Node 18 wird nicht mehr unterstützt. Das ist kein Code-Problem, sondern ein Infrastrukturproblem: Wer noch auf Node 18 hosted — ob auf eigenem Server, bei einem Managed-Hoster oder in einer Cloud-Umgebung — muss vor oder parallel zum Upgrade auf Node 20 wechseln. Bei manchen Hosting-Providern ist das ein Konfigurationsschalter. Bei anderen bedeutet es ein Serverupgrade oder eine Migration auf eine andere Infrastruktur.

Zustand der Abhängigkeiten

Neben den Next.js-eigenen Breaking Changes gibt es einen Faktor, der im Briefing oft unterschätzt wird: der Zustand der restlichen package.json. Veraltete Abhängigkeiten, die inkompatibel mit Node 20 oder React 19 sind, können den Upgrade-Aufwand erheblich erhöhen. Wer seit Monaten keine npm audit-Bereinigung gemacht hat und viele Pakete im Rückstand hat, zahlt gewissermaßen die aufgelaufene technische Schuld beim Upgrade nach.

Ein sauberes Abhängigkeitsumfeld ist kein Luxus — es ist die Grundlage für planbare Upgrade-Kosten.

Testabdeckung

Wie sicher ist das Team danach, dass das Upgrade nichts kaputt gemacht hat? Wer eine gute Testabdeckung mit automatisierten Tests hat — Unit-Tests, Integrationstests, End-to-End-Tests mit Cypress oder Jest — kann nach dem Upgrade auf Knopfdruck prüfen. Wer hauptsächlich manuell testet, zahlt entweder in Testzeit oder in Risiko.

Projekte ohne Tests brauchen nach dem Upgrade deutlich mehr manuelle Verifikationsaufwand. Das gehört zur realistischen Kalkulation.

Anzahl der betroffenen Projekte

Wer mehrere Next.js-Projekte betreibt, multipliziert den Aufwand nicht einfach — aber er addiert ihn. Jedes Projekt hat seinen eigenen Zustand, seine eigene Abhängigkeitsliste, seine eigene Hosting-Infrastruktur. Vier Projekte bedeuten vier separate Analysen und vier separate Upgrades, auch wenn es Ähnlichkeiten gibt.

Hypothetisches Planungsbeispiel: zwei Projekte im Vergleich

Um zu zeigen, warum Pauschalpreise hier nicht funktionieren, ein transparentes Gegenüberstellungsbeispiel — als hypothetische Einschätzung, keine reale Projektreferenz:

Projekt A ist mit Codemod und anschließendem Abnahmetest in wenigen Stunden erledigt. Projekt B hat dagegen auf fast jedem Aufwandstreiber etwas zu tun: Webpack-Analyse, 47 async-Migrationen, Middleware-Umbau auf Node.js-Runtime, 12 revalidateTag-Anpassungen, 8 runtimeConfig-Umstellungen, AMP-Entscheidung, Hosting-Upgrade auf Node 20 und anschließend aufwändige manuelle Verifikation. Das ist ein mehrere Tage umfassendes Vorhaben.

Beide Projekte laufen auf Next.js 15. Beide sollen auf Next.js 16 migriert werden. Der Aufwandsunterschied ist trotzdem fundamental — und er lässt sich nur durch Codeanalyse aufdecken, nicht durch Erfahrungswerte „aus dem Bauch".

Was das Aufschieben kostet

Das Argument „wir schieben das Upgrade auf, bis es dringender wird" hat einen konkreten Preis — nur ist er weniger sichtbar als eine Rechnung.

Die Maintenance-LTS-Phase von Next.js 15 endet nach der offiziellen Support-Policy zwei Jahre nach dem Release, also am 21. Oktober 2026. Danach sind laut Policy keine kritischen Bugfixes und Sicherheitsupdates mehr zugesagt. Vercel behält sich Ausnahmen bei besonders schwerwiegenden Lücken vor, garantiert sie aber nicht.

Wie hoch das Risiko ist, zeigt ein Blick auf die Sicherheitshistorie der letzten Monate: Seit Mai 2026 gab es Security-Releases im Mai, Juli, August, September und Oktober — darunter kritische Lücken mit Remote Code Execution in der Image Optimization API (GHSA-2464-fhr4-w9xw, gepatcht in 15.5.28) und Server Actions (GHSA-p3m5-59mp-jv5r). Die letzte bekannte 15.x-Version zum Zeitpunkt der Recherche ist 15.5.28 vom 14. Oktober 2026. Wer auf diesem Stand bleibt, ist gegen alle bisher bekannten Lücken geschützt — aber gegen künftig entdeckte gibt es nach Ablauf der Maintenance-Phase laut Policy keine zugesagten Patches mehr.

Das ist kein theoretisches Risiko. Es ist eine betriebliche Entscheidung: Wer wartet, akzeptiert das Risiko, irgendwann auf einem Framework ohne Sicherheits-Backports zu sitzen. Und ein ungeplantes Notfall-Upgrade unter Druck ist fast immer teurer und fehleranfälliger als ein vorbereitetes.

Die Alternative zu einem geplanten Upgrade ist übrigens kein günstigerer Weg — es ist ein ungeplanter. Und zur laufenden Softwarewartung und was sie kostet kommen beim Aufschieben unweigerlich aufgelaufene technische Schulden hinzu, die irgendwann nachbezahlt werden.

Warum der Codemod nicht alles erledigt

Die offiziellen Codemods von Vercel sind ein sinnvolles Werkzeug — sie erledigen den mechanischen Teil der Migration. Aber sie haben Grenzen:

• Sie wandeln um, was eindeutig identifizierbar ist. Logik, die über mehrere Dateien verteilt ist, oder Wrapper-Funktionen, die intern auf deprecated APIs zugreifen, werden nicht zuverlässig erkannt.
• Sie prüfen nicht, ob das Ergebnis semantisch korrekt ist — nur ob die Syntax stimmt.
• Sie laufen nicht gegen laufende Tests. Regressionen, die durch die Umstellung entstehen, zeigen sich erst beim Testen.
• Infrastruktur — Node.js-Version, Hosting-Konfiguration, CI/CD-Pipelines — liegt vollständig außerhalb des Codemod-Scopes.

Ein erfahrener Entwickler nutzt den Codemod als Ausgangspunkt, nicht als Abschluss. Die eigentliche Arbeit beginnt danach: Prüfen, testen, Infrastruktur anpassen, Randfälle aufdecken.

Das geplante Upgrade vs. das Notfall-Upgrade

Ein Upgrade, das geplant und strukturiert durchgeführt wird, hat drei Vorteile gegenüber einem, das unter Druck entsteht:

Erstens bleibt Zeit für Vorbereitung: Abhängigkeiten bereinigen, Tests ergänzen, Hosting-Infrastruktur vorab auf Node 20 upgraden, CI-Pipelines anpassen.

Zweitens lässt sich der Aufwand im Voraus durch Codeanalyse verbindlich beziffern — statt mit einer vagen Schätzung ins Blaue zu gehen.

Drittens sinkt das Regressionsrisiko, weil genug Zeit für Abnahmetests und Korrekturen bleibt — keine Nachtschichten, keine hektischen Rollbacks in der Produktion.

Wer ein produktives Next.js-Projekt betreibt und den Upgrade-Zeitpunkt selbst wählen kann, ist besser gestellt als wer ihn durch ein Sicherheitsereignis aufgezwungen bekommt. Das gilt unabhängig davon, wie groß das Projekt ist.

Wie ein verbindliches Angebot entsteht: der Upgrade-Check

Das Problem mit Next.js Upgrade Kosten ist nicht, dass sie unkalkulierbar wären — es ist, dass sie ohne Blick in den Code nicht kalkulierbar sind. Deshalb ist der sinnvolle erste Schritt keine Schätzung, sondern eine Analyse.

Bei SW Business Solutions läuft das so: Wir analysieren Ihr Repository systematisch gegen alle bekannten Breaking Changes von Next.js 16 — Webpack-Konfiguration, asynchrone API-Migrationen, Middleware-Setup, Cache-Konfiguration, Image-Konfiguration, Parallel Routes, Lint-Setup, Hosting-Infrastruktur und Abhängigkeiten. Auf Basis dieser Analyse erstellen wir ein verbindliches Festpreis-Angebot für die Migration.

Sie bekommen also keine Schätzung ins Blaue, sondern ein Angebot, das auf dem tatsächlichen Zustand Ihres Codes beruht. Das ist der Unterschied zwischen einem planbaren Upgrade und einem, das am Ende doppelt so viel kostet wie gedacht.

Wer außerdem mehrere Projekte migrieren möchte oder das Upgrade mit einer Bereinigung der technischen Schulden verbinden will, kann beides in der Analyse abbilden lassen. Der Webentwicklung-Ansatz, Upgrade und Codequalität gemeinsam zu adressieren, reduziert langfristig den Wartungsaufwand — und das ist ein Argument, das auch im nächsten Budget-Meeting zieht.

Was Sie vor dem Upgrade selbst prüfen können

Auch ohne externe Analyse gibt es Punkte, die Sie intern vorab klären können:

• Node.js-Version des Hostings: Läuft Ihre Umgebung bereits auf Node.js 20.9 oder höher? Wenn nicht, ist das der erste Schritt — unabhängig vom Next.js-Upgrade.
• Eigene Webpack-Konfiguration: Haben Sie in Ihrer next.config-Datei ein webpack-Feld? Wenn ja, müssen Sie verstehen, was es tut und ob es ein Turbopack-Äquivalent gibt.
• runtimeConfig: Nutzen Sie serverRuntimeConfig oder publicRuntimeConfig? Das sind klare Migrationsaufgaben.
• AMP: Haben Sie AMP-Seiten? Die Entscheidung, ob Ersatz gebaut wird oder die Seiten entfallen, muss vor dem Upgrade stehen.
• Testabdeckung: Wie sicher sind Sie nach dem Upgrade, dass nichts kaputt ist? Wenn die Antwort „nicht sehr" ist, ist der Aufwand für einen Upgrade entsprechend höher.

Diese Punkte geben Ihnen ein erstes Gefühl für die Komplexität — ersetzen aber keine systematische Analyse aller betroffenen Stellen im Code.

Abgrenzung: Was dieser Artikel nicht abdeckt

Dieser Artikel beschreibt ausschließlich das einmalige Next.js-Major-Upgrade von Version 15 auf 16 und die Aufwandstreiber, die dabei zählen. Was danach anfällt — regelmäßige Abhängigkeitsupdates, laufende Sicherheitspatches, kontinuierliche Pflege des Projekts — ist ein anderes Thema. Was Software Wartungsvertrag Kosten für laufende Betreuung bedeuten, ist dort ausführlich beschrieben.

Auch die Frage, ob Sie das Upgrade selbst durchführen oder beauftragen sollten, bleibt einem eigenen Artikel vorbehalten, der in dieser Serie noch folgt.

Konkrete nächste Schritte

Wenn Sie ein Next.js-Projekt auf Version 16 upgraden müssen und wissen wollen, was das konkret bedeutet und kostet:

1. Prüfen Sie intern die o. g. Punkte (Node.js-Version, Webpack-Konfiguration, runtimeConfig, AMP, Testabdeckung).
2. Beauftragen Sie eine systematische Codeanalyse — entweder intern durch Ihr Entwicklungsteam oder extern durch einen erfahrenen Partner.
3. Lassen Sie sich auf Basis der Analyse ein verbindliches Angebot erstellen, bevor Sie ein Budget freigeben.

Eine Schätzung ohne Analyse ist keine belastbare Planungsgrundlage. Eine Analyse ohne Angebot ist ein halbfertiger Schritt. Der vollständige Weg ist: Analyse → verbindliches Angebot → geplantes Upgrade.

SW Business Solutions führt diesen Upgrade-Check als strukturierte Codeanalyse durch und erstellt darauf basierend ein Festpreis-Angebot für die Migration Ihres Next.js-Projekts auf Version 16. Wenn Sie wissen wollen, was das Upgrade Ihr Projekt konkret kostet — nicht pauschal, sondern auf Basis Ihres Codes — nehmen Sie Kontakt auf.