BitTitan MigrationWiz : corriger les dates d'emails

Ce que BitTitan MigrationWiz fait aux dates d'emails

La migration s'est terminée vendredi dernier. 47 boîtes aux lettres transférées depuis Exchange sur site vers Microsoft 365, tout au vert dans le tableau de bord MigrationWiz. Puis lundi matin, le premier ticket arrive : "Tous mes emails affichent le 28 mars 2026."

Chaque message, sans exception. Des années de correspondance, des propositions clients de 2019, des factures de 2021, tout estampillé avec la date de migration. Le journal MigrationWiz indique que tout a été transféré avec succès (et c'est techniquement vrai). Mais les dates ont disparu.

BitTitan MigrationWiz est l'un des outils les plus utilisés pour la migration email cloud-to-cloud. Il gère les migrations Exchange vers Microsoft 365, Google Workspace vers Exchange, les transferts cross-tenant, et bien d'autres scénarios. L'outil fonctionne bien pour ce qu'il fait. Le problème de dates n'est pas un bug de MigrationWiz. C'est une conséquence du fonctionnement du protocole IMAP au niveau transport, et MigrationWiz le déclenche d'une manière spécifique.

Comment MigrationWiz gère les en-têtes Received

Quand MigrationWiz transfère un email de la source vers la destination, il utilise le protocole IMAP (ou Exchange Web Services, selon le type d'endpoint). Pendant ce processus, le serveur de messagerie de destination ajoute un nouvel en-tête Received: contenant l'horodatage actuel, exactement comme il le ferait pour tout email entrant.

Voici à quoi ressemble une chaîne d'en-têtes Received typique après une migration MigrationWiz :

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

L'en-tête Received: original de 2019 est toujours là. L'en-tête Date: original aussi. Mais les clients de messagerie comme Outlook n'utilisent pas ceux-là. Outlook lit l'en-tête Received: le plus récent pour déterminer quand afficher le message, et cet en-tête indique désormais le 28 mars 2026.

La valeur INTERNALDATE (l'horodatage que les serveurs IMAP utilisent pour le tri) est également écrasée pendant le transfert. MigrationWiz tente de préserver les dates quand la destination le supporte, mais le résultat dépend fortement du comportement du serveur de destination. Le pipeline de transport de Microsoft 365, par exemple, écrase l'INTERNALDATE avec son propre horodatage de livraison, peu importe ce que MigrationWiz demande.

Pourquoi le "Date Mapping" de MigrationWiz ne suffit pas

BitTitan propose une fonctionnalité "Date Mapping" dans les Options avancées de MigrationWiz. Sur le papier, ça ressemble à la solution. En pratique, ça contrôle la plage de dates des messages à migrer, pas la préservation des dates à destination.

La confusion est compréhensible. Le paramètre contient le mot "date". Mais ce qu'il fait réellement, c'est filtrer les messages source par plage de dates avant la migration. Un message de 2018 arrive quand même à destination avec l'horodatage de migration.

Il y a aussi la question des endpoints IMAP vs Exchange. Quand MigrationWiz migre entre deux serveurs Exchange via EWS (Exchange Web Services), la préservation des dates fonctionne mieux parce qu'EWS offre plus de contrôle sur les métadonnées des messages. Mais dès qu'IMAP est impliqué d'un côté ou de l'autre, l'opération IMAP APPEND prend le relais et le serveur de destination décide quel horodatage utiliser.

Certains administrateurs ont tenté de relancer la migration avec des configurations d'endpoints différentes, espérant que le passage d'IMAP à EWS corrigerait les dates rétroactivement. Ça ne marche pas. Les messages sont déjà à destination avec les mauvaises dates. Relancer MigrationWiz ne ferait que créer des doublons.

Scénarios MigrationWiz spécifiques qui cassent les dates

Toutes les migrations MigrationWiz ne causent pas de problèmes de dates. Le problème dépend de la combinaison d'endpoints :

• Exchange (sur site) vers Microsoft 365 via IMAP : Les dates sont cassées. Le pipeline de transport M365 ajoute de nouveaux en-têtes Received et écrase l'INTERNALDATE.
• Google Workspace vers Microsoft 365 : Les dates sont cassées. MigrationWiz utilise IMAP pour lire depuis Google et écrit vers M365, qui ajoute ses en-têtes de transport.
• Exchange vers Exchange (EWS vers EWS) : Les dates sont généralement préservées. EWS contourne le pipeline de transport des deux côtés.
• N'importe quoi vers Google Workspace via IMAP : Les dates sont cassées. L'implémentation IMAP de Google ajoute un en-tête Received avec l'horodatage d'insertion.
• Cross-tenant Microsoft 365 : Dépend de la méthode. Le chemin IMAP casse les dates. L'EWS direct peut les préserver.

Le tableau de bord MigrationWiz ne signale pas les problèmes de dates. Tout apparaît comme "Completed" parce que les messages ont bien été transférés. Le contenu est intact, les pièces jointes sont là, la structure des dossiers est préservée. Ce sont uniquement les dates qui ont changé, et MigrationWiz ne considère pas ça comme une erreur de migration.

Le vrai coût des mauvaises dates après MigrationWiz

Les mauvaises dates d'emails ne sont pas juste gênantes. Pour les organisations qui ont migré avec BitTitan, les conséquences vont au-delà d'une boîte de réception désordonnée.

Les équipes juridiques ne peuvent pas utiliser les emails comme preuves quand chaque message affiche la date de migration au lieu de la date d'envoi réelle. Les contrôles fiscaux exigent des preuves chronologiques des communications. Les cadres de conformité comme le RGPD, eIDAS et les réglementations CNIL imposent une tenue de registres précise, et des emails avec des horodatages fabriqués ne répondent pas à cette exigence.

Et puis il y a le côté pratique. Essayez de retrouver cette discussion contractuelle de novembre 2022 quand toute votre boîte affiche mars 2026. Trier par date ? Inutile. Rechercher par plage de dates ? Retourne tout ou rien.

Pour les MSP qui ont utilisé MigrationWiz sur les environnements clients, ça crée un problème de responsabilité. Le client a payé pour une migration. Il en a eu une, mais son archive email est effectivement cassée pour tout flux de travail basé sur les dates.

Un MSP dont on a eu connaissance avait migré environ 380 boîtes aux lettres pour un cabinet d'avocats. Trois mois plus tard, l'équipe contentieux du cabinet a découvert le problème de dates pendant une phase de discovery. Chaque email qu'ils devaient présenter comme preuve affichait la date de migration. Le MSP a dû expliquer pourquoi 6 ans de correspondance horodatée affichaient tous juin 2025.

Corriger les dates BitTitan MigrationWiz

L'en-tête Date: original est toujours présent dans chaque email. MigrationWiz ne touche pas au corps du message ni aux en-têtes d'origine. Ce sont l'en-tête Received: supplémentaire et l'INTERNALDATE écrasé qui causent le problème d'affichage.

Redate.io se connecte à la boîte aux lettres (Google Workspace, Microsoft 365 ou IMAP), scanne les emails affectés par la migration MigrationWiz, et corrige les métadonnées de date via un pipeline d'analyse multi-étapes propriétaire. La correction cible spécifiquement la couche de métadonnées, en faisant du pattern matching contre les signatures d'en-têtes MigrationWiz connues, y compris les identifiants caractéristiques mx.migrationwiz.com et bittitan.com dans la chaîne Received.

Chaque email corrigé est individuellement vérifié par rapport à l'original. La vérification contrôle l'intégrité du message, la préservation des pièces jointes, le placement dans les dossiers et le threading. Les emails originaux sont conservés dans un dossier visible Redate.io - Originals pendant 30 jours en cas de besoin de rollback.

Comprendre le problème, c'est une chose. Corriger 15 000 emails sans perdre une seule pièce jointe, casser des signatures S/MIME ou corrompre des frontières MIME multipart, c'en est une autre. Un script qui fonctionne sur 10 messages de test en laboratoire ne gérera pas les cas limites d'une boîte de production avec 7 ans de correspondance, des messages chiffrés PGP et des en-têtes non-ASCII RFC 2047.

Comment vérifier que chaque message corrigé est intact ? Que le threading fonctionne toujours, que les invitations d'agenda se résolvent encore, que la pièce jointe de 47 Mo sur cet email de 2020 n'a pas été corrompue ? Redate.io fait tout cela automatiquement, pour chaque message. Et si quelque chose semble incorrect, l'original est là dans le dossier de sauvegarde.

Le scan gratuit prend environ deux minutes. Il se connecte à la boîte aux lettres, identifie chaque email estampillé avec la date de migration MigrationWiz, et affiche le nombre exact et le coût avant tout paiement. Pas de carte de crédit, pas d'engagement.

Guides de correction par plateforme pour BitTitan

Le processus de correction varie selon la destination où MigrationWiz a déplacé vos emails. Redate.io gère les spécificités de chaque plateforme automatiquement, mais pour les détails sur votre configuration :

• Corriger les dates BitTitan dans Outlook
• Corriger les dates BitTitan dans Microsoft 365
• Corriger les dates BitTitan dans Google Workspace
• Corriger les dates BitTitan dans Exchange Online

Redate.io fonctionne aussi pour les migrations terminées il y a des mois ou des années. L'en-tête Date original n'expire pas.

Migration avec BitTitan MigrationWiz et des dates incorrectes ? Lancez un scan gratuit pour voir exactement combien d'emails sont affectés avant de vous engager.