この記事のベスト プラクティスに沿うことで、Google Workspace Migrate を使った移行をスムーズに行うことができます。
詳しくは、Google Workspace Migrate: データ移行のベスト プラクティス（PDF、英語のみ）をご覧ください。
始める前に
- 最新バージョンのソフトウェアを使用する - Google は、Google Workspace Migrate プラットフォームとノード ソフトウェアを定期的に更新しています。また、データベース ソフトウェアも随時更新しています。最新の Google Workspace Migrate の機能や修正を利用できるように、最新バージョンのソフトウェアを使用してください。
詳しくは、ソフトウェアをアップグレードするをご覧ください。
- システム要件を遵守する - 移行には多くのリソースが必要です。移行の進行中は新しいリソースをプロビジョニングできないため、システム要件を満たしている、またはシステム要件を上回っていることが重要です。
詳しくは、システム要件をご確認ください。
ネットワークを設定する
- Google Cloud を使用する - Google は、Google Workspace Migrate の動作確認を Google Cloud 上で広範に実施してきました。必要とされる仕様に合わせてネットワークと仮想マシン（VM）をプロビジョニングするなど、Google Cloud での移行をサポートするための十分なサポート体制が整っています。
- ネットワーク レイテンシを減らす - ネットワーク パフォーマンスを向上させるには、同一ネットワーク上のサーバー同士を接続して物理的に近い場所に配置します。
Google Cloud の内部で Google Compute Engine を使用している場合は、サービス ポイントに近い国 / リージョンまたはゾーンを選択して、ネットワーク レイテンシを減らすことをおすすめします。たとえば、データソースに最も近いメインの国 / リージョンやゾーンを選択します。
- Chrome ブラウザをデフォルトに設定する - Google Workspace Migrate と Google Cloud のどちらの動作確認も、Chrome ブラウザ上で広範に実施されています。
詳しくは、Chrome を既定のブラウザに設定するをご覧ください。
- Microsoft Windows の自動更新を無効にする - 移行中にサーバーが意図せず再起動しないよう、Windows の更新は移行が有効でないときに実施するよう管理します。
- 正しいワーカーノード数を設定する - 導入するワーカーノード サーバーの数は、組織内のユーザー数と移行するデータ量に合致している必要があります。移行フェーズの規模と複雑さを組織の目標に照らし合わせて、そうした目標を達成するのに十分な数のノードを確実にプロビジョニングしている必要があります。
詳細は、必要なノードサーバーの数を検討するをご確認ください。
- クラスタあたりのワーカーノード数を 40 台までにする - 大規模に移行する場合のワーカーノードの最大数は 40 です。40 台のノードが組み合わさってクラスタが形成されます。1 回の移行に複数のクラスタを導入できます。クラスタは自己完結型であり、データベース、ノード、プラットフォームを共有しません。したがって、異なるクラスタ上にある移行データセットは、できる限り相互に排他的である必要があります。
詳しくは、ノードサーバーのインストールをご覧ください。
- 適切なデジタル証明書を設定する - Google Workspace Migrate では、TLS 証明書が暗号化プロトコルとして使用されています。TLS を使って Google Workspace Migrate プラットフォームとノードサーバーが設定されます。現在のところ、Google では自己署名証明書はサポートされていません。
詳しくは、TLS 証明書を使用してポートを設定するをご覧ください。
移行を計画する
- データをスキャンする - 移行の前にデータのフルスキャンを実施することをおすすめします。フルスキャンは移行よりも高速に実行され、次のような利点があります。
- コーパスサイズの見積もり、ソースデータの種類、データに関する問題がレポートされます。
- ワーカーノード間でのワークロードの分散が最適化されます。
- シリアル処理を必要とする大規模な個別データセットが優先順位付けされます（メールの量が極端に多いユーザーなど）。その結果、大規模なデータセットが移行のボトルネックになることはありません。
- データを移行する準備ができたら新しい Google Workspace Migrate プロジェクトを設定する - テスト プロジェクトを再利用する場合、Google Workspace Migrate ではテスト段階でデータがすでに移行されていることが認識され、再移行が行われません。テストの完了後に新しいプロジェクトを使用することで、この問題を回避できます。
- 1 つの移行元ユーザーを同じプロジェクト内の複数の移行先ユーザーにマッピングしない - このようにマッピングすると、予期しない移行が発生する可能性があります。1 人のユーザーを複数の移行先ユーザーにマッピングする必要がある場合は、マッピングごとに別々の Google Workspace Migrate プロジェクトを使用します。
データをドライブに移行する
ファイルを Google ドライブに移行するときは、次のことをおすすめします。
- Google ドライブでの大規模な移行に関するおすすめの方法でガイドラインをご確認ください。
- 移行先を複数の場所に分けます（別々のユーザーのマイドライブ、別個の共有ドライブなど）。
- 可能であれば、マッピングで複数のドライブ ユーザーを指定します。こうすることで、移行の負荷を複数のユーザーに分散して、割り当て量に関する問題を回避できます。
- 共有ドライブに移行して、すべてのチームメンバーが組織のリソースにアクセスできるようにします。
詳しくは、共有ドライブのベスト プラクティスとヒントをご覧ください。
- ユーザー間のさまざまな共有を Google グループに統合して、共有ドライブのメンバー管理とグループへの連絡を容易に行えるようにします。
- 可能であればフォルダを階層化しないようにします。
ドライブに保存できるデータのサイズと種類には制限があります。詳しくは、Google ドライブに保管可能なファイルをご覧ください。
次のステップ
データソースに関するモニタリング ポイントを確認します。
Google、Google Workspace、および関連するマークとロゴは、Google LLC の商標です。その他すべての企業名および商品名は、関連各社の商標または登録商標です。