Next.js 15: What Production Teams Need to Know

We just migrated 12 production applications to Next.js 15, and the experience taught us everything you need to know about what works, what breaks, and whether Turbopack is actually ready for prime time. The headline features promise significant improvements, but the migration path has some sharp edges that aren't obvious from the documentation alone.

The Big Changes You Need to Know

Next.js 15 ships with three major changes that will affect every production deployment. First, params and searchParams are now async Promises instead of synchronous objects, which means every dynamic route needs refactoring. Second, Turbopack is now stable for local development (though not production builds yet), promising dramatically faster compile times. Third, the default caching behavior has been inverted—everything that was cached by default now requires explicit opt-in, which can catch you off guard if you relied on automatic caching for performance.

The async request APIs change is the most impactful breaking change. In Next.js 14, you could destructure params directly from props. Now in Next.js 15, you must await them first since they're Promises. This affects every page component, every generateMetadata function, and any server component that reads route parameters. On our smallest app with 22 pages, the migration took 40 minutes. On our largest app with 187 pages, it took 6 hours of careful refactoring and testing.

Code Migration Example

Here's what the migration looks like in practice. Your old Next.js 14 code that synchronously accessed params needs to be converted to async functions that await the parameters:

// Before (Next.js 14)
export default function ProductPage({ params, searchParams }) {
  const { id } = params;
  const sort = searchParams.sort;
  return <Product id={id} sort={sort} />;
}

// After (Next.js 15)
export default async function ProductPage({ params, searchParams }) {
  const { id } = await params;
  const { sort } = await searchParams;
  return <Product id={id} sort={sort} />;
}

The reason for this change is Next.js's preparation for Partial Prerendering (PPR). Making these async allows static shells with dynamic data holes, theoretically improving your Largest Contentful Paint because the shell ships instantly while data streams in. In practice, it's a breaking change across every dynamic route in your application. Next.js provides a codemod to automate about 80% of this migration, but you'll still need to manually fix edge cases where the automated transformation doesn't quite understand your code's intent.

Turbopack Performance Reality Check

Next.js 15 marks Turbopack as stable for development, though production builds still use Webpack. We enabled Turbopack on 8 production apps and measured the results carefully. On our small app with 22 pages, dev server startup dropped from 3.2 seconds to 1.1 seconds—a 66% improvement. Our medium app with 87 pages saw startup time fall from 12.4 seconds to 3.8 seconds (69% faster). Most impressively, our large app with 187 pages went from 28.1 seconds to 7.2 seconds, a 74% speed improvement that makes a massive difference in developer experience.

Hot Module Replacement is also noticeably faster with Turbopack. Changes reflect in 200-400ms compared to 1-2 seconds with Webpack, making the development loop feel nearly instant. However, there are gotchas: custom Webpack configurations don't transfer to Turbopack, some loaders like SVGR had compatibility issues on one of our apps, and production builds still use Webpack so you won't see deploy-time speedups yet. Despite these limitations, the development experience improvement is significant enough that we're keeping Turbopack enabled on all our projects.

Caching Behavior Changes

Next.js 15 inverts the default caching strategy in ways that can significantly impact performance if you're not prepared. Previously, fetch requests were cached by default, route handlers were cached, and the client-side router cache lasted 30 seconds. Now, fetch requests are not cached by default unless you explicitly opt in with cache: 'force-cache', GET route handlers are not cached automatically, and the client-side router cache has been reduced from 30 seconds to 0 seconds for pages. If you relied on automatic caching, your app just got slower and your API call volume might increase 4x overnight like we saw on one production app.

The fix requires auditing every fetch call and adding explicit caching where needed. Use cache: 'force-cache' for data that rarely changes, next: { revalidate: 60 } for data that should refresh every minute, or cache: 'no-store' for data that must always be fresh. We spent 3 days across our 12 apps reviewing and adding appropriate caching strategies, but the explicit approach actually resulted in better performance long-term because we were forced to think about each endpoint's caching requirements rather than relying on potentially inappropriate defaults.

Should You Upgrade?

If you're starting a new project, absolutely use Next.js 15—the improved developer experience with Turbopack alone justifies it. For existing production apps, the decision depends on your team's bandwidth for migration work. Plan for one hour per 10 pages to migrate the async params changes, plus additional time to audit and update caching strategies. The performance benefits are real, but they require upfront investment to realize. Our recommendation: upgrade during a slower period when you have time to properly test, not right before a major feature launch.