It's 2026. App Router has been stable for over two years. Pages Router still works, still gets security patches, and Vercel hasn't deprecated it. So the question keeps coming up: which one should I use?
The answer depends on whether you're starting fresh or maintaining an existing project. Let's look at both.
What App Router actually gives you now
When App Router launched, the pitch was Server Components and streaming. Two years later, the real wins are more practical:
Layouts that persist across navigations. A dashboard shell that doesn't remount when you switch tabs. A checkout flow where the cart sidebar survives page transitions. In Pages Router, you fake this with _app.tsx and state management. In App Router, it's a layout.tsx file.
Server Components by default. Your components ship zero JS to the client unless you opt in with 'use client'. For content-heavy pages — blogs, marketing sites, documentation — this means dramatically less JavaScript. I hit Lighthouse 98 on a trilingual site partly because most components never touch the client bundle.
Server Actions. Form submissions and mutations without API routes. One function, one file, 'use server' at the top. It removes an entire layer of boilerplate. (Though there are gotchas I learned the hard way.)
Parallel routes and intercepting routes. Modal patterns where the URL updates but the parent page stays mounted. Photo galleries, login modals, detail panels — all with proper back-button behavior.
Streaming and Suspense. The shell loads instantly, slow data streams in. Users see something immediately instead of staring at a spinner. For pages with multiple independent data sources, this is a noticeable UX improvement.
When Pages Router is still the right call
Existing project, working fine
If you have a Pages Router project in production, users are happy, and the team ships features without friction — don't migrate. Pages Router isn't going anywhere, and a migration gives you zero new features your users will notice. It's engineering time with no product return.
I've seen teams spend 3–4 weeks migrating medium-sized apps to App Router. The result: the same app, slightly less JS shipped, and a team that now needs to relearn patterns they had muscle memory for. Not worth it unless you're hitting a specific ceiling.
Team hasn't used App Router before
The mental model shift is real. Server Components have serialization boundaries — you can't pass functions or event handlers from server to client components. State management changes. Data fetching moves from getServerSideProps to async components. Error boundaries work differently.
For a team new to App Router, budget 1–2 weeks of ramp-up time before you're shipping at the same velocity. On a tight deadline, that's a real cost.
Libraries that haven't caught up
Most major libraries work with App Router now. But if your project depends on something that requires client-side rendering patterns throughout — certain animation libraries, complex drag-and-drop setups, or niche state management tools — check compatibility first. Wrapping everything in 'use client' defeats the purpose.
The migration path: coexistence
If you do decide to migrate, Next.js supports both routers simultaneously. The app/ directory uses App Router; the pages/ directory uses Pages Router. They coexist in the same project.
The practical approach:
- New routes go in
app/. Every new page or feature uses App Router. - Existing routes stay in
pages/. Don't touch working code. - Migrate opportunistically. When you're already rewriting a page for a feature change, move it to
app/. - Shared layouts first. The biggest win from migration is persistent layouts. Start there.
I've done this on two client projects. Full migration took 2–3 months of opportunistic moves, with zero downtime and no big-bang rewrite. The pages/ directory shrank naturally.
The honest recommendation
Starting a new project in 2026? Use App Router. The ecosystem has caught up, the patterns are stable, and the developer experience advantages (layouts, Server Components, streaming) compound over the life of the project. You'll also get better documentation and community support going forward — most new tutorials, examples, and library guides assume App Router.
Maintaining a Pages Router project? Keep it. Migrate only if you're hitting specific ceilings:
- You need persistent layouts and can't fake them cleanly
- Your client-side JS bundle is too large and Server Components would meaningfully reduce it
- You're adding i18n routing and App Router's file-based approach is cleaner
Mixing both? Perfectly fine. It's not a temporary hack — it's how Next.js was designed to support gradual adoption.
The question "App Router or Pages Router?" is still real in 2026. But the answer is simpler than it was two years ago: default to App Router for new work, don't migrate old work without a reason.
Working with Next.js and not sure which patterns fit your project? Let's talk — I help teams pick the right architecture so they ship faster, not just differently.