Pages vs App Router: Key Differences & Migration Mindset

Next.js has been evolving rapidly, and one of the biggest changes in recent versions is the introduction of the App Router (available since Next.js 13). While the Pages Router has served as the backbone for years, the App Router brings a whole new paradigm—heavily inspired by React Server Components and modern application patterns.

If you’re wondering whether to stick with Pages or start migrating to the App Router, this article will break down the key differences and provide a migration mindset to guide you through the shift.

1. The Core Difference

Pages Router
- File-based routing under the /pages directory.
- Relies on React’s client-side rendering (CSR), server-side rendering (SSR), and static site generation (SSG).
- Mature, stable, and widely used.
App Router
- Introduces a new /app directory for routing.
- Built around React Server Components (RSCs) by default.
- Emphasizes server-first rendering, streaming, and colocation of data + UI.
- Still evolving, but officially recommended by Vercel as the future of Next.js.

2. Routing Paradigm

Pages Router: Routing is file-based, and dynamic routes rely on [slug].js or [id].js files. API routes also live in /pages/api.
App Router:
- Routing is nested and layout-driven.
- Folders represent segments of the route.
- Supports parallel routes (@slot), intercepting routes, and shared layouts.
- API routes move to Route Handlers inside /app/api.

✅ Migration Mindset: Think in components + layouts instead of just pages.

3. Data Fetching

Pages Router: Uses special functions like getStaticProps, getServerSideProps, and getStaticPaths.
App Router:
- Data fetching is just async/await inside Server Components.
- No need for special Next.js functions; React Suspense handles streaming and loading states.
- Built-in caching and revalidation via fetch options (cache, revalidate).

✅ Migration Mindset: Learn to use async server components and React Suspense instead of Next.js-specific data functions.

4. Layouts and Nested UI

Pages Router: Layouts had to be manually implemented, often via _app.js or third-party libraries.
App Router:
- Layouts are first-class citizens.
- Nested layouts enable better UI sharing (think dashboards with sidebars or modals).
- Automatic persistence of state and navigation between layouts.

✅ Migration Mindset: Break your app into UI regions rather than monolithic pages.

5. Rendering & Performance

Pages Router: Mainly CSR + SSR + SSG. Incremental Static Regeneration (ISR) was a major upgrade.
App Router:
- Defaults to Server Components, with selective Client Components.
- Enables streaming UI and progressive rendering.
- Reduced JavaScript bundle size since much of the rendering logic stays on the server.

✅ Migration Mindset: Optimize what truly needs to be a client component (forms, hooks, browser APIs). Everything else stays server-rendered.

6. API Routes vs Route Handlers

Pages Router: API routes live under /pages/api.
App Router:
- Uses Route Handlers in /app/api/route.js.
- Fully typed with TypeScript, leveraging the Request/Response Web API standard.
- Closer to edge-friendly APIs.

✅ Migration Mindset: Treat APIs as first-class route handlers, consistent with modern web standards.

7. Migration Considerations

If you’re moving from Pages to App Router, here’s a practical mindset:

Start Small: Try migrating new sections (like a dashboard or blog) to /app first, while keeping legacy routes in /pages. Both can coexist.
Think Server-First: Use server components by default, and only mark client components when truly needed.
Refactor Data Layer: Move away from getServerSideProps → embrace fetch with revalidation.
Redesign Layouts: Break your app into nested layouts to fully leverage the new paradigm.
Test Performance: Compare bundle sizes, TTFB, and user experience before fully committing.

8. Should You Migrate Now?

If you’re building a new project → Start with App Router.
If you’re maintaining a stable project → Stick with Pages Router for now, unless you need advanced layouts, streaming, or RSC benefits.
If you’re planning for long-term growth → Gradually adopt App Router features to future-proof your codebase.

Final Thoughts

The shift from Pages Router to App Router is not just an upgrade—it’s a paradigm shift. The Pages Router focused on simplicity and static/dynamic rendering, while the App Router embraces a server-first, React 18-powered world.

Migrating requires a change in mindset: from page-centric thinking to component- and layout-centric thinking. The payoff? Better performance, reduced client-side overhead, and a future-ready Next.js application.

📌 FAQs: Pages Router vs App Router

Q1. Can I use both Pages and App Router in the same Next.js project?
Yes. Next.js supports hybrid projects where /pages and /app directories can coexist. This makes gradual migration possible without breaking existing routes.

Q2. Do I have to migrate my project to the App Router right now?
Not immediately. Pages Router is still fully supported. However, new features and improvements are focused on the App Router, so migration is recommended for future-proofing.

Q3. What happens to getServerSideProps and getStaticProps in the App Router?
They are no longer used. Instead, you fetch data directly in Server Components using async/await and built-in caching/revalidation options.

Q4. Are API routes different in the App Router?
Yes. API routes are now handled by Route Handlers inside /app/api, which follow the modern Request/Response Web API.

Q5. What are the main benefits of the App Router?

Server-first rendering by default
Reduced bundle size
Streaming & React Suspense support
Nested layouts and parallel routes
Cleaner data fetching patterns

Q6. Is App Router stable for production?
Yes, it’s production-ready as of Next.js 13.4 and later. Many large apps already run fully on the App Router.