Redate.io

BitTitan MigrationWiz: メール日付の修正方法

1 min

BitTitan MigrationWizがメールの日付に与える影響

金曜日に移行が完了しました。47個のメールボックスがオンプレミスのExchangeからMicrosoft 365に移動され、MigrationWizのダッシュボードではすべてグリーン表示。そして月曜の朝、最初のチケットが届きます。「すべてのメールが2026年3月28日と表示されている。」

すべてのメッセージが同じ状態です。2019年のクライアント提案書、2021年の請求書、何年にもわたる業務メール、すべてが移行日の日付で表示されます。MigrationWizのログでは、すべてが正常に転送されたと記録されています（技術的にはその通りです）。しかし日付は失われました。

BitTitan MigrationWiz（リデイト）は、クラウド間メール移行で最も広く使用されているツールの一つです。ExchangeからMicrosoft 365、Google WorkspaceからExchange、テナント間の移動など、さまざまな移行に対応しています。ツール自体は設計通りに動作します。日付の問題はMigrationWizのバグではありません。IMAPプロトコルレベルでの移行の仕組みに起因する結果であり、MigrationWizがそれを特定の方法でトリガーするのです。

MigrationWizのReceivedヘッダー処理

MigrationWizがソースから宛先にメールを転送する際、IMAPプロトコル（またはエンドポイントのタイプに応じてExchange Web Services）を使用します。このプロセス中に、宛先メールサーバーは現在のタイムスタンプを含む新しいReceived:ヘッダーをメッセージに付加します。これは受信メールに対して行われる通常の処理と同じです。

MigrationWiz移行後の典型的なReceivedヘッダーチェーンは以下のようになります。

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

2019年のオリジナルのReceived:ヘッダーはそのまま残っています。オリジナルのDate:ヘッダーも同様です。しかしOutlookのようなメールクライアントはそれらを使用しません。Outlookはメッセージの表示時刻を決定するために最新のReceived:ヘッダーを読み取りますが、そのヘッダーは今や2026年3月28日を示しています。

INTERNALDATEの値（IMAPサーバーがソートに使用するタイムスタンプ）も転送中に上書きされます。MigrationWizは宛先がサポートする場合に日付を保持しようとしますが、結果は宛先サーバーの動作に大きく依存します。実は、Microsoft 365のトランスポートパイプラインは、MigrationWizの要求に関係なく、INTERNALDATEを独自の配信タイムスタンプで上書きします。

MigrationWizの日付マッピングが機能しない理由

BitTitanはMigrationWizの詳細オプションで"Date Mapping"機能を提供しています。書面上は解決策に見えます。しかし実際には、移行するメッセージの日付範囲を制御するだけで、宛先での日付保持方法を制御するものではありません。

混乱するのは当然です。設定名に「日付」と書いてあります。しかし実際に行うのは、移行前にソースメッセージを日付範囲でフィルタリングすることです。2018年のメッセージも移行タイムスタンプで宛先に届きます。

IMAPとExchangeエンドポイントの問題もあります。MigrationWizがEWS（Exchange Web Services）を使用して2つのExchangeサーバー間で移行する場合、EWSはメッセージのメタデータに対するコントロールが大きいため、日付の保持がうまく機能します。しかしIMAPがソース側でも宛先側でも関与した瞬間、IMAP APPEND操作が引き継ぎ、宛先サーバーがどのタイムスタンプを使用するかを決定します。

一部の管理者は異なるエンドポイント構成で移行を再実行し、IMAPからEWSへの切り替えで日付が遡及的に修正されることを期待しました。修正されません。メッセージはすでに誤った日付で宛先にあります。MigrationWizを再実行すると重複が作成されるだけです。

日付を破壊する具体的なMigrationWizシナリオ

すべてのMigrationWiz移行で日付の問題が発生するわけではありません。問題はエンドポイントの組み合わせに依存します。

  • Exchange（オンプレミス）からMicrosoft 365へ（IMAP経由）: 日付が破壊されます。M365のトランスポートパイプラインが新しいReceivedヘッダーを追加し、INTERNALDATEを上書きします。
  • Google WorkspaceからMicrosoft 365へ: 日付が破壊されます。MigrationWizはGoogleからIMAPで読み取り、トランスポートヘッダーを追加するM365に書き込みます。
  • ExchangeからExchangeへ（EWSからEWS）: 日付は通常保持されます。EWSは両側でトランスポートパイプラインをバイパスします。
  • 任意のソースからGoogle Workspaceへ（IMAP経由）: 日付が破壊されます。GoogleのIMAP実装は挿入タイムスタンプ付きのReceivedヘッダーを追加します。
  • テナント間Microsoft 365移行: 方法によります。IMAPパスは日付を破壊します。直接EWSは保持できる場合があります。

