Migrer de Zimbra vers Oworks, étape par étape

Ce qu'Oworks fait de votre Zimbra

Oworks n'est pas un concurrent de Zimbra. La page Produit liste les briques de la suite, et Zimbra y figure comme serveur de « messagerie, agenda, contacts » :

Carbonio en webmail ; Zimbra pour la messagerie, l'agenda et les contacts (IMAP, SMTP, CalDAV, CardDAV) ; Postfix et Rspamd pour l'acheminement et le filtrage (MTA-STS, SPF, DKIM, DMARC) ; Matrix et Element pour la discussion ; Meet pour les réunions ; OpenCloud et OnlyOffice pour les fichiers et les documents ; Keycloak pour l'identité (OIDC, SAML, LDAP). La sauvegarde est annoncée « à préciser ».

Le projet n'est donc pas « sortir de Zimbra » mais sortir d'un Zimbra isolé : une instance seule, souvent ancienne, administrée par un seul écran, sans discussion, sans visioconférence, sans fichiers, sans délégation entre entités. La page États et administrations formule la bascule ainsi : « Oworks et votre Zimbra partagent le même domaine ; les comptes basculent à votre rythme, ou Oworks reprend vos instances. » Deux chemins sans rapport l'un avec l'autre. Reprendre l'existant ou migrer vers une plateforme neuve : c'est l'inventaire qui tranche.

Une précision sur Carbonio, développé par l'éditeur italien Zextras. Celui-ci le présente comme « a separate, modern platform built by Zextras — not a Zimbra fork ». Il le conçoit comme « a migration path for organizations moving off Zimbra » (zextras.com/carbonio). Dans Oworks, les deux cohabitent : Carbonio en interface, Zimbra en serveur.

Pourquoi un Zimbra isolé finit par poser problème

Le support s'arrête, les correctifs aussi. Les dates sont publiques, sur la page Zimbra Releases : 8.8.15 LTS, end of technical guidance au 31/12/2024 ; 9.0.0, end of technical guidance au 30/06/2025 ; 10.0.0, end of general support au 30/06/2025. Seule la branche 10.1 (Daffodil, GA 16/07/2024) n'a pas de date de fin. En 8.8.15, le cas le plus fréquent dans les administrations, vous exploitez depuis près de deux ans une version qui ne reçoit plus rien.

Ce que ça veut dire. La page Zimbra Security Advisories liste, pour les seuls derniers mois, une inclusion de fichier locale non authentifiée dans l'interface Classic (CVE-2026-73574), plusieurs XSS stockées déclenchées par un nom d'expéditeur ou une pièce jointe, une injection de commande dans la supervision SNMP. Toutes corrigées dans la branche 10.1.x, nulle part ailleurs. L'éditeur précise d'ailleurs que les versions anciennes non supportées ont souvent les mêmes vulnérabilités. Plusieurs failles Zimbra figurent au catalogue KEV de la CISA.

Le mur des paquets, et les fonctions qui manquent. Obtenir des paquets binaires officiels de l'Open Source Edition pour les branches récentes n'est plus la formalité que c'était. La suite suit la branche 10.1, la seule que Zimbra maintienne encore : les branches 8.8.15, 9.0.0 et 10.0.0 sont en fin de vie. Les sources FOSS sont publiées par Zimbra sur GitHub, les binaires étant reconstruits par la communauté ; les correctifs de sécurité y arrivent après un embargo d'environ soixante jours. L'éditeur suit les avis amont, les traite selon leur criticité et conduit ses propres audits. Et le périmètre ne bouge pas : « messagerie et agenda ; le reste en produits séparés », résume la page Comparer.

Ce que vous gardez, ce que vous gagnez

Vous gardez vos domaines et vos adresses (la FAQ est explicite : les domaines sont ajoutés et vérifiés dans la console, les utilisateurs gardent leurs adresses), vos protocoles standard, ainsi que zmprov et zmmailbox, qui ne disparaissent pas d'un Zimbra devenu brique d'Oworks. Vos utilisateurs d'Outlook classique le gardent, connecté nativement (voir plus bas).

