#Gmail 移行プロセス

以下のセクションでは、Gmail 移行の一般的な移行プロセスを説明します。このドキュメントに記載されている内容は、若干の調整を加えることで、一般的なガイドラインとして利用することもできます。

• 準備
• 移行の実行

お客様の移行要件に応じて、追加のステップが必要となる場合も、プロセスに含まれている一部のステップが不要となる場合もあります。

#準備

移行前に、移行するオブジェクト タイプを特定する必要があります。詳細については、対応状況一覧 を参照してください。

#1.移行元ユーザーのフィルターを構成する (任意)

Google テナントにユーザー メールボックスが多数存在し、その中の一部のみを移行する場合、移行元テナントで Google グループまたは組織単位を作成し、移行するユーザーおよび Fly migration for Google アプリへの同意に使用するユーザーを Google グループまたは組織単位を追加することができます。Fly migration for Google アプリをインストールする場合、特定のグループまたは組織部門次のステップでユーザーを選択してください オプションを選択し、特定のグループまたは組織部を選択してアプリのインストールを完了します。選択したグループまたは組織単位に存在しないユーザー メールボックスを移行することはできません。

#2.Gmail の必要な権限を持つアプリ プロファイルを作成する

Fly を Gmail に接続するには、AvePoint Online Services で必要な権限を持つアプリ プロファイルを作成します。Gmail 移行の必須権限を確認するには、必須権限 を参照してください。

#3.Exchange Online 用の必要な権限を持つアプリ プロファイルを作成する

Fly を Exchange Online に接続するには、AvePoint Online Services で必要な権限を持つアプリ プロファイルを作成することを推奨します。Exchange Online 移行の必須権限を確認するには、必須権限 を参照してください。

#4.移行元テナントの検出を実行する (任意)

Gmail からの移行を実行する前に、Gmail のテナント検出を実行して、オブジェクト数、オブジェクト タイプ、オブジェクト サイズ、その他の詳細をスキャンして報告することができます。検出レポートから、移行元環境をより深く理解し、移行を計画することができます。詳細については、テナントの検出ユーザー ガイド を参照してください。

#5.移行先テナントでユーザーを作成する

移行先テナントに新しい Microsoft 365 ユーザーを追加します。

• Gmail から Exchange Online への移行を実行し、ドメインを移行先環境に移動する場合:

  ドメインを Exchange Online テナントに追加することをお勧めします。これにより、Exchange Online メールボックス アドレスが Gmail 内のアドレスと同じであることを確保できます。移行プロジェクトでマッピングを構成する際に、移行元と移行先のメールボックスに同じアドレスを使用することができます。例: user@googleworkspace.com と user@googleworkspace.com

• Gmail から Exchange Online への移行を実行し、ドメインを移行先環境に移動しない場合:

  移行プロジェクトでマッピングを構成する際に、移行元と移行先のメールボックスに異なるアドレスを使用することができます。例: user@googleworkspace.com と user@destcontoso.onmicrosoft.com

ユーザーの準備方法に関するユーザー ガイド を参照してください。

#6.ユーザーのメールボックスを作成する

メールボックスを作成するために移行先ユーザーにライセンスを割り当てます。詳細については、Microsoft 365 ライセンスをユーザーに割り当てる を参照してください。

#7.共有メールボックスおよびリソース メールボックスをプロビジョニングする

移行先でリソース メールボックスおよび共有メールボックス (必要な場合) をプロビジョニングします。移行先で共有メールボックスまたはリソース メールボックスが存在しない場合、Fly は新しい共有メールボックスまたはリソース メールボックスを作成することができます。

#8.移行先メールボックスへの移行の大容量メール アイテムを処理する

• Microsoft では、受信したメッセージの最大サイズが既定で 35 MB に設定されています。潜在的な例外を避けるために、この制限を 150 MB に増加することをお勧めします。制限を構成するには、大きいメール メッセージ を参照してください。

  サンプルの PowerShell コマンド:

  Set-Mailbox -Identity user@contoso.com -MaxReceiveSize 150MB

• ルール クォータ制限などの他の制限があります。受信トレイ ルールはすべてのルールに対して 256 KB の制限を適用しています。制限を構成するには、Exchange Online の受信トレイ ルールで使用される領域を変更する を参照してください。

  サンプルの PowerShell コマンド:

  Set-Mailbox -Identity user@contoso.com -RulesQuota "<32 KB to 256 KB>"

#9.訴訟ホールドおよび単一アイテムの回復を無効にする (任意)

移行中、移行されたデータの修正および多数のアイテムの上書きを実行する必要がある場合、関連する移行先メールボックスで訴訟ホールドおよび単一アイテムの回復の両方を無効にすることをお勧めします。訴訟ホールドまたは単一アイテムの回復が有効になっている場合、アイテムが削除・上書きされると、Exchange はそれらのアイテムを 回復可能なアイテム フォルダーに自動移動し、そこのストレージを消耗します。

訴訟ホールドは既定で無効になっており、単一アイテムの回復は既定で有効になっています。

詳細については、Exchange Online の In-Place ホールドと訴訟ホールド および Exchange Online でメールボックスの単一アイテムの回復を有効または無効にする を参照してください。

サンプル PowerShell コマンド:

​Set-Mailbox -Identity user@contoso.com -SingleItemRecoveryEnabled $false -LitigationHoldEnabled $false

#10.移行先保持ポリシーを確認する

保持ポリシーが移行元データ用に構成されている場合、移行先保持ポリシーと移行元保持ポリシーが同じであることを確認してください。同じでない場合、異なる保持ポリシーにより、移行先データは削除される可能性があります。

#11.Gmail 移行のスロットリング制限

#Google Workspace のスロットリング制限

