Si tu empresa tiene un portal, una app móvil con backend propio, un sistema de facturación o cualquier integración hecha en JavaScript o TypeScript, es muy probable que corra sobre Node.js sin que nadie lo mencione en las juntas. Esta semana ese componente invisible volvió a ser noticia: la comunidad discute el nuevo calendario de versiones del proyecto, justo cuando Node 26 está por convertirse en la línea de soporte de largo plazo recomendada.

No es un tema solo para desarrolladores. El calendario de versiones de tu plataforma base define cuándo dejas de recibir parches de seguridad, cuándo tu proveedor de hosting deja de darte soporte y cuánto te va a costar la próxima migración. Vale la pena entenderlo con calma.

Qué cambió en el calendario de Node.js

El equipo de Node.js publicó este año su anuncio «Evolving the Node.js Release Schedule», donde replantea el ritmo con el que aparecen las versiones mayores. El cambio central, recogido por InfoQ, es que a partir de Node 27 habrá una sola versión mayor al año, en lugar del esquema de dos lanzamientos anuales al que la industria estaba acostumbrada.

En paralelo, la línea estable avanza: los proyectos que usan el alias lts/* en su integración continua están ajustando sus configuraciones porque la transición hacia Node 26 como versión LTS activa está prevista para finales de octubre, alrededor del día 28. Es un movimiento rutinario, pero que suele tomar por sorpresa a los equipos que no revisan sus pipelines.

El contexto de fondo es el que analiza un artículo publicado esta semana en DEV Community: el nuevo calendario también responde a la presión sobre quienes mantienen el proyecto. Sostener varias líneas de versiones en paralelo durante años exige trabajo voluntario que no siempre está disponible. Menos versiones mayores significa un soporte más concentrado y, en teoría, más sostenible.

Por qué esto es un asunto de negocio, no solo técnico

Cuando una versión llega a su fin de vida deja de recibir correcciones de seguridad. Como recuerda NodeSource en su guía sobre versiones y fin de soporte, operar una versión fuera de mantenimiento es un riesgo de negocio: tu aplicación sigue funcionando, pero cualquier vulnerabilidad nueva se queda sin parche oficial. Para una PyME mexicana que maneja datos de clientes, facturación electrónica o pagos en línea, eso se traduce en exposición legal y reputacional, no solo en deuda técnica.

La buena noticia del ritmo anual es que tu empresa necesitará una sola ventana de pruebas al año en lugar de dos. La mala es que cada salto puede acumular más cambios, así que posponerlo tres o cuatro años sale mucho más caro que atenderlo a tiempo.

Plan de cinco pasos para tu empresa

Levanta el inventario. Anota qué aplicaciones usas, quién las desarrolló, sobre qué versión de Node corren y dónde están alojadas. Sin esa lista, cualquier plan es una suposición.
Fija la versión LTS como objetivo. Define que tus sistemas productivos vivan siempre en la línea de soporte de largo plazo vigente y deja las versiones «current» para experimentos, nunca para producción.
Revisa tus pipelines. Si tu integración continua usa el alias genérico de LTS, el cambio hacia Node 26 llegará solo a finales de octubre. Mejor fija la versión de forma explícita y actualízala cuando tú decidas, no cuando el alias se mueva.
Prueba en un ambiente espejo. Valida la aplicación completa —no solo que arranque— antes de tocar producción: reportes, generación de PDF, timbrado, correos, integraciones con bancos y pasarelas.
Calendariza la ventana anual. Con una versión mayor al año, puedes dejar agendada una semana fija de actualización, idealmente en temporada baja de tu operación, y presupuestarla como mantenimiento recurrente.

Preguntas que le debes hacer a tu proveedor

¿En qué versión de Node.js corre hoy mi sistema y hasta cuándo tiene soporte?
¿El contrato de mantenimiento incluye las actualizaciones de plataforma o se cobran aparte?
¿Existe un ambiente de pruebas o cada cambio se valida directo en producción?
¿Cuánto tiempo de indisponibilidad implica la actualización y cuál es el plan de regreso si algo falla?

Si alguna de esas preguntas no tiene respuesta clara, ahí está el verdadero pendiente. El cambio de calendario de Node.js no es una emergencia; es una oportunidad para ordenar el mantenimiento de tu software con fechas conocidas por adelantado.

Cómo lo vemos en EDISAS

En treinta años desarrollando software para PyMEs y gobierno en Sinaloa hemos visto el mismo patrón: los sistemas no fallan el día que salen a producción, fallan el día que nadie los actualizó durante cinco años. Un ciclo anual predecible es, en realidad, un regalo para la planeación: permite meter la actualización en el presupuesto, avisar a los usuarios y ejecutarla en frío.

Nuestra recomendación para este cierre de año es sencilla: pide el inventario de versiones de tus aplicaciones antes de que termine octubre y deja agendada tu ventana de actualización. Es una hora de trabajo administrativo que te puede ahorrar semanas de urgencias.