Vous gagnez une identité unique sur Keycloak avec second facteur et fédération d'annuaire ; une isolation par organisation à trois niveaux d'administration (plateforme, organisation, unité) ; discussion, réunions, fichiers et documents dans le même socle ; un journal d'audit exportable ; une console unique.

L'inventaire préalable

Rien ne se décide avant cet inventaire : il détermine le chemin, les vagues et le budget. Les commandes sont celles de Zimbra, Zmprov et Zmmailbox. Une réserve sur la première : la page Zmprov est une contribution communautaire vérifiée sur ZCS 6.0.x, à recouper avec le guide d'administration de votre version.

1. Version exacte et niveau de correctif.
2. Comptes. zmprov -l gaa, zmprov cta <domaine>. Séparez boîtes humaines, boîtes fonctionnelles, comptes de service et comptes désactivés : les administrations ont souvent une forte proportion de comptes morts qu'il ne faut pas migrer.
3. Domaines et alias de domaine. zmprov gad, zmprov gd <domaine>.
4. Volumétrie. Taille par boîte et totale, nombre de messages, taille du plus gros message : la seule donnée qui permettra d'annoncer une durée. L'éditeur ne publie pas de débit type : l'outil de migration existe dans la console, mais son rendement n'a pas fait l'objet d'une mesure opposable à un client. Exigez un essai sur un lot représentatif de votre parc plutôt qu'une promesse de durée.
5. Listes de distribution. zmprov gadl, gdl, gdlm : membres, propriétaires, droits d'envoi, listes dynamiques.
6. Alias de comptes. Aucune commande ne les liste par domaine : ils se lisent dans les attributs des comptes (zmprov ga), donc à extraire par script.
7. Partages. zmprov gsi <propriétaire>, zmprov gpdlsi. Le poste qui casse le plus : dossiers montés, agendas et carnets partagés, et qui partage à qui.
8. Filtres côté serveur. Dans les attributs Sieve du compte, lisibles par zmprov ga : trente règles de tri non exportées, trente règles perdues.
9. Signatures, identités, sources de données. zmprov gsig, gid, gds ; les signatures HTML à images liées sont les plus fragiles.
10. Classes de service. zmprov gac -v : quotas, préférences imposées, fonctions activées.
11. Intégrations. Annuaire (Active Directory, LDAP ou Entra ID, cités sur la page Modes d'exploitation), applications métier qui envoient du courrier, passerelles antispam, archivage légal, sauvegarde, supervision, copieurs.
12. Clients, et surtout la version d'Outlook. Comptez les postes en Outlook classique et ceux déjà passés au nouvel Outlook pour Windows : la connexion native suppose Outlook classique (voir plus bas). Ajoutez Thunderbird et les téléphones, avec leur mode de configuration.
13. DNS. MX, SPF, DKIM (sélecteurs et clés), DMARC, autodiscover, et tout équipement référençant l'IP du serveur.

Les chemins de migration et leurs compromis

A. Reprise de l'instance existante

« Oworks reprend vos instances » : le chemin le plus court, puisque les données ne bougent pas. En pratique il suppose une compatibilité de version, donc une montée de version préalable probable.

Deux chemins, l'un et l'autre déjà conduits. La reprise sur place : l'instance existante est intégrée telle quelle, les données ne bougent pas, les boîtes gardent leurs identifiants, et la fenêtre d'interruption se compte en heures. Le transfert vers une instance neuve : on monte une plateforme propre et on y transfère les données par lots. C'est plus long, mais l'ancienne instance reste intacte en secours jusqu'au bout, et on repart sur une infrastructure dimensionnée pour la suite plutôt que sur l'héritage.

Ce qui fait pencher d'un côté ou de l'autre : la version de Zimbra en place (une branche en fin de vie se reprend mal telle quelle), l'état de l'infrastructure si elle doit être renouvelée de toute façon, et la tolérance à l'interruption.

Les deux chemins valent pour une édition Network comme pour une édition Community. Et c'est le moment de regarder ce que vous payez : en Network Edition, les licences couvrent notamment la sauvegarde, le connecteur Outlook et l'extension EWS. Oworks les remplace par ses propres composants, sous licence AGPL-3.0.

B. Export / import par l'API REST de Zimbra

Le chemin le plus fidèle avec les outils natifs :

/opt/zimbra/bin/zmmailbox -z -m user@domaine -t 0 getRestURL "//?fmt=tgz" > /tmp/compte.tgz
/opt/zimbra/bin/zmmailbox -z -m user@domaine -t 0 postRestURL "//?fmt=tgz&resolve=reset" /tmp/compte.tgz

Le -t 0 supprime le délai d'expiration, indispensable sur les grosses boîtes ; resolve=reset efface le dossier existant, voire la boîte entière à la racine. Compromis : fidèle, mais séquentiel, gourmand en espace temporaire et sans reprise sur incident.

C. Synchronisation IMAP, plus exports d'agendas et de contacts

Le chemin documenté par Zextras pour alimenter une installation Carbonio neuve : Migration to Carbonio CE. Deux phases, et la source n'est jamais modifiée.

• Provisionnement : domaines, comptes et listes exportés en LDIF (slapcat) puis injectés par slapadd -F /opt/zextras/data/ldap/config/ -v -l.
• Courrier : imapsync, depuis l'image Docker officielle gilleslamiral/imapsync, en boucle sur les comptes du domaine.
• Agendas et contacts : exportés en ICS et CSV, réinjectés via postRestURL '/Calendar?fmt=ics' et postRestURL '/Contacts?fmt=csv&csvfmt=thunderbird-csv'.

Deux contraintes : la destination doit être installée sur un domaine local distinct (carbonio.local) des domaines importés, pour éviter les conflits LDAP ; les commandes s'exécutent en zextras sur le nœud portant le composant Mailstore & Provisioning. Le périmètre annoncé couvre domaines, classes de service, comptes, messages, dossiers personnels et partagés, listes de diffusion, signatures, agendas et contacts. La page précise que ses commandes « are given as examples only » : ce n'est pas un mode opératoire clé en main.

Un article de la communauté Zextras (25/07/2023) la déroule pas à pas, bascule DNS comprise, avec --authuser1 / --authuser2 pour synchroniser via un compte d'administration global : How To Use Imapsync To Migrate Zimbra To Carbonio Community Edition. Les pages de migration de la documentation Carbonio commerciale, elles, répondent 404 au 08/11/2026 : la seule référence officielle utilisable est celle de l'édition Community.

Sur imapsync (imapsync.lamiral.info), une propriété commande le plan de bascule : il est incrémental, on l'arrête et le relance sans créer de doublons. D'où une passe à froid des semaines avant la bascule, puis un rattrapage le jour J. Il ne migre ni contacts ni agendas, et n'est pas fait pour maintenir deux boîtes actives en miroir.

D. L'outillage de migration d'Oworks

Ce que décrit la FAQ : « Depuis la console : vous déclarez la source (Zimbra, Exchange, Microsoft 365 ou tout serveur IMAP), choisissez les boîtes et suivez l'avancement de chaque lot. » Ces outils sont inclus dans toutes les éditions.

Ce que nous recommandons d'exiger avant de s'engager, quel que soit le fournisseur : une migration par lots dont chacun se relance seul après incident, sans reprendre les précédents ; un journal par boîte indiquant ce qui a été transféré et ce qui a échoué ; et un essai sur un lot représentatif de votre parc, avec vos plus grosses boîtes et vos agendas les plus partagés, plutôt qu'une démonstration sur des comptes neufs. Le périmètre exact repris au-delà du courrier (agendas, contacts, tâches, filtres, partages) se vérifie sur cet essai : c'est la seule mesure qui vaille.

Le déroulé type, par phases

La page États et administrations donne la démarche en cinq temps : atelier, architecture, pilote, généralisation, transfert. Côté exploitation :

Phases 0 et 1 : atelier et architecture. L'inventaire ci-dessus, les intégrations, la gouvernance cible (qui administre quoi), puis dimensionnement, sites, sécurité, plan de bascule. Les prérequis sur site, listés sur la page Modes d'exploitation : un cluster Kubernetes, du stockage objet et bloc, un raccordement d'annuaire facultatif, un second site recommandé pour la reprise d'activité. Point de bascule n° 1 : le choix du mode (sur site, chez un opérateur agréé, ou en ligne) et de l'édition. Il ne se reprend pas facilement.

Phase 2 : plateforme debout, à vide. Installation, annuaire, organisations et unités, politiques de sécurité, journal d'audit branché sur votre supervision.

Phase 3 : préparation du courrier. Domaines vérifiés dans la console, clés DKIM côté Oworks, enregistrements publiés en gardant l'ancien en place, cohabitation établie. Point de bascule n° 2 : la première modification DNS. À partir de là, vous travaillez en production.

Phase 4 : pilote. Un groupe réel, choisi pour sa représentativité et non pour sa complaisance : un service qui partage des agendas, un cadre avec des filtres, une assistante avec délégation, un poste Outlook classique, un poste au nouvel Outlook, un mobile. Point de bascule n° 3 : la décision de généraliser, qui doit pouvoir être « non ».

Phase 5 : généralisation par vagues. La FAQ décrit la logique : « l'ancien et le nouveau système cohabitent sur le même domaine pendant la migration ; les utilisateurs basculent par groupes, à votre rythme. » La règle de découpage n'est pas l'organigramme, c'est le graphe des partages : ceux qui partagent agendas et dossiers basculent ensemble.

Phase 6 : extinction et transfert. Arrêt des services de l'ancien Zimbra, conservation de l'archive, transfert de compétences. Gardez l'ancienne instance accessible en lecture seule au moins le temps d'un cycle complet d'activité (une clôture mensuelle, une campagne, une session budgétaire) avant de l'éteindre. C'est ce délai, et non une durée théorique, qui révèle ce qu'on avait oublié de migrer. Ne confondez pas cette conservation avec la restauration contractuelle d'une organisation, qui est un autre dispositif.

Ce qui casse souvent, et comment l'anticiper

Les partages d'agenda et les dossiers montés. Le point noir. Un montage pointe vers un compte sur un serveur donné : si le propriétaire est resté derrière et l'utilisateur devant, il ne répond plus. Anticipation : extraire tous les partages, regrouper leurs communautés dans la même vague, prévoir une recréation après bascule. Prévenez les secrétariats de direction.

Les filtres côté serveur. Non transportés par IMAP, absents du périmètre du chemin C. Anticipation : exporter les scripts Sieve, les réinjecter, faire vérifier. Un filtre qui pointe vers un dossier renommé envoie le courrier dans le vide.

Les listes de distribution. Les membres se migrent, les subtilités non : droit d'écriture, propriétaire, listes dynamiques. Anticipation : recenser, recréer, tester un envoi réel sur chaque liste critique.

Les signatures. Dans le périmètre annoncé du chemin C, mais les images liées et les signatures imposées par classe de service se perdent. Anticipation : normaliser les signatures institutionnelles plutôt que migrer le désordre.

Les alias. Invisibles, donc oubliés ; un alias manquant produit un rejet immédiat. Anticipation : liste exhaustive et test d'envoi sur chaque alias publié.

Les clients mobiles. À reconfigurer : une notice d'une page par modèle, écrite avant la vague, et une permanence physique le jour J. Le poste qui génère l'essentiel des appels au support.

Les délégations et les « envoyer en tant que ». Elles se perdent silencieusement : on le découvre quand un directeur ne voit plus la boîte de son cabinet.

Les applications et les copieurs qui envoient du courrier. IP et identifiants codés en dur dans une configuration que personne ne documente. Anticipation : relever les authentifications SMTP sur le MTA avant la bascule, c'est la seule cartographie fiable.

La réputation d'envoi. Changer d'IP sortante, c'est repartir de zéro : SPF, DKIM et DMARC justes avant de monter en volume.

La bascule : coexistence, redirection, retour arrière

La coexistence. Le principe annoncé par Oworks, deux systèmes sur un seul domaine, correspond à un mécanisme classique côté Zimbra, documenté sous le nom de Split Domain : l'attribut zimbraMailTransport du compte indique où livrer son courrier et peut router vers l'autre système ; au niveau du domaine, un « catch-all » envoie vers le second système ce qui n'existe pas localement. Il n'y a donc qu'une autorité : le système qui reçoit le MX livre les comptes qu'il détient et relaie les autres.

Nous recommandons de confier le MX au nouveau système dès la première vague, et de lui faire relayer vers l'ancien les comptes non encore basculés. La bascule d'un compte devient alors une opération locale, sans toucher au DNS, donc réversible en minutes. L'inverse, où l'ancien système reste primaire, fonctionne aussi, mais chaque vague dépend alors d'un système qu'on cherche précisément à quitter. Le mécanisme est détaillé dans Partager un domaine entre deux messageries. Le routage par compte et les listes à cheval se règlent en atelier, sur votre annuaire.

Le retour arrière. Posez la question avant la première vague. Il n'est pas gratuit : le courrier reçu depuis la bascule est sur la nouvelle plateforme, et le ramener suppose une synchronisation inverse. Deux règles limitent les dégâts : garder l'ancienne boîte intacte en lecture seule, et faire des vagues assez petites pour qu'un retour arrière tienne en une heure. Ne comptez pas sur une resynchronisation inverse pour votre plan de retour arrière, même si votre fournisseur en propose une : un outil de plus est un risque de plus au pire moment. La boîte d'origine laissée intacte en lecture seule est le seul retour arrière qui ne dépende de rien. Dimensionnez vos vagues en conséquence.

Après : ce qu'il faut vérifier

Dans l'heure qui suit chaque vague : un envoi et une réception depuis l'extérieur, pour chaque domaine et chaque alias critique ; SPF, DKIM et DMARC en pass dans l'en-tête d'un message reçu ; un rendez-vous créé et accepté, une disponibilité consultée entre deux utilisateurs dont un non basculé ; un partage d'agenda et un dossier partagé ouverts ; une liste de distribution critique testée ; un filtre ; un téléphone, un Outlook et un webmail connectés ; le journal d'audit ; la file du MTA, vide.

Dans la semaine : volumétrie comparée à la source, appels au support, courrier rejeté dans les journaux du MTA, et relevé des utilisateurs qui n'ont pas ouvert leur boîte. Ce sont eux qui découvriront un problème dans trois semaines.

Outlook : la question que tout migrant Zimbra pose

C'est souvent la question qui décide d'un projet, et la réponse est favorable : Outlook classique se connecte nativement à Oworks en MAPI over HTTP, EWS et ActiveSync. La section Architecture de la page Produit liste ces trois protocoles, la page Éditions les porte à la ligne « Outlook connecté en natif (MAPI, EWS, ActiveSync) », et la page États le formule ainsi : « Outlook : les agents le gardent, connecté nativement. »

C'est Outlook classique, pas le nouvel Outlook pour Windows. Ce n'est pas une limite d'Oworks : c'est Microsoft qui le documente. Dans le comparatif officiel Feature comparison between new Outlook and classic Outlook, la ligne « Messaging Application Programming Interface (MAPI) » est « Available » pour Outlook classique et « Not supported » pour le nouvel Outlook ; même verdict pour « COM add-ins ». Elle classe « Exchange (on-prem and on-prem ADFS) » en « Partially Available » sur le nouvel Outlook, « Supported via IMAP – functionality limited based on protocol capabilities » : un parc déjà passé au nouvel Outlook retombe sur IMAP, CalDAV et CardDAV. À vérifier à l'inventaire, avant de s'engager sur une expérience utilisateur.

L'horizon de support d'Outlook classique est documenté, et il n'est pas infini. La page Microsoft Stages of migration to new Outlook for Windows (mise à jour du 23/02/2026) décrit trois étapes (opt-in, opt-out, cutover) et indique : « Existing installations of classic Outlook through perpetual and subscription licensing will continue to be supported until at least 2029 », avec « at least 12 months of notice » avant le cutover en production. À la date de cette page, Microsoft situe le produit en étape opt-in ; l'étape en cours est à vérifier sur la page.

La connexion native d'Outlook est disponible quelle que soit l'édition, et le carnet d'adresses hors connexion est servi lui aussi.

Côté mobile, ActiveSync ouvre la messagerie native des téléphones, et la FAQ mentionne les applications Oworks pour iPhone et Android. Un écart à corriger sur le site : cette même FAQ place encore MAPI over HTTP et EWS sur la feuille de route, alors que les pages Éditions, Produit et États les donnent comme livrés.

Et ensuite : amener les utilisateurs sur les clients de la suite

La connexion native d'Outlook a une vertu de conduite de projet : elle permet de migrer le serveur sans migrer les utilisateurs en même temps. Deux chantiers, deux risques, deux calendriers. On déplace les boîtes, on vérifie le courrier, on stabilise ; les agents gardent leur client. L'accompagnement vient après, à l'inverse du « grand soir », où l'on découvre le même week-end un problème de routage et une révolte d'utilisateurs.

Mais ce n'est pas une destination. Garder Outlook indéfiniment, c'est garder une dépendance à une feuille de route qu'on ne maîtrise pas, alors qu'on a migré pour s'en affranchir. Deux faits documentés par Microsoft :

• le nouvel Outlook ne prend en charge ni MAPI ni les compléments COM (comparatif officiel), et l'horizon de support d'Outlook classique est « at least 2029 » (étapes de migration) ;
• EWS est en retrait : la page Deprecation of Exchange Web Services in Exchange Online annonce qu'en octobre 2026 EWS commence à être désactivé globalement et qu'en avril 2027 il l'est totalement. Cela ne concerne qu'Exchange Online : Microsoft indique qu'il n'y a pas de changement pour Exchange Server, donc rien ne touche l'EWS d'Oworks. Reste que c'est l'orientation de l'éditeur sur ces protocoles.

La fin de parcours raisonnable est donc une phase 7, conduite à froid une fois la messagerie stabilisée : ouvrir le webmail Carbonio et les applications de la suite à un service volontaire, mesurer, élargir ; commencer par ceux qui n'ont rien à perdre (mobiles, nouveaux arrivants, postes partagés) ; traiter en dernier les usages Outlook structurants (délégations de cabinet, agendas de direction, compléments métier) en vérifiant un par un leur équivalent. Les fonctions absentes d'Outlook (discussion, réunions, documents coédités) sont le meilleur levier d'adoption : les agents y vont pour ce qu'ils y gagnent, pas parce qu'on leur a retiré leur client.

Ce qui marche, et ne coûte rien : basculer les équipes entières plutôt que des individus, pour que les gens retrouvent leurs interlocuteurs ; ouvrir la discussion et les réunions avant la messagerie, pour que la suite arrive par ce qu'elle apporte et non par ce qu'elle remplace ; désigner un référent par direction, à qui on demande plutôt qu'au support. Guides, vidéos et sessions servent surtout à rassurer la hiérarchie.

---