The call usually comes from someone who has just been handed the server. A sysadmin leaves, an IT manager inherits a Zimbra box nobody has logged into for two 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.
CloudSpinx runs and rescues Zimbra mail servers for organisations across Kenya and East Africa, and the estates we are called into are almost never greenfield. They are working installations on versions that have quietly gone unsupported, still delivering mail, still holding a decade of correspondence, and no longer receiving the patches that matter.
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 release a great many Kenyan estates still run, lost technical guidance on 31 December 2024. Version 9.0 followed on 30 June 2025. Version 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 now sits at patch level 10.1.20.
"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 catalogue of vulnerabilities it has confirmed are being exploited in the wild, not theoretical ones. As of catalogue version 2026.08.11 it holds 18 Zimbra entries. Seven were added in 2022, two in 2023, one in 2024, four in 2025 and four more during 2026. The oldest 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 that attackers are actively working on right now, and four new confirmed-exploited flaws in the current year is a live rate. Anyone can verify this against the CISA catalogue 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. For most organisations already on 9.0 or 10.0 with a healthy server, this is the right answer and it is not dramatic. The path from 9.0 goes through 10.0 before 10.1, so it is a staged upgrade rather than a single jump, and it 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, which it very often is. 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 under about 50 mailboxes with no data-residency requirement, the hosted suites will cost less than the rescue plus the ongoing administration, and we will tell you so. We covered where that line falls 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
Almost every failed Zimbra upgrade we have been called in to fix failed for the same reason: nobody proved the backup could be restored before they started.
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 second most common cause 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.
What we check first on a Zimbra box we have just inherited
Run these in order on any server you have just taken responsibility for. The whole pass takes an afternoon and it decides everything else.
Confirm the exact version and patch level, not the version somebody remembers. Check the operating system underneath is still supported, because it frequently is not. Look at whether the admin console is reachable from the public internet, which it should not be. Verify the last successful backup and then restore it somewhere else. Check SPF, DKIM, DMARC and the PTR record actually resolve correctly, because a rescued server that lands in spam has not been rescued. Search the logs and the webmail directories for the artefacts of the known exploited flaws, since a server that sat unpatched through 2025 has been scanned many times. Finally, list every account with admin rights and remove the ones belonging to people who left.
If that list 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. The scoping form takes two minutes, or reach us on WhatsApp at +254 713 403 044.