Google にもスロットリング制限があります。一度に実行するマッピングの数が多いほど、スロットリング制限の移行速度に対する影響も大きくなります。スロットリング問題を軽減するには、Google サポートに連絡してください。

#Microsoft スロットリングの制限

Microsoft はスロットリングを使用して Microsoft 365 操作を管理し、スロットリング制限は移行パフォーマンスに影響を与えます。Microsoft 365 管理センターに移動し、スロットリングの制限を解除します。

1. Microsoft 365 管理センターのヘルプ (?) に移動します。

2. 検索フレーズとして EWS 調整 を入力します。

3. 環境の確認が要求される場合は、[テストの実行] をクリックします。このテストは、基本的にテナントに適用されている EWS 調整を確認します。

   ​

4. サポート アシスタントはテナント設定を確認し、「Exchange Web サービスは調整済みです」 と結論付けます (通常の状況)。テナントの EWS ポリシーの設定を更新し、調整を 30、60、90 日間無効にすることができます。

5. ポリシーの調整を保持する期間を選択し、[Update] をクリックします。

   

6. しばらくして、サポート アシスタントは設定が変更されたことを通知します。

#12.移行スループット

メール移行の場合、EWS の合理的な移行速度は 1.8 GB/時間/マッピングです。実行できるマッピングの数は、購入したサブスクリプションに基づいて自動的に割り当てられます。購入するユーザー シートが多いほど、1 件のプロジェクトで実行できるマッピングの数も多くなります。

Graph API の場合、合理的な移行速度は 1.45 GB/時間/マッピングです。このパフォーマンスは、シミュレートされた顧客データで測定されたものです。Graph API の進化に伴い、このパフォーマンスは今後のバージョンでも引き続き追跡されます。

移行パフォーマンスに影響する可能性のある要因が多数あることに注意してください。

• スループット: 上記のスループット数は完全移行を対象としています。一般的には、増分移行の場合、スループットが低くなる可能性があります。FLY は増分移行の移行済みアイテムの状態を確認するために時間を費やす必要があります。

• 移行元と移行先でスロットリング問題が発生することで、移行パフォーマンスに影響を与える可能性があります。

#13.移行元および移行先の接続を作成する

接続の作成 を参照して、Fly を移行元 Google テナントおよび移行先 Microsoft 365 テナントに接続します。

プロジェクト設定

一般的には、事業部などの事業単位に基づいてプロジェクトを作成することをお勧めします。また、異なるタイプのメールボックスは異なるマッピング ファイルで構成することをお勧めします。

その他の設定

メールボックス マッピング ファイルおよびユーザー マッピング ファイルを設定します (任意)。

#14.移行ポリシーを策定する

Gmail 移行ポリシーでは、Gmail 移行用のオブジェクトの移行範囲、競合解決、ユーザー マッピング、詳細オプションを構成することができます。詳細については、移行ポリシーの作成 を参照してください。

#15.パイロット実行をプランニングする

以下の目的でパイロット実行を行うことをお勧めします。

• Fly のインターフェイスに慣れ、移行プロセスの全体を把握します。

• 本番の移行前に、潜在的な問題を早期に発見して解決します。

• コンテンツ サイズが大きい場合のスロットリング状況を把握し、Microsoft 365 で解決するようにします。

プロジェクトとマッピングを構成する方法については、プロジェクトの作成 および 移行マッピングの作成 を参照してください。

#移行の実行

移行を実行する方法については、以下のセクションを参照してください。

#1.Fly でプロジェクトおよびマッピングを構成する

プロジェクトとマッピングを構成する方法については、プロジェクトの作成 および 移行マッピングの作成 を参照してください。

#2.通常の完全移行を実行する

ジョブを実行する前に、マッピングを検証して、マッピングが移行可能であることを確認することをお勧めします。詳細については、マッピングの事前分析 を参照してください。

その後、構成した移行ポリシーに基づいてオブジェクトを移行する完全移行ジョブを実行することができます。詳細については、オブジェクトを移行する移行の実行 を参照してください。

#3.通常の増分移行を実行する

新規・更新・失敗したデータを処理します。通常の増分移行を実行する方法については、オブジェクトを移行する移行の実行 を参照してください。

#4.移行結果を検証する

• マッピング レポートを確認します。(マッピングが失敗した場合、またはマッピングが完了したが実行中に例外が発生した場合、移行エラー セクションでマッピングのエラー コードおよびコメントを確認することができます。エラー コードをクリックすると、トラブルシューティング ガイド でそのコードの詳細および推奨事項を表示することができます。これらの情報はエラーの解決や回避に役立てます。)

• 移行先で移行済みデータを確認します。

• 移行先でアイテム数を確認します。

• 開催者と出席者のつながりを確認します。

• 新しいデータが移行先メールボックスに作成できること

• 会議 / 定期的な会議機能が正常に動作できること

#5.最終の増分移行を実行する

すべての移行元データが移行先に移行されることを確認します。

#6.DNS の TTL を短縮する

カットオーバー時に組織外のユーザーから送信されたメールの遅延を軽減するために、DNS の TTL (time-to-live) を 1 時間またはそれ以下に短縮することをお勧めします。

#7.最終のカットオーバーを実行する

Exchange MX レコードの変更などを実行します。メール システムが変更された MX レコードを識別するには、最大 72 時間がかかることがあります (前のセクションで述べた TTL に関連しています)。移行元データの更新が移行先に移行されることを確認するため、カットオーバー後に最終増分ジョブを実行することをお勧めします。プロジェクト マッピングの移行元メール アドレスが変更されておらず、プロジェクト マッピングの移行先メール アドレスが元の移行先メール アドレスのエイリアスとして存在していることを確認してください。