Migrating to the Next.js App Router

Lessons learned from migrating large-scale Indian production applications to the new Next.js App Router architecture.

By Rohan Mehta — Head of Engineering · Aug 12, 2023

Over the past year we've migrated several production applications — including high-traffic e-commerce and SaaS platforms — from the Next.js Pages Router to the App Router. The new architecture is a genuine improvement, but the migration is not free. Here's what we learned, so your team doesn't have to learn it the hard way.

Why Migrate At All

The App Router isn't just a new folder structure. It unlocks React Server Components, streaming, nested layouts, and granular caching — features that translate directly into faster pages and less client-side JavaScript. On one e-commerce migration, we cut the client bundle by 38% simply because product listing logic moved to the server.

If your app is stable and small, staying on the Pages Router is fine for now. But for applications where performance is revenue — commerce, media, marketplaces — the App Router's server-first model pays for itself.

Plan the Migration Incrementally

The single best decision we made: never migrate everything at once. Next.js allows the app and pages directories to coexist, and we exploited that fully.

• Start with static, low-risk routes: marketing pages, blog, docs
• Move shared layout into the new nested layout system early
• Migrate data-heavy routes one at a time, with performance budgets
• Leave complex, auth-gated flows for last

Each phase shipped to production independently. At no point was there a long-lived migration branch — those die in code review.

The Mental Model Shift

The hardest part isn't code — it's thinking. In the App Router, components are server-first by default. Data fetching moves out of getServerSideProps and into the components that need the data. Client interactivity becomes an explicit opt-in with the "use client" directive.

Mistakes We Made So You Don't Have To

• Marking entire page trees as client components, negating server benefits — keep "use client" at the leaves
• Assuming caching behaves like before — the App Router's cache layers need explicit configuration
• Fetching the same data in multiple components without request deduplication awareness
• Underestimating third-party libraries that assume browser-only environments

Treat the App Router migration as an architecture review, not a refactor. The teams that audit their data flow first migrate twice as fast.

Results Worth the Effort

Across our migrations, the pattern held: 25-40% smaller client bundles, noticeably faster Time to First Byte with streaming, and — unexpectedly — better developer velocity after the first month, because nested layouts eliminated a whole class of prop-drilling and layout duplication.

The App Router is the future of Next.js, and the future is already stable. Migrate deliberately, route by route, with metrics at every step — and the payoff is real.