Pourquoi une checklist de migration est indispensable
La migration email est l'une des opérations informatiques les plus risquées qu'une organisation puisse entreprendre. On déplacé des années de communication professionnelle entre plateformes, et un seul oubli peut corrompre les metadonnées de toutes les boîtes aux lettres. La victime la plus fréquente ? Les dates des emails. Après migration, chaque email risque d'afficher la date de migration au lieu de la date d'envoi ou de réception d'origine.
Cette checklist couvre chaque phase du processus de migration. Suivez ces étapes pour minimiser le risque de corruption des dates et autres problèmes de metadonnées. Et si la migration est déjà terminée et que des problèmes de dates sont apparus, continuez la lecture.
Phase 1 : planification pré-migration
Inventorier les boîtes aux lettres
Avant de toucher à un outil de migration, documentez chaque boîte qui sera migrée. Enregistrez le nombre tôtal de boîtes, le nombre approximatif d'emails par boîte, la plage de dates des emails les plus anciens, et les boîtes partagees ou groupes de distribution. Cet inventaire détermine quel outil de migration utiliser, combien de temps la migration prendra, et quel tarif s'applique pour d'éventuelles corrections post-migration.
Choisir le bon outil de migration
Tous les outils de migration ne gèrent pas les dates de la même façon. Renseignez-vous sur la manière dont chaque outil gère la préservation de l'IMAP INTERNALDATE et s'il ajoute des en-têtes "Received" pendant le processus d'APPEND. Les outils populaires incluent BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO et l'import natif du Centre d'administration Exchange. Chacun de ces outils peut causer des problèmes de dates car le protocole IMAP lui-même exige que le serveur de destination ajoute un en-tête "Received" lors de l'insertion. Mais certains outils préservent mieux l'INTERNALDATE que d'autres. Pour mieux comprendre le fonctionnement de l'INTERNALDATE, voir IMAP INTERNALDATE : pourquoi les dates cassent.
Tout sauvegarder
Créez une sauvegarde complète de chaque boîte aux lettres avant la migration. Cette sauvegarde sert à la fois de filet de sécurité et de point de référence pour vérifier les dates après coup. Pour Google Workspace, utilisez Google Takeout ou un outil de sauvegarde tiers. Pour Microsoft 365, utilisez la sauvegarde Exchange Online ou l'export en PST. Pour les serveurs IMAP, utilisez imapsync pour créer une copie locale.
Stockez les sauvegardes dans un emplacement complètement séparé des serveurs source et destination.
Documenter les dates d'origine
Sélectionnez 10 à 20 emails par boîte répartis sur différentes plages de dates (les plus anciens, les plus récents et plusieurs intermédiaires). Enregistrez la date de "Réception", la date d'"Envoi" et les en-têtes bruts de chaque email. Ces emails de référence deviennent votre base de vérification après migration. Faites une capture d'ecran de la boîte triee par date pour documenter visuellement l'ordre chronologique d'origine.
Phase 2 : migration de test
Migrer d'abord une boîte de test
Ne lancez jamais une migration complète sans tester d'abord.
Créez une boîte de test avec un échantillon représentatif d'emails (au moins 100, couvrant plusieurs années). Lancez la migration sur cette seule boîte et examinez les résultats en profondeur avant de poursuivre. Ce test revele les problèmes de dates, les erreurs d'encodage, les bugs de gestion des pieces jointes et les écarts de structure de dossiers avant qu'ils n'affectent les boîtes de production.
Vérifier les dates sur la boîte de test
Après avoir migré la boîte de test, vérifiez les dates immédiatement. Ouvrez la boîte dans le client de messagerie que les utilisateurs finaux utiliseront réellement (Outlook, Apple Mail, Thunderbird ou l'interface webmail). Comparez les dates affichées avec les emails de référence documentés en Phase 1. Vérifiez à la fois les dates de "Réception" et d'"Envoi". Ouvrez les en-têtes bruts de plusieurs emails et cherchez les en-têtes "Received" nouvellement ajoutes avec l'horodatage de migration.
Si les dates sont fausses sur la boîte de test, elles seront fausses sur toutes les boîtes. Arrêtez tout et réglez le problème avant de procéder à la migration complète.
Tester avec plusieurs clients de messagerie
Les différents clients de messagerie affichent les dates différemment. L'interface web de Gmail peut montrer des dates correctes (elle utilise l'en-tête "Date") tandis qu'Outlook montre la date de migration (il privilégie l'en-tête "Received"). Testez avec chaque client que les utilisateurs de l'organisation utilisent, notamment Outlook Bureau, Outlook sur le web, Apple Mail, Thunderbird et toute application mobile de messagerie.
Phase 3 : exécution de la migration
Configuration de l'outil de migration
Configurez l'outil de migration pour préserver l'INTERNALDATE autant que possible. Dans imapsync, utilisez les flags appropriees pour définir l'INTERNALDATE sur la destination. Dans BitTitan MigrationWiz, vérifiez les paramètres avances pour les options de gestion des dates. Ces paramètres n'empêcheront pas complètement les problèmes d'en-tête "Received", mais ils réduisent la gravité des problèmes de dates dans certains clients. Documentez chaque paramètre de configuration utilise pour pouvoir reproduire la migration si nécessaire.
Migrer par lots
Ne migrez pas toutes les boîtes simultanement. Migrez par lots de 10 à 20 boîtes en vérifiant les dates après chaque lot. Si un lot montre des problèmes de dates, vous le détectez avant que toute l'organisation soit affectée. D'ailleurs, la migration par lots reduit aussi la charge sur les serveurs source et destination, diminuant le risque de timeouts ou d'erreurs de connexion qui peuvent causer des migrations partielles.
Surveiller la progression
Suivez la progression de la migration pour chaque boîte. Enregistrez l'heure de début, l'heure de fin, le nombre d'emails migrés et les erreurs éventuelles. Les outils de migration fournissent généralement des logs, conservez-les pour chaque boîte. Si des problèmes de dates sont decouverts plus tard, les logs aident à identifier exactement quel lot de migration et quels paramètres ont été utilisés.
Phase 4 : vérification post-migration
Vérifier les dates immédiatement
Vérifiez les dates des emails dans les 24 heures suivant la migration. Pour chaque lot, ouvrez 5 à 10 boîtes et comparez les dates avec les références pré-migration. Si les dates sont fausses, documentez l'étendue du problème (combien de boîtes affectées, combien d'emails par boîte) pendant que les informations sont fraîches.
Vérifier tous les types de dossiers
Les problèmes de dates peuvent affecter certains dossiers différemment. Vérifiez les dates dans la Boîte de réception, les Éléments envoyés, les Brouillons et tout dossier ou libellé personnalisé. Certains outils de migration traitent les dossiers séquentiellement, et des erreurs dans un dossier n'indiquent pas nécessairement des erreurs dans les autres.
Vérifier la recherche et le tri
Ouvrez une boîte migrée, triez par date et confirmez que l'ordre chronologique correspond à l'original. Recherchez des emails par plage de dates et vérifiez que les résultats sont exacts. Testez toute regle automatisée ou tout filtre qui depend des dates de réception. Si l'organisation utilise des outils de conformité ou d'eDiscovery, vérifiez que les requêtes basées sur les dates renvoient des résultats corrects.
Erreurs courantes qui causent des problèmes de dates
Sauter la migration de test
L'erreur la plus courante est de migrer toutes les boîtes sans tester d'abord. Quand les problèmes de dates sont decouverts, toutes les boîtes sont affectées et le serveur source a peut-être déjà été désactivé. Une migration de test de 30 minutes peut eviter des semaines de remédiation. Pourquoi s'en passer ?
Ignorer les ajouts d'en-têtes "Received"
Les administrateurs se concentrent souvent sur la préservation de l'INTERNALDATE et négligent le problème d'en-tête "Received". Même quand l'INTERNALDATE est correctement défini, l'en-tête "Received" de migration fait qu'Outlook et d'autres clients affichent la mauvaise date. C'est la source la plus fréquente de plaintes post-migration. Lisez pourquoi les emails affichent de mauvaises dates après migration pour une explication technique complète.
Désactiver le serveur source trop tôt
Si des problèmes de dates sont decouverts après l'arrêt du serveur source, l'option de re-migration disparait. Gardez le serveur source accessible (même en lecture seule) pendant au moins 30 jours après la migration. Cela fournit une solution de repli si des problèmes sérieux apparaissent plus tard.
Que faire si les dates sont déjà fausses
Si la migration a déjà été effectuée et que les dates sont incorrectes, le problème est réparable. L'en-tête "Date" d'origine est préservé dans chaque email, ce qui signifie que l'information de date correcte existe toujours. Les dates d'emails peuvent être corrigées après migration, même des mois ou des années plus tard.
Le moteur de correction propriétaire de Redate.io se connecte à la boîte et recherche les emails avec des metadonnées de date corrompues. Le pipeline d'analyse multi-étapes identifié les signatures de migration, applique des corrections ciblées tout en préservant l'intégrité des messages (y compris les signatures S/MIME, les structures multipart et les en-têtes non-ASCII), et execute une vérification d'intégrité sur chaque email corrigé. L'analyse est gratuite et montre exactement combien d'emails sont concernés. Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours.
Tenter ce genre de correction manuellement ou avec un script personnalisé est tentant mais risque. Les cas particuliers comme les messages chiffrés PGP, les limites MIME corrompues, les structures multipart imbriquées et les décalages de Content-Transfer-Encoding peuvent silencieusement corrompre des emails sans que l'on s'en rende compte avant qu'il ne soit trop tard. Et comment vérifier que 10000 emails corrigés sont tous intacts ?
Prêt a vérifier si votre boîte à des problèmes de dates ? Lancez une analyse gratuite avec Redate.io - aucun paiement requis pour voir combien d'emails sont concernés.