次の方法で共有

Microsoft 365 と Office 365 のメール移行のパフォーマンスとベスト プラクティス

  • [アーティクル]

オンプレミスでホストされている組織のメール データを Microsoft 365 または Office 365 に移行するためのパスは多数あります。 Microsoft 365 または Office 365 への移行を計画する場合は、データ移行プロセスと速度を明確に理解することで、管理者がより良い計画を立てるのに役立ちます。

Microsoft 365 または Office 365 へのメールの移行の概要

Microsoft 365 または Office 365 では、「複数のメール アカウントを Microsoft 365 または Office 365 に移行する方法」で説明されているように、メール、予定表、連絡先のデータを既存のメッセージング環境から Microsoft 365 または Office 365 に移行するためのいくつかの方法がサポートされています。

Microsoft 365 または Office 365 のネットワークとパフォーマンスに関連する質問については、「 Microsoft 365 または Office 365 のネットワーク計画とパフォーマンスチューニング」を参照してください。

よく使用される移行方法

移行方法 説明 リソース
インターネット メッセージ アクセス プロトコル (IMAP) 移行 Exchange 管理センターまたは Exchange Online PowerShell を使用して、ユーザーのメールボックスの内容を IMAP メッセージング システムから Microsoft 365 または Office 365 メールボックスに移行できます。 これには、Gmail や Yahoo Mail などの Microsoft 以外のホスティング メール サービスからのメールの移行が含まれます。 Exchange Online では、組織の既存の Gmail/G Suite/Google WorkSpace (GWS) 展開から Exchange Online にメールを移行するための高度に特殊なプロセスがモダン EAC で提供されるようになりました。 IMAP メールボックスを Microsoft 365 または Office 365 に移行する
カットオーバー移行 カットオーバー移行を使用して、オンプレミスのすべてのメールボックスを数日間にわたって Microsoft 365 または Office 365 に移行します。 メール組織全体を Microsoft 365 または Office 365 に移行し、Microsoft 365 または Office 365 でユーザー アカウントを管理する場合は、カットオーバー移行を使用します。 カットオーバー移行を使用して、オンプレミスの Exchange 組織から Microsoft 365 または Office 365 に最大 2,000 個のメールボックスを移行できます。 ただし、推奨されるメールボックスの数は 150 です。 パフォーマンスは、それより大きい数値で低下する可能性があります。 また、オンプレミス Exchange 組織のメール連絡先と配布グループも移行されます。 Microsoft 365 または Office 365 への一括移行
段階的な移行 段階的な移行は、最終的に組織のすべてのメールボックスを Microsoft 365 または Office 365 に時間をかけて移行する予定の場合に使用します。 段階的な移行を使用して、数週間または数か月間、オンプレミスメールボックスのバッチを Microsoft 365 または Office 365 に移行します。 Microsoft 365 または Office 365 への段階的なメール移行について知っておくべきこと
ハイブリッド展開 ハイブリッド展開により、組織は、既存のオンプレミス Exchange 組織との機能豊富なエクスペリエンスと管理制御をクラウドに拡張できます。 ハイブリッド展開は、オンプレミスの Exchange 組織と Microsoft 365 または Office 365 の Exchange Online の間で、単一の Exchange 組織のシームレスな外観を提供します。 さらに、ハイブリッド展開は、Microsoft 365 または Office 365 組織に完全に移行するための中間ステップとして機能します。 Microsoft 365 および Office 365 メール移行アドバイザー

Exchange Server のハイブリッド展開

メール移行アドバイザー

Exchange オンプレミスの Exchange 展開アシスタント 2013/2016/2019

Exchange Server 2013 ハイブリッド展開

最低限のハイブリッド構成
サード パーティを利用した移行 サード パーティから入手できるツールは数多くあります。 GWS、GoDaddy、Yahoo、IBM Lotus Notes、Novell GroupWise などのメール プラットフォームから電子メールの移行を行うために、独自のプロトコルとアプローチを使用します。 サード パーティ プラットフォームから Exchange に移行する場合に利用できるサード パーティの移行ツールとパートナーを以下に示します。

バイナリ ツリー / クエスト / QuadroTech: バイナリ ツリーと QuadroTech が Quest の一部になりました。 Quest は、クロスプラットフォーム メッセージングの移行と共存ソフトウェアのプロバイダーであり、複数のプラットフォーム間の分析、共存、および移行のための製品を Exchange Online に提供します。 クエスト ソリューションは、移行中の共存を維持しながら、メールボックス、パブリック フォルダー、予定表情報を同期します。

BitTitan: さまざまなプラットフォームから Microsoft 365 または Office 365 に移行するための自動化されたソリューションを提供します。

CodeTwo: Exchange On-Prem、IMAP サーバー、Microsoft 365 テナント間の Microsoft 365 (Office 365) への安全で自動化されたデータ移行のための Microsoft 365 および Office 365 移行ソリューションのプロバイダー。

Transvault: Exchange および Notes から Microsoft 365 へのクラウド Office 移行ソリューションのプロバイダー。 Transvaultは、移行のためのソースの数十をサポートし、プロジェクトの任意のサイズ、複雑な電子メールアーカイブの移行と PST 管理を提供する製品を提供しています。 エンタープライズ移行ソリューションは、セキュリティで保護され、準拠しており、効率的で、ユーザーに焦点を当て、オンプレミスとクラウドの両方で実行できます。

SkyKick: 複数のソースの種類から Microsoft 365 または Office 365 に移行するための自動移行ソリューションのプロバイダー。 エンドツーエンドの移行ツールにより、移行プロジェクトの販売、計画、移行、管理、およびオンサイトの各フェーズでパートナーを支援します。

