Migrer une messagerie sans perdre de données

Migrer une messagerie sans perdre de données ni subir d'interruption évitable

Migrer d'un fournisseur à un autre ne revient pas simplement à copier des fichiers. Vous synchronisez une base active tandis que de nouveaux messages arrivent, que des utilisateurs suppriment des éléments et que les métadonnées évoluent. Une mauvaise préparation peut diviser le routage, omettre des messages et provoquer une crise le lundi matin.

Ce guide propose un plan par phases pour une petite entreprise : préparation du DNS, stratégie IMAP, bascule et vérification. Aucun processus ne garantit l'absence totale d'interruption ou de perte, mais ces contrôles réduisent le risque.

Pourquoi tant de migrations échouent

Trois oublis causent une grande partie des incidents. Les comprendre avant la migration évite de les découvrir en production.

Cache DNS : si le TTL n'est pas réduit avant la bascule, certains résolveurs peuvent envoyer le courrier aux anciens et nouveaux serveurs pendant jusqu'à 24 heures.
Limitation : des fournisseurs comme Google peuvent plafonner les téléchargements IMAP à environ 2,500 MB/jour selon le compte et la politique. La synchronisation ralentit ou s'arrête alors en cours de route.
Élargissement du périmètre : IMAP ne transfère que les messages compatibles. Calendriers et contacts utilisent d'autres protocoles, notamment CalDAV et CardDAV.

Phase 1 : audit technique (7 jours avant)

Impossible de migrer ce dont on ignore l'existence. Commencez par un inventaire technique plutôt que par vos souvenirs.

Recenser les identités cachées

Une liste d'utilisateurs ne suffit pas. Cartographiez chaque point d'entrée :

• Alias : john@ reçoit-il aussi le courrier de sales@ ? Oublier cet alias sur la nouvelle plateforme peut provoquer des rejets.
• Listes de distribution : team@ et info@ sont-ils des boîtes partagées ou des groupes de transfert ?
• Transferts : auditez les règles côté serveur. Les transferts cachés vers des comptes Gmail personnels cesseront de fonctionner s'ils ne sont pas recréés et autorisés.

Repérer les très grandes boîtes

Identifiez les boîtes dépassant 10 GB. IMAP multiplie les opérations et une boîte de 50 GB peut prendre longtemps. Microsoft 365 peut limiter le trafic après environ 20 GB/jour selon le service. Lancez une présynchronisation pour ces utilisateurs au moins 5 jours avant la bascule. Le guide de migration Google Workspace documente les conditions actuelles.

La réalité d'une migration limitée aux messages

Les outils, dont imapsync et le moteur intégré de TrekMail, utilisent le protocole IMAP (RFC 3501). IMAP transfère uniquement les messages compatibles.

Calendriers et contacts ne font pas partie d'IMAP. Ils utilisent des formats ou protocoles distincts, comme Exchange et CalDAV. Demandez aux utilisateurs d'exporter calendriers (.ics) et contacts (.vcf ou .csv) avant de résilier l'ancien abonnement, puis testez l'importation.

Phase 2 : préparation de l'infrastructure (48 heures avant)

Ne déplacez pas encore les données. Préparez d'abord la destination et le routage.

La règle des 300 secondes pour le TTL DNS

Le TTL indique combien de temps un résolveur peut mettre un enregistrement DNS en cache. Avec la valeur courante de 86,400 secondes (24 heures), certains continueront d'utiliser l'ancien enregistrement jusqu'à expiration.

Chez votre fournisseur DNS, par exemple Cloudflare, GoDaddy ou Route53, fixez le TTL du MX à 300 secondes lorsque c'est possible. Faites-le au moins 24 heures avant et vérifiez la valeur publiée.

Préparer la destination

Créez les boîtes chez le nouveau fournisseur. Sur TrekMail, configurez vos domaines et utilisateurs dans le tableau de bord. Sur Nano, renseignez les identifiants SMTP externes, comme SES ou Mailgun, et testez l'envoi avant la bascule.

Assurez-vous de disposer d'identifiants valides pour les boîtes sources. Sinon, réinitialisez-les ou utilisez un accès administrateur compatible et autorisé.

Phase 3 : stratégie de présynchronisation

Évitez de tout déplacer en une seule nuit. Une migration en plusieurs étapes réduit le volume et le risque de la bascule finale.

Étape 1 : passage historique (3 jours avant)

Configurez l'outil pour copier les messages antérieurs à 7 jours. Selon l'usage, cela peut représenter environ 95% du volume tandis que les utilisateurs continuent de travailler. Si une pièce jointe de 2 GB échoue, vous aurez le temps d'en rechercher la cause.

