The App Router has been the recommended default for a while now, and most new projects should start there. But "most" isn't "all," and I still see teams either forcing App Router onto a product it doesn't fit, or sticking with Pages Router out of inertia when App Router would genuinely serve them better. Here's how to actually make the call.
What actually changed between the two
Pages Router is the original Next.js routing model: file-based routes, getServerSideProps and getStaticProps for data fetching, everything rendered as a Client Component by default unless you opt into static generation.
App Router introduces React Server Components as the default, nested layouts, streaming, and a fundamentally different data-fetching model where you fetch data directly inside Server Components instead of through special page-level functions. It's a genuinely different mental model, not just a folder structure change.
Why App Router is the right default for most new projects
Server Components reduce client-side JavaScript. For content-heavy or SEO-sensitive pages, shipping less JavaScript to the browser is a real, measurable performance win, not a marketing claim.
Nested layouts solve a real pain point. Pages Router's shared layout patterns always felt slightly hacky. App Router's nested layout system handles this cleanly, particularly useful for SaaS products with persistent navigation shells around changing content.
Streaming and partial rendering. App Router can start sending parts of a page to the browser before every piece of data has loaded, which matters for dashboards pulling from multiple slow data sources.
It's where Next.js's actual investment is going. New features, documentation focus, and community tooling are overwhelmingly oriented around App Router now. Building on Pages Router increasingly means building against the grain of where the ecosystem is headed.
Where Pages Router still makes sense
You have a large, stable Pages Router codebase already. Migration isn't free. If the App Router's benefits, streaming, Server Components, nested layouts, aren't solving an active pain point in your product, a full migration is often not worth the engineering time it costs.
Your team hasn't internalized the Server/Client Component mental model yet. I've seen this cause more bugs and confusion than it's worth when teams migrate before they actually understand the boundary between the two. If your team needs more ramp-up time, shipping features on Pages Router while your team builds App Router fluency on smaller side projects is a reasonable, deliberate choice.
You're using a library that doesn't yet fully support Server Components. This gap is closing steadily across the ecosystem, but it still occasionally forces a Pages Router decision for specific, dependency-driven reasons rather than a routing preference.
The mistake I see most often
Teams migrate to App Router because it's the "current" thing to do, without actually restructuring their data-fetching patterns to take advantage of Server Components. They end up with App Router's file structure wrapped around Pages Router-style client-side data fetching, getting the migration cost without the actual performance benefit. If you're migrating, migrate the mental model, not just the folder structure, or don't migrate yet.
My actual recommendation, by scenario
- New SaaS project starting today: App Router, full stop. There's no good reason to start a new project on the router Next.js itself is gradually deprioritizing.
- Existing stable Pages Router product, no active pain point: Stay put. Migrate opportunistically if you're already doing major feature work in a specific section, not as a dedicated migration project with no other justification.
- Existing product with real performance or DX pain that App Router solves: Migrate deliberately, section by section, with the team actually trained on Server Components first, not mid-migration.
The bottom line
App Router is the right default in 2026, and I recommend it for essentially every new SaaS project I architect. But "right default" doesn't mean "mandatory for every existing codebase this week." Match the decision to whether App Router solves a real problem you have, not to which option feels more current.
Suggested internal links: Link to Day 1's Next.js for SaaS article and Day 11's WebSockets vs Polling piece.
CTA: Weighing a migration or a fresh build decision? Book a free architecture review.