BCC: コラボレーション移行戦略をサポートすることで、企業を支援します。 Microsoft Exchange、Microsoft 365、および Office 365 に移行するための、Domino プラットフォームに基づく移行ツールのクラス最高のサプライヤー。

移行方法のパフォーマンス

次のセクションでは、メールボックスとメールボックス データを Microsoft 365 または Office 365 に移行するためのさまざまな移行方法について、メールボックスの移行ワークロードと観察されたパフォーマンス結果を比較します。 これらの結果は、内部テストと、Microsoft 365 または Office 365 への実際の顧客移行に基づいています。

重要

移行の実行方法と実行時期の違いにより、実際の移行速度が異なる場合があります。

顧客移行ワークロード

次の表では、一般的な移行に関連するさまざまなワークロードと、それぞれの課題とオプションについて説明します。

Workload Notes (メモ)
オンボード (Microsoft 365 または Office 365 への移行) Microsoft では、データ移行機能とツールを使用して、Exchange Server オンプレミス ( カットオーバー/ステージング/ハイブリッド経由) または Gmail/S Suite/GWS ( EAC、 PowerShell 経由) または 他の IMAP ソース (PowerShell、 Gmail via IMAP) または テナント間の移行 から Microsoft 365 または Office 365 で Exchange Online にデータを移行するためのツールを提供しています。
Multi-Geo 世界中にオフィスを持つ多国籍企業は、多くの場合、データ所在地の要件を満たすために、特定の地域に保存されている従業員データを格納する必要があります。 複数地域を使用すると、1 つの Microsoft 365 または Office 365 組織が複数の Microsoft 365 または Office 365 データセンター地域 (geo) にまたがることができます。これにより、選択した地域に Exchange データを保存し、ユーザーごとに保存できます。 詳細については、「 Multi-Geo を使用してエンタープライズ レベルのグローバル データの場所コントロールを取得する」を参照してください。
暗号化 顧客キーを使用したサービス暗号化は、Microsoft 365 または Office 365 のアプリケーション 層で保存データを暗号化するために使用されるルート キーをプロビジョニングおよび管理できる機能です。 メールボックスを初めて暗号化するには、メールボックスの移動が必要です。 詳細については、「 Microsoft Purview カスタマー キーを使用したサービス暗号化」を参照してください。
GoLocal Microsoft は引き続き、新しいリージョン (geo) に新しいデータセンターを開いています。 既存の顧客は、対象となる場合に、元のデータセンターの顧客データを新しい geo に移動するように要求できます。 この要求を行うことができる期間は、通常、サービスの全体的な需要に応じて 1 年または 2 年です。 顧客データの移動を要求できるこの期間は、新しい geo の起動のデータセンター (DC) が短くなることに注意してください (その時点で、移動を要求するには約 3 ~ 6 か月です)。 詳細については、「 新しい Microsoft 365 データセンター geo へのコア データの移動」を参照してください。

Microsoft 365 データ センター内でメールボックスを移行する場合、すべてのメールボックスの移動または一括メールボックスの移動には、操作が完了するまでの時間が必要です。 Microsoft 365 サービス アクティビティなど、正確にどのくらいの時間に影響を与える可能性があるいくつかの要因があります。 このサービスは、メールボックスの移動などの随意のワークロードを調整して、すべてのユーザーに対してサービスが最適に実行されるように設計されています。 ただし、サービスの任意のリソースの可用性に応じて、メールボックスの移動が処理されることを期待できます。 リソースの調整の詳細については、 このブログ投稿を参照してください。

Exchange Online でのメールボックス移行の期間の見積もり

移行を計画するために、次の表に、一括メールボックスの移行または個々の移行が完了するタイミングに関するガイドラインを示します。 これらの見積もりは、以前の顧客移行のデータ分析に基づいています。 すべての環境が一意であるため、正確な移行速度は異なる場合があります。

メールボックスのサイズ プロファイルに基づくメールボックスの移行期間:

  • GoLocal/Multi-Geo/Exchange Online での暗号化

    Workload メールボックス サイズ (GB) P50 (50 パーセンタイル期間) (日) P90 (90 パーセンタイル期間) (日数)
    GoLocal/Multi-Geo/Encryption 0 - 10 1 1
    GoLocal/Multi-Geo/Encryption 10 - 50 2 6
    GoLocal/Multi-Geo/Encryption 50 - 100 4 11
    GoLocal/Multi-Geo/Encryption 100 - 200 6 14
    GoLocal/Multi-Geo/Encryption > 200 非サポート 非サポート

  • オンプレミスの Exchange サーバーからの Exchange Online へのオンボード (カットオーバー/ステージング/ハイブリッド)

    Workload メールボックス サイズ (GB) P50 (50 パーセンタイル期間) (日) P90 (90 パーセンタイル期間) (日数)
    オンプレミスからのオンボード 0 - 10 1 3
    オンプレミスからのオンボード 10 - 50 2 6
    オンプレミスからのオンボード 50 - 100 4 13
    オンプレミスからのオンボード 100 - 200 10 31
    オンプレミスからのオンボード > 200 非サポート 非サポート

  • Exchange Online へのテナント間移行 ( Microsoft ファースト パーティ ソリューション を使用するか 、サード パーティソリューションを使用します)。

    Workload メールボックス サイズ (GB) P50 (50 パーセンタイル期間) (日) P90 (90 パーセンタイル期間) (日数)
    テナント間 0 - 10 1 1
    テナント間 10 - 50 1 2
    テナント間 50 - 100 2 5
    テナント間 100 - 200 3 6
    テナント間 > 200 サポート対象外 非サポート

  • Gmail/G Suite/GWS (EAC、 PowerShell) から Exchange Online への特別なオンボード

    Workload メールボックス サイズ (GB) P50 (50 パーセンタイル期間) (日) P90 (90 パーセンタイル期間) (日数)
    特殊化された Gmail オンボード 0 - 10 1 2
    特殊化された Gmail オンボード 10 - 50 1 8
    特殊化された Gmail オンボード 50 - 100 3 12
    特殊化された Gmail オンボード 100 - 200 5 19
    特殊化された Gmail オンボード > 200 サポート対象外 非サポート

  • IMAP ソース (その他の IMAP ソース、PowerShell、IMAP 経由の Gmail) から Exchange Online にオンボードする

    Workload メールボックス サイズ (GB) P50 (50 パーセンタイル期間) (日) P90 (90 パーセンタイル期間) (日数)
    汎用 IMAP オンボード 0 - 10 1 1
    汎用 IMAP オンボード 10 - 50 1 2
    汎用 IMAP オンボード 50 - 100 1 8
    汎用 IMAP オンボード 100 - 200 3 29
    汎用 IMAP オンボード > 200 非サポート 非サポート

  • PST インポートを使用した Exchange Online へのオンボード

    Workload メールボックス サイズ (GB) P50 (50 パーセンタイル期間) (日) P90 (90 パーセンタイル期間) (日数)
    PST インポート 0 - 10 1 1
    PST インポート 10 - 50 1 3
    PST インポート 50 - 100 2 5
    PST インポート 100 - 200 3 6
    PST インポート > 200 非サポート 非サポート