MigrationWizのダッシュボードは日付の問題をフラグしません。メッセージは実際に正常に転送されたため、すべて"Completed"と表示されます。コンテンツは完全、添付ファイルは正常、フォルダ構造は保持。変わったのは日付だけであり、MigrationWizはそれを移行エラーとして追跡しません。

MigrationWiz後の誤った日付の実際のコスト

誤ったメール日付は単に不便なだけではありません。BitTitanで移行した組織にとって、影響は受信トレイの乱れを超えています。

法務チームは、すべてのメッセージが実際の送信日ではなく移行日を表示している状態では、メールを証拠として使用できません。税務監査では通信の時系列的な証明が必要です。SOX、HIPAA、GDPRなどのコンプライアンスフレームワークは正確な記録管理を義務付けており、偽造されたタイムスタンプのメールはその要件を満たしません。

そして実務的な問題もあります。メールボックス全体が2026年3月を表示している状態で、2022年11月の契約に関する議論を見つけようとしてみてください。日付で並べ替え? 役に立ちません。日付範囲で検索? すべてが返されるか何も返されないかのどちらかです。

クライアント環境でMigrationWizを使用したMSPにとって、これは責任問題を生み出します。クライアントは移行に対して支払いました。移行は完了しましたが、メールアーカイブは日付ベースのワークフローに対して事実上機能しなくなっています。

ある法律事務所に対して約380のメールボックスを移行したMSPの話を聞きました。3か月後、その事務所の訴訟チームがドキュメントディスカバリーの過程で日付の問題を発見しました。証拠として提示する必要があるすべてのメールが移行日を表示していました。MSPは6年分のタイムスタンプ付き通信がなぜすべて2025年6月を表示しているのか説明しなければなりませんでした。

BitTitan MigrationWizの日付を修正する

オリジナルのDate:ヘッダーはすべてのメール内にまだ存在しています。MigrationWizはメッセージ本文やオリジナルのヘッダーには触れません。追加されたReceived:ヘッダーと上書きされたINTERNALDATEが表示の問題を引き起こしています。

Redate.ioはメールボックス（Google Workspace、Microsoft 365、またはIMAP）に接続し、MigrationWiz移行の影響を受けたメールをスキャンし、独自のマルチステージ分析パイプラインを通じて日付メタデータを修正します。修正はメタデータ層を対象とし、Receivedチェーン内のmx.migrationwiz.comやbittitan.comの特徴的な識別子を含む、既知のMigrationWizヘッダーシグネチャとのパターンマッチングを行います。

修正されたすべてのメールはオリジナルと個別に検証されます。検証ではメッセージの整合性、添付ファイルの保持、フォルダ配置、スレッドの動作を確認します。オリジナルのメールはロールバックが必要な場合に備えて、Redate.io - Originalsフォルダに30日間保持されます。

問題を理解することと、15,000通のメールを添付ファイルの損失、S/MIME署名の破壊、マルチパートMIME境界の破損なしに修正することは全く別の話です。ラボで10通のテストメッセージで動作するスクリプトでは、7年分の通信、PGP暗号化メッセージ、RFC 2047非ASCIIヘッダーを含む本番メールボックスのエッジケースは処理できません。

修正された各メッセージが完全であることをどう検証しますか? スレッドがまだ機能しているか、カレンダー招待がまだ解決されるか、2020年のあのメールの47MBの添付ファイルが破損していないか? Redate.ioはこれをすべてのメッセージに対して自動的に実行します。そして何か問題があれば、オリジナルはバックアップフォルダにすぐそこにあります。

無料スキャンは約2分で完了します。メールボックスに接続し、MigrationWiz移行日のタイムスタンプが付いたすべてのメールを特定し、支払い前に正確な件数と費用を表示します。クレジットカード不要、契約不要です。

BitTitanユーザー向けプラットフォーム別修正ガイド

修正プロセスはMigrationWizがメールを移動した先によって異なります。Redate.ioは各プラットフォームの仕様を自動的に処理しますが、お使いの環境の詳細が必要な場合は以下をご覧ください。

Redate.ioは数か月前や数年前に完了した移行にも対応しています。オリジナルのDateヘッダーには有効期限がありません。

BitTitan MigrationWizで移行して誤った日付のままですか? 無料スキャンを実行して、何かを決定する前に影響を受けているメールの正確な件数を確認してください。

関連記事

Exchange Online移行後のメール日付破損を修正する

EAC経由のIMAP移行後、メールの日付がすべて移行日になっていませんか？原因と修正方法をIT管理者向けに詳しく解説します。

Exchange IMAPインポート:メール日付がずれる原因

EACやPowerShellを通じたExchange IMAPインポートはメール日付を上書きします。Exchangeのトランスポートパイプラインが原因となる仕組みと修正方法を解説します。

GSMMO移行でメール日付が変わった場合の修正方法

GSMMOはPSTやOutlookデータをGoogle Workspaceに移行する際にメール日付を変更します。原因と正しい日付の復元方法を解説します。