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 question de date : celle que porte chaque copie quand elle est écrite dans la nouvelle boîte.

Où se trouve vraiment la mauvaise date

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). La destination, elle, garde la date qu'on lui donne : Microsoft 365, Outlook.com et Gmail conservent la date d'origine quand la copie la porte. Si chaque email affiche la date de migration, c'est donc la date que MigrationWiz a transmise, ou n'a pas transmise, qui est en cause.

Voici ce que les en-têtes d'un de ces emails portent encore après une migration MigrationWiz :

Date: Tue, 15 Jan 2019 09:32:10 +0100
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

L'en-tête Date: d'origine de 2019 est toujours là, comme la chaîne Received: d'origine. Et dans Microsoft 365, la date qu'Outlook affiche comme date de réception est l'enregistrement que fait la boîte de l'arrivée de chaque email : si MigrationWiz n'a pas transmis la date d'origine, cet enregistrement dit 28 mars 2026.

La valeur INTERNALDATE (l'horodatage que les serveurs IMAP utilisent pour le tri) est la date que la copie a reçue. MigrationWiz tente de préserver les dates, et Microsoft 365 garde la date qu'on lui donne : quand les dates ressortent quand même fausses, c'est que la date transmise pour chaque email n'était pas celle d'origine.

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. En IMAP aussi, la destination garde la date qu'on lui donne : ce qui compte, c'est que la date d'origine soit transmise.

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 erronées. Chaque email reçoit la date de la copie.
• Google Workspace vers Microsoft 365 : Les dates sont erronées. MigrationWiz utilise IMAP pour lire depuis Google et écrit vers M365 sans la date d'origine.
• Exchange vers Exchange (EWS vers EWS) : Les dates sont généralement préservées. En EWS, la date d'origine voyage avec le message.
• N'importe quoi vers Google Workspace via IMAP : En IMAP, Gmail garde la date que l'outil transmet et n'ajoute rien. Les dates ne sont fausses que si cette date n'est pas celle d'origine, ou si la copie passe par l'API d'import de Gmail, qui ajoute une ligne Received: datée du jour de la copie.
• Cross-tenant Microsoft 365 : Tout dépend de la date que la méthode transmet.

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 inexploitable 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. C'est la date que la boîte a enregistrée pour chaque copie qui cause 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, et elle n'a pas besoin de savoir quel outil a fait la migration : elle repère les emails dont la date affichée ne correspond pas à leur date d'origine.

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 jusqu'à ce que vous les supprimiez vous-même, 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.