A Zimbra server can be running perfectly and still not really be yours. The licence key decides that, and it is the artefact least likely to surface when a handover starts. Not the invoice. The key.
Zimbra consultants in Kenya inherit far more servers than they build. The estate is ten years old, the engineer who installed it moved on twice, and the handover was a password written on the back of a delivery note. CloudSpinx takes over Zimbra mail servers other people set up, for businesses, schools and public bodies in Kenya and across East Africa, and the first hour on a new one always goes the same way: work out what the client actually owns.
Usually less than they think.
Zimbra consultants, resellers and the licence in between
Three different suppliers describe themselves the same way. A reseller sells you the licence and renews it once a year. An engineer runs the platform: the operating system, the patch cycle, storage, backups, whether your mail lands in inboxes. A helpdesk fixes Outlook profiles and resets passwords. All three will say they support Zimbra, and in Kenya you are frequently buying one of them while believing you bought all three.
The licence matters more than the invoice suggests. Since version 9 the official builds have sat behind a Network Edition key, and Zimbra's download page is blunt about the current line: a new v10.1 license key is required to run Zimbra Daffodil.
The source stays open, which is where the free edition confusion comes from. The build does not.
- the only path that ends patched
- the patch never arrives
Moving from 10.0 to 10.1 needs a new key rather than the one already on the server, which is where a lapsed reseller relationship stops being a paperwork problem and becomes a stalled upgrade.
"Technical guidance" is not the same as being supported
Zimbra's lifecycle has two phases and they get conflated constantly. General support ships security fixes. Technical guidance, the phase after it, explicitly does not: the policy says there will be no new releases, bug fixes or security patches, only somebody left to talk to. The 10.1 line holds general support until the end of 2027. Everything before it has already left.
Which means "we support your Zimbra" can be a true statement from a supplier who has not applied a patch in two years, because none exist for the version you are on. Ask which phase your release sits in and the date it ends. A consultant who cannot answer that from memory is not tracking it, and the versions that are actually dead are not an obscure detail.
Four things that must be in your organisation's name
Competence is the easy half to assess. Continuity is the half that costs money, and it comes down to four artefacts. Every one of them is routinely registered to the supplier because that was quicker on the day.
Ask for all four at the start of an engagement, when they are a formality. Asked for at the end, they are leverage, and the person holding them knows it.
The backup is where this turns from irritating into serious. Files on an external drive in somebody's office are a copy. A restore needs the same Zimbra version standing up somewhere, the tooling that wrote the backup, and a person who has done it before on that data. Until all three exist at once you have storage, not a backup, and you find out which on the morning you need it.
Insisting on the test costs you an afternoon. One mailbox, restored from last night into a scratch account, while you watch. You learn whether a backup ran, whether anybody has ever tested one, and how much mail you would actually lose. A Zimbra expert treats that as an ordinary Tuesday. A licence reseller finds reasons.
What Zimbra support in Kenya should actually cover
A support arrangement worth paying for names the patch window and holds to it, and tests a restore on a schedule rather than after an incident. It also watches deliverability. SPF, DKIM, DMARC and the reverse DNS record all drift, and a mail server nobody will accept mail from is down in every sense the business cares about. Out of hours matters here too. Mail breaks at 6am, before anyone is in the office, and when the server sits in a Nairobi rack rather than a cloud console, somebody has to be able to physically reach it.
The honest part, which is also the part that decides whether we take the work: below roughly 50 mailboxes with no requirement to keep data in the country, self-hosting is the wrong purchase. A hosted suite costs less than the attention a mail server needs, and we will tell you that before quoting rather than after. Above that, or where a regulator or a contract fixes where the mail sits, running your own starts making sense and the supplier question becomes the real one.
When the right answer is to keep the consultant you have
Most of these reviews should not end with a new supplier, and most do not. If the version is still in general support, the key is registered to your organisation and somebody can restore a mailbox on request, the arrangement works. What is missing is only that nobody ever wrote down who holds what. Replacing that costs you years of accumulated knowledge about your own mail flow, and you rarely get it back.
The time to move is when the answers do not come back at all. A supplier who cannot produce the key, cannot name the date support ends on your version and has never tested a restore is not running your mail server. They are renewing a licence next to it, and what that leaves exposed is the whole mailbox history of the organisation.
If you would rather have the audit done than run the interview yourself, send us the version number, the mailbox count and who currently holds the key. We will come back with what it takes to bring the server current and what running it costs, free and with nothing to sign: the scoping form takes two minutes, or WhatsApp us on +254 713 403 044.