注:

一部の外れ値メールボックスは、メールボックス プロファイルに基づいて完了するまでに時間がかかります。 また、テナントのメールボックスが平均して大きい場合は、移行期間の延長にも影響する可能性があります。

移行のパフォーマンス要因

メールボックス/電子メールの移行には、移行のパフォーマンスに影響を与えるいくつかの一般的な要因があります。

一般的な移行パフォーマンス要因

以下の表は、移行パフォーマンスに影響を与える一般的な要因の一覧を示しています。 詳細については、個別の移行方法に関するセクションで説明します。

要因 説明 例
データ ソース 移行するデータをホストするデバイスまたはサービス。 ハードウェア仕様、エンド ユーザー ワークロード、バックエンド保守作業に伴うさまざまな制限がデータ ソースに適用されます。 Gmail では一定時間に抽出可能なデータ量が制限されています。
データの種類および密度 お客様のビジネスはそれぞれユニークなため、メールボックス内のメール アイテムの種類および各種類の割合は大きく異なります。 それぞれに 10 MB の添付ファイルが付属する 400 アイテムが保存された 1 つの 4 GB メールボックスは、アイテム数が 100,000 未満の 1 つの 4 GB メールボックスよりも移行に時間がかかりません。
移行サーバー 多くの移行ソリューションでは、中継機能を担う移行サーバーまたはワークステーションを使用して移行を実行します。 お客様が、ハイブリッド展開用の MRSProxy サービスやクライアント PC の非ハイブリッド移行をホストするために、低パフォーマンスの仮想マシンを使用していることはよくあります。
移行エンジン ソース サーバーからデータをプルするデータ移行エンジンは、必要に応じてデータを変換します。 その後、エンジンはネットワーク経由でデータを送信し、データを Microsoft 365 または Office 365 メールボックスに挿入します。 メールボックス。 MRSProxy サービスには、固有の機能および制限があります。
オンプレミス ネットワーク アプライアンス エンドツーエンドのネットワーク パフォーマンス (データ ソースから Exchange Online クライアント アクセス サーバーまで) は、移行のパフォーマンスに影響します。 オンプレミス組織でのファイアウォールの構成および仕様。
Microsoft 365 または Office 365 サービス Microsoft 365 と Office 365 には、移行ワークロードを管理するためのサポートと機能が組み込まれています。 ユーザー調整ポリシーには既定の設定があり、全体的な最大データ転送レートを制限します。

ネットワークのパフォーマンス要因

ここでは、移行中のネットワーク パフォーマンスを向上するためのベスト プラクティスについて説明します。 移行中のネットワーク パフォーマンスに対する影響のうち最も大きいものは、サード パーティのハードウェアおよびインターネット サービス プロバイダー (ISP) に関連するため、一般的な説明にとどめます。

Exchange Analyzer を使用して、Microsoft 365 または Office 365 とのネットワーク接続についてより深く理解します。 Microsoft サポートおよび回復アシスタントで Exchange Analyzer テストを実行するには、[Advanced Diagnostics > Exchange Online Check Exchange Online > ネットワーク接続>はい] に移動します。 Microsoft サポートと回復アシスタントの詳細については、 Microsoft サポートと回復アシスタントに関する記事を参照してください。

