📍 Article principal : Mailcow vs Mailu vs Stalwart pour PME. Ce tutoriel guide pas à pas la migration depuis Microsoft 365 ou Google Workspace vers un Mailcow auto-hébergé, sans interruption visible des utilisateurs.
La migration depuis un service cloud vers un Mailcow auto-hébergé est l’une des opérations les plus impactantes qu’une PME puisse mener — la messagerie est la colonne vertébrale des communications professionnelles. Mal exécutée, la migration cause des courriels perdus, des utilisateurs frustrés, des contrats commerciaux bloqués. Bien orchestrée, elle se déroule sur deux à quatre semaines avec une coupure perçue de quelques minutes seulement. Ce tutoriel décrit la procédure éprouvée — préparation, communication interne, transfert IMAP avec imapsync, bascule DNS progressive, vérifications post-migration.
Prérequis
- Mailcow déjà déployé et fonctionnel (voir tutoriel installation)
- SPF/DKIM/DMARC configurés (voir tutoriel délivrabilité)
- Sécurité de base appliquée (voir tutoriel sécurité)
- Accès admin Microsoft 365 ou Google Workspace pour le source
- Liste exhaustive des utilisateurs à migrer avec mots de passe ou méthode d’auth
- Niveau : avancé
- Temps estimé : 2 à 4 semaines de planning, 1 à 3 jours de migration effective
Étape 1 — Audit de l’existant et plan de migration
Avant toute action technique, dresser un inventaire complet. Combien d’utilisateurs au total ? Quels alias et listes de distribution actifs ? Quel volume de données par boîte (peut varier de 100 Mo à 50 Go) ? Quels services tiers s’authentifient sur des comptes email (Slack, Trello, applications métier) ? Quels filtres de redirection automatique sont actifs ? Cet inventaire prend généralement une semaine et révèle souvent des configurations oubliées qu’il faudra reproduire dans Mailcow.
Préparer ensuite le plan de migration. Phase 1 (semaine 1) : création des comptes Mailcow, configuration des alias, communication initiale aux utilisateurs. Phase 2 (semaine 2) : synchronisation initiale IMAP en arrière-plan pendant que la production reste sur Microsoft/Google. Phase 3 (semaine 3 — bascule) : synchronisation incrémentale, mise à jour DNS, formation des utilisateurs. Phase 4 (semaine 4 — stabilisation) : support actif, résolution des incidents, vérification que rien n’est perdu.
Étape 2 — Préparer Mailcow pour la migration
Côté Mailcow, créer toutes les boîtes utilisateur en avance avec des mots de passe temporaires. Configurer les alias et listes de distribution selon l’inventaire. Ajuster les quotas selon le volume réel de chaque boîte (ne pas créer une boîte 5 Go pour un utilisateur qui en a 20 actuellement). Activer les groupes SOGo équivalents aux groupes Microsoft 365 ou Google. Tester la connexion IMAP/SMTP de quelques comptes manuellement pour valider que tout fonctionne avant la synchronisation massive.
Augmenter temporairement le quota de l’instance Mailcow elle-même si le volume total à migrer dépasse l’espace disque alloué. Pour 100 utilisateurs avec 5 Go moyen chacun, prévoir 600 Go minimum (500 Go boîtes + 100 Go marge système). Ajouter un volume Hetzner si nécessaire et l’attacher au conteneur Mailcow vmail. Tester avant la migration que le volume est correctement monté et accessible.
Étape 3 — Synchroniser avec imapsync
imapsync est l’outil de référence pour migrer les boîtes IMAP entre serveurs. L’outil parcourt récursivement chaque dossier (inbox, sent, drafts, spam, archives), copie les messages avec leurs flags (lu/non lu, marqué, étoilé), préserve les dates originales. Pour une migration depuis Microsoft 365, il faut activer l’authentification par mot de passe d’application (App Password) ou utiliser OAuth 2.0 — le mot de passe principal ne fonctionne pas par défaut sur les comptes 365 modernes.
imapsync \ --host1 outlook.office365.com --user1 user@masociete.sn --password1 "<app-password>" \ --host2 mail.masociete.sn --user2 user@masociete.sn --password2 "<new-password>" \ --ssl1 --ssl2 \ --automap \ --syncinternaldates \ --useheader Message-Id
L’option automap aligne les noms de dossiers (Inbox, Sent Items, Deleted Items côté Microsoft vers les équivalents Mailcow). syncinternaldates préserve les dates originales pour ne pas désordonner les boîtes. useheader Message-Id permet de relancer imapsync incrémentalement sans dupliquer les messages déjà synchronisés.
Pour 100 utilisateurs, scripter imapsync dans une boucle bash qui itère sur la liste. Démarrer la synchronisation initiale plusieurs jours avant la bascule pour absorber le gros du transfert. Le débit typique est de 10 à 50 Go par heure selon la bande passante. Une boîte de 5 Go prend donc entre six minutes et une heure. Pour 100 boîtes en série, prévoir 24 à 48 heures de synchronisation initiale.
Étape 4 — Communication aux utilisateurs
La communication interne fait souvent la différence entre une migration réussie et un chaos opérationnel. Annoncer la migration deux semaines avant la date de bascule via un mail de la direction. Trois jours avant, envoyer un guide pratique qui détaille : la nouvelle URL du webmail, les paramètres de configuration des clients (Outlook, Thunderbird, Apple Mail, mobiles), le mot de passe initial avec invitation à le changer immédiatement, le canal de support en cas de problème.
Le jour J, prévoir une équipe support disponible pendant les heures ouvrables — typiquement deux ou trois personnes pour aider à reconfigurer les clients et résoudre les questions. Préparer une FAQ à diffuser : comment retrouver mes anciens contacts, comment configurer ma signature, comment activer la 2FA, etc. Cette FAQ évite la majorité des appels en répétant simplement les actions de base.
Étape 5 — Bascule DNS
La bascule DNS est le moment critique. Avant la bascule, faire une dernière synchronisation incrémentale pour rattraper les courriels arrivés depuis la sync initiale. Modifier ensuite l’enregistrement MX du domaine pour pointer vers mail.masociete.sn au lieu des serveurs Microsoft ou Google. La propagation DNS prend de 5 minutes à 4 heures selon le TTL configuré — abaisser le TTL à 300 secondes une semaine avant la migration accélère la propagation.
Pendant la fenêtre de propagation, certains expéditeurs envoient encore vers l’ancien serveur, d’autres vers le nouveau. Conserver actif l’ancien serveur pendant 7 à 14 jours pour absorber ce trafic résiduel — Microsoft 365 et Google Workspace facturent au mois, donc garder un mois de plus n’est pas un drame budgétaire. Pendant cette période, vérifier régulièrement les anciens serveurs pour récupérer les courriels arrivés en retard et les transférer manuellement vers Mailcow si nécessaire.
Étape 6 — Vérifications post-migration
Une fois la bascule effectuée, plusieurs vérifications cruciales. Premier : tester l’envoi et la réception de courriels entre comptes internes et avec des comptes externes (Gmail, Microsoft, fournisseurs/clients connus). Deuxième : vérifier la délivrabilité avec mail-tester.com depuis chaque domaine actif pour confirmer que le score reste bon malgré le changement d’IP. Troisième : confirmer que tous les utilisateurs peuvent se connecter via leur client habituel et accéder à leurs anciens courriels.
Quatrième vérification : inventorier les services tiers qui utilisent l’authentification email (newsletters, applications SaaS, services de signature électronique) et reconfigurer leurs credentials SMTP avec les nouveaux paramètres Mailcow. Cinquième : surveiller les logs Postfix/Rspamd pendant la première semaine pour détecter les anomalies — taux de rejet inhabituellement élevé, courriels qui partent en spam massivement, comptes qui présentent des taux de bounce anormaux.
Migrer aussi calendriers et contacts
imapsync ne gère que les courriels IMAP — les calendriers et contacts demandent une procédure distincte. Pour Microsoft 365, exporter chaque calendrier au format ICS via Outlook Web (Paramètres → Calendrier → Calendriers partagés → Publier un calendrier). Pour Google Workspace, l’export se fait depuis Google Takeout en format ICS. Importer ensuite dans SOGo Mailcow via l’interface webmail : Calendrier → Importer un fichier ICS. Chaque utilisateur doit faire cette opération individuellement, ou la déléguer à l’équipe IT pour les comptes critiques.
Pour les contacts, même procédure avec le format VCF. Exporter depuis le client source, importer dans SOGo. Penser à vérifier les groupes de contacts et les listes de distribution qui peuvent ne pas être correctement transférées par les exports automatiques. Pour les déploiements à grande échelle (50+ utilisateurs), un script qui automatise l’import ICS/VCF par boîte fait gagner plusieurs jours de travail manuel.
Stockage des anciennes archives
Plusieurs PME conservent des années d’archives email qui occupent énormément d’espace. Plutôt que de migrer tout cela dans Mailcow actif, considérer une stratégie d’archivage : les courriels de plus de deux ans partent dans une instance Mailcow secondaire dédiée à l’archivage, hébergée sur un VPS plus modeste avec stockage S3-compatible bon marché. L’instance principale reste légère et performante avec uniquement les données récentes actives.
Cette architecture à deux niveaux divise typiquement par cinq la consommation mémoire et CPU de l’instance principale. Les utilisateurs accèdent aux archives via un client IMAP secondaire ou via un webmail dédié pour les recherches historiques. Pour les services réglementés qui doivent conserver dix ans de courriels (banques, finance), cette séparation est non négociable — l’archive lente et bon marché ne pénalise pas l’expérience email quotidienne.
Erreurs fréquentes
| Erreur | Cause | Solution |
|---|---|---|
| Authentification Microsoft 365 refusée | App Password non créé ou désactivé | Activer App Password dans le compte M365, ou utiliser OAuth 2.0 |
| Sync extrêmement lente | Bande passante insuffisante côté serveur | Lancer imapsync depuis le VPS Mailcow lui-même pour bande passante max |
| Courriels en double après resync | Mauvaise option de matching | Toujours utiliser –useheader Message-Id |
| Calendriers et contacts non transférés | imapsync ne gère que IMAP, pas CalDAV/CardDAV | Exporter ICS/VCF depuis source, importer dans SOGo Mailcow |
| Délivrabilité dégradée après migration | Nouvelle IP sans réputation | Warmup progressif, monitoring Postmaster Tools |
Adaptation au contexte ouest-africain
Pour les PME ouest-africaines, deux particularités méritent attention. Premier : les mots de passe doivent souvent être communiqués individuellement aux utilisateurs en présentiel ou par WhatsApp Business — beaucoup de collaborateurs en région ne consultent pas systématiquement leurs courriels professionnels et la communication par email pour annoncer le mot de passe peut donc être inefficace. Prévoir une coordination directe avec chaque manager d’équipe pour faciliter cette diffusion. Deuxième : la formation utilisateur est cruciale dans les contextes où les compétences IT sont inégalement distribuées. Investir une demi-journée de formation présentielle avec démonstration sur grand écran de la configuration des clients populaires (Outlook, Gmail mobile) facilite radicalement la transition et réduit drastiquement le volume de tickets support post-migration.
Coût et planning détaillés
Pour estimer concrètement le projet de migration, voici un planning type pour une PME de 50 utilisateurs. Semaine 1, audit et planification — 3 jours de travail interne. Semaine 2, déploiement Mailcow et configuration initiale — 2 jours de prestation externe à 200 000 XOF par jour soit 400 000 XOF, plus 1 jour interne. Semaine 3, synchronisation initiale imapsync — automatique mais demande surveillance, environ 4 heures de travail interne. Semaine 4, bascule DNS et formation utilisateurs — 2 jours intensifs de support, 3 personnes mobilisées.
Coût total du projet : environ 1 million XOF en prestation externe et 12 jours-homme internes. Économie annuelle Microsoft 365 évitée pour 50 utilisateurs : 4 800 EUR soit environ 3,2 millions XOF. ROI atteint en moins d’un an, économie cumulée sur trois ans dépassant 8 millions XOF — équivalent à plusieurs nouveaux postes commerciaux pour développer le business. Cette équation économique justifie largement la migration pour la majorité des PME ouest-africaines au-delà de 30 utilisateurs.
Communication post-migration et retours utilisateurs
Pendant les deux semaines suivant la bascule, instaurer une rétroaction systématique avec les utilisateurs. Envoyer un sondage simple à toute l’équipe : la connexion fonctionne-t-elle, les anciens courriels sont-ils accessibles, le client mobile se synchronise-t-il, y a-t-il des courriels qui semblent perdus ? Les retours révèlent souvent des configurations spécifiques oubliées dans l’inventaire initial — un alias rare, une règle de transfert automatique vers une boîte personnelle, une signature complexe avec image embarquée.
Documenter chaque incident résolu dans un journal partagé qui devient le runbook de référence pour les futures migrations ou pour onboarder un nouveau collaborateur. Cette traçabilité simple transforme l’expérience individuelle de l’équipe IT en savoir collectif réutilisable. Pour les PME qui font ensuite des migrations similaires (rachat d’autre PME, intégration de nouvelle filiale), ce runbook fait gagner plusieurs jours de planification.
Décommissionnement de l’ancien environnement
Une fois la migration validée et le mois supplémentaire écoulé, procéder au décommissionnement structuré de l’ancien environnement Microsoft 365 ou Google Workspace. Étape 1, exporter une dernière fois toutes les boîtes en archive locale chiffrée pour conservation hors du cloud propriétaire. Étape 2, désactiver les comptes utilisateurs un par un avec confirmation que chaque collaborateur a bien accès à son nouveau compte Mailcow. Étape 3, transférer la propriété des documents Drive ou OneDrive vers d’autres solutions de stockage si la PME en a (Nextcloud auto-hébergé par exemple). Étape 4, résilier l’abonnement administrateur en respectant le préavis contractuel.
Cette procédure ordonnée prend deux à trois jours mais évite les pertes de données silencieuses qu’une coupure brutale provoquerait. Conserver toutes les preuves de transfert (confirmations email, captures de comptes désactivés, dates de résiliation) dans un dossier d’archive du projet — ces preuves servent en cas de litige ultérieur sur la facturation ou en cas de contrôle administratif sur la durée de conservation des données.
Pour aller plus loin
🔝 Retour à l’article principal : Mailcow vs Mailu vs Stalwart pour PME. Tutoriels précédents : déployer Mailcow, SPF/DKIM/DMARC, sécurité.
Documentation imapsync : imapsync.lamiral.info, guide Microsoft 365 OAuth IMAP : learn.microsoft.com. La migration depuis le cloud vers l’auto-hébergé est l’investissement initial le plus rentable d’une stratégie d’infrastructure souveraine — la PME économise plusieurs milliers d’euros par an, gagne en contrôle de ses données, et démontre une maturité technique qui rassure ses clients institutionnels. Le projet demande un mois de préparation rigoureuse mais paye des dividendes pendant des années.