Upgrading from Next.js 15 to 16: what's blocking you?

[icyJoseph]

To help us prioritize fixes, docs, and codemods, we'd like to understand what's keeping your app on Next.js 15.

If you're still on 15, please share:

• Version: your current 15.x version, and whether you use the App Router, Pages Router, or both
• Blocker: what's stopping the upgrade. For example a breaking change, a dependency that doesn't support 16 yet, Turbopack, caching changes, or limited team time
• Attempts: whether you've tried upgrading, and where it broke

If someone has already described your blocker, add a 👍 to their comment instead of repeating it.

• Haven't started yet? Follow the Next.js 16 upgrade guide.
• Found a bug in 16? Please open an issue with a reproduction.

Keep in mind that Next.js 15 was originally scheduled to reach end of life on Oct. 21, 2026. Its Maintenance LTS has been extended to give teams more time to upgrade. We'll continue publishing security releases for Next.js 15 through Jan. 31, 2027. See the support policy for details.

[oafleming]

We are still on 15... Nothing is stopping me and my team other than the fact that we were waiting to upgrade to Next.js 17 as we did not want to jump from 16 then turn around and have to jump to 17 a week later but no announcement has been made for 17 that I can find as the new releases has been dropping every October so we are still waiting it must be coming soon November 1st is this Sunday.

[icyJoseph]

Hi, that's very reasonable, we used to release a major on the Next Conf cadence and such but that's never been a formal contract so to speak.

I'd say, you should upgrade to version 16.4.x because it contains new features, improvements and bug fixes, like faster dev server, with less memory overhead, better prefetching — improved from early 16.0 — and more. There's also bugs initially reported in version 15, that have been fixed in 16, without a clear way to backport, and given it is Maintenance LTS, whether or not it ends up with a backport depends on each fix.

During version 16 you can also gradually adopt cache components w/ partial prefetching, and give feedback.

[oafleming]

Okay that sounds good to me... we will start working on 16 asap.. Question?? One of our staff is a content creator and wanted to produce a Next.js 17 tutorial so when it drops (releases) then the video will be available for the public the same day how can he get an early version (canary) or beta so he can get this done instead of waiting for the official version to release then rushing to get Next.js 17 tutorial uploaded?? (Thanks ahead of time for your response)✌️

[icyJoseph]

We strive to be very open and forward about our releases, specially major versions, since those have new features and breaking changes (node version, browser support, removal of deprecated APIs, and others).

Check the feed at https://nextjs.org/feed.xml, blog posts, and follow socials like X.

So far, we have done RC, Beta and Preview releases. Often this is done because we still need to complete or refine documentation, codemods, error pages and messages, and fix bugs found in canaries, but who knows, when 17 eventually comes around, we might be ready to just launch.

Also we did create https://preview.nextjs.org/docs to publish canary docs ahead of 16.2 and 16.3, and are still maintaining it.

[davidpc-pg]

Nextauth v4.x is incompatible with Next.js 16 and v5 is still beta...

[icyJoseph]

Thanks for this, any reason in particular? I found this bug report nextauthjs/next-auth#13388

Any other issues with that library?

[icyJoseph]

Looks like version compatibility with next@16 and v4 was fixed here https://github.com/nextauthjs/next-auth/pull/13303/changes

[davidpc-pg]

Thanks for pointing that out. Didn't realize v4 was going to be made compatible with 16.

[k-prashant]

We are a media-based company, and AMP pages and AMP Stories play a significant role in our publishing strategy, as they contribute considerably to our organic traffic.

With Next.js having dropped AMP support, upgrading to the latest versions, particularly v16.x, has become challenging for us. Maintaining AMP compatibility is an important requirement for our business, and the lack of native support creates a significant migration concern.

Our internal engineering team is currently evaluating the available options. At this stage, there is a growing inclination to consider moving away from Next.js to an alternative framework that continues to support AMP.

We would appreciate it if the Next.js team provide guidance on a recommended approach for media publishers who still rely heavily on AMP pages and AMP Stories.

This would help organisations like ours continue benefiting from the Next.js ecosystem without compromising our existing publishing and organic traffic strategy.

[icyJoseph]

Thanks for sharing this. This is exactly the kind of feedback this thread was created for.

Next.js 16 removed AMP support because adoption had declined significantly and maintaining it added complexity to the framework, as described in the upgrade guide.

Google's treatment of AMP has changed a lot as well. AMP stopped being a requirement for Top Stories in 2021, and since July 1, 2026, Google Search no longer serves AMP pages from the AMP Cache or viewer. A click on an AMP result now goes to the AMP URL on your own domain, and Google says AMP content ranks like any other page.

It helps to separate the format AMP, and what Next.js supported. An AMP page is an HTML document with its own rules, like the AMP runtime, a single inline stylesheet, and AMP elements like amp-img in place of regular ones. Before Next.js 16, the framework built the AMP document around your page: the boilerplate, the scripts for any AMP components you used, validation, and the link from the HTML version. The AMP markup itself was always written in the app. That split comes with AMP, whichever framework renders it.

Web Stories are the clearest case where AMP still has its own distribution. They're a distinct kind of content: a Web Story exists only as an AMP document, with no HTML version alongside it to fall back to, and it's often made with dedicated tooling. Stories are still hosted by your app, so you can serve them as static files from the public folder or generate them on request.

In Next.js 16, I'd use a Route Handler that returns the AMP document as HTML , for example at an /amp/... path.

The Backend for Frontend guide shows the pattern with an RSS feed built from a template string, and an AMP page works the same way with a text/html content type. To serve the AMP version behind something like ?amp=1, the same guide shows how to route requests to a Route Handler with rewrites.

Your data fetching can be shared with your regular pages, while the AMP markup is its own rendering concern, much like ImageResponse renders Open Graph images separately from your pages, or any other of the specialized route hanlders. I haven't tested this end-to-end with AMP, so treat it as an approach to explore, not a validated recipe.

Happy to keep on hacking/answering here to help develop a way forward. If you build an AMP renderer route handler along these lines, please share it here.