要因 説明 ベスト プラクティス
ネットワーク キャパシティ メールボックスを Microsoft 365 または Office 365 に移行するのにかかる時間は、ネットワークの使用可能な最大容量によって決まります。 ネットワークの利用可能キャパシティを特定して、最大アップロード キャパシティを判断します。
ISP に問い合わせて、割り当て済みの帯域幅を確認し、一定時間に転送可能な合計データ量などの制限の詳細について把握します。
ツールを使用して実際のネットワーク キャパシティを評価します。 オンプレミスのデータ ソースから Microsoft のデータセンター ゲートウェイ サーバーまでのエンドツーエンドのデータ フローを必ずテストしてください。
ネットワーク キャパシティに影響する可能性があるその他のネットワークに対する負荷 (バックアップ ユーティリティや定期保守など) を特定します。
ネットワークの安定性 ネットワークが高速であれば常に移行が速くなるとは限りません。 ネットワークが安定していない場合は、エラー修正が発生するためデータ転送の時間が長くなります。 移行の種類によっては、エラー修正が移行のパフォーマンスに大きく影響する場合があります。 多くの場合、ネットワークのハードウェアおよびドライバーに関する問題がネットワークの安定性に関する問題を引き起こします。 ハードウェア ベンダーと協力してネットワーク デバイスを理解し、ベンダーが提供する最新の推奨ドライバーおよびソフトウェア更新プログラムを適用してください。
ネットワークの遅延 侵入検出機能がネットワーク ファイアウォールで構成されていると、大幅なネットワークの遅延を引き起こすことが多く、移行のパフォーマンスに影響します。
Microsoft 365 または Office 365 メールボックスへのデータの移行は、インターネット接続に依存します。 インターネットの遅延は、移行全体のパフォーマンスに影響します。
また、同じ会社内のユーザーが、地理的に離れた場所にあるデータセンターにクラウド メールボックスを所有している場合もあります。 お客様の ISP によって、移行のパフォーマンスが異なる可能性があります。		 使用する可能性があるすべての Microsoft データセンターとの間のネットワーク遅延を評価して結果が一定であることを確認します (これで、エンド ユーザーに対する安定したパフォーマンスを保証しやすくなります)。 (これは、エンド ユーザーの一貫性のあるエクスペリエンスを確保するのにも役立ちます)。インターネット関連の問題に対処するには、ISP と協力してください。
Microsoft データセンター サーバーの IP アドレスを許可リストに追加するか、ネットワーク ファイアウォールからすべての移行関連トラフィックをバイパスします。 Microsoft 365 または Office 365 の IP 範囲の詳細については、「 Microsoft 365 および Office 365 の URL と IP アドレス範囲」を参照してください。

環境内の移行の詳細な分析については、 メールボックス移行パフォーマンス分析に関するページを参照してください。 この投稿には、移動要求の分析に役立つスクリプトが含まれています。

Microsoft 365 と Office 365 の調整

Microsoft 365 と Office 365 は、セキュリティとサービスの可用性を確保するためにさまざまな調整メカニズムを使用します。 次の 3 種類の調整が移行のパフォーマンスに影響する可能性があります。

  • ユーザー調整
  • 移行サービス調整
  • リソース正常性ベースの調整

注:

Microsoft 365 と Office 365 の 3 種類の調整は、すべての移行方法に影響を与えるわけではありません。

Microsoft 365 と Office 365 のユーザー調整

ユーザー調整は、ほとんどのサード パーティ製移行ツールおよびクライアントのアップロードによる移行方法に影響を与えます。 これらの移行方法では、HTTP プロトコル経由のリモート プロシージャ コール (RPC) などのクライアント アクセス プロトコルを使用して、メールボックス データを Microsoft 365 または Office 365 メールボックスに移行します。 これらのツールは、IBM Lotus Domino や Novell GroupWise などのプラットフォームからデータを移行する場合に使用されます。

ユーザーの調整は、Microsoft 365 と Office 365 で最も制限の厳しい調整方法です。 ユーザー調整は個別のエンド ユーザーに対して動作するようにセットアップされるため、アプリケーション レベルで使用すると調整ポリシーを超過しやすく、データ移行の速度が遅くなります。

Microsoft 365 と Office 365 の移行サービスの調整

移行サービスの調整は、すべての Microsoft 365 または Office 365 移行ツールに影響します。 移行サービスの調整は、Microsoft 365 または Office 365 移行ソリューションの移行コンカレンシーとサービス リソースの割り当てを管理します。

移行サービス調整は、次の移行方法を使用して実行される移行に影響を与えます。

  • IMAP 移行
  • Exchange の一括移行
  • 段階的な Exchange の移行
  • ハイブリッド移行 (ハイブリッド環境における MRSProxy サービス ベースの移動)

重要

前述の移行方法は、ユーザーの調整の影響を受けません。

移行サービス調整の例として、単純な Exchange の移行および IMAP 移行中に同時に移行されるメールボックス数の制御があります。 既定値は 20 です。 つまり、すべての移行バッチから最大 20 個のメールボックスがいつでも移行されます。 Exchange 管理センターまたは Windows PowerShell で、移行バッチの同時メールボックス移行の数を増やすことができます。 この設定を最適化する方法の詳細については、「 Microsoft 365 または Office 365 で移行バッチを管理する」を参照してください。

Microsoft 365 または Office 365 リソースの正常性ベースの調整

すべての移行方法は利用可能時間の調整により管理されます。 ただし、Microsoft 365 または Office 365 サービスの調整は、前に説明した他の種類の調整ほど Microsoft 365 または Office 365 の移行には影響しません。

リソース正常性ベースの調整は、最も消極的な調整方法です。 エンド ユーザーおよび重大なサービス操作に影響を与える可能性があるサービス利用可能時間の問題を防ぐために実行されます。

エンド ユーザーのパフォーマンスが影響を受ける可能性があるレベルまでサービスのパフォーマンスが低下した場合は、パフォーマンスが回復してサービスが調整のしきい値未満のレベルに戻るまでの間、ハイブリッド移行がキューに登録されます。

次に、コマンドレットを使用したストール期間に関するお客様の表示内容を Get-MoveRequestStatistics - <> -IncludeReport 示します。

$R.REPORT.TARGETTHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 00:02:07.6222549
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:38:41.7018480
CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:26:34.6588104
DISKLATENCYTHROTTLE : 1.15:45:37.7873632

$R.REPORT.SOURCETHROTTLES
NETWORKTHROTTLE : 00:00:00
CPUTHROTTLE : 3.03:21:07.7192848
REMOTESERVERTHROTTLE : 00:00:00
MDBREPLICATIONTHROTTLE : 00:00:00

CONTENTINDEXINGTHROTTLE : 00:00:00
BIGFUNNELTHROTTLE : 00:00:00
MDBAVAILABILITYTHROTTLE : 00:00:00
DISKLATENCYTHROTTLE : 00:20:47.1101552
MDBMAINTENANCETHROTTLE : 00:00:00

