We Upgraded This Site to Next.js 16 in Production: What Broke and What Got Faster

Framework upgrade posts are usually written from a demo repo. This one is from the site you are reading right now: thecodevolt.com runs Next.js 16 with React Compiler enabled and Turbopack in production, and the upgrade produced exactly four surprises worth writing down.

Surprise one, and the one that will bite bilingual sites hardest: middleware.ts is now proxy.ts. Next.js 16 renamed the file convention, and the failure mode is vicious because it is silent. Our locale detection and redirect logic lives in that file via next-intl. After the version bump, the build passed, the site rendered, and /en and /tr URLs worked when typed directly, but the root redirect and locale negotiation were simply gone. No error, no warning: a file the framework no longer looks for just stops being invoked. The fix is a rename plus updating the exported config matcher. If you run i18n middleware, test the bare-domain redirect first thing after upgrading.

Surprise two, a good one: React Compiler. We flipped reactCompiler: true and deleted nothing at first, then progressively removed useMemo and useCallback wrappers from animation-heavy components and measured no regressions. The compiler memoizes at build time, and on a Framer Motion heavy site like this one, that means fewer stale-closure bugs and less boilerplate in every interactive section. It is production-stable in our experience, with one caveat: components doing clever mutation tricks that violate React's rules get skipped silently, so keep your ESLint react-hooks rules on.

Surprise three: Turbopack is fast and it holds grudges. Dev-server startup went from around 6 seconds to under 1, and hot reload is effectively instant. But Turbopack's cache assumes it is the only thing writing to your source tree. When files are edited outside the dev server (a codegen script, a git checkout, an AI coding tool writing files directly), it can keep serving stale chunks with no error overlay. The symptom is maddening: your change is on disk and the browser refuses to show it. The cure is boring: restart the dev server after out-of-band edits, and teach your team that rule before they lose an hour to it.

Surprise four: the ESLint flat-config migration is part of the upgrade whether you planned it or not. Next.js 16's lint integration expects eslint.config.mjs flat config, and half the plugin ecosystem still documents the legacy .eslintrc format. Budget an hour for translating your config, and resist the urge to disable rules to make the migration go faster; the react-hooks rules are exactly what keeps React Compiler effective.

What did not break deserves a sentence: the App Router surface, generateMetadata, route handlers, sitemap and OG image generation, next-intl message loading, and every Framer Motion and GSAP animation ran unchanged. The upgrade is genuinely incremental; the danger is concentrated in the renamed proxy file and the tooling around the code, not the code itself.

The honest checklist for a mid-sized production site: read the release notes for renamed conventions first, upgrade in a branch, rename middleware.ts to proxy.ts, run the type checker, migrate ESLint config, click through every locale redirect and form, then enable React Compiler as a separate commit so you can bisect. Half a day if nothing exotic surfaces. If your site is revenue-critical and you would rather someone else absorb the sharp edges, this is the kind of work we do for clients weekly.