How we think about incremental Next.js migrations

A Next.js migration is rarely a framework problem. It is a product-continuity problem. The current application still has customers. The team still has a roadmap. The architecture is the thing in the way.

Rewrites fail because they ask the organization to pause. Incremental migrations work because they ask the organization to change where new work goes.

Land new work in the target

The first success is not "the old app is gone." It is "the next feature did not make the old app thicker." Routing, design primitives, and data access need a home in the new system before anyone talks about a cutover.

Slice vertically

Horizontal rewrites look productive: convert all buttons, then all forms, then all pages. They keep two complete products alive. Vertical slices — a route, a workflow, a surface — let you learn the real constraints: auth, caching, the parts of the design system that were actually load-bearing.

Keep one product surface

Users should not care that two architectures exist. Preview deployments, shared types, and explicit ownership matter more than a dramatic date on a slide.

The migration is done when the old system is an island, not when a banner says "now in Next.js."