ソリューションとプラクティス:

同等の状況が発生した場合は、Microsoft 365 または Office 365 のリソースが利用可能になるまで待ちます。

非ハイブリッド展開での移行のパフォーマンスの要因およびベスト プラクティス

このセクションでは、IMAP による移行、一括移行、段階的な移行の各方法に影響する要因について説明します。 また、移行のパフォーマンスを向上させるためのベスト プラクティスも示します。

要因 1: ハイブリッド以外のデプロイ移行のデータ ソース

次の表では、現在の電子メール組織の移行元サーバーによる移行への影響、および移行への影響を軽減するためのベスト プラクティスについて説明します。

チェックリスト 説明 ベスト プラクティス
システムのパフォーマンス データ抽出は、リソースを集中的に使用するタスクです。 最適な移行のパフォーマンスを実現するには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。 多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。 システム リソースが不足している場合には、移行によって追加の負荷がかかると、エンド ユーザーに影響を与える可能性があります。 パイロット移行テスト時に、システムのパフォーマンスを監視します。 システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。 可能であれば、ハードウェア リソースを追加すると移行元システムのパフォーマンスを高め、タスクやユーザーを移行に関係のない他のサーバーに移動してシステムの負荷を軽減します。

詳細については、「Exchange Server のサーバーの正常性とパフォーマンス (2007、2010、2013、2016、2019)」を参照してください。

注: Exchange Server 2007 および 2010 はアクティブにサポートされなくなりました。 Exchange 2013 Server のサポート終了は 、2023 年 4 月に予定されています。 Exchange Server 2016 および 2019 は、2025 年 10 月まで延長サポートされています。 詳細については、 Exchange Server のサポート性マトリックス を参照してください。

複数のメールボックス サーバーが存在するオンプレミス Exchange 組織から移行する場合は、複数のメールボックス サーバーに均等に分散された移行ユーザーの一覧を作成することをお勧めします。 個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

たとえば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。 他の移行元システムに対しても、同様のプラクティスを適用できます。 勤務時間後、週末、祝日など、サーバー リソースの利用可能時間が最大になるときに移行を実行します。
バックエンド タスク 移行時に実行されている他のバックエンド タスク。 営業時間後に移行を実行するのがベスト プラクティスであるため、移行は、オンプレミス サーバーで実行されているメンテナンス タスク (データ バックアップなど) と競合することが一般的です。 移行中に実行される可能性がある他のシステム タスクを確認します。 データの移行は、リソースを大量に消費する他のタスクが実行されていないときに実施することをお勧めします。
注: オンプレミスの Exchange を使用しているお客様の場合、一般的なバックエンド タスクはバックアップ ソリューションと Exchange ストアメンテナンス (2013、2016、2019) です。
調整ポリシー 一定の時間の間にシステムから抽出できるデータの速度と量に関する特定の制限を設定する調整ポリシーを使用して電子メール システムを保護するのが一般的な方法です。 電子メール システム用にデプロイされた調整ポリシーを確認します。 たとえば、Google メールでは、一定期間に抽出できるデータの量が制限されます。 Exchange のバージョンによっては、(IMAP 移行で使用される) オンプレミス メール サーバーへの IMAP アクセスや、(Exchange の一括移行や段階的な Exchange の移行で使用される) RPC over HTTP プロトコル アクセスを制限するポリシーが存在します。

調整設定を確認するには、 Get-ThrottlingPolicy コマンドレットを 実行します。 調整の詳細については、「(2007、2010、2013、2016、2019)」を参照してください。

IMAP 調整の詳細については、「 IMAP メールボックスを Microsoft 365 または Office 365 に移行する」を参照してください。

要因 2: ハイブリッド以外のデプロイ移行用の移行サーバー

IMAP 移行、一括移行、段階的な移行は、クラウドから開始されるデータプル型の移行方法であるため、専用の移行サーバーは必要ありません。 ただし、インターネットに接続するプロトコル ホスト (IMAP または RPC over HTTP プロトコル) は、メールボックスとメールボックス データを Microsoft 365 または Office 365 に移行するための移行サーバーとして機能します。 そのため、現在のメール組織のデータ ソース サーバーに関する前のセクションで説明した移行のパフォーマンス要因とベスト プラクティスは、インターネット エッジ サーバーにも適用されます。 Exchange 2007、Exchange 2010、および Exchange 2013 組織では、クライアント アクセス サーバーが移行サーバーとして機能します。

詳細については、以下を参照してください:

要因 3: ハイブリッド以外のデプロイ移行の移行エンジン

IMAP、カットオーバー、ステージングされた Exchange の移行は、Exchange 管理センターの [移行] ダッシュボードを使用して実行されます。 これは、Microsoft 365 または Office 365 の移行サービスの調整の対象となります。

ソリューションとプラクティス:

お客様は、Windows PowerShell を使用して移行の同時実行数 (同時に移行するメールボックスの数など) を指定できるようになりました。 既定値は 20 メールボックスです。 移行バッチを作成した後は、次の Windows PowerShell コマンドレットを使用して、この数を最大で 100 まで増やすことができます。

Set-MigrationEndPoint <Identity> -MaxConcurrentMigrations <value between 1 and 100>

詳細については、「 Microsoft 365 または Office 365 で移行バッチを管理する」を参照してください。

注:

データ ソースに、すべての接続を管理するための十分なリソースがない場合は、高いコンカレンシーを回避することをお勧めします。 最初は 10 程度の小さい数から始めます。 エンド ユーザーのアクセスに問題が発生しないようにデータ ソースのパフォーマンスを監視しながらこの数を徐々に増やします。

要因 4: ハイブリッド以外のデプロイ移行のネットワーク

