You own a large, stable Next.js application built entirely on the Pages Router. How do you decide whether migrating to the App Router is worth doing, and what would make you decide against it?
answer
- not a deadline, an investment
- where does new capability land
- sample components: how many could be server
- enumerate the pinning dependencies first
- don't start what you can't close
basics
~20 sDecide on where the framework's new capability lands and whether your app can use it. The Pages Router is still supported, so migration is an investment, not a deadline — argue it from concrete wins like server-side data access and smaller client bundles, and decline when the app is in maintenance or its architecture cannot benefit.
solid answer
~50 sStart by rejecting the framing that this is maintenance work you owe the framework — the Pages Router still ships and still builds. Then make the case on specifics: new framework capability lands App-Router-first, so staying put is a slow accumulation of features you cannot adopt; Server Components can remove real client-bundle weight; nested layouts and per-segment loading states solve structural problems the `getLayout` convention only papered over. Against that, price the honest cost — every route touched, the shell duplicated during the window, third-party libraries that assume the old model, and a team that has to learn a genuinely different execution model. I would decline when the app is in maintenance with no roadmap, when it is client-state-heavy enough that most of it would stay `'use client'` anyway, or when a critical dependency has no App Router story. And I would not start a migration I cannot commit to finishing.
go deeper
Know that the Pages Router still works and is still supported, so an existing app is not broken or unsupported by staying on it.
Be able to list what the App Router offers concretely — Server Components, nested layouts, per-segment loading and error handling — rather than describing it as simply newer.
Argue the case with evidence: sample which components could actually be Server Components, identify the dependencies that would pin routes to pages/, and pilot one real route before extending the programme.
Own the decision including the option to decline. Price it against the rest of the roadmap, define a closing condition and a one-way rule before the first route moves, and be willing to say the migration should not start if you cannot commit to finishing it.
## Frame the decision correctly The first move is to reject the implicit deadline. Next.js has not deprecated the Pages Router; applications built on it continue to build and deploy. So the question is not "when must we" but "does this investment beat the alternatives on the same roadmap" — a feature, a performance programme, a test-coverage push, a dependency upgrade. That reframing matters because migration proposals often arrive as anxiety rather than analysis: the docs lead with the App Router, conference talks assume it, and the team feels behind. That is a real cost — it shows up in hiring and in how much of the ecosystem's guidance applies to you — but it should be named as one input among several, not smuggled in as an obligation. ## What actually argues for migrating **Where new capability lands.** The framework's newer work — partial prerendering, explicit caching directives, the streaming and metadata surfaces — is built for the App Router. Staying on the Pages Router does not break anything today; it means the gap between what the framework can do and what your app can adopt widens every release. For an application with years of roadmap ahead, that compounding matters more than any single feature. **Client bundle weight.** If a meaningful share of your pages is largely read-only rendering — content, catalogue, dashboards that display more than they manipulate — Server Components can move that work and its dependencies off the client permanently. Measure it before promising it: look at what fraction of your current bundle is in components that never handle interaction. **Structural fit.** Nested layouts, per-segment loading and error boundaries, and route-level data co-location solve problems the Pages Router made you solve by convention (`Component.getLayout`, a single top-level data function per route, hand-rolled loading states). If your app is fighting those conventions, the migration is buying structure, not novelty. **Server-side data access.** Moving data access into components that only ever run on the server removes a whole category of accidental client exposure and prop-drilling. For apps with a heavy API-proxying layer, that can simplify real code. ## What argues against **The app is in maintenance.** If the roadmap is bug fixes and the odd copy change, there is no future capability to unlock, and the migration is pure cost with a bug-risk tail. **The app is client-state-heavy.** An editor, a design tool, a trading UI — something where nearly every component is interactive — will end up with `'use client'` almost everywhere. You pay the full migration cost and collect very little of the benefit. Sample honestly: take a dozen representative components and ask which could actually be Server Components. **A dependency has no path.** A CSS-in-JS runtime that relied on `_document` style extraction, a router-events-based integration, a component library that assumes the old model — each of these pins routes in `pages/` indefinitely. Enumerate them *before* committing, because they determine whether the window can ever be closed. **Team bandwidth and model shift.** This is not a rename. Engineers have to internalise where code executes, what crosses the server/client boundary, and how caching behaves — and caching defaults have moved between Next major versions, so the team also has to learn to check rather than assume. Budget the learning, and expect a period where reviews catch mistakes that used to be impossible. ## How I would run it if the answer is yes I would insist on three things before the first route moves. **A closing condition.** Define what "done" means and put a date on it. The characteristic failure of incremental migration is stalling with both trees live, carrying duplicated shells forever. **A one-way rule.** No new routes in `pages/`. The old tree may only shrink. This is cheap to enforce and it converts every new feature into migration progress. **A pilot with a measurement.** Migrate one real, non-trivial island first — not a toy route — and measure what you claimed: bundle delta, time to first byte, developer time per route. If the pilot does not produce the numbers the proposal promised, that is the cheapest possible place to stop. I would also decide explicitly what happens to `pages/api` routes. They are independent of the UI migration and can stay indefinitely; folding them into the same programme inflates scope for no user-visible gain. ## The answer an interviewer is listening for Not a verdict. They want to hear that you price the migration against the roadmap rather than against fashion, that you can name the specific properties of an application that make the App Router pay off or not, that you sized the blockers before committing, and that you would rather not start than leave a codebase permanently split in half.
- How would you quantify the client-bundle benefit before committing the team to the migration?Sample rather than guess. Take a representative set of routes, and for each component ask whether it handles interaction or merely renders. Sum the bundle contribution of the non-interactive set — that is the ceiling on what Server Components could remove. Then migrate one real route as a pilot and compare the measured delta against that ceiling before extending the programme.
- What is the single strongest signal that a Pages Router app should not migrate?That most of its components would end up marked `'use client'` anyway. A heavily interactive application — an editor, a canvas tool — pays the entire migration cost and collects almost none of the server-rendering benefit. A close second is a load-bearing dependency with no App Router story, which guarantees the codebase stays permanently split.
- How do you stop an incremental migration from stalling at 60% complete?Two mechanisms. A hard rule that new routes are only written in `app/`, so the old tree can only shrink, and a named owner with a date for the residue. Track the routes that are genuinely blocked — usually by a dependency — as explicit blockers with their own resolution plan, rather than letting them dissolve into a permanent backlog.
- Do pages/api routes have to move as part of the same programme?No, and folding them in usually inflates scope for no user-visible gain. API routes under `pages/api` keep working alongside the App Router and only conflict if you create a route handler at the same path. Decide their fate separately, on their own merits, once the UI migration's value has been demonstrated.
saying these in an interview costs you the question
- Says the Pages Router is deprecated and migration is mandatory
- Argues for migrating without measuring any expected benefit
- Ignores dependencies that pin routes to the old router
- Plans a big-bang rewrite on a long-lived branch
- Treats permanent coexistence as an acceptable end state