Next.js Rendering Models and What They Mean for a CMS Migration

Statically generated routes

Pages produced at build time are the easiest case. The build output is finished HTML with a known URL for each page, which means the destination structure is already visible. Content usually comes from a data source the build reads — markdown files, a headless CMS, a local dataset — and that source is what migrates into the new system.

The main trap is dynamic route generation. A route that enumerates hundreds of paths from a dataset must produce exactly the same permalinks afterwards, including any locale prefix. Export the generated path list from the build and treat it as the redirect map's reference.

Server-rendered and revalidated routes

Server-rendered routes personalise or compute something per request. Ask what that computation is: if it is content assembly, it becomes a template query; if it is genuine personalisation, it needs an explicit decision about whether the destination should support it at all.

Incrementally revalidated routes sit in between and often reveal a hidden dependency on an external system. Migrating them means deciding where freshness now comes from — scheduled imports, an API call at render time, or accepting that the content is simply edited in the CMS like everything else.

Middleware and edge logic deserve their own inventory. Redirects, locale detection and access rules implemented in middleware are invisible in the page tree and are frequently forgotten until something breaks in production.

Images, fonts and metadata

The framework's image component does resizing, format negotiation and lazy loading automatically. After migration that behaviour must be reproduced deliberately: responsive source sets, modern formats, explicit dimensions to prevent layout shift, and eager loading for the hero image only.

Font loading is similar — self-host, preload the critical face, and keep the fallback metrics close enough that swapping does not shift the layout.

Metadata defined in the framework's head configuration must be re-expressed as template logic. This is the moment to move from hard-coded values to real per-entry fields, which is an improvement rather than a chore.

Deciding what to keep

Some Next.js applications should not become template sites at all. If the product is genuinely interactive — a dashboard, a search interface over a large index, a tool — keeping the front end and using the CMS as a content API is the honest answer. The mistake is choosing headless for a marketing site because the current stack happens to be a framework.