検証テスト:

移行方法に応じて、次の検証テストを実行できます。

  • IMAP 移行: サンプル データを含むソース メールボックスを事前に設定します。 次に、インターネット (オンプレミス ネットワークの外部) から、Microsoft Outlook などの標準の IMAP メール クライアントを使用してソース メールボックスに接続し、ソース メールボックスからすべてのデータをダウンロードするのにかかる時間を決定して、ネットワークパフォーマンスを測定します。 スループットは、他の制約がないため、Microsoft 365 または Office 365 の IMAP 移行ツールを使用して取得できるスループットと似ています。

  • 切り替えおよび段階的な Exchange 移行: サンプル データを含むソース メールボックスを事前設定します。 次に、インターネット (オンプレミス ネットワークの外部) から、RPC over HTTP Protocol を使用して Outlook を使用してソース メールボックスに接続します。 キャッシュ モードを使用して接続していることを確認します。 移行元メールボックスからすべてのデータを同期するのにかかる時間を確認して、ネットワークのパフォーマンスを測定します。 スループットは、他の制約がないため、Microsoft 365 または Office 365 の簡単な Exchange 移行ツールを使用して取得できるスループットと似ています。

実際の IMAP、カットオーバー、またはステージングされた Exchange 移行中にオーバーヘッドが発生します。 ただし、実際のスループットは、これらの検証テストの結果と同様である必要があります。

要素 5: Microsoft 365 および Office 365 サービスによるハイブリッド以外の展開移行

Microsoft 365 または Office 365 のリソース正常性ベースの調整は、ネイティブの Microsoft 365 または Office 365 の単純な移行ツールを使用した移行に影響します。 「Microsoft 365 または Office 365 リソースの正常性ベースの調整」セクションを参照してください。

Microsoft 365 または Office 365 で要求を移動する

移動要求の状態情報の取得に関する一般的な情報については、「移動要求のプロパティの表示」を参照してください。

  • Move-Mailbox

  • [Get-MoveRequestStatistics]](/powershell/module/exchange/get-moverequeststatistics)

Microsoft 365 または Office 365 サービスでは、移行キューと移行に割り当てられたサービス リソースがテナント間で共有され、移動プロセスの各段階での移動要求の管理方法に影響します。

Microsoft 365 と Office 365 には、次の 2 種類の移動要求があります。

  • "移動" 要求のオンボード: 新しい顧客の移行は、移動要求のオンボードと見なされます。 これらの要求には通常の優先度が設定されます。

  • データセンター内部の "移動" 要求: これらは、データセンター操作チームによって開始されたメールボックス移動要求です。 これらの移動要求には遅延が発生してもエンドユーザー エクスペリエンスには影響しないため、低い優先度が設定されます。

"キューに登録済み" および "処理中" の状態にある移動要求で考えられる影響および遅延

  • キューに入っている移動要求: この状態は、移動がキューに登録されており、Exchange メールボックス レプリケーション サービスが移動を受け取るまで待機していることを指定します。 Exchange 2003 の移動要求の場合、この段階ではユーザーは引き続きメールボックスにアクセスできます。

    次の 2 つの要因によって、Mailbox Replication サービスによって処理される要求が決定されます。

    • 優先度: 優先度の高いキューに入った移動要求は、優先度の低い移動要求の前に取得されます。 これで、データセンター内部移動要求の前に、必ず顧客移行移動要求が処理されるようになります。

    • キュー内の位置: 移動要求の優先度が同じ場合、要求がキューに入る前に、メールボックス レプリケーション サービスによって以前に取得されます。 同時に複数のお客様がメールボックスの移行を実行する可能性があるため、新規の移動要求が処理される前にキューにとどまる場合があります。

多くの場合、メールボックス要求が処理前にキュー内で待機する時間は、移行計画時に考慮されません。 このことは、計画したすべての移行が完了するのに十分な時間が割り当てられない原因となります。

  • 進行中の移動要求: この状態は、移動がまだ進行中であることを指定します。 オンライン メールボックス移動である場合、ユーザーはメールボックスにまだアクセスできます。

メールボックス移動要求の状態が "処理中" になると、優先度は関係なくなります。新しい移動要求は、高い優先度が設定されている場合でも、既存の処理中の移動要求が完了するまでは処理されません。

ベスト プラクティス

計画: 前述したように、Exchange 2003 ユーザーはハイブリッド移行中にアクセスを失うため、通常、Exchange 2003 のお客様は移行をスケジュールするタイミングと所要時間についてより懸念しています。

一定時間に移行するメールボックス数を計画する場合は、次の点を考慮します。

  • 移動要求がキュー内で待機する時間を含めます。 次の式を使用してこの計算を行います。

    (移行するメールボックスの合計数) = (合計時間) - (平均キュー時間)) * (移行スループット)

    ここで、移行スループットは 1 時間に移行できるメールボックスの合計数です。

For example, assume you have a six-hour window to migrate mailboxes. 平均キュー時間が 1 時間で、1 時間あたり 100 個のメールボックスの移行スループットがある場合は、6 時間の時間枠で 500 個のメールボックスを移行できます:500 = (6 - 1) * 100。

  • キュー内にとどまる時間を抑えるために、当初計画した時刻よりも早めに移行を開始します。 メールボックスがキューに登録されている場合でも、Exchange 2003 ユーザーは引き続きメールボックスにアクセスできます。

キュー時間の決定: Microsoft は顧客の移行スケジュールを管理していないため、キュー時間は常に変化します。

発生する可能性がある待ち時間を特定するために、実際の移行を開始する数時間前にテストの移動をスケジュールできます。 その後、実際に要求がキュー内にとどまった時間に基づいて、移行を開始すべき時刻および一定時間内に移動できるメールボックス数をより正確に推定できます。

