Cómo elegir un stack web pensando en su mantenimiento

Elegir un stack web implica decidir cómo se construirá el proyecto y cómo se mantendrá. Una demostración rápida o un benchmark pueden aportar información, pero no describen las actualizaciones que necesitará una aplicación durante varios años.

Empieza por un inventario de versiones. “Usa Node” o “está hecho con PHP” no basta para conocer su situación.

Soporte activo, seguridad y fin de vida

El soporte activo suele incluir correcciones y mejoras según la política del proyecto. Una fase de mantenimiento puede limitarse a seguridad y fallos críticos. Al llegar al fin de vida, no debes contar con parches ordinarios del proyecto.

Estas etiquetas no significan exactamente lo mismo en todos los productos. Consulta la política y la rama concreta, y distingue el soporte oficial de un servicio comercial adicional.

Algunas fechas que conviene comprobar

El calendario oficial de Node.js permite identificar cuándo termina cada rama:

En PHP, el soporte de seguridad de 8.2 termina el 31 de diciembre de 2026 y el de 8.3 el 31 de diciembre de 2027. Las ramas 8.4 y 8.5 tienen su propia ventana de soporte activo y de seguridad.

Son fechas consultadas el 20 de septiembre de 2026. Verifica el calendario oficial cuando planifiques la migración y comprueba también el framework, los paquetes y el alojamiento.

Next.js sí publica una política de soporte

Next.js distingue Active LTS y Maintenance LTS. La versión mayor actual permanece activa hasta la siguiente; la anterior entra en mantenimiento, con una ventana de dos años desde su publicación inicial.

Su política advierte además de que las actualizaciones de mantenimiento pueden incluir cambios incompatibles. Por eso “sigue soportado” no significa “puedo actualizarlo sin probar”.

La conclusión práctica es guardar el enlace a la política real de cada herramienta. No deduzcas que carece de soporte porque la guía de actualización no incluya todas las fechas.

Qué preguntar antes de elegir

El rendimiento también importa. Mídelo con páginas, datos y dispositivos representativos. No todas las comparativas son inútiles, pero una cifra sin contexto no permite predecir la experiencia de tu aplicación.

Un plan de mantenimiento que se pueda ejecutar

Anota componente, versión, responsable, fuente de soporte y próxima revisión. Reserva una ventana para actualizar antes del vencimiento y prueba las rutas críticas: acceso, formularios, pagos, búsqueda y cualquier integración relevante.

Un sitio estático reduce algunas dependencias de ejecución, pero sigue necesitando mantenimiento de herramientas de construcción, servidor, librerías y servicios externos. Tampoco queda libre de trabajo por no tener un framework en el navegador. El mismo inventario sirve para decidir si una función web necesita un polyfill.

Para valorar el estado de una web existente, cuéntanos cómo está alojada y qué funciones necesita.