La misma página, la misma tabla y la misma fila. El 12 de agosto ponía Q3 2026. El 4 de octubre ponía Q4 2026. Entre una captura y otra, el calendario de ciclo de vida de Zabbix movió cuatro casillas un trimestre entero, sin nota y sin anuncio, y sin que cambiara nada en tu servidor. Si en agosto apuntaste en algún sitio cuándo te tocaba actualizar la monitorización, lo que apuntaste ya no vale.
La fecha, que es a lo que has venido
Noviembre de 2026. Es lo que dice hoy la página de roadmap de Zabbix para la 8.0 LTS, y la tabla de ciclo de vida lo redondea a Q4 2026. No hay día publicado. La 8.0.0rc2 salió el 21 de octubre, veinte días después de la rc1, y la documentación de la rama 8.0 sigue etiquetada como «development version, it may be incomplete» mientras la 7.4 figura como «current». De hoy al 31 de diciembre quedan 66 días.
Y conviene decir lo otro en la misma frase: noviembre es el cuarto plan publicado. En esa misma página de roadmap, la fecha de la 8.0 LTS fue Q2 2026 en la captura del 20 de febrero, Q3 2026 en la del 5 de junio, septiembre de 2026 en la del 12 de agosto, y noviembre desde algún momento antes del 15 de octubre. Tres deslizamientos en ocho meses. Llegar tarde a una versión mayor es lo normal; lo que no lo es tanto es colgar de ahí una ventana de mantenimiento como si fuera firme.
Las cuatro casillas que se movieron
La comparación es literal y se puede repetir: dos capturas de zabbix.com/life_cycle_and_release_policy en el archivo de Internet, una del 12 de agosto de 2026 y otra del 4 de octubre. Entremedias Zabbix publicó notas de versión, claro, varias; lo que no hay en ninguna, ni en el blog del proyecto, es una línea que diga que el calendario se ha movido. Cambió la tabla y ya está.
Las tres primeras filas son la misma noticia contada tres veces: la 8.0 va un trimestre tarde respecto de la revisión anterior de esta página (y medio año respecto de la primera que publicó el roadmap), y arrastra consigo sus propios vencimientos de 2029 y 2031. La cuarta es la que te toca a ti. El fin de soporte de la 7.4 —una versión que ya está instalada y funcionando en producción— se movió porque se movió el de otra versión que todavía no existe. No tocaste nada y tu fecha cambió.
Y ese Q1 2027 tampoco es firme, por el mismo mecanismo. La política dice que el soporte limitado de una rama estándar dura «Minimum 6 months (until next Standard Release)», y la siguiente estándar es la 8.2, que esa misma tabla coloca en Q1 2027. De ahí sale el Q1 2027 de la 7.4: está copiado de la fila de abajo. Y la fila de abajo ya la desmiente el propio fabricante en la otra página, porque el roadmap da para la 8.2 septiembre de 2027. Dos páginas de Zabbix, dos fechas distintas para la versión de la que depende el último día de tu 7.4.
Lo decimos con la prueba más barata que tenemos a mano, que es nuestra. En julio escribimos en este mismo blog que el soporte limitado de la 7.4 llegaba «hasta el cuarto trimestre de 2026» y que la página de ciclo de vida situaba la 8.0 en «Q3 2026». Las dos frases eran correctas el día que se publicaron y ninguna lo es hoy. No nos equivocamos al copiar: copiamos bien una tabla que luego se movió. Es exactamente lo que le va a pasar a lo que apuntes tú esta tarde.
«until 8.0 LTS» no es una fecha
En la fila de la 7.4, la columna de fin de soporte completo no lleva un día ni un trimestre. Lleva esto, tal cual: until 8.0 LTS. Es una dependencia escrita en la casilla donde esperabas una fecha. El día que Zabbix publique la 8.0 —el que sea de noviembre, o de diciembre, o de más allá— la 7.4 deja de tener soporte completo. Ese día no lo decides tú, no lo sabes y no lo puedes poner en un calendario.
Y la misma página, unos párrafos más arriba, dice otra cosa sobre esa misma versión. La política de publicación establece que una versión estándar lleva «Full Support: 6 months». La 7.4 salió el 1 de julio de 2025. Van casi dieciséis meses. Las dos frases son ciertas y están en el mismo documento, pero no dicen lo mismo: una promete una duración, que sobre el papel venció hace casi diez meses, y la otra una dependencia de una fecha ajena. La que manda en la práctica es la segunda, y por un motivo incómodo: tu prórroga existe porque alguien va tarde. El día que deje de ir tarde, se acaba.
La versión más nueva se queda sin soporte antes que la vieja
Los números de la propia tabla, restados:
Quien en julio de 2025 se fue a la 7.4 porque era más nueva se compró, respecto de quien se quedó en la 7.0 LTS, unos siete meses menos de soporte completo y dos años y tres meses menos de soporte limitado. La versión más antigua aguanta hasta junio de 2029; la más moderna se queda sin nada en el primer trimestre de 2027. Es la diferencia entre una rama LTS y una estándar, escrita en la política y a la vista de cualquiera. Si lo tuyo es justamente la lista de funcionalidades, la repasamos en su día: qué cambia de verdad en Zabbix 8.0.
Sobre qué contiene cada ventana, la página es explícita para las ramas LTS: el soporte completo son «feature updates + security fixes» y el limitado, «critical fixes only». Para las estándar da las duraciones pero no describe el contenido. En cualquiera de las dos lecturas, el final de la ventana de la 7.4 es el mismo: Q1 2027 y a partir de ahí, nada.
Doce meses en preestreno y tres ramas parcheadas el mismo día
La rama abrió con la alpha1 el 30 de octubre de 2025 y llegó a la rc2 el 21 de octubre de 2026: once meses y veintidós días, con un hito por trimestre —las alphas y las betas las repasamos aquí en su momento— y veinte días entre las dos candidatas. Es una cadencia sana.
El 20 de octubre de 2026 salieron la 7.4.16, la 7.0.32 y la 6.0.49, las tres el mismo día. Tres ramas vivas recibiendo correcciones esa semana, y la más antigua de ellas es de febrero de 2022: la 6.0 LTS conserva soporte limitado hasta el 28 de febrero de 2027, apenas un mes antes de que se acabe el de la 7.4, que salió tres años y medio después. Hoy no hay incendio; hay una decisión de calendario, y las de calendario se toman mal con prisa.
Si lo instalaste del repositorio de tu distribución, lo tuyo no es una actualización
«Do not perform a direct upgrade, as this may result in a broken installation.» Con esa frase cierra la documentación de actualización por paquetes de la 8.0 el aviso sobre los paquetes de Zabbix que trae tu distribución. De ellos dice que «no están soportados por Zabbix y pueden estar desactualizados o no tener las últimas funcionalidades y correcciones», menciona en particular las basadas en Debian, y especifica que si vienes de ahí —o los tuviste instalados en algún momento— el procedimiento es desinstalar los paquetes viejos, buscar y eliminar los restos de la instalación anterior e instalar los oficiales.
Instalar Zabbix con un apt install del repositorio de Debian o Ubuntu fue, durante años, lo más razonable del mundo: estaba ahí, se actualizaba solo con el resto del sistema y funcionaba. Esa comodidad se cobra ahora, y no en horas de más: el plan deja de llamarse «actualización» y pasa a llamarse «reinstalación», con su propia ventana y su propia conversación con quien tiene que aprobarla.
Por si sirve para situarte antes de hacer cualquier plan, estas dos órdenes contestan de dónde salió lo que tienes:
# versión exacta del servidor
zabbix_server -V
# de qué repositorio vino el paquete (Debian/Ubuntu)
apt policy zabbix-server-mysql
# lo mismo en RHEL y derivados
dnf list installed 'zabbix*'La ventana en la que no ves nada
El procedimiento oficial empieza parando el servidor «para asegurarse de que no entran datos nuevos en la base» y el segundo paso es copiar la base de datos. Sobre lo que viene después, la documentación dice esto: «Depending on the database size, the database upgrade to version 8.0 may take a long time». La migración dura lo que de largo sea tu histórico, y el único número que te dice cuánto es el que tardó tu última restauración de prueba.
Y ahí está el problema que no tiene ninguna otra actualización. La monitorización es la pieza que te avisa de que lo demás se ha roto. Mientras la actualizas, está parada. Durante ese rato —el que dure la migración del esquema, que no sabes de antemano— tu parque entero funciona igual que si nadie lo estuviera mirando, porque nadie lo está mirando. Si algo se cae a mitad, te enteras cuando llame alguien.
Aquí somos aburridos a propósito. No se toca al vigilante sin haber restaurado la copia de la base en otro sitio, no sólo haberla hecho —un backup sin probar no es un backup, es un amuleto—, sin tener medido cuánto tardó esa restauración, que es la duración real de tu ventana ciega, y sin algo que vigile por fuera mientras tanto. Nosotros mantenemos SmokePing al lado de Zabbix, y nos sirve también para esto: cuando uno está parado, el otro sigue midiendo. Si el ruido es tu problema antes que el calendario, de eso va la monitorización que sí avisa. Esa es la parte que cubrimos en soporte IT 24/7: alguien despierto mirando algo que no es el sistema que está apagado.
Cuándo NO saltar a la 8.0
El día uno, no. La rc2 es de hace cinco días. Una .0 de cualquier plataforma pasa sus primeras semanas descubriendo lo que no salió en las pruebas, y una monitorización no es el sitio donde quieres descubrirlo con ella. Nosotros no metemos una x.0 en producción en las primeras semanas salvo que haya un motivo concreto que lo justifique, y «es la nueva» no es un motivo concreto.
- Si estás en 7.0 LTS y nada de la lista de la 8.0 te mueve la aguja: tienes soporte completo hasta el 30 de junio de 2027. No hay prisa, no la fabriques. Ir ahora te compra funcionalidades que a lo mejor no necesitas y una migración de esquema que seguro que no.
- Si estás en 7.4: aquí no tienes el lujo de esperar mucho. Tu ventana de soporte completo se cierra con la publicación de la 8.0 y la limitada se acaba en Q1 2027. El plan se hace ahora, aunque la ejecución sea en enero.
- Si tu instalación vino del repositorio de la distribución, ya sabes que lo tuyo es una reinstalación. Necesita su propia ventana y su propia prueba previa, y no cabe en la misma noche que lo demás.
Las cinco líneas que pedimos antes de tocar una monitorización
Esto es lo que necesitamos saber de una plataforma de monitorización antes de plantear nada. Ninguna entrada es brillante; todas son la diferencia entre enterarte en agosto y enterarte en enero.
- Versión exacta y de dónde salió el paquete. No «Zabbix 7», sino 7.4.16 y repositorio oficial o de la distribución. Es la diferencia entre una actualización y una reinstalación.
- Si su fila del calendario del fabricante es una fecha o una dependencia. Si pone «hasta que salga X», no es una fecha: es un riesgo con dueño ajeno, y va anotado como tal.
- Tamaño del histórico y duración de la última restauración de prueba. Ese segundo número es la duración real de la ventana en que no ves nada. Si nadie lo ha medido, no existe.
- Qué vigila a la monitorización mientras está parada, y quién mira ese algo. Las dos mitades: la sonda y la persona. Una sonda que nadie mira es decoración.
- La fecha en que alguien vuelve a leer la página de ciclo de vida del fabricante. Trimestral, y con nombre y apellidos de quien la lee.
Dónde encaja esto en lo que hacemos
Llevamos monitorización ajena con Zabbix y SmokePing, y la parte menos lucida del trabajo es exactamente esta: saber qué versión corre en cada sitio, de dónde salió el paquete y qué día deja de recibir parches. Eso es mantenimiento informático en el sentido literal de la palabra, y cuando además tienes que justificar ante alguien que tus sistemas reciben correcciones de seguridad, se llama cumplimiento y continuidad: un sistema fuera de soporte es un hallazgo en cualquier auditoría, y la fecha en que lo será no la fija tu calendario. Si quieres que miremos contigo qué versión tienes y qué ventana te queda de verdad, hablamos.
Fuentes. Todo lo de aquí se puede comprobar en el origen. El calendario: Zabbix Life Cycle & Release Policy, consultada el 26 de octubre de 2026, de donde salen las filas de 8.0 LTS (Q4 2026 / Q4 2029 / Q4 2031), 7.4 (1 de julio de 2025, until 8.0 LTS, Q1 2027) y 7.0 LTS (4 de junio de 2024, 30 de junio de 2027, 30 de junio de 2029), más las definiciones de la política: estándar cada 6 meses con 12 de soporte (Full Support: 6 months), LTS cada 1,5 años con 5 de soporte (Full Support: 3 years — feature updates + security fixes; Limited Support: 2 years — critical fixes only). El movimiento de las cuatro casillas: capturas de esa misma página en el Internet Archive del 12 de agosto de 2026 (8.0 LTS en Q3 2026 / Q3 2029 / Q3 2031 y 7.4 con soporte limitado hasta Q4 2026) y del 4 de octubre de 2026 (ya con los valores actuales). La captura del 28 de junio de 2026 coincide con la de agosto. La fecha de noviembre y sus tres predecesoras: roadmap oficial, que hoy da «November 2026» para 8.0 LTS y, después, septiembre de 2027 para 8.2, marzo de 2028 para 8.4 y septiembre de 2028 para 9.0 LTS. Las fechas anteriores salen de capturas de esa misma página en el Internet Archive: «Q2 2026» el 20 de febrero de 2026, «Q3 2026» el 5 de junio y «September 2026» el 12 de agosto; el 15 de octubre ya ponía noviembre. La discrepancia de la 8.2: la tabla de ciclo de vida la sitúa en Q1 2027 (misma casilla en las capturas de junio, agosto y octubre) mientras el roadmap da septiembre de 2027; de esa casilla de la 8.2 cuelga, vía «Minimum 6 months (until next Standard Release)», el Q1 2027 de la 7.4. Nuestro propio error de julio —«hasta el cuarto trimestre de 2026» y «Q3 2026»— está en el post enlazado más arriba, publicado el 30 de julio de 2026, y se mantiene sin reescribir a propósito. Las versiones y sus fechas: notas de versión — 8.0.0alpha1 el 30 de octubre de 2025, alpha2 el 19 de febrero de 2026, beta1 el 22 de mayo, beta2 el 9 de julio, rc1 el 1 de octubre y rc2 el 21 de octubre; 7.4.16, 7.0.32 y 6.0.49 el 20 de octubre de 2026; la fila de 6.0 LTS (8 de febrero de 2022) da fin de soporte completo el 28 de febrero de 2025 y limitado el 28 de febrero de 2027. La actualización: manual de actualización a 8.0 (de donde sale la frase sobre la duración de la migración de la base), la página de actualización por paquetes (paquetes de la distribución no soportados y «Do not perform a direct upgrade…») y la de Debian/Ubuntu, con los ocho pasos del procedimiento. El etiquetado «development version» de la rama 8.0 frente a «current» de la 7.4 es el del selector de versiones de esas mismas páginas. Lo nuestro: que operamos Zabbix y SmokePing, y la regla de no tocar la monitorización sin una restauración probada, es nuestra forma de trabajar, no una recomendación del fabricante. Los 66 días son del 26 de octubre al 31 de diciembre de 2026, y las comparaciones de meses entre 7.0 LTS y 7.4 salen de restar las fechas de la tabla asumiendo que la 8.0 sale en noviembre; si vuelve a moverse, la resta cambia, que es justamente el argumento del artículo. Foto: «312 Adelaide Street - 6th floor server room» de Mike Beltzner, Wikimedia Commons, CC BY-SA 2.0.
Microsoft 365
ES 
CAT 
EN