たとえば、計画した移行を開始する 4 時間前にテストの移行が完了したとします。 テストの移行の待ち時間は約 1 時間だったことを確認します。 この場合、すべての移行が時間内に終了するように、最初に計画した時刻よりも 1 時間早く移行を開始することを検討する必要があります。

Microsoft 365 または Office 365 の移行用のサード パーティ製ツール

サードパーティ製ツールは、主に、Gmail/G Suite/GWS (Google ワークスペース)、IBM Lotus、Domino、Novell GroupWise からのツールなど、Exchange を含まない移行シナリオで使用されます。 このセクションでは、実際の製品や移行ツールではなく、サード パーティ製の移行ツールで使用される移行プロトコルに重点を置いて説明します。 次の表に、Microsoft 365 または Office 365 の移行シナリオ用のサード パーティ製ツールに適用される要因の一覧を示します。

重要

サード パーティ製ツールを使用して移行を実行した後のデータの整合性または整合性に関する問題については、サポートのためにツールを提供したベンダーにお問い合わせください。

要因 1: サード パーティ製ツールの移行用のデータ ソース

チェックリスト 説明 ベスト プラクティス
システムのパフォーマンス データ抽出は、リソースを集中的に使用するタスクです。 最適な移行のパフォーマンスを実現するには、移行元システムに十分なリソース (CPU 時間やメモリなど) が必要です。 多くの場合、移行時の移行元システムは、通常のエンド ユーザーの負荷で限界近くまでキャパシティを利用しています。 システム リソースが不足している場合には、移行によって追加の負荷がかかると、エンド ユーザーに影響を与える可能性があります。 パイロット移行テスト時に、システムのパフォーマンスを監視します。 システムがビジー状態の場合は、移行の速度が遅くなったり、サービスの利用に問題が発生したりする可能性があるため、特定のシステムに集中した移行をスケジュールしないことをお勧めします。 可能であれば、ハードウェア リソースを追加すると移行元システムのパフォーマンスを高め、タスクやユーザーを移行に関係のない他のサーバーに移動してシステムの負荷を軽減します。

詳細については、「Exchange Server のサーバーの正常性とパフォーマンス (2007、2010、2013、2016、2019)」を参照してください。

注: Exchange Server 2007 および 2010 はアクティブにサポートされなくなりました。 Exchange 2013 Server のサポート終了は 、2023 年 4 月に予定されています。 Exchange Server 2016 および 2019 は、2025 年 10 月まで延長サポートされています。 詳細については、 Exchange Server のサポート性マトリックス を参照してください。

複数のメールボックス サーバーが存在するオンプレミス Exchange 組織から移行する場合は、複数のメールボックス サーバーに均等に分散された移行ユーザーの一覧を作成することをお勧めします。 個別のサーバーのパフォーマンスに基づいて、この一覧をさらに微調整し、スループットを最大化できます。

たとえば、サーバー A のリソースの利用可能時間がサーバー B よりも 50% 長い場合は、同じ移行バッチにおいてサーバー A からのユーザー数を 50% 多くするのが適切です。 他の移行元システムに対しても、同様のプラクティスを適用できます。

勤務時間後、週末、祝日など、サーバー リソースの利用可能時間が最大になるときに移行を実行します。
バックエンド タスク 通常は、その他のバックエンド タスクが移行時に実行されます。 移行は勤務時間後に実行するのがベスト プラクティスなので、社内のサーバーで実行中の他の保守タスク (データのバックアップなど) と競合することがよくあります。 移行中に実行される可能性がある他のシステム タスクを確認します。 データの移行は、リソースを大量に消費する他のタスクが実行されていないときに実施することをお勧めします。

注: オンプレミスの Exchange を使用しているお客様の場合、一般的なバックエンド タスクはバックアップ ソリューションと Exchange ストアメンテナンス (2013、2016、2019) です。

調整ポリシー 一定時間内に特定の移行方法を使用してシステムから抽出できるデータ量および抽出速度に対して特定の制限を設定する調整ポリシーを使用して、メール システムを保護するのが一般的です。 電子メール システム用にデプロイされた調整ポリシーを確認します。 たとえば、Google メールでは、一定期間に抽出できるデータの量が制限されます。 Exchange のバージョンによっては、(IMAP 移行で使用される) オンプレミス メール サーバーへの IMAP アクセスや、(Exchange の一括移行や段階的な Exchange の移行で使用される) RPC over HTTP プロトコル アクセスを制限するポリシーが存在します。

調整設定を確認するには、 Get-ThrottlingPolicy コマンドレットを 実行します。 調整の詳細については、「(2007、2010、2013、2016、2019)」を参照してください。

IMAP 調整の詳細については、「 IMAP メールボックスを Microsoft 365 または Office 365 に移行する」を参照してください。

要因 2: サード パーティ製ツールの移行用の移行サーバー

Microsoft 365 または Office 365 の移行用のほとんどのサード パーティ製ツールは、クライアントによって開始され、Microsoft 365 または Office 365 にデータをプッシュします。 これらのツールでは、一般的に移行サーバーが必要です。 これらの移行サーバーには、システムのパフォーマンス、バックエンド タスク、移行元サーバーの調整ポリシーなどの要因があてはまります。

注:

一部のサードパーティの移行ソリューションは、クラウドベースのサービスとしてインターネット上でホストされており、オンプレミスの移行サーバーは必要ありません。

ソリューションとプラクティス:

移行サーバーを使用する場合の移行パフォーマンスを向上させるには、「 Factor 1: データ ソース for サード パーティツールの移行 」セクションで説明されているベスト プラクティスと同じベスト プラクティスを適用します。

要因 3: サード パーティ製ツールの移行用の移行エンジン

