--- title: "OpenShift 5 alarga el soporte: 24 meses por versión y hasta 5 años con ELC" description: "Red Hat amplía en OpenShift 5 el soporte estándar de 18 a 24 meses, sustituye EUS por versiones ELC con hasta cinco años de soporte y prepara actualizaciones que saltan versiones con un solo reinicio." url: https://revistacloud.com/openshift-5-ciclo-de-vida-soporte-24-meses-elc-cinco-anos/ date: 2026-11-10 modified: 2026-11-10 author: "Antonio" image: https://revistacloud.com/wp-content/uploads/2026/11/openshift-5-ciclo-de-vida-soporte-elc.png categories: ["Cloud", "Tecnología"] tags: ["contenedores", "Kubernetes", "OpenShift", "red hat", "virtualización"] type: post lang: es --- # OpenShift 5 alarga el soporte: 24 meses por versión y hasta 5 años con ELC **Red Hat ha cambiado el ciclo de vida de OpenShift con la versión 5 de su plataforma de contenedores basada en Kubernetes. Cada versión tendrá 24 meses de soporte estándar, frente a los 18 de hasta ahora, y una de cada tres, a partir de la 5.2, será una versión de ciclo de vida extendido (ELC) con hasta tres años adicionales, cinco en total. Lo explican Aubrey Muhlach y Daniel Messer, responsables de marketing y gestión de producto de OpenShift, en un artículo publicado en el blog de Red Hat.** **Las claves del nuevo ciclo de vida de OpenShift 5 en 30 segundos** - El soporte estándar de cada versión pasa de 18 a 24 meses desde OpenShift 5.0. - Las versiones ELC, una de cada tres desde la 5.2, suman hasta cinco años de soporte. - Las ELC saldrán siempre entre junio y septiembre y sustituyen a las EUS. - Llegan actualizaciones que saltan versiones con un solo reinicio y comprobaciones previas con IA. El anuncio complementa el [lanzamiento de OpenShift 5](https://revistacloud.com/red-hat-lanza-openshift-5-con-inteligencia-artificial-integrada-y-nuevas-funciones-de-ciberseguridad/), centrado en el agente OpenShift Lightspeed, la seguridad de confianza cero y la criptografía poscuántica. Aquí el foco es otro, menos vistoso pero muy relevante para quien opera clústeres en producción: cuánto tiempo se puede quedar uno en una versión y cuánto cuesta moverse a la siguiente. Red Hat resume su prioridad como estabilidad de la plataforma y previsibilidad a largo plazo. ## Versiones ELC en lugar de EUS En OpenShift 4, las empresas que querían quedarse más tiempo en una versión recurrían a las versiones con soporte de actualización extendido (EUS). OpenShift 5 las sustituye por las ELC, que llegan en una de cada tres versiones empezando por la 5.2 y suman hasta tres años de soporte extendido a los dos estándar. Red Hat se compromete además a publicarlas siempre entre junio y septiembre de cada año, lo que permite planificar con antelación los saltos de una ELC a la siguiente. El artículo no detalla todavía fechas concretas. El cambio no afecta solo al núcleo. Advanced Cluster Management, Quay, OpenShift Data Foundation y OpenShift Virtualization seguirán el mismo ciclo de vida que la plataforma, ELC incluidas, y Advanced Cluster Security pasa a alinearse con ella desde la 5.0. Otros componentes, como Logging, GitOps, Pipelines, Service Mesh, la observabilidad, el operador de cert-manager o las API de protección de datos, tendrán versiones alineadas con cada ELC. Según Red Hat, un despliegue con OpenShift y estos complementos podrá quedarse en la misma versión hasta cinco años, recibiendo solo parches de seguridad y correcciones. ## Actualizaciones con un solo reinicio La otra mitad del anuncio son las actualizaciones. Red Hat prevé en OpenShift 5 actualizaciones de salto entre versiones ELC que solo requieren un reinicio del plano de control y de los nodos de trabajo, en lugar de encadenar varias versiones intermedias. Las actualizaciones mayores, menores y de parche seguirán el mismo procedimiento en el sitio, incluido el paso de OpenShift 4 a 5, algo que hasta ahora solía exigir migraciones más laboriosas entre generaciones de la plataforma. Antes de actualizar, un agente conectado a un modelo de lenguaje ejecutará comprobaciones en segundo plano cuando haya una versión disponible, detectará riesgos y estados problemáticos conocidos y generará un plan de actualización. Para quien no quiera depender de IA, habrá también comprobaciones previas específicas de cada versión que funcionan sin modelos. Según los autores, actualizar la plataforma debería ser un proceso regular y previsible, no un acontecimiento disruptivo. Para los equipos de sistemas, el cambio acerca OpenShift a los ciclos de vida largos que ya conocen de las distribuciones Linux empresariales, algo especialmente útil en entornos regulados o en aplicaciones críticas que hay que recertificar con cada cambio de versión. También pesa en las decisiones de quienes están replanteando su virtualización tras los cambios de VMware y comparan OpenShift Virtualization con otras alternativas como las que repasamos en nuestra [guía de migración a Proxmox](https://revistacloud.com/migracion-proxmox/). ## Preguntas frecuentes ### ¿Cuánto soporte tiene cada versión de OpenShift 5? 24 meses de soporte estándar, frente a los 18 de OpenShift 4. Las versiones ELC suman hasta tres años más, cinco en total. ### ¿Qué son las versiones ELC? Versiones de ciclo de vida extendido que sustituyen a las EUS. Habrá una de cada tres a partir de OpenShift 5.2, publicadas siempre entre junio y septiembre. ### ¿Se puede actualizar de OpenShift 4 a 5 sin migrar? Sí. Según Red Hat, el paso de 4 a 5 sigue el mismo procedimiento de actualización en el sitio que el resto de versiones. **Fuentes:** - [Red Hat: Red Hat OpenShift 5 delivers innovation and predictability for the long haul](https://www.redhat.com/en/blog/predictability-red-hat-openshift-5)