Next.js 15 End of Life: What It Means and How to Upgrade to Next.js 16

The Next.js 15 end of life date is today, October 21, 2026. If your product runs on Next.js 15, it does not break tonight, but it has just left the window in which the Next.js team ships security fixes for it. This guide explains what end of life actually means for a production app, which Next.js 16 changes are most likely to affect you, and the upgrade sequence we follow so the move is a planned piece of work instead of an emergency.

Why Next.js 15 reaches end of life on October 21, 2026

The official Next.js support policy works in two phases. A major version is in Active LTS until the next major ships, getting features, fixes, and security patches. It then moves to Maintenance LTS, where it only gets critical bug fixes and essential security updates.

The policy also says each major stays in Maintenance LTS for two years after its initial release. Next.js 15.x was released on October 21, 2024, so its two years end today. Next.js 16.x, released on October 21, 2025, is the current Active LTS line.

Recent history shows why this matters. The October 2026 security release, which we covered in our Next.js security patch guide, shipped fixes for both 16.4.1 and 15.5.28. That second fix line is the one that now goes away.

What end of life means for your product

End of life is a risk change, not an outage. Here is what changes in practice:

• •Your app keeps running. Nothing is switched off, and your hosting provider will not delete your deployment.
• •New vulnerabilities may stay open. The policy notes that the team will, in rare cases, patch versions outside the policy depending on severity. Treat that as a safety net, not a plan.
• •Dependencies drift away from you. Libraries in the React ecosystem test against current versions first. The longer you stay on 15, the more often a routine package update will pull you toward an upgrade anyway.
• •Compliance questions get harder. If you sell to larger US or UK customers, expect security questionnaires and SOC 2 reviews to ask how you keep software patched. "Our framework is past end of life" is an awkward answer during a sales cycle.

For a founder or CTO, the practical question is not whether to upgrade, but when and how much it will cost. For most products, the honest answer is: soon, and less than you fear.

The Next.js 16 changes most likely to affect you

The official version 16 upgrade guide lists every change. In our experience, these are the ones that show up in real codebases.

Runtime requirements

Next.js 16 needs Node.js 20.9 or newer (Node.js 18 is no longer supported) and TypeScript 5.1 or newer. Check your CI image, your Dockerfile, and your hosting platform's Node setting before anything else. A mismatched Node version is the most common reason an upgrade works locally and fails in the pipeline.

Async request APIs are now mandatory

Next.js 15 introduced async params, searchParams, cookies(), headers(), and draftMode(), but kept a temporary synchronous fallback. Version 16 removes that fallback. If your 15 app still reads params.slug directly, it will break. The same applies to Open Graph image functions and sitemap id values, which now arrive as promises.

Middleware becomes proxy

The middleware file convention is deprecated and renamed to proxy. One important catch: proxy runs on the Node.js runtime only. If your middleware deliberately runs on the edge runtime, the guide says to keep using middleware for now rather than renaming it blindly.

Turbopack is the default bundler

Both next dev and next build now use Turbopack. If your project has a custom webpack configuration, sometimes added quietly by a plugin, next build will fail on purpose. You can migrate the config, or keep webpack for builds with the --webpack flag while you plan the move.

Caching and image defaults

revalidateTag now requires a second argument, a cacheLife profile. On the image side, several defaults changed: images.minimumCacheTTL rises from 60 seconds to 4 hours, and images.qualities now only allows 75 unless you configure more values. Local images with query strings need an images.localPatterns entry.

Removed features

next lint is gone (next build no longer lints), AMP support is removed, and serverRuntimeConfig and publicRuntimeConfig are replaced by plain environment variables. Parallel route slots now need an explicit default.js, or the build fails.

A step-by-step upgrade plan

This is the sequence we use on client projects. It keeps each change small enough to review.

