Should I upgrade to Next.js 16?
Decide when to upgrade to Next.js 16, given Turbopack becoming the default, async request API breaking changes, and official migration guidance.
Blockers
- Requires runtime/nodejs-20 20.9.0+ (ESM and async API support)
- Requires package/typescript-5 5.1.0+ (type-level features for App Router)
- Requires package/react-19 19.0+ (RSC and async Server Components)
- cookies/headers/params/searchParams/draftMode must be awaited — sync access removed
- next build fails with custom webpack config — must use --webpack flag or remove config
- next lint command removed
- middleware.ts deprecated — renamed to proxy.ts (Edge runtime not supported in proxy)
- framework/nextjs-16 incompatible with engine/webpack: next build fails with webpack config present — Turbopack is default
Who this is for
- small-team
- enterprise
- monorepo
- low-ops
Candidates
Upgrade directly to Next.js 16 now
As of 2026-03-15, Next.js 16 is the Active LTS release in the official support policy. The official v16 upgrade guide says Turbopack is stable and used by default for `next dev` and `next build`, and synchronous access to request-bound APIs such as `cookies`, `headers`, `draftMode`, `params`, and `searchParams` is fully removed.
When to choose
Best for small-team + low-ops teams, or enterprise + monorepo teams already on 15.x, that want the current supported major with the fewest intermediate steps. Choose this when you have little or no custom webpack behavior, can update App Router code to `await` dynamic APIs, and want to align quickly with the official default toolchain as of 2026-03-15.
Tradeoffs
This follows the official forward path and lets you use the built-in v16 codemod flow. The migration still touches package scripts, async request access, `next.config` Turbopack settings, `next lint` removal, and possibly `middleware` to `proxy` renames.
Cautions
The v16 guide says `next build` will fail if a custom `webpack` config is present, to prevent misconfiguration; you must either migrate that setup, build with `--webpack`, or explicitly choose Turbopack and ignore the webpack config. The same guide also raises platform floors to Node.js 20.9.0+, TypeScript 5.1.0+, and modern browsers. For `proxy`, the official v16 guide says Edge runtime is not supported there; if you need Edge runtime, keep using `middleware` for now.
Stage on Next.js 15.5 first, then cut over to 16
The official Next.js 15.5 release added `next typegen`, stable typed routes with Turbopack compatibility, and a deprecation warning for `next lint` ahead of its removal in 16. The 15 and 16 upgrade docs together make this a practical prep step for teams that want to separate async API cleanup from the major-version switch.
When to choose
Best for enterprise + monorepo teams, or small-team + monorepo teams with a larger codebase, where you want one release to generate route types and clear async Dynamic API warnings, then a later release to adopt v16 defaults. Choose this when staged validation is more important than getting to v16 in one jump.
Tradeoffs
This reduces migration risk by splitting the work into preparation and cutover phases. The cost is extra release overhead, temporary dual-version migration planning, and more time before you reach the Active LTS line.
Cautions
This is a staging path, not a destination: the support policy lists 15.x as Maintenance LTS as of 2026-03-15. Use the official `next-async-request-api` codemod, then manually resolve any `@next-codemod-error` comments that remain, because the docs say the codemod cannot cover all cases.
Defer Next.js 16 temporarily and stay on 15.x while removing Turbopack blockers
The official support policy lists 15.x as Maintenance LTS and 16.x as Active LTS as of 2026-03-15. This is a containment option for apps still blocked by Turbopack gaps or webpack-specific behavior that the official Turbopack docs call out, such as unsupported webpack plugins, unsupported `sassOptions.functions`, or Yarn PnP not being planned.
When to choose
Best for enterprise + monorepo teams that depend on custom webpack behavior, unsupported Turbopack features, or edge-case build integrations and cannot absorb build-risk right now. Choose this only when the blocker is concrete and verified, and when a bounded migration backlog exists to remove it.
Tradeoffs
This minimizes immediate disruption and lets you keep a known build path while you inventory blockers. The downside is remaining on Maintenance LTS, delaying the official default bundler path, and accumulating migration debt that still has to be paid later.
Cautions
The support policy says Maintenance LTS receives only critical bug fixes and essential security updates. If you move partly to 16 before all blockers are gone, the v16 guide documents `next build --webpack` as the temporary opt-out. Also, the v16 upgrade guide says teams already using experimental PPR on Next.js 15 canaries should stay on their current 15 canary until Next.js publishes a migration guide to Cache Components.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to Next.js 16?"