Changer de messagerie sans improviser.
Une migration touche les domaines, le DNS, les identités, les données, les logiciels et les appareils. Le passage se prépare avant le premier déplacement.
MrMail peut étudier des sources Zimbra, IMAP, Microsoft 365 ou Exchange et d’autres messageries hébergées. La méthode dépend de la source, des volumes, des types de données et de la fenêtre disponible.
Parcours de migration
De l’inventaire à la validation.
1. Inventaire
Recenser domaines, boîtes, alias, groupes, volumes, dépendances et personnes responsables.
2. Types de données
Distinguer messages, dossiers, calendriers, contacts, tâches, partages et éléments qui ne se transfèrent pas automatiquement.
3. Domaine et DNS
Préparer MX, SPF, DKIM, DMARC et autres enregistrements utiles sans supposer leur état actuel.
4. Logiciels et appareils
Identifier navigateur, Outlook, Thunderbird, mobiles, protocoles et fonctions de synchronisation réellement utilisés.
5. Pilote
Tester la méthode, la compatibilité et le résultat avec un périmètre représentatif lorsque le projet le permet.
6. Bascule
Convenir de la fenêtre, des responsabilités, de la communication et d’une solution de repli adaptée au risque.
7. Vérification
Contrôler acheminement, connexion, données, calendriers, contacts, partages et appareils après le changement.
8. Suivi
Traiter les écarts observés et remettre un environnement dont le périmètre de support est compris.
Aucune méthode ne garantit universellement une migration sans perte. Les limites de la source, des formats et des outils sont expliquées avant la bascule.
Points de contrôle
Reconnaître un changement maîtrisé.
Comprendre avant
Au-delà des boîtes, il faut inventorier alias, groupes, calendriers, contacts, tâches, partages, archives, transferts et sources d’identité. Toutes les origines n’exposent pas les mêmes objets.
La liste des données indique ce qui sera transféré, recréé ou exclu consciemment.Maîtriser la bascule
DNS, dernière synchronisation, communication et configuration des logiciels doivent s’aligner. Un raisonnement de repli adapté est défini pour les dépendances critiques.
Un pilote réduit l’incertitude sans remplacer le contrôle global.Vérifier après
Après le changement, on contrôle acheminement, connexion, données représentatives, partages et appareils. Les écarts sont documentés et dirigés vers le support convenu.
La recette porte sur des résultats vérifiés, pas seulement sur un outil lancé.Les outils accélèrent certaines tâches; ils ne remplacent ni planification, ni vérification, ni responsabilité.
Le support commence par une frontière compréhensible.
Pendant la migration, un interlocuteur défini doit pouvoir prendre les décisions et répondre aux questions. MrMail coordonne méthode et communication avec les responsables.
Après la bascule, on distingue correction de migration, exploitation de la plateforme et problèmes liés aux appareils, réseaux ou logiciels tiers du client.
Canaux, horaires, modèle de réponse et travaux supplémentaires suivent l’accord concret. Aucun SLA universel ni absence totale d’interruption n’est promis.
La migration finit lorsque l’acheminement et le travail sont vérifiés, pas lorsque la copie s’arrête.
Questions de transition
La migration peut-elle être progressive?
Souvent oui, mais le domaine, la coexistence et les flux doivent être étudiés pour le cas concret.
Y a-t-il un retour arrière?
Le raisonnement de repli fait partie de la préparation; sa forme dépend de la source et du moment de la bascule.
Que couvre le support après migration?
Canaux, horaires, délais et responsabilités suivent l’accord de support, pas une promesse générale du site.
Préparer le changement avant de fixer la date.
Indiquez le système actuel, les utilisateurs, les données et la période souhaitée.