Upgrading to Next.js 16: A Checklist for Owners and Engineers

Upgrading a framework is rarely the interesting part of running a web application, which is exactly why it gets postponed until something forces the issue. In 2026 the forcing function has a name: security releases. If your Next.js application is not on a line that receives fixes, you cannot take them. This checklist is written for two readers at once, the person who owns the application and the engineer who will do the work, and it follows the official upgrade guide for version 16.

Why this is a business question as well as a technical one

The July 2026 security release addressed four high-severity and five moderate issues, including denial of service through Server Actions, a middleware and proxy bypass in particular Turbopack configurations, and two server-side request forgery issues. The September release fixed seven more, including a server-side request forgery in image optimisation for applications using images.remotePatterns and several caching problems. On 8 October 2026 Vercel announced that it plans to publish another out-of-band security update on 14 October 2026, addressing two critical and one high severity vulnerabilities in upstream dependencies.

None of that means your application is vulnerable today. Whether it is depends on which version you run, how you host it and which features you use. What it does mean is that a Next.js application is a living dependency. Somebody has to read the advisories, decide whether they apply and apply the update, which is the territory covered by our web application maintenance checklist. An upgrade you do calmly in October is cheaper than one you do in a hurry after a disclosure.

What changes in version 16

The official guide groups the changes. The ones most likely to touch a typical business application are below.

Version 16 changes most likely to affect an existing application

Change	What to check	Who usually owns it
Node.js and TypeScript minimums	Node.js 20.9 or later and TypeScript 5.1 or later. Node.js 18 is no longer supported.	Engineer and hosting
Turbopack by default	next dev and next build use Turbopack. A custom webpack configuration makes next build fail unless you opt out or migrate it.	Engineer
Asynchronous request APIs	Synchronous access to cookies, headers, draftMode, params and searchParams is removed. A separate codemod handles it.	Engineer
middleware renamed proxy	The middleware file and export are deprecated in favour of proxy, which runs on the Node.js runtime, not the Edge runtime.	Engineer
Image defaults	Default minimumCacheTTL rises from 60 seconds to 4 hours, the 16 pixel size leaves the default list, and local IP optimisation is blocked unless you allow it.	Engineer and content owner
Parallel routes	Every parallel route slot now needs an explicit default file or the build fails.	Engineer
Removals	AMP support, the next lint command and runtime configuration (serverRuntimeConfig, publicRuntimeConfig) are gone. Use environment variables and the ESLint CLI instead.	Engineer

Before you start: the inventory

Spend an hour on this before any code changes. It decides how hard the job is.

1. Which version are you on? Look at the lockfile, not the package.json range.
2. Which Node.js version does production run? Version 16 needs 20.9 or later.
3. Do you have a custom webpack configuration? This is the most common reason a build fails after the upgrade, and plugins can add one without you writing it.
4. Do you still use the old middleware file, AMP, runtime configuration or next lint?
5. What does your image configuration look like? In particular remote patterns, local images with query strings and cache settings.
6. What tests exist? If the answer is none, the first deliverable is a small set of tests for your critical journeys. See our software testing and QA automation service for what that involves.
7. Where does it run, and who owns the deployment? Hosting choices change how patches and caching behave, which we cover in where to host a Next.js app.

The upgrade, step by step

1. 01BranchWork off a clean branch with a green build.
2. 02CodemodRun the official upgrade codemod.
3. 03FixResolve breaking changes and rerun checks.
4. 04PreviewTest key journeys on a preview deployment.
5. 05ReleaseShip with monitoring and a rollback.

1. Run the codemod

The guide recommends the upgrade codemod. This is the command as documented, not something specific to your project:

npx @next/codemod@canary upgrade latest

According to the guide, it updates configuration for Turbopack, migrates next lint to the ESLint CLI, renames the deprecated middleware convention to proxy, and removes the unstable_ prefix from stabilised APIs. It does not run every migration. If your code still reads params, searchParams, cookies() or headers() synchronously, run the separate asynchronous request APIs codemod as well:

npx @next/codemod@canary next-async-request-api .

2. Review the diff like any other change

Codemods are fast but they are not infallible. Read the diff. A reviewer who understands the application should look especially at authentication checks that used to live in middleware, because the July security release is a reminder that those checks sit on an important boundary.

3. Fix what the build tells you

Run the build and work through the failures. The commonest are the custom webpack configuration, missing default files in parallel routes and type errors from the asynchronous params change. The guide's next typegen command can generate helper types for pages, layouts and route handlers, which makes the asynchronous migration type-safe.

4. Test on a preview deployment

Automated checks are necessary, not sufficient. Click through the journeys that earn money: sign up, log in, pay, submit an enquiry. Check images, redirects and headers. Compare page speed against your budget; our piece on Next.js performance budgets explains how to set one. If you have no baseline, take one now, before you ship, so you can tell whether anything changed.

5. Release with a way back

Deploy at a quiet time, watch error rates and key conversions, and keep the previous version one click away. For the first week, treat every unusual support ticket as a possible upgrade side effect until proven otherwise.

Where Cache Components fit

Next.js 16.4, released on 6 October 2026, makes Cache Components the default for new projects created with create-next-app. Vercel says the model will become the default in Next.js 17 and recommends it for every app from 16.4. For existing applications it describes migration as something to plan, with a next upgrade --agent command and dedicated skills to assist.

Our advice is to keep this separate from the version 16 upgrade. Cache Components changes how an application decides what to cache and when, so it deserves its own plan, its own testing and its own release. Do the upgrade, let it settle, then decide whether the new caching model earns its place in your application. We are not aware of a published date for Next.js 17, so we have not assumed one.

Costs and trade-offs

We are not going to invent a price or a duration here, because they depend on things only an inspection of your project can reveal. What we can say is where effort usually goes: configuration clean-up, the middleware to proxy move, image behaviour, and building enough test coverage to trust the result. If you are two major versions behind, plan to do it in stages rather than in one jump, and budget for the testing as a first-class task.

Security notes

• Take security releases on a defined cadence rather than when you happen to notice them. The advisories also list workarounds for people who cannot upgrade at once, such as not building rewrite hostnames from user input, but a workaround is a stopgap.
• Pin or validate the Host and X-Forwarded-Host headers at your proxy if you run a custom server. The July advisory for Server Actions on custom servers says managed hosting pins the host upstream, and that next start and standalone output do so from version 14.2 onward.
• After a security upgrade, check whether any cached content should be purged. The September release included cache poisoning issues, and the published CVE record says a poisoned entry persists until it is revalidated or replaced.
• Do not forget transitive dependencies such as the image library. Security notes can name them separately from Next.js itself.

How SystemNexa can help

If you would rather not carry this yourself, our Next.js development and managed web application services cover upgrades, patching and monitoring as part of looking after an application, and website performance optimisation covers checking that the numbers stay healthy afterwards. We would start with the inventory above and tell you honestly how big the job is.

Conclusion

A Next.js 16 upgrade is mostly a sequence of small, documented changes that become painful only when they are bunched together. Take the inventory, branch, run the codemod, fix, test on preview, release with a rollback, and then keep to a patching routine so the next upgrade is small. If you want a second pair of eyes on an application that is behind, get in touch about managed web application services.