Next.js Upgrading to version 14
Of the three version-specific upgrade guides in this series, 13→14 is genuinely the smallest — a handful of removals and renames rather than the sweeping architectural shifts you'll find in the 15 and 16 guides. That said, small doesn't mean skippable: one of these changes (the Node.js version bump) is a hard floor you simply cannot work around, and getting the codemods right here saves real manual find-and-replace work.
The upgrade command
npm i next@next-14 react@18 react-dom@18 && npm i eslint-config-next@next-14 -D
Notice this pins react@18 and react-dom@18 explicitly, rather than reaching for @latest — Next.js 14 is built against React 18, not 19 (that jump comes in the version-15 guide, covered as its own article in this series). If you're on TypeScript, don't forget the type packages travel alongside the runtime ones: upgrade @types/react and @types/react-dom to their matching latest versions too, or you'll end up with a version mismatch between your actual React runtime and the types your editor is checking against.
What actually changed
Node.js 16 is no longer supported — full stop
The minimum Node.js version moves from 16.14 to 18.17. This isn't a soft recommendation you can defer — Node 16 reached its own end-of-life, and Next.js 14 simply won't run on it. If you're on an older Node version, upgrading your actual runtime environment (not just your package.json dependencies) is a hard prerequisite here, not an optional nice-to-have alongside the framework bump.
next export is gone — use the config option instead
The standalone next export command has been removed entirely, in favor of the output: 'export' configuration option covered in this series' dedicated static-exports article. If you're upgrading a project that still calls next export directly in a build script, that script will simply fail on 14 — the fix is switching to the config-based approach, not finding some flag to restore the old command.
ImageResponse moves from next/server to next/og
// Before
import { ImageResponse } from "next/server";
// After
import { ImageResponse } from "next/og";
This is precisely mechanical enough that a codemod exists specifically for it:
npx @next/codemod@latest next-og-import .
Worth running rather than hand-editing every import site individually, especially on a codebase with more than a couple of dynamic OG image routes.
@next/font is gone — next/font was always the destination
The standalone @next/font package — which existed as a separate install before font optimization got folded into the framework itself — is now fully removed, in favor of the built-in next/font that's been the recommended path for a while already. Another dedicated codemod handles this cleanly:
npx @next/codemod@latest built-in-next-font .
This one does double duty, worth knowing precisely: it doesn't just rewrite your imports, it also uninstalls the now-unnecessary @next/font package from your dependencies — one command handling both the code change and the dependency cleanup together, rather than leaving a dead package sitting in your package.json after the imports have already moved on.
The WASM target for next-swc is removed
A lower-level internals change most projects won't need to think about directly — next-swc's WebAssembly compilation target has been removed. This is really only relevant if you were on a platform specifically relying on the WASM build of the Rust-based compiler (some restrictive or unusual deployment environments where native binaries weren't an option) — for the overwhelming majority of projects running on ordinary Node.js infrastructure, this has no practical effect at all.
Key Takeaways
| Change | What to do |
|---|---|
| Node.js 16 → 18.17 minimum | Upgrade your actual runtime, not just package.json — this is a hard requirement |
next export removed | Migrate to output: 'export' in next.config.js |
ImageResponse moved | npx @next/codemod@latest next-og-import . |
@next/font removed | npx @next/codemod@latest built-in-next-font . (also uninstalls the old package) |
next-swc WASM target removed | Only relevant if you specifically relied on the WASM build |
This upgrade is genuinely low-risk as these things go — two codemods handle the mechanical import renames entirely, and the one change that actually requires manual intervention (the Node.js version floor) is unambiguous rather than a judgment call. Run both codemods, confirm your deployment environment is on Node 18.17+, and this upgrade is close to done.
