Red Hat ha presentado Red Hat Enterprise Linux Long-Life Add-On, una extensión anual que permitirá mantener versiones antiguas de RHEL durante décadas, incluso después de agotar los periodos habituales de soporte ampliado. La compañía evita comprometer una fecha definitiva de retirada y plantea renovaciones sucesivas para aquellas organizaciones que no puedan actualizar sus sistemas al ritmo marcado por el calendario convencional.
La propuesta está dirigida a cargas difíciles de modificar: plataformas bancarias, redes de telecomunicaciones, sistemas sanitarios, infraestructuras públicas, equipos industriales y aplicaciones sometidas a certificaciones muy costosas. En estos entornos, cambiar de sistema operativo puede exigir nuevas auditorías, pruebas con hardware específico y meses de trabajo sobre aplicaciones que continúan cumpliendo correctamente su función.
Las claves de RHEL Long-Life Add-On en 20 segundos
- Extiende el soporte de determinadas versiones de RHEL mediante renovaciones anuales.
- Red Hat no establece una fecha final predeterminada para dejar de ofrecerlo.
- Solo estará disponible para clientes con una suscripción activa Extended Life Cycle, Premium.
- Puede contratarse por uno o varios años, según las necesidades del proyecto.
- Mantiene actualizaciones de seguridad y correcciones de errores dentro del alcance definido por Red Hat.
- Incluye soporte técnico permanente cuando se combina con ELC Premium.
- No añade nuevas funciones ni convierte una versión antigua en compatible con cualquier hardware futuro.
- Está pensado para sistemas cuya actualización implique riesgos regulatorios u operativos elevados.
- El precio no se ha comunicado públicamente.
- La renovación anual depende de que Red Hat mantenga comercialmente la oferta y el cliente siga contratándola.
RHEL 8, 9 y 10 disponen de un ciclo ordinario de diez años dividido entre soporte completo y mantenimiento. Red Hat ofrece después Extended Life Cycle para determinadas versiones menores, con periodos ampliados que pueden llevar una versión elegible hasta los 14 años. Long-Life comienza donde termina ese recorrido y añade periodos renovables de un año sin un límite previamente publicado.
Cómo encaja Long-Life en el ciclo de soporte de RHEL
El anuncio puede resumirse como una nueva capa situada al final de la vida comercial habitual de Red Hat Enterprise Linux. No reemplaza las suscripciones existentes ni permite saltar directamente desde una instalación estándar a un soporte indefinido.
La organización debe contar primero con Extended Life Cycle, Premium. Esta modalidad mantiene versiones menores elegibles durante más tiempo y proporciona asistencia técnica las 24 horas, además de actualizaciones seleccionadas. Long-Life toma el relevo cuando concluye ese periodo.
Desde RHEL 9, Red Hat ha unificado varias fórmulas anteriores bajo la denominación Extended Life Cycle. Las versiones menores pares, como RHEL 9.2, 9.4 o 9.6, pueden recibir hasta seis años de soporte desde su publicación. En el caso de la última versión menor de una generación, ELC puede prolongar la cobertura cuatro años más allá de los diez años ordinarios del sistema.
| Etapa | Cobertura orientativa |
|---|---|
| Soporte completo | Nuevas funciones, correcciones, seguridad y compatibilidad con hardware |
| Mantenimiento | Seguridad y errores relevantes, sin grandes incorporaciones funcionales |
| Extended Life Cycle | Mantenimiento ampliado para versiones menores elegibles |
| Long-Life Add-On | Extensiones anuales renovables después de ELC |
| Canal retirado | Acceso al contenido publicado, pero sin nuevas correcciones |
La expresión utilizada por Red Hat, “sin fecha final predeterminada”, necesita una precisión. No equivale a una garantía irrevocable de soporte eterno. El cliente debe renovar la extensión cada año y la prestación se rige por las condiciones comerciales, técnicas y contractuales de la compañía.
La política oficial describe Long-Life como una sucesión de periodos anuales abiertos: un primer año después de ELC, un segundo y tantos adicionales como se renueven. Cuando una organización deja de contratarlo, conserva acceso a los paquetes publicados en un canal retirado, pero ya no recibe nuevas correcciones de vulnerabilidades ni errores.
Red Hat presenta la oferta con acceso a parches de seguridad y correcciones urgentes. La política general del ciclo de vida de RHEL contempla avisos de seguridad y errores conforme a los criterios definidos para cada fase, aunque el alcance exacto puede variar según la versión, el paquete y el contrato. Las empresas deberán revisar qué componentes están incluidos antes de asumir que toda la distribución recibirá cualquier parche durante décadas.
Tampoco habrá nuevas versiones menores, funciones adicionales ni una renovación continua del hardware admitido. Una instalación antigua puede seguir recibiendo mantenimiento y, aun así, no reconocer un procesador, una controladora de almacenamiento o una tarjeta de red lanzados muchos años después.
Por qué una empresa pagaría por mantener un Linux antiguo
Actualizar un servidor corporativo no suele consistir en instalar la nueva versión y reiniciar. En aplicaciones de negocio con años de historia, el sistema operativo está conectado con bases de datos, bibliotecas, agentes de seguridad, software de copia, herramientas de monitorización y controladores certificados.
Un cambio de versión puede alterar dependencias, eliminar interfaces antiguas o exigir un nuevo conjunto de pruebas. En un banco, una operadora o un hospital, la organización también puede tener que demostrar ante auditores que la plataforma modificada continúa cumpliendo sus requisitos.
El problema es todavía mayor en sistemas industriales y equipos especializados. Una máquina puede estar diseñada para funcionar durante 20 o 30 años, mientras el ciclo de soporte de su sistema operativo es mucho más corto. Sustituir el software puede obligar a recertificar el dispositivo completo, incluso cuando el hardware y la aplicación siguen funcionando.
Long-Life ofrece una salida comercial a ese desajuste. La empresa puede mantener la versión validada y continuar recibiendo determinadas correcciones mientras prepara una migración, prolonga la vida de un equipo o espera a que finalice un contrato.
Entre los casos más claros aparecen:
- Sistemas de control industrial vinculados a maquinaria con ciclos de renovación largos.
- Plataformas de telecomunicaciones que requieren ventanas de mantenimiento muy limitadas.
- Aplicaciones financieras sometidas a validaciones internas y regulatorias.
- Equipos médicos cuyo software forma parte de una certificación.
- Sistemas públicos que dependen de desarrollos antiguos y proveedores externos.
- Aplicaciones empresariales que ya no reciben nuevas funciones, pero siguen siendo necesarias.
El valor no está únicamente en los parches. Mantener una vía oficial de soporte permite abrir incidencias, obtener ayuda de ingeniería y demostrar ante un auditor que el sistema no está completamente abandonado.
También puede reducir el riesgo de una migración apresurada. Cuando una fecha de fin de soporte se acerca, algunas organizaciones acumulan cambios, pruebas y sustituciones en un proyecto realizado bajo presión. Una extensión anual proporciona tiempo adicional para planificar, aunque ese tiempo tendrá un coste y no elimina el trabajo pendiente.
Soporte prolongado no significa ausencia de deuda técnica
La posibilidad de mantener RHEL durante décadas puede resultar atractiva, pero no debería convertirse en una política general para evitar cualquier actualización.
Una versión antigua conserva decisiones de diseño, bibliotecas y limitaciones propias de su época. Red Hat puede corregir una vulnerabilidad grave mediante backporting, incorporando el parche sin cambiar toda la versión del componente, pero no siempre es viable trasladar indefinidamente cada mejora de seguridad.
Los Application Streams también pueden seguir calendarios distintos al del sistema operativo. Lenguajes, bases de datos, servidores web y entornos de ejecución incluidos en RHEL pueden tener una vida útil menor, por lo que mantener el núcleo de la distribución no garantiza que todas las aplicaciones continúen plenamente soportadas.
La compatibilidad con terceros plantea otra limitación. Un fabricante de software puede dejar de certificar su producto sobre una versión concreta aunque Red Hat siga manteniéndola. Lo mismo puede ocurrir con agentes EDR, plataformas de copia de seguridad, controladores, hipervisores y herramientas de gestión.
También hay un coste operativo difícil de medir. Los administradores deben conservar conocimientos sobre versiones antiguas, repositorios separados y procedimientos que ya no se utilizan en el resto de la empresa. Cuanto más se aleja un servidor del estándar corporativo, más especial se vuelve su mantenimiento.
La virtualización puede aliviar el problema del hardware. Red Hat contempla que sistemas invitados antiguos se ejecuten sobre hosts más modernos, lo que permite desacoplar parcialmente la vida del sistema operativo de la del servidor físico. No resuelve las dependencias de la aplicación, pero evita exigir controladores recientes a la instalación heredada.
Una estrategia razonable debería distinguir entre sistemas que necesitan estabilidad excepcional y aquellos que simplemente no se han actualizado por falta de planificación. Long-Life tiene sentido cuando el coste o el riesgo del cambio están documentados. Resulta menos defendible cuando se utiliza para aplazar indefinidamente una modernización necesaria.
Red Hat tampoco ha publicado el precio de la nueva extensión. El coste probablemente dependerá del número de sistemas, la versión, el nivel de soporte y la duración contratada. Las organizaciones tendrán que compararlo con el gasto de migrar, mantener conocimientos especializados y asumir las limitaciones de una plataforma antigua.
La novedad cambia, en cualquier caso, una de las reglas habituales del software empresarial. La fecha de retirada deja de ser un límite técnico automático y pasa a convertirse en una decisión económica renovada cada año. Para determinadas cargas puede ser una solución sensata; para otras, una forma cara de conservar problemas que deberían haberse resuelto antes.
Preguntas frecuentes
¿RHEL tendrá soporte para siempre?
Red Hat no fija una fecha final para Long-Life, pero el soporte debe renovarse anualmente y está sujeto a las condiciones técnicas y comerciales de la compañía.
¿Cualquier instalación de RHEL puede contratar Long-Life?
No. La oferta está destinada a clientes que ya disponen de una suscripción activa Extended Life Cycle, Premium para una versión elegible.
¿Long-Life añade nuevas funciones a una versión antigua?
No. Su objetivo es mantener la seguridad, corregir errores prioritarios y proporcionar soporte técnico, no incorporar funciones ni compatibilidad general con hardware nuevo.
¿Puede sustituir a un plan de migración?
Puede dar más tiempo para preparar una actualización o mantener una carga excepcionalmente estable, pero no elimina la obsolescencia de aplicaciones, bibliotecas, hardware y productos de terceros.
vía: redhat