Surveillez les erreurs HTTP 429 ou « User is throttled ». Si elles apparaissent, réduisez la concurrence, par exemple à 5 utilisateurs au lieu de 50, puis suivez les recommandations du fournisseur.

Étape 2 : gel opérationnel (moment de la bascule, vendredi soir)

Prévenez les utilisateurs et demandez-leur de ne pas envoyer de nouveaux messages pendant la fenêtre. Si possible, limitez la source à la lecture sans bloquer la réception. Modifier les mots de passe peut créer d'autres risques; documentez et testez la procédure.

Étape 3 : synchronisation différentielle

Relancez l'outil pour copier les 7 derniers jours et rapprocher les éléments modifiés pendant la préparation. Si près de 95% des données se trouvent déjà à destination, cette passe est souvent plus courte, mais sa durée dépend du volume, des limites et des différences entre serveurs.

Phase 4 : la bascule

Changer les enregistrements MX

Remplacez les MX par ceux du nouveau fournisseur. Pour TrekMail, les valeurs indiquées sont :

Avec un TTL de 300 secondes, beaucoup de résolveurs changent rapidement, mais des caches externes peuvent prolonger la transition. Maintenez et surveillez les deux systèmes.

Authentification SPF et DKIM

Une migration exige de mettre à jour et valider les enregistrements d'authentification. Leur absence peut dégrader la délivrabilité et favoriser le classement en spam, sans déterminer seule le résultat.

• SPF : mettez à jour le TXT sans créer plusieurs enregistrements SPF. Exemple : v=spf1 include:spf.trekmail.net -all
• DKIM : générez les clés dans le tableau de bord du nouveau fournisseur, ajoutez les CNAME ou TXT au DNS, puis vérifiez la signature.

Consultez la configuration de la messagerie sur votre domaine pour le détail.

Vérifier les anciens services

Si vous quittez Google Workspace tout en conservant Drive ou Docs, Gmail peut encore intercepter le courrier interne selon la configuration. Désactivez Gmail pour les utilisateurs concernés ou configurez une distribution partagée, puis testez les chemins internes et externes.

Phase 5 : vérification

Ne vous contentez pas de demander aux utilisateurs si tout est présent. Utilisez des mesures et des échantillons.

Nombre d'éléments, pas taille

Ne comparez pas seulement les GB, car compression et représentation varient. Comparez le nombre d'éléments dans chaque dossier :

Un écart inférieur à 1% ne doit pas être accepté automatiquement : il peut provenir d'éléments corrompus, dupliqués ou incompatibles. Au-delà de 5%, une enquête est urgente. Documentez chaque exception.

Hiérarchie des dossiers

Recherchez les dossiers aplatis. Une arborescence comme Clients/2024/Project A/Invoices/Paid peut être tronquée. Contrôlez aussi les espaces de noms tels que INBOX.Sent et Sent.

Résoudre les pannes courantes

Le moteur de migration intégré de TrekMail

Si coordonner IMAP, limitations et propagation DNS représente trop de travail, le moteur TrekMail automatise une partie du processus. L'administrateur reste responsable du DNS, des droits, des données hors périmètre et de la vérification finale.

Pour les petites entreprises (1 à 50 utilisateurs)

TrekMail comprend un moteur de migration. Connectez un fournisseur compatible, comme Gmail, Outlook ou cPanel, sélectionnez les boîtes et lancez la tâche. L'infrastructure gère les nouvelles tentatives, limitations et doublons selon ses capacités. Contrôlez les rapports et rapprochez la source; aucune ligne de commande n'est requise pour le flux pris en charge.

Pour les agences (100+ domaines)

Gérer les migrations de nombreux clients consomme du temps. TrekMail propose des opérations en masse, un stockage mutualisé entre domaines et une tarification fixe dans les limites du forfait.

Les offres payantes décrites incluent un essai de 14 jours avec carte. Nano est annoncé sans carte. Confirmez tarifs, admissibilité et conditions actuelles.

Conclusion : migrer correctement la messagerie

Une migration devient maîtrisable lorsque le processus est respecté. Préchargez les données, réduisez le TTL à 300 secondes, lancez une synchronisation différentielle et vérifiez nombres, échantillons et exceptions. L'objectif est aussi d'adopter une infrastructure qui couvre vos besoins de messagerie professionnelle avec des coûts prévisibles.

Pour essayer le moteur intégré, créez un compte TrekMail gratuit, vérifiez la compatibilité de la source et commencez par une boîte non critique.