サード パーティ製移行ツールで使用される最も一般的なプロトコルは、Exchange Web サービスおよび RPC over HTTP プロトコルです。

Exchange Web サービス:

Exchange Web Services は、大規模なデータ バッチをサポートし、サービス指向の調整が向上するため、Microsoft 365 または Office 365 への移行に使用する推奨プロトコルです。 Microsoft 365 または Office 365 では、偽装モードで使用する場合、Exchange Web サービスを使用した移行では、ユーザーが予算を設定した Microsoft 365 または Office 365 Exchange Web Services リソースを消費せず、代わりに予算リソースのコピーを使用します。

  • 同じ管理者アカウントによる Exchange Web サービスの偽装呼び出しはすべて、その管理者アカウントに対する割り当てとは別に計算されます。

  • 偽装セッションごとに、ユーザーの実際の割り当てのシャドウ コピーが作成されます。 この特定のセッションのすべての移行がこのシャドウ コピーを消費します。

  • 偽装に基づく調整はユーザー移行セッションごとに別々に行われます。

  • 移行の完了を許可するために、Exchange Web Services 調整ポリシーをテナントで一時的に変更できます (30、60、または 90 日間)。 これは、Microsoft 365 管理センターの [ヘルプ] セクションから要求できます。

ベスト プラクティス:

  • EWA 偽装を使用したサード パーティ製移行ツールを使用するお客様の移行のパフォーマンスは、他のテナントによる Exchange Web サービス ベースの移行およびサービス リソースの使用と競合します。 そのため、移行のパフォーマンスは場合によって異なります。

  • お客様は、可能な限り Exchange Web サービス偽装を使用したサード パーティ製移行ツールを使用する必要があります。これらのツールは、通常、RPC over HTTP プロトコルなどのクライアント プロトコルを使用した場合に比べて、より高速で効率的なためです。

RPC over HTTP プロトコル:

従来の移行ソリューションでは、RPC over HTTP プロトコルが使用されます。 この方法は、Outlook などのクライアント アクセス モデルに完全に基づいており、Microsoft 365 または Office 365 サービスは、アプリケーションではなくユーザーが使用することを前提としてアクセスを調整するため、スケーラビリティとパフォーマンスが制限されます。

ベスト プラクティス:

  • RPC over HTTP Protocol を使用する移行ツールの場合、移行サーバーを追加し、複数の Microsoft 365 または Office 365 管理ユーザー アカウントを使用して、移行スループットを向上させるのが一般的な方法です。 各管理ユーザーは Microsoft 365 と Office 365 のユーザー調整の対象であるため、この方法ではデータ挿入の並列処理を実現し、より高いデータ スループットを実現できます。 多くの企業のお客様は 20 から 30 GB/時の移行スループットを実現するために 40 台以上の移行サーバーをセットアップする必要があったという報告があります。

  • 移行ツールの開発フェーズでは、メッセージを移行するのに必要な RPC 操作の数を考慮することが重要です。 これを示すために、Microsoft 365 または Office 365 サービスによってキャプチャされたログは、顧客が Microsoft 365 または Office 365 に移行するために使用する 2 つのサード パーティの移行ソリューション (サード パーティ企業によって開発) 用に収集されています。 サード パーティ企業によって開発された 2 つの移行ソリューションを比較しました。 また、各移行ソリューションにおける 2 つのメールボックスの移行を比較し、Outlook の .pst ファイルのアップロードとも比較しました。 結果は次のとおりです。

メソッド メールボックスのサイズ アイテム数 移行時間 合計 RPC トランザクション数 平均クライアント待ち時間 (ミリ秒) AvgCasRPCProcessingTime (ミリ秒)
ソリューション A (メールボックス 1) 376.9 MB 4,115 4:24:33 132,040 48.4395 18.0807
ソリューション A (メールボックス 2) 249.3 MB 12,779 10:50:50 423,188 44.1678 4.8444
ソリューション B (メールボックス 1) 618.1 MB 4,322 1:54:58 12,196 37.2931 8.3441
ソリューション B (メールボックス 2) 56.7 MB 2,748 0:47:08 5,806 42.1930 7.4439
Outlook 201.9MB 3,297 0:29:47 15,775 36.9987 5.6447

注:

クライアントとサービスのプロセス時間は似ていますが、ソリューション A はデータの移行にさらに多くの RPC 操作を要します。 各操作ではクライアント待機時間とサーバー プロセス時間が消費されるため、ソリューション A はソリューション B と Outlook と比較して同じ量のデータを移行する方がはるかに遅くなります。

要因 4: サード パーティ製ツールの移行のためのネットワーク

ベスト プラクティス:

RPC over HTTP プロトコルを使用するサード パーティ製移行ソリューションでは、次の方法で移行のパフォーマンスを推測できます。

  1. 移行サーバーから、RPC over HTTP Protocol を使用して、Outlook を使用して Microsoft 365 または Office 365 メールボックスに接続します。 キャッシュ モードを使用して接続していないことを確認します。

  2. サンプル データを含む大きな .pst ファイルを Microsoft 365 または Office 365 メールボックスにインポートします。

  3. この .pst ファイルをアップロードするのにかかる時間を計って、移行のパフォーマンスを測定します。 他に制約がない場合、移行のスループットは、RPC over HTTP プロトコルを使用したサード パーティ製移行ツールを使用した場合のスループットと似た数値になるはずです。 実際の移行時にはオーバーヘッドが発生するため、スループットは若干変動する可能性があります。

要素 5: Microsoft 365 および Office 365 サービス

Microsoft 365 と Office 365 のリソース正常性ベースの調整は、サード パーティの移行ツールを使用した移行に影響します。 詳細については、「 Microsoft 365 と Office 365 のリソース正常性ベースの調整 」を参照してください。