1. 1.Get to the latest 15.x first. Move to the newest 15.5 release and make sure the build, tests, and type check pass. Upgrading from a clean, current baseline makes every later error easier to read.
2. 2.Update the runtime. Bump Node.js to 20.9 or newer everywhere: local machines, CI, Docker images, and hosting settings.
3. 3.Run the official codemods on a branch. npx @next/codemod@canary upgrade latest handles the Turbopack config move, the next lint migration, and the middleware rename. It does not run every migration, so also run npx @next/codemod@canary next-async-request-api . if any synchronous request access remains.
4. 4.Fix what the codemods leave behind. Search for codemod comments and UnsafeUnwrapped casts, then fix them properly. This is where most of the real work sits.
5. 5.Review images and caching. Check every quality prop and every revalidateTag call, and decide whether the new image cache default suits content that changes often.
6. 6.Replace lint and runtime config. Point your CI at the ESLint CLI or Biome directly, and move runtime config values to environment variables.
7. 7.Test on a preview deployment. Walk through sign up, log in, checkout, uploads, and anything behind middleware or Server Actions. A green build is not the finish line; the official checklist says the same.

Here is the change that touches the most files in a typical App Router app:

import { revalidateTag } from "next/cache";

// Next.js 15 (sync fallback, removed in 16)
// export default function Page({ params }: { params: { slug: string } }) {
//   return <h1>{params.slug}</h1>;
// }

// Next.js 16: params is a Promise; PageProps comes from `npx next typegen`
export default async function Page(props: PageProps<"/blog/[slug]">) {
  const { slug } = await props.params;
  return <h1>{slug}</h1>;
}

export async function publishPost(id: string) {
  "use server";
  // Before: revalidateTag(`post-${id}`)
  revalidateTag(`post-${id}`, "max");
}

One rule we hold firmly: do not adopt new features during the upgrade. Cache Components and the React Compiler are worth evaluating, but they are opt-in, and the official guide warns against enabling them just to complete the migration. Ship the upgrade, let it settle in production, then try new features one at a time.

How long it takes and what it costs

Effort depends far more on your codebase than on Next.js itself. Use these signals to size it:

• •Small and quick: App Router, no custom webpack config, Node-runtime middleware or none, standard next/image usage, decent test coverage. Expect a few days of engineering plus testing.
• •Medium: a mix of Pages and App Router, several parallel routes, custom image qualities, or lint wired into the build. Expect one to two weeks.
• •Larger: custom webpack loaders, edge middleware doing real work, AMP pages, heavy use of runtime config, or a monorepo with several Next.js apps. Here the upgrade needs design decisions, and each app should be upgraded separately.

The hidden cost is usually testing, not code. If you have no automated tests around checkout or sign up, add a few before the upgrade. They pay for themselves on this change and every one after it.

What we check first on real projects

Our own site runs on Next.js 16.4.1, so the Next.js 16 rules above are the ones we work with every day. The checks that matter most depend on what the product does.

On an image-heavy site like Bureau of Innovation, a gallery for designer furniture served through an AWS S3 image pipeline on Next.js, the new next/image defaults are the first thing we would review, because the photography is the product. On a product like Capitalista, where we split a static marketing site from an authenticated, server-rendered investor dashboard, the priority is the middleware and request API changes that sit around authentication.

If you want an outside team to run the upgrade, our web app development service can take it on as a fixed-price change request or as part of a monthly retainer for ongoing work after launch. For the wider picture of the stack we choose and why, see our guide to the best tech stack for SaaS.

Conclusion

Next.js 15 reaching end of life is not a crisis, but it is a deadline that has now passed. Your app still runs, yet every month on an unsupported version adds a little more security and maintenance risk. The move to Next.js 16 is well documented, largely automated, and for most apps a matter of days of focused work plus careful testing.

Do it on a branch, keep the scope to the upgrade itself, and test the flows your revenue depends on. If you would rather hand it to engineers who do this routinely, tell us about your app and we will scope the upgrade with you.