Next.js 15 Support Ends October 21: Your Upgrade Options

Next.js 15 leaves Maintenance LTS on October 21, 2026. That is not an announcement; it is arithmetic on Vercel's published Next.js support policy, which says each major version stays in Maintenance LTS for two years following its initial release, and which lists 15.x as released on October 21, 2024. When we read the page on October 21, 2026 it still showed 15.x in Maintenance LTS and 16.x in Active LTS, released October 21, 2025. From the 22nd, under the policy as written, only 16.x carries a support commitment.

For a team running production on 15, the practical change is narrow and important. During Maintenance LTS, Vercel commits to ship critical bug fixes and essential security updates. After it, that commitment lapses. The policy keeps a clause for rare circumstances, where a severe enough bug may be patched outside the LTS lines, but that is a discretion, not a promise, and no team should plan a security posture around it.

This post stays within the policy page. It does not predict what Vercel will announce next, and it does not restate the migration guide; our Next.js 15 to 16 migration playbook already covers the mechanics. What follows is the decision: upgrade now, accept the gap, or buy time, and how to scope each.

Next.js has two support phases and a pre-release channel. Daily builds go to the canary channel, which Vercel says is tested internally before promotion but not recommended for production traffic. When a major is released it enters long-term support. Active LTS lasts until the next major and includes new features, regular bug fixes, performance improvements and security patches. When a new major ships, the previous one becomes Maintenance LTS.

Maintenance LTS is the phase that matters here, and the page defines it tightly. Vercel commits to shipping only critical bug fixes and essential security updates, and explains that the narrow scope reduces the risk of regressions while keeping applications secure. Updates in this phase land as semver-minor releases even when they are breaking. Each major stays in Maintenance LTS for two years following its initial release. And then the one sentence of discretion: in rare circumstances, depending on the severity of the underlying bug, Vercel will patch versions outside the LTS policy.

One example of how the two-year rule has already worked: Next.js 14 was released on October 26, 2023 and the policy page lists it as unsupported now, which is consistent with a window that closed in late October 2025. The failure case is reading the table's label rather than the rule. On October 21 the page still said Maintenance LTS beside 15.x, which is true that day and false the next.

Teams sometimes wait for an end-of-life notice before acting. Next.js does not issue one; the policy is the notice. The two-year clock runs from the initial release of the major, not from the day it moved into Maintenance LTS, and the page gives both dates needed: 15.x released October 21, 2024, and the two-year rule. The window therefore closes two years later to the day. It does not reset when Next.js 16 shipped on the anniversary, and it does not extend because a point release such as 15.5 appeared later in the line.

The table below sets out the dates as the policy gives them and the status each line has on either side of the deadline. The right-hand column is the policy applied, not a statement from Vercel, and we will update the row if the page changes.

Nothing stops working on October 22. A Next.js 15 application builds, deploys and serves exactly as it did. What changes is the flow of fixes. Vercel moved Next.js security patches to a pre-announced, roughly monthly schedule in July 2026, which we covered in our monthly patch cadence playbook. The first release under that programme targeted both 16.2 and 15.5, because 15 was in Maintenance LTS and entitled to essential security updates. The next one that ships after October 21 has no such obligation to 15.

The example to picture is a specific one. A monthly release lands in November with a high-severity fix in the server-side request handling that both 15 and 16 share. The 16.x patch ships. Whether a 15.x patch ships depends on Vercel judging the bug severe enough to invoke the rare-circumstances clause. A team on 15 learns the answer when the advisory is published, and if the answer is no, the only fix is the upgrade it had deferred, now done under pressure. The failure case is budgeting for that scenario as if it were unlikely; with a monthly cadence and public CVEs, it is the expected case.

Exposure is not uniform across 15.x apps. A fully static site with no server routes, no middleware and no server actions has a small attack surface regardless of version; its remaining risk is the build toolchain and whatever runs at request time on the host. An application that serves authenticated pages, runs middleware on every request, accepts uploads or proxies to internal services is the kind that security advisories tend to name. The July 2026 security releases, covered in our Next.js and Node.js patch week post, were a mix of default-on and configuration-specific issues, which is typical.

An agency example: an estate of thirty client sites built from one 15.x starter has one upgrade to design and thirty to apply, and the design is the expensive part. The failure case is the reverse order, upgrading the loudest client first by hand and discovering the template problems thirty times. Our web development practice runs this as a template-first pass.

Most of a major-version upgrade is a dependency bump and a build. The 15 to 16 move has four changes that take thought, and they are the ones to size before anything else. The full treatment, with codemods, a phased rollout and a tested rollback, is in the playbook; this is the summary a planning meeting needs.

First, Cache Components. Next.js 16 pairs partial prerendering with the use cache directive and the cacheLife and cacheTag APIs, so caching becomes an explicit per-component decision rather than a route-level default. Second, the proxy rename: the middleware file becomes proxy.ts, a literal rename that trips teams only when they overthink it. Third, unstable_cache, which Next.js 16 replaces with use cache; it keeps working, there is no official codemod for it, and each call site needs a human, because use cache does not persist values across deployments the way unstable_cache does. Fourth, the Edge Runtime, which is deprecated in favour of the default Node.js runtime; any route declaring the edge runtime needs that export removed and its code checked for Node compatibility.

The example that surprises teams is the cache one. An app that relied on implicit route-level caching in 15 and adopts use cache broadly in 16 can serve stale data where it never did before. The failure case is treating Cache Components as a performance feature to switch on everywhere rather than a correctness decision to make per component. Our Next.js 16.3 upgrade decision guide also flags that the experimental useCache flag is itself marked deprecated in 16.3, so target the stable directive, not the flag.

Three routes exist and only one is free of ongoing cost. The routing below matches each to the situation that justifies it. The estimates are rough planning ranges, not measured figures, and they assume a team that already knows its codebase.

Some teams will read this on October 22 with a release freeze, a missing test suite, or a dependency that has no 16-compatible version. The honest position is that 15.x is now outside the policy and the task is to shorten the gap, not to argue it away. Four things reduce exposure while the upgrade is scheduled. Pin to the last 15.x release so that nothing older is in production. Put the application behind a web application firewall with managed rules, which can catch some of the generic request-shape attacks that framework CVEs are exploited through. Reduce the server surface: disable route handlers and middleware that are not in use, and check that debug or preview endpoints are off in production. And subscribe to the monthly security pre-announcements, so that the first 16-only advisory is read the day it is published and assessed against your code.

An example of the right way to record this: a one-line entry in the risk register that says 15.x left Maintenance LTS on October 21, 2026, lists the compensating controls, and names the sprint in which 16 ships. The failure case is the register entry that cites the rare-circumstances clause as the mitigation. It is not one, and an auditor who reads the policy page will say so.