Migrating from page router with dynamic root level and i18n to app router

[jonas-scytech]

Summary

Hi guys, I'm having a hard time trying to convert my site to use the app router.

Most of my pages are under a dynamic root, ie pages/[category]/..., and I also have support for i18n routing, so the following route is also possible: https://example.com/[lang]/[category]/rest.

Now, afaik, when using app router, to support i18n we should add a root dynamic route like: app/[lang] and this is where it clashes with my pages. I can't have both pages/[category] and app/[lang] as it makes Next not know where to route.

So, my question is: Is there a way to migrate my site without having to migrate all my pages all at once? I really wanted to make a progressive transition, only migrating a few pages and componentes at a time.

Additional information

I can't create a temporary route like `pages/temp/[category]` as it would affect SEO and existing links, but if there is a way to do that without this issue, please let me know.

Example

No response

[coltmans]

Would love to hear something about that, since we also struggle to migrate to AppRouter with this issue.

[logusivam]

Yes, this is a real and well-known constraint during Next.js App Router migrations, and progressive migration is absolutely possible — but it requires a specific structural approach to resolve the [category] vs [lang] dynamic segment clash. Here's the complete picture.

---

Why the clash happens

Next.js resolves routes by matching the file system structure across both pages/ and app/ directories simultaneously during migration. When you have:

pages/[category]/...
app/[lang]/...

Both are top-level dynamic segments. Next.js cannot distinguish between them at routing time — a request to /foo/bar could match either pages/[category]/bar or app/[lang]/bar, and Next.js has no way to know which you intend. This is a hard constraint in the hybrid routing model.

---

The correct solution — wrap everything under a [lang] route group in app/

The key insight is that in the App Router, route groups ((folder)) and the optional catch-all segment ([[...slug]]) let you restructure routing without affecting the public URL.

Step 1 — Structure your app/ directory with an optional lang prefix

Use an optional catch-all to absorb both the with-lang and without-lang cases at the top level:

app/
  [[...lang]]/
    [category]/
      page.tsx
      [...rest]/
        page.tsx

This matches all of:

• /category/rest (no lang)
• /en/category/rest (with lang)
• /fr/category/rest (with lang)

without conflicting with pages/[category] because you've removed the pages/[category] route once you migrate it.

Step 2 — Use a route group to isolate i18n layout from non-i18n pages

app/
  (i18n)/
    [lang]/
      [category]/
        page.tsx
  (root)/
    [category]/
      page.tsx

Route groups (parentheses folders) don't affect the URL — (i18n) and (root) are invisible to the router. This lets you have separate layouts for localized and non-localized routes without URL conflicts.

---

The progressive migration path — step by step

Phase 1 — Keep pages/ for everything, add app/ incrementally

Next.js explicitly supports having both pages/ and app/ active simultaneously. Pages in pages/ continue to use the Pages Router; pages in app/ use the App Router. They coexist.

The constraint is: the same URL path cannot be handled by both routers simultaneously. As long as each URL is handled by exactly one, you're fine.

pages/
  [category]/
    index.tsx        ← still handled by Pages Router
    [slug].tsx       ← still handled by Pages Router

app/
  about/
    page.tsx         ← migrated to App Router (different URL, no clash)
  blog/
    page.tsx         ← migrated to App Router (different URL, no clash)

Phase 2 — Migrate [category] routes page by page

When you're ready to migrate a specific category (e.g. /products/), move it to app/ and remove it from pages/:

app/
  products/          ← migrated, now handled by App Router
    page.tsx
    [slug]/
      page.tsx

pages/
  [category]/        ← still handles all other categories
    [slug].tsx

This works because /products/ is now a static segment in app/ that takes precedence over the dynamic [category] in pages/ for that specific path. Next.js always prefers more specific (static) matches over dynamic ones.

Phase 3 — Handle i18n during migration

For i18n, add the [lang] prefix only to routes you've migrated to app/, and keep your existing next.config.js i18n config active for pages/ routes during the transition:

// next.config.js — keep this for pages/ routes during migration
module.exports = {
  i18n: {
    locales: ['en', 'fr', 'de'],
    defaultLocale: 'en',
  },
}

For app/ routes, handle i18n via the [lang] segment in the file structure as shown in Step 1/2 above, with a middleware to redirect/rewrite as needed.

Phase 4 — Add middleware to bridge i18n between both routers

// middleware.ts
import { NextRequest, NextResponse } from 'next/server'

const LOCALES = ['en', 'fr', 'de']
const DEFAULT_LOCALE = 'en'

export function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname

  // Check if pathname already has a locale prefix
  const pathnameHasLocale = LOCALES.some(
    locale => pathname.startsWith(`/${locale}/`) || pathname === `/${locale}`
  )

  if (!pathnameHasLocale) {
    // Detect locale from Accept-Language header or cookie
    const locale = request.cookies.get('NEXT_LOCALE')?.value ?? DEFAULT_LOCALE

    // Rewrite internally without redirecting (preserves URLs for SEO)
    return NextResponse.rewrite(
      new URL(`/${locale}${pathname}`, request.url)
    )
  }
}

export const config = {
  matcher: [
    '/((?!_next|api|favicon.ico|.*\\..*).*)',
  ],
}

This rewrites requests internally so /products/slug is handled as /en/products/slug by the App Router, without changing the URL visible to users or search engines — preserving SEO and existing links exactly as you require.

---

On your SEO concern about temporary routes

You're right that pages/temp/[category] would break SEO and existing links. The approach above avoids this entirely:

• No URL structure changes at any point in the migration
• pages/[category] continues handling all non-migrated routes at their original URLs
• app/ takes over specific routes as you migrate them, at the same original URLs
• Middleware handles i18n transparently without URL changes

---

Complete recommended directory structure during migration

app/
  (migrated)/              ← route group, invisible to URLs
    [lang]/
      products/            ← migrated category, static segment wins over pages/[category]
        page.tsx
        [slug]/
          page.tsx
      about/
        page.tsx

pages/
  [category]/              ← still handles all non-migrated categories
    index.tsx
    [slug].tsx
  api/
    ...                    ← API routes stay in pages/api/ throughout

middleware.ts              ← handles i18n for both routers
next.config.js             ← keep i18n config for pages/ during transition

---

Key rules to avoid routing conflicts during progressive migration

Rule	Why
Remove a route from pages/ when you add it to app/	Same URL cannot be in both routers simultaneously
Use static segments in app/ for migrated categories	Static beats dynamic — /products in app/ wins over [category] in pages/
Keep next.config.js i18n config active until all pages are migrated	Pages Router needs it; App Router uses [lang] segment instead
Use NextResponse.rewrite in middleware, not redirect	Rewrite preserves URLs for SEO; redirect changes the URL
Don't use [[...slug]] at the top level of app/ while pages/[category] exists	Optional catch-all would conflict with every pages/ dynamic route

Progressive migration is entirely supported and this approach is exactly how the Next.js team recommends doing it. You don't need to migrate everything at once.

Hope this helps — if it answers your question, would you mind clicking "Mark as answer" so others searching for the same thing can find it quickly?