A Next.js Pages Router to App Router migration on a typical marketing site takes about 1 to 6 weeks of developer time. At market rates of $23 to $39 an hour in Asia to $89 to $140 an hour for a mid-level US developer, that's roughly $900 to $34,000 for small and medium sites. It's worth doing when you're already redesigning, upgrading Next.js or fighting heavy JavaScript. If your site is fast, ranks well and rarely changes, stay where you are. The Pages Router isn't deprecated.
I'm writing this for the person approving the budget, not the developer doing the work. I build Next.js marketing sites and fix technical SEO on them, so I look at this through the lens of rankings, tracking and speed. The code isn't what worries me. What worries me is a change that quietly breaks rankings, tracking or speed on the pages that bring in leads.
Is the Next.js Pages Router being deprecated?
No. The Pages Router is still supported in Next.js 16, so there's no deadline forcing you onto the App Router. The Pages Router docs say it's still supported in newer versions of Next.js. To be fair, they also recommend migrating so you can use React's newer features, and new Next.js features usually land in the App Router first.
The Next.js team said early on that incremental adoption was non-negotiable, and you can still move one route at a time today. So you get to decide on the merits, on your own schedule. Nobody needs to panic-buy a rewrite.
How much does a Pages Router to App Router migration cost?
A small Next.js site costs roughly $920 to $11,200 to move to the App Router, a medium site roughly $2,760 to $33,600, and a large site $7,360 to $89,600. Where your developer is based makes most of the difference. The effort ranges below come from a published buyer's guide on this exact migration. The hourly rates come from SecondTalent's 2026 rate data: $89 to $140 an hour for a mid-level US developer and $23 to $39 an hour for Asia. I multiplied them out assuming full 40-hour weeks, so read these as a planning ceiling, not a quote.
| Site size | Typical scope | Effort | At $23–$39/hr | At $89–$140/hr |
|---|---|---|---|---|
| Small (5–15 routes) | Marketing pages, a blog, a contact form | 1–2 weeks | $920–$3,120 | $3,560–$11,200 |
| Medium (15–60 routes) | Several templates, CMS pages, preview, redirects | 3–6 weeks | $2,760–$9,360 | $10,680–$33,600 |
| Large (60+ routes or app features) | Search, login, multiple languages, custom API routes | 2–4 months | $7,360–$24,960 | $28,480–$89,600 |
The 2 to 4 months for large sites is calculated as 8 to 16 working weeks of 40 hours.
For wider context, Upwork puts Next.js freelance work anywhere from $800 for small updates to $50,000 or more for enterprise builds. A routing migration on a marketing site usually sits toward the lower end.
Page count matters less than how complex each page is. A hundred blog posts on one shared template are cheap to move. Ten custom interactive pages aren't. These push the price up:
- A lot of logic in
getServerSidePropsorgetStaticProps - Multiple languages (i18n routing)
- A UI or animation library that doesn't work in React Server Components
- No tests and no staging environment
- Doing a Next.js version upgrade in the same job
What brings it down: TypeScript throughout, a clean CMS setup, consistent templates and a staging site that already exists.
What actually changes when you migrate to the App Router?
Visitors shouldn't notice anything. Behind the scenes, though, nearly every part of the site that touches SEO, data or tracking moves somewhere new. Here's what each change means for you as the buyer:
| Pages Router | App Router | What it risks for you |
|---|---|---|
_app and _document | app/layout.tsx | Analytics, fonts and global styles move, so tracking can break |
next/head or next-seo | Metadata API | Titles, canonicals and social tags can change without anyone noticing |
getStaticProps / getServerSideProps | Server Components with explicit caching | Pages can turn dynamic (slower, costlier) or serve stale content |
next/router | next/navigation | Menus, filters and query-string handling such as UTMs can break |
pages/api routes | Route handlers (optional) | Form submissions and webhooks need retesting |
middleware.ts | proxy.ts in Next.js 16 | Redirect and geo logic needs checking if you upgrade too |
For SEO, the metadata change is the big one. I've gone into the details in next-seo vs the Next.js Metadata API. Short version: every title, description, canonical and Open Graph tag gets rewritten, so every one of them needs checking.
What can go wrong for SEO and Core Web Vitals?
Four things go wrong most often: metadata drift, changed URLs, pages switching from static to dynamic rendering, and more JavaScript reaching the browser. None of them throws an error. You have to go looking.
Metadata drift. A canonical that disappears or a template title that now comes out blank won't break the build. It shows up weeks later as lost rankings. The fix is boring and it works: before each route goes live, crawl staging and production and compare the title, description, canonical, robots tag, H1 and structured data side by side.
Changed URLs. A routing migration shouldn't change a single URL. It happens anyway. Trailing slashes flip, dynamic segments get renamed, or someone tidies up old paths while they're in there. If URLs do change, every old one needs a permanent redirect. My free Redirect Map Builder turns a list of old and new URLs into a redirects() array for next.config.js, and flags chains, loops and trailing-slash mismatches.
Rendering and caching changes. This one catches people out. Next.js 15 stopped caching fetch requests and GET route handlers by default, and it made cookies(), headers() and params asynchronous. If one component in a shared layout reads a cookie, a page that used to be static HTML can quietly become server-rendered on every request. Slower first byte, bigger hosting bill, and nobody touched the design.
Core Web Vitals going the wrong way. The App Router gets sold on the promise of less JavaScript. You only get that if someone redesigns the data flow. Code ported line by line tends to put whole component trees behind "use client", so the browser downloads more JavaScript than before, and more JavaScript usually means worse INP. If your site already struggles, read how to fix Next.js Core Web Vitals first. Some of those fixes don't need a router change at all.
Don't change URLs during the migration
Keep the routing migration and any URL clean-up as separate projects. If rankings dip, you'll know which change caused it and can roll back one thing.
How would I run the migration on a production marketing site?
I'd move routes lowest risk first, and ship each one as its own deploy so a problem can be rolled back without touching anything else. On a lead-gen site the landing pages earn the money, so the order matters far more than clever code. This is the order I'd follow, and it lines up with what experienced migrators publish:
- 1
Record a baseline
Crawl every URL and export titles, canonicals, robots tags and schema. Save Core Web Vitals field data from Search Console so you can compare later.
- 2
Upgrade first, migrate second
Move to the current Next.js and React versions while still on the Pages Router, and ship that on its own.
- 3
Build the root layout
Move fonts, global CSS and analytics into app/layout.tsx, then confirm GA4 and Tag Manager events still fire.
- 4
Move low-risk routes
Start with the privacy policy, 404 and simple content pages to prove the layout and metadata setup.
- 5
Move templates one at a time
Blog posts and landing page templates next, comparing metadata and checking that static pages stay static.
- 6
Complex routes last
Forms, search and anything interactive go last. Delete each old pages file as soon as its new version ships, then watch Search Console.
Because each step is its own deploy, a bad route means reverting one file, not a month of work. Expect the first route to take the longest, since that's where the layout, metadata and caching patterns get worked out. Budget for it.
If tracking matters to you (on a lead-gen site it should), it's a good moment to check that Google Tag Manager isn't slowing the site down.
When should you stay on the Pages Router?
Stay on the Pages Router if your site is fast, ranks well and rarely changes, or if it depends on libraries that don't support React Server Components. Most advice online is written by developers who want to use the new thing. Here's how I'd decide if it were my money:
| Your situation | My recommendation |
|---|---|
| Site is fast, ranks well and rarely changes | Stay. Spend the budget on content or conversion |
| Redesign or rebrand planned soon | Migrate as part of it, since the templates are being rebuilt anyway |
| Heavy JavaScript and failing INP on content pages | Measure first, then migrate the worst templates |
| You rely on libraries that don't support Server Components | Stay, or budget for replacing those libraries too |
| No tests, no staging, one developer | Set up staging first. Migrating without it is the real risk |
| New hires only know the App Router | Migrate gradually, starting with new pages |
There's a middle path people often miss. Build every new page in the app folder and leave the old ones in pages. Your newest landing pages get App Router layouts and Server Components, and the pages that already rank don't get touched.
What should you ask a developer before approving it?
Ask how they'll keep every URL and every piece of metadata identical, and how they'll prove it route by route. A good developer will have specific answers. If all you hear is vague talk about "modernising the stack", be wary.
- Will every URL stay identical, and how will you prove it?
- How will you compare metadata, canonicals and structured data before and after each route?
- Which routes move first, and why those?
- Can we deploy and roll back route by route?
- How will you check that static pages stay static after the move?
- How will you measure Core Web Vitals before and after?
- Does the price include the Next.js version upgrade, or is that separate?
- Who confirms that GA4, Tag Manager and form tracking still work?
Keep the technical SEO checklist for Next.js open while you go through their plan.
Next step
If you're weighing up this migration, send me your site's URL, roughly how many routes it has and what's planned for the next six months. I'll tell you straight whether migrating makes sense now, later or not at all, and which routes I'd move first. You can read more about my Next.js and React website service, or book a 20-minute call and we'll go through it together.
