Next.js 15 pierde soporte oficial el 21 de octubre de 2026. Plan concreto para auditar, migrar y asegurar tu app.
Next.js 15 pierde todo soporte oficial el 21 de octubre de 2026, según el calendario de fin de vida publicado por HeroDevs. Concretamente: ningún parche de seguridad después de esa fecha, ni siquiera en caso de vulnerabilidad crítica. Si tu aplicación aún se ejecuta en esa versión, este artículo te da un plan para auditar, migrar y evitar los problemas típicos antes de la fecha límite.
Por qué esta fecha importa realmente
Una versión al final de su vida útil no deja de funcionar de la noche a la mañana. Continúa ejecutándose, silenciosamente, hasta el día en que sale un CVE y nadie lo corrige para ti.
Ese es el verdadero riesgo: no una caída inmediata, sino una ventana de exposición que se abre sin previo aviso. Los equipos de seguridad de tus clientes o socios B2B preguntan cada vez más sobre el soporte de las dependencias en sus auditorías de proveedores. Un framework sin mantenimiento puede causar que falles una auditoría SOC2 o ISO 27001, independientemente de la calidad de tu código.
Next.js 15 está actualmente en mantenimiento LTS, lo que significa: parches de seguridad críticos únicamente, sin nuevas funcionalidades. Después del 21 de octubre de 2026, incluso eso se detiene. Tienes, a la fecha de escritura de este artículo, poco menos de tres meses para decidir.
Tres meses suena a mucho tiempo. No lo es para un equipo de menos de 5 devs que también necesita entregar sus features del trimestre.
Auditar antes de migrar: qué verificar primero
Migrar sin una auditoría previa es la mejor manera de descubrir un breaking change en producción un viernes por la noche. Antes de tocar el package.json, revisa estos puntos.
El uso residual del Pages Router. Muchas aplicaciones Next.js migraron hacia el App Router en la fachada pero conservan rutas API o páginas legacy en el sistema antiguo. Estas son las primeras en romperse durante un cambio de versión mayor.
Las dependencias de terceros relacionadas con el renderizado. Las librerías que parchean el comportamiento de renderizado de Next.js (ciertos SDKs de A/B testing, ciertas herramientas de personalización) a menudo son las últimas en publicar una versión compatible. Verifica su changelog antes de comprometerte con un calendario.
Las Server Actions y el caché de datos. El comportamiento de caché introducido con el App Router ha evolucionado varias veces desde Next.js 13. Si tu equipo implementó workarounds manuales para gestionar la revalidación, estos son puntos de fricción prácticamente garantizados durante una migración mayor.
La versión de Node.js y React subyacentes. Next.js 15 se basa en React 19; un cambio de versión mayor del framework casi siempre viene acompañado de un aumento en la versión mínima de Node soportada. Verifica tu runtime de producción, incluidos los entornos de preview.
Haz este inventario en una simple tabla, línea por línea, con una columna de "riesgo" y otra de "esfuerzo estimado". Te toma media jornada. Te ahorra dos semanas de sorpresas desagradables.
Los pasos concretos de una migración sin roturas
Una vez hecha la auditoría, la migración en sí sigue un camino bastante establecido, siempre que no saltes etapas.
Paso 1: aislar un entorno de prueba representativo
Nunca migres directamente en una rama que apunta a producción. Crea un entorno espejo con un conjunto de datos realista, no una base vacía. Los bugs de caché y revalidación a menudo aparecen solo con tráfico real y datos reales.
Paso 2: subir de versión por etapas, no de un salto
Si aún estás en Next.js 13 o 14, no apuntes directamente a Next.js 16 en un único commit. Pasa primero por Next.js 15, estabiliza, luego continúa. Cada salto de versión mayor aislado es más fácil de depurar que un salto acumulativo de tres versiones.
Paso 3: usar los codemods oficiales cuando existan
Vercel históricamente publica codemods para automatizar parte de las migraciones entre versiones mayores (renombramiento de imports, adaptación de config). Nunca cubre el 100% del trabajo, pero evita errores tipográficos en cientos de archivos.
Paso 4: probar el build de producción, no solo el desarrollo
El modo desarrollo oculta ciertos problemas de generación estática o Edge Runtime. Un next build completo, seguido de un despliegue en un entorno de preview aislado, debe formar parte del checklist antes de cualquier merge.
Paso 5: planificar un rollback antes del despliegue, no después
Mantén la versión anterior desplegable en un clic durante al menos dos semanas después del cambio. La mayoría de las regresiones de caché o SEO (meta tags, sitemap, redirecciones) aparecen solo después de varios días de tráfico real.
Un equipo de producto con una aplicación de 200 páginas y Server Actions complejas contará varias semanas de trabajo distribuidas en dos o tres sprints. Un sitio de presentación de 15 páginas sin lógica de negocio pesada puede, en cambio, cambiar en un solo sprint. La brecha en la carga de trabajo entre estos dos casos es enorme, desconfía de las estimaciones genéricas que encuentras en línea, casi nunca consideran el tamaño real del proyecto.
Quedarse en next.js 15 o migrar ahora: la comparativa
| Criterio | Quedarse en Next.js 15 después del 21/10/2026 | Migrar a Next.js 16 antes del plazo |
|---|---|---|
| Parches de seguridad | Ninguno después de la fecha de fin de vida | Soporte activo, parches regulares |
| Compatibilidad auditorías de proveedores | Riesgo de no conformidad (SOC2, ISO 27001) | Conforme con requisitos de mantenimiento |
| Costo inmediato | Nulo a corto plazo | Tiempo dev a movilizar (semanas a meses) |
| Riesgo a mediano plazo | Deuda técnica acumulada, migración más difícil mañana | Base de código actualizada, futuras migraciones más simples |
| Acceso a nuevas funcionalidades | Ninguno | Sí, según el roadmap de Next.js |
Esta tabla no es neutral: en la inmensa mayoría de los casos, diferir la migración solo mueve el problema y lo empeora. La única excepción legítima es un proyecto en fin de vida él mismo, que planeas decomisionar antes del plazo, en cuyo caso la pregunta ni siquiera se plantea.
Lo que hay que recordar
Tres puntos a tener en cuenta. Primero, la fecha del 21 de octubre de 2026 no es un rumor: es el calendario oficial de fin de vida de Next.js 15. Segundo, la auditoría previa, Pages Router residual, dependencias de terceros, caché, versión Node— determina el 80% del éxito de la migración, mucho antes de escribir una sola línea de código. Finalmente, una migración por etapas con entorno de prueba representativo sigue siendo el método más seguro, incluso si toma más tiempo que un salto directo.
Si tu equipo aún duda sobre el calendario o la magnitud del proyecto, detallamos un enfoque similar de actualización de versión en nuestro artículo sobre TypeScript 7.0 y el compilador nativo en Go, los mismos principios de auditoría y etapas aplican.
Preguntas frecuentes
¿Qué pasa concretamente si nos quedamos en next.js 15 después del 21 de octubre de 2026?
La aplicación continúa funcionando normalmente. El riesgo es la ausencia de parche en caso de una vulnerabilidad de seguridad descubierta después de esa fecha, y una potencial no conformidad en auditorías de proveedores que verifican el soporte activo de dependencias críticas.
¿Cuánto tiempo toma una migración de next.js 15 a next.js 16?
Depende completamente del tamaño y complejidad de la aplicación. Un sitio simple puede cambiar en un sprint; una aplicación con Server Actions complejas y un Pages Router residual puede requerir varios sprints distribuidos a lo largo de algunas semanas.
¿Hay que migrar directamente a next.js 16 si aún estamos en next.js 13?
No, es mejor pasar por Next.js 15 primero, estabilizar, luego continuar. Un salto de versión aislado es más fácil de depurar que múltiples cambios mayores en uno solo.
¿Los codemods oficiales son suficientes para migrar sin intervención manual?
No. Los codemods automatizan parte del trabajo, renombramientos de imports, ajustes de configuración— pero nunca cubren casos de negocio específicos, especialmente alrededor del caché y las Server Actions. Un paso manual sigue siendo indispensable.
¿Cómo probar una migración de next.js sin arriesgar la producción?
Creando un entorno de preview aislado con un conjunto de datos realista, ejecutando un build de producción completo (next build), y manteniendo la versión anterior desplegable con rollback durante al menos dos semanas después del cambio.
