Zimbra 9 is no longer a supported destination for a production mail platform. As of October 2026, Zimbra 9.0 has reached end of life, Zimbra 10.0 has also passed its support window, and the active Daffodil branch is Zimbra 10.1. For that reason, a current Zimbra 9 upgrade plan should normally target a supported Zimbra 10.1 release rather than stop at 10.0. At the time of writing, Zimbra 10.1.21 was released on September 24, 2026. Check the official Zimbra 10.1.21 release notes before scheduling production work because patch requirements and known issues can change.
The upgrade itself can be straightforward on a standard installation, but the right method depends on your operating system, topology, NG modules, custom authentication, licensing, and tolerance for downtime. This guide focuses on those choices as much as the commands, so you can select a path that fits the environment rather than forcing every deployment through the same procedure.
| Approach | Advantages | Trade-offs | Best fit |
|---|---|---|---|
| In-place upgrade | Keeps the existing server identity, data paths, and most configuration in place. Official Zimbra documentation supports in-place upgrades for single-node and multi-node deployments. | Requires a maintenance window and leaves less room to redesign an old operating system or storage layout. | A healthy, supported OS with a conventional Zimbra 9 configuration. |
| Rolling multi-server upgrade | Can reduce broad service interruption by upgrading roles in a controlled order. | More coordination is required. Mixed-version mailstore behavior and proxy login-server configuration need extra attention. | Larger multi-node environments where service continuity matters. |
| Fresh Zimbra 10.1 installation plus migration | Lets you move to a newer supported OS, new storage, or redesigned topology without carrying every legacy dependency forward. | Needs migration planning, temporary capacity, DNS/cutover work, and more validation. | Older operating systems, major hardware refreshes, substantial customizations, or deployments you do not want to upgrade in place. |
Zimbra's current documentation lists in-place and rolling upgrade paths, including environments with NG modules, but it directs NG-module users to the dedicated migration resources. If the installer detects NG modules, do not casually bypass that check: the installer warns that continuing can remove NG packages and associated data. Review the official Daffodil upgrade instructions and the applicable NG migration guide first.
Start by establishing a baseline. Log in as the zimbra user and record the installed release plus current service state:
su - zimbra
zmcontrol -v
zmcontrol status
If services are already failing, resolve that problem before the major upgrade. An upgrade is a poor time to discover that LDAP, mailbox, MTA, or proxy problems predate the maintenance window. Also inventory custom Zimlets, external authentication, integrations, certificates, relay rules, scripts, and any local changes under /opt/zimbra.
Zimbra specifically calls out zmdbintegrityreport as a useful pre-upgrade check because pre-existing MariaDB corruption can become more difficult to diagnose during a major-version change. Run it as the zimbra user on store nodes:
su - zimbra
zmdbintegrityreport
Zimbra notes that this report can take from minutes to an hour depending on database size and storage performance. Do not schedule it at the last minute on a large mailstore.
Next, make a full, restorable backup using the backup method appropriate to your edition and environment. A backup is only useful if you know where it is, it completed successfully, and you have a practical restore plan. Zimbra recommends a full backup before major upgrade work and another full backup after the upgrade because database schema changes may occur.
Also back up SAML and SPNEGO customizations separately. Zimbra warns that those customizations can be overwritten during the upgrade. If you depend on custom salocal.cf.in, custom SpamAssassin rules, or other locally maintained files, compare current release notes for files that may be replaced and save copies before starting.
A single-server installation can move directly to the installer after prechecks. Multi-server deployments need ordering discipline. Zimbra's documented sequence is LDAP master first, then LDAP replicas, MTA servers, proxy servers, License Daemon Service, OnlyOffice server, and finally mailstore servers.
LDAP masters must be upgraded and running before you proceed to the other roles. During rolling upgrades, Zimbra also warns that when Zimbra 10 and older mailstores coexist, zimbraReverseProxyUpstreamLoginServers should contain only Zimbra 10 mailbox servers; otherwise, users on Zimbra 10 mailstores can encounter Modern Web App login problems.
No dé por sentado que el sistema operativo de un servidor Zimbra 9 seguirá siendo compatible en 2026. La documentación actual de Zimbra muestra plataformas compatibles más recientes, como RHEL/Rocky/Oracle Linux 9 y Ubuntu 22.04, mientras que la compatibilidad con Ubuntu 24.04 se generalizó con Zimbra 10.1.17. Las notas de la versión 10.1.21 de Zimbra también indican que la compatibilidad con Ubuntu 18.04 se dejará de ofrecer a partir de la próxima versión. Si su servidor Zimbra 9 utiliza una plataforma antigua, una instalación limpia y una migración podrían ser más convenientes que combinar un cambio importante en Zimbra con una transición del sistema operativo.
Confirma el espacio de almacenamiento disponible antes de ejecutar el instalador. El instalador de Zimbra comprueba el espacio disponible y se detiene si el sistema no dispone de suficiente.
Zimbra 10.1 también modificó su sistema de licencias. El license.xmlformato anterior ya no es compatible con la versión 10.1. Necesitará la nueva clave de licencia alfanumérica de 18 a 26 caracteres antes de la instalación o actualización. Obtenga la clave correcta de Zimbra antes del período de mantenimiento. La página oficial de descargas de Zimbra advierte explícitamente a los usuarios que deben contar con la nueva licencia v10.1 antes de comenzar.
Descargue el paquete que coincida con su sistema operativo y arquitectura de CPU compatibles desde el área de descargas oficial de Zimbra. No reutilice un paquete creado para otra distribución. Mantenga el archivo en un directorio de trabajo como /var/tmp.
Si Zimbra publica una suma de verificación para el paquete que descarga, verifíquela antes de extraer el archivo. Un cálculo de suma de verificación local se ve así:
sha256sum zcs.tgz
La suma de verificación que se muestra en la ilustración no es la suma de verificación de la versión. Utilice únicamente la suma de verificación proporcionada para su paquete.
El proceso documentado de Zimbra no requiere que detenga los servicios manualmente antes de la actualización. El instalador detiene e inicia los servicios según sea necesario. Como root, extraiga el archivo descargado, ingrese al directorio expandido y ejecute install.sh:
cd /var/tmp
tar xzvf zcs.tgz
cd <expanded-directory>
./install.sh
Zimbra recomienda ejecutar la actualización dentro de un multiplexor de terminal como screen, especialmente en sesiones SSH remotas, para que una conexión perdida no termine una actualización larga:
screen ./install.sh
El instalador detecta la instalación existente de Zimbra y presenta la ruta de actualización. Las instrucciones actuales de Zimbra indican que, cuando se le solicite, acepte el uso del repositorio de paquetes de Zimbra y, a continuación, confirme que desea actualizar. En una actualización a la versión 10.1 de un solo nodo, el zimbra-license-daemonpaquete es obligatorio; rechazarlo impide que la actualización continúe.
Antes de responder a la última pregunta, revise la lista de paquetes. En The system will be modified. Continue? [N], ingrese Ysolo cuando esté seguro de que las copias de seguridad, la licencia, el origen de los paquetes, el almacenamiento y las comunicaciones de mantenimiento están configurados correctamente. El instalador detiene los servicios antiguos, reemplaza los paquetes, restaura la configuración, realiza la actualización y reinicia los servicios. Los entornos grandes pueden tardar considerablemente más que los sistemas de prueba pequeños.
Si utiliza una licencia sin conexión/manual, siga la ruta de activación específica que se indica en la guía de actualización actual de Zimbra. No copie las instrucciones para licencias en línea en un entorno sin conexión. Asimismo, la guía para nodos de buzones difiere cuando se trata de comprobaciones de activación, por lo que debe utilizar la documentación específica de la versión en lugar de un comando antiguo copiado de una versión anterior.
Una vez finalizada la instalación, vuelva al zimbrausuario y compruebe el estado del servicio y la versión instalada:
su - zimbra
zmcontrol status
zmcontrol -v
A continuación, pruebe el comportamiento del que realmente dependen los usuarios: SMTP entrante y saliente, entrega interna, IMAP/POP si está habilitado, inicios de sesión en aplicaciones web modernas y clásicas, buzones de correo delegados, operaciones de calendario, sincronización móvil, conectividad con Outlook si tiene licencia, autenticación externa, Zimlets, copias de seguridad, supervisión y cualquier aplicación que utilice las interfaces Zimbra SOAP o EWS.
No omita las acciones posteriores a la actualización específicas de la versión. Las notas de la versión de Zimbra 10.1.19 y posteriores mencionan una mitigación SNMP actualizada para los clientes que actualizan desde 10.0.x, 9.0.x u 8.8.15. Para una actualización de producción en 2026, lea las notas de parche actuales y aplique cualquier mitigación necesaria después de la actualización principal. Zimbra 10.1.21 también incluye correcciones de seguridad que afectan al cliente web clásico, la autenticación WebDAV, la recuperación de contraseñas, OpenJDK, NGINX y las integraciones, lo que es otra razón para no quedarse con una compilación 10.0 obsoleta.
Una actualización in situ resulta atractiva porque implica menos cambios, pero no es automáticamente la opción de menor riesgo. Reconsidere el plan si se da alguna de estas condiciones:
En esos casos, un entorno Zimbra 10.1 paralelo con una migración controlada puede requerir más preparación, pero ofrece límites de reversión más claros y una mejor oportunidad para modernizar la plataforma subyacente.
zmdbintegrityreporten los nodos de la tienda y solucionar errores.license.xml.screenuna sesión de terminal persistente equivalente.Para un servidor Zimbra 9 en buen estado, con un sistema operativo compatible y configuración convencional, la actualización in situ a la rama Zimbra 10.1 Daffodil suele ser la opción más directa. En el caso de un sistema operativo antiguo, una implementación compleja de módulos NG o un servidor que requiera cambios importantes en la infraestructura, una instalación y migración nuevas pueden ofrecer un entorno operativo más limpio, aunque impliquen más trabajo.
La comprobación de calidad clave no se limita a si el proceso install.shllega a su fin. Una actualización exitosa implica que el servidor cuenta con un parche 10.1 compatible, todos los servicios necesarios funcionan correctamente, el flujo de correo y el acceso de los usuarios operan según lo previsto, las integraciones personalizadas se han vuelto a probar, la licencia está activa, las medidas de mitigación específicas de la versión se han implementado y se dispone de una copia de seguridad reciente posterior a la actualización. Durante la planificación, es importante tener a mano la guía oficial de actualización de Zimbra Daffodil , las notas de la versión 10.1.21 y la documentación oficial para servidores múltiples , ya que estas fuentes deben tener prioridad sobre los fragmentos de comandos antiguos.
Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
