A sysadmin leaves, an IT manager inherits a Zimbra box nobody has logged into in years, and the first thing they find is a version number that stopped receiving fixes a while ago. If your Zimbra 9 end of life question is really "how exposed are we right now", the answer is more than you would like, and the upgrade is less dramatic than you are bracing for.
An inherited estate is rarely broken in a way anyone can see. It is a working installation on a version that has quietly gone unsupported, still delivering mail, still holding years of correspondence, and no longer receiving the patches that matter, which is the kind of Zimbra mail server CloudSpinx runs and rescues for organizations across Kenya and East Africa.
Which versions are actually dead
Zimbra's own release table is unambiguous, so start there rather than with a vendor's sales pitch.
Version 8.8.15, the long-term support release, lost technical guidance on 31 December 2024. Version 9.0 followed on 30 June 2025, and 10.0.x reached end of general support on the same day. The current line is 10.1, which went GA in July 2024 and is at patch 10.1.21.
"End of support" does not mean the software stops. That is exactly the problem. A Zimbra 8.8.15 server will keep delivering mail for years, which is why so many are still out there, and the failure mode is not an outage but a breach nobody notices for months.
The security picture, in numbers you can check
This is the part that changes the conversation with a board.
CISA maintains a catalog of vulnerabilities it has confirmed are being exploited in the wild, not theoretical ones. It holds 19 Zimbra entries. Seven were added in 2022, two in 2023, one in 2024, four in 2025 and five during 2026. The oldest CVE still listed is CVE-2018-6882.
Read that distribution again. Zimbra is not a product with a historical security problem that got cleaned up. It is a product attackers are working on now, and five confirmed-exploited additions in 2026 alone is a live rate. Anyone can verify this against the CISA catalog rather than taking our word for it.
Mail servers are also the worst possible thing to run unpatched, because they are internet-facing by definition, they authenticate your entire staff, and they hold the archive an attacker most wants. A compromised mail server is not one incident, it is the credential source for the next several.
Your three realistic options
Upgrade in place to 10.1. On a healthy server already on 9.0 or 10.0, this is the right answer and it is not dramatic. Zimbra's upgrade guide covers it, a Network Edition license is required for 10.x, and the job needs a tested backup and a maintenance window rather than a rebuild.
Rebuild onto a new server and migrate the data. From 8.8.15 this is usually cleaner than an in-place chain, and it is what we recommend when the underlying OS is also out of support. You get a current operating system, a current Zimbra, and a rehearsed cutover instead of an upgrade that has to succeed on the first attempt on a production box.
Leave Zimbra. Sometimes honest. If you are below the crossover with no data-residency requirement, the hosted suites will cost less than the rescue plus the ongoing administration, and we will tell you so. The arithmetic for where that line falls is in what a Zimbra server costs against Microsoft 365.
The option that is not on the list is staying where you are. An unpatched mail server is not a deferred cost, it is an accumulating one.
The thing that makes these upgrades go wrong
Nobody proved the backup could be restored before they started. That is the failure.
Zimbra's own backup tooling in Network Edition is decent. What is usually missing is a restore that somebody has actually performed onto different hardware, with the mail checked afterwards. A backup you have never restored is a belief, not a control, and an upgrade is precisely the moment that belief gets tested. Take the snapshot, restore it somewhere else, open a mailbox, then start.
The other way it goes wrong is a server that was already compromised before the upgrade began. Upgrading a breached box carries the intrusion forward into the clean version, which is why our security work on an inherited estate starts with looking for that rather than assuming it away.
Start with three commands and a browser
On a server you have just taken over, establish what is actually installed before anyone plans an upgrade around what somebody remembers:
su - zimbra -c 'zmcontrol -v'
cat /etc/os-release
su - zimbra -c 'zmprov gaaa'The first prints the exact release and patch level to hold against Zimbra's table. The second says whether the operating system underneath is still supported, and if it is not, the rebuild path above has chosen itself. The third lists every admin account, and any that belong to people who have left get disabled today.
Then open https://mail.example.co.ke:7071/ from a phone on mobile data. That is the admin console's default port, and if the login page loads from the public internet, close it at the firewall before you do anything else, because the console is exactly what the exploited flaws are aimed at. Only after that comes the restore test, then SPF, DKIM, DMARC and the PTR record (a rescued server that lands in spam has not been rescued), and then a search of the logs and webmail directories for the artifacts of the catalog entries above.
If that reads like a week you do not have, that is what our managed IT engagements cover, and we would rather do the audit before an incident than the forensics after one.
Send us the version number and the mailbox count and we will tell you which of the three paths fits, at no cost and with no obligation, through the scoping form or on WhatsApp at +254 713 403 044.