App Router migrations done in theory in production.

On a content-heavy marketing site we migrated last year, App Router cut Time-to-First-Byte by removing the round-trip to a client-side data fetcher — the page rendered server-side with the data already in place, no loading shimmer for users, no extra hop for crawlers. On a separate internal product, App Router let us stream the slowest part of the page (a third-party API call that took roughly 2.4 seconds) while the rest rendered immediately. The wins are concrete, not abstract: fewer client bundles, less hydration work, server-only secrets that never reach the browser, and the option to run database queries inside React components instead of bouncing through an API route. The site you are reading is one of those deployments.

Not every project earned the migration. Apps with heavy client-side state — drag-and-drop editors, real-time collaboration UIs, anything where most of the screen is interactive — got minimal benefit from server components and a real cost in mental-model retraining. Pages Router also stayed sensible for projects pinned to libraries that had not shipped React Server Components support yet (a moving target, but still real for some auth providers and rich-text editors as of this writing). And honestly: when the team did not have a free quarter to absorb new caching semantics, we would recommend deferring. App Router rewards teams that can think in cache layers; it punishes teams that just want JSX and a deployment URL.

After half a dozen migrations, these are the patterns we keep returning to:

- Move static-content pages first (marketing, docs, blog), defer interactive surfaces until the team's comfort level is high. - Apply 'use client' at the leaf component, not the layout — every 'use client' at a parent forfeits the server-rendering benefits of the whole subtree. - Keep pages/api until route handlers are proven for your workload — they coexist cleanly, no need to rewrite working endpoints on day one. - Test ISR end-to-end after migration. The semantics shifted from getStaticProps + revalidate to the revalidate export plus revalidateTag. Cache misses look different. - Wire fetch() caching deliberately. Default force-cache caught us once — a third-party rate-limited API got hammered when we forgot to set { cache: 'no-store' }. - Bring in our web development team for the migration if there is no slack on the engineering side. App Router rewards experience.

Five factors we use when scoping a migration:

SEO and ISR. Pages Router has battle-tested ISR through getStaticProps + revalidate. App Router uses the revalidate export and revalidateTag() for fine-grained invalidation. Our take: equivalent for marketing sites; App Router wins where time-bound data needs targeted revalidation.

Learning curve. Pages Router takes about a day to internalize for an experienced React engineer. App Router takes one to two weeks of real work to internalize server components, the new caching layer, and route handler semantics. Our take: budget the team ramp into the migration estimate or it lands late.

RSC library compatibility. Pages Router is universally compatible. App Router needs every client-state library in the tree to play nicely with React Server Components. Our take: audit your top five libraries before committing — most have shipped RSC support, but the one that has not will hold up the rollout.

Third-party libraries. Pages Router: pick anything. App Router: requires 'use client' boundaries and sometimes wrapper components for libraries that read browser APIs at module scope. Our take: the wrapper layer is small but real; budget a half-day per major library.

Real cost in dev hours. A 40-page marketing site: 2–3 weeks. A SaaS app — think dashboards, auth, third-party libraries, the shape of a job-matching platform or a tax credit portal — runs 6–8 weeks. Our take: these are NerdHeadz numbers from real projects; multiply by 1.5 if your team is also learning App Router during the migration. Pair with the Vercel AI SDK if you are adding streaming AI features at the same time — it slots cleanly into App Router's streaming model.

For more on the larger engagement shape, see our custom software development approach.