Next.js 15 tightens caching semantics and makes partial prerendering more predictable in production. Teams that skipped the App Router migration are now hitting real deadlines — and the upgrade path is smoother than the 13→14 jump, but only if you audit dynamic routes first. The framework assumes you have already mapped which routes are safe to cache aggressively and which ones require per-request personalization.
The stakes are higher than a typical minor release because caching defaults changed how implicit revalidation behaves on routes that never declared a strategy. Product and marketing pages that “felt static” may now participate in semantics you did not opt into explicitly.
We run a three-phase checklist: inventory `fetch` calls and cache directives, validate middleware edge cases, then load-test ISR pages under realistic traffic. Most regressions we see come from assumptions about `revalidate` that no longer hold. Phase one alone usually surfaces dozens of undocumented fetch paths across layouts, loading UI, and server actions.
Partial prerendering changes how streaming boundaries interact with cached shells. Document which routes are static shells versus dynamic holes before you flip the flag in production. Teams that skip this diagram step often roll back because marketing sees stale hero content while engineering insists the cache is “working as designed.”
If you are planning a Q3 upgrade, start with a staging branch that mirrors your CDN headers. The framework is ready; your cache layer might not be. Include authenticated flows in synthetic tests — not only anonymous catalog browsing.
Align observability before rollout completes: cache hit ratio, RSC payload sizes, and TTFB by route belong on the same dashboard your on-call already watches. Close the upgrade with a written retro covering surprises, rollback readiness, and what you would stage differently next time.
