Migración y rescate de Next.js
De Pages Router a App Router, de otro framework a Next.js, o una base de código heredada que nadie quiere tocar — migrada de forma incremental, en producción y sin congelar el desarrollo.
Dos situaciones traen aquí a la mayoría de los equipos. O una aplicación Next.js existente se ha quedado pequeña en Pages Router y el camino incremental no es evidente, o una aplicación construida por otros se ha convertido en algo que el equipo actual tiene miedo de desplegar.
Ambas tienen solución. Ninguna requiere una reescritura.
De Pages Router a App Router
Los dos routers interoperan. Esa es toda la estrategia: una aplicación
compartida donde app/ y pages/ coexisten, migrada desde las hojas, con cada
ruta moviéndose tras su propio pull request y su propia verificación.
Empezamos por rutas de poco tráfico y bajo riesgo para construir los patrones
compartidos —layouts, acceso a datos, límites de error— y luego subimos hasta
las rutas que importan. La obtención de datos pasa de getServerSideProps al
árbol de componentes. El estado de cliente que solo existía para compensar el
modelo de renderizado antiguo suele desaparecer por completo.
De otro framework a Next.js
Create React App, SPAs con Vite, Gatsby y una larga cola de configuraciones de webpack a medida. La parte mecánica es el enrutado y la configuración de build; la parte que exige criterio es decidir cuáles de las suposiciones de la aplicación eran artefactos del framework y cuáles eran requisitos reales.
Bases de código heredadas
Antes de cambiar nada, lo leemos todo. Dos semanas de orientación producen un mapa de dependencias, un inventario de renderizado de cada ruta, una lista de lo que está muerto y un registro de riesgos priorizado. Ese documento es tuyo independientemente de lo que decidas después: es lo que vuelve gobernable la base de código, y varios clientes se lo han llevado a casa y han hecho el trabajo ellos mismos.
Nos parece un resultado razonable.