Google Workspaceのお引越しは「最初の一歩」が肝心

2026-08-06

はじめに

ありがたいことに、直近グループウェアのデータ移行に関するお問い合わせを多くいただいております。
「M&Aで買収した会社のテナントをメインテナントへ統合したい」、「分社に伴い Google Workspace のテナントを分けたい」など、移行のパターンはさまざまです。

一方で、グループウェアのデータ移行は一筋縄ではいきません。事前に把握しておくべき点や検討事項、実際に要する期間など、考えることは多岐にわたります。

ZUNDAでは、Google Workspace 間のデータ移行には CloudM Migrate のご利用を提案しています。

本記事では、CloudM を使った実際の移行プロジェクトをもとに、Google Workspace の移行にどれくらいの期間が必要なのか、どのような手順で進めるのか、事前に何を考えておくべきなのかを解説します。

本記事の3行まとめ

グループウェアのデータ移行は、200〜300ユーザー規模でもプロジェクト期間として3〜6ヶ月程度を見込む必要があり、ユーザー数や共有ドライブの容量・ファイル数が増えるほど長期化します。
CloudM による移行は“コピーして新規作成”する方式のため、Google APIのrate limitなどの制約があり、事前移行を活用して本番移行の作業期間を短縮するのが一般的です。
移行を成功させるには、移行対象の洗い出し、権限のマッピング作成、外部テナントとの依存関係、不要データの選別といった事前検討が欠かせません。

データ移行に要する期間

お問い合わせの中でも、特に影響が大きい要件のひとつが「移行完了までに要する期間」です。

弊社がこれまでご支援してきた CloudM Migrate による Google Workspace 移行プロジェクトでは、200〜300ユーザー規模でも、プロジェクト期間として3〜6ヶ月程度を確保いただくケースが多いです。
ユーザー数が多い、共有ドライブの容量が大きい、ファイル数が多い、といった条件が重なるほど、期間は長くなる傾向があります。

CloudM によるデータ移行は、移行元テナントのデータを移行先テナントへ“移動”するのではなく、“コピーして新規作成”するイメージです。

そのため、データ容量はもちろん、ファイル数（アイテム数）も移行期間に大きく影響する重要な要素となります。

ファイルやアイテムの作成に時間を要する理由

CloudM はGoogleのAPIを利用して、移行先テナントにファイルやメールなどのアイテムを作成します。
GoogleのAPIには厳しいrate limitがあり、手動で大量のドライブを移行しようとしても制限が掛かりやすい仕様となっています。

また、CloudM 側のインスタンスにも処理プロセス数の上限があるため、結果として移行には時間を要します。

support.cloudm.io

移行プロジェクトの流れ

ここでは、実際の移行プロジェクトの中でも、移行期間や全体設計に影響しやすい主要なフェーズを解説します。

移行元テナントのアセスメント
事前移行
本番移行

1. 移行元テナントのアセスメント

CloudM では、移行元テナントのアセスメント（事前調査）を実施することが推奨されています。
Google Workspace では、テナント全体のファイル容量やユーザーごとのデータ容量（ファイルサイズ）を把握するのが難しい一方、CloudMの「環境スキャン」を利用すると、ファイルサイズとファイル数まで確認できます。
スキャン結果をもとに、移行計画を策定していきます。

2. 事前移行

移行元テナントのデータは、最終的にはすべて移行先テナントへ移す必要がありますが、週末のみで完了させるのは現実的ではありません。

そこで CloudM では「事前移行」として、本番移行の直前までのデータ（14〜30日前程度）をあらかじめ移行先テナントへ移行して、本番移行の作業期間を短縮することが推奨となります。

事前移行に要する期間はファイル容量やファイル数により異なります。実際の案件ベースですと30人程度で10日間、300人で3週間かかったという実績もありますが、数千人であったり容量やアイテム数が大きいなどの場合は事前移行を数回するということもあります。こういった設計をするためにも事前のアセスメントが重要になります。

3. 本番移行

本番移行では、事前移行を実施した時点以降の全期間のデータを、移行先テナントへ流し込みます。また、事前移行後に移行先テナント側で変更したファイルなどは、このタイミングで移行先テナントへマージされます。

CloudM では、事前移行済みのファイルを本番移行までの間に変更したり保存場所を変更した場合でも、本番移行で変更後のデータが移行先テナントに反映されます。
ただし、事前移行後に削除されたデータは、本番移行を行なっても移行先テナントからは削除されません。

さらに、移行先テナントでドメインを継続利用する場合は、本番移行の直前にドメイン移行も行う必要があります。

[事前移行]
移行元テナント:　zunda.co.jp　　　※メインドメイン
移行先テナント:　tmp.zunda.co.jp

[本番移行]
移行元テナント:　old.zunda.co.jp
移行先テナント:　zunda.co.jp　　　※メインドメイン

support.cloudm.io

なおテナントからテナントからメインドメインを削除すると、別の Google Workspace テナントにドメインを登録できるようになるまで、最大で24時間ほどかかる可能性があります。

管理対象の Google アカウントからドメインを削除する | Domain management | Google Workspace Help

knowledge.workspace.google.com

この間、移行対象ドメイン宛てのメールが不通になってしまうため、Gmail とは別の仕組みでメールを受信できるようにしておく必要があります。

ZUNDAにドメインのネームサーバー管理をお任せいただける場合は、この期間中にドメイン宛てに届いたメールを、特定のメールアドレス（移行対象ドメインとは別）へ転送することも可能です。

このように、移行元で利用していたドメインを移行先でも継続利用する場合は、考慮事項が増えます。

グループウェアのデータ移行をする際に考えること

ここまでデータ移行の期間や流れについて説明しました。ここからは、実際に移行プロジェクトを任された管理者様が検討すべきポイントを解説します。

プロジェクト開始前から検討

移行対象の洗い出し

まずは、移行対象となるユーザー、共有ドライブ、グループ、リソースなどを早めに洗い出す必要があります。
「移行元テナントのアセスメント」の項で触れた”環境スキャン”は、移行するユーザーや共有ドライブを指定して実行することで、より正確なファイルサイズやファイル数を把握できます。

外部のテナントには干渉できないことを認識しておく

Google Workspace では外部テナントのユーザーともコラボレーションできますが、データ移行を検討する際は「外部ユーザーには干渉できない」制約があります。そのため、外部テナントとの依存関係を把握しておく必要があります。

例えば、自社のユーザーAのマイドライブに外部ユーザーがオーナーとなっているファイルが存在する場合、そのファイルは移行先に移行できません。ファイルの所有権がテナントに帰属する共有ドライブでは問題ないですが、マイドライブでの外部共有を制限していないテナントの場合は注意が必要です。

また、外部ユーザーが作成した Google Chat のスペースは移行対象とならないなどの制約もあります。

移行しないデータを決め、整理する

グループウェアのデータ移行では、基本的にはすべてのデータを持っていきたくなりますが、不要なデータを事前に整理することで移行期間を短縮でき、移行に必要なライセンスを減らすことも可能です。

CloudM Migrate のライセンス形態については、以前のブログでも簡単に記載していますが、共有ドライブは10GBにつき1ライセンス消費する点をご認識ください。

support.cloudm.io

そのため、特に共有ドライブでは、移行するドライブと移行しないドライブをあらかじめ切り分けておくことをおすすめします。

プロジェクト進行中に検討

権限のマッピング

CloudM では、マイドライブや共有ドライブのフォルダ／ファイルに付与されている権限を、移行先テナントでも維持できます。
そのためには、事前に権限のマッピングを作成しておく必要があります。

例えば、移行元で aaa@source.com に権限が付与されている場合、移行先では対応するアカウントである aaa@destination.com に権限を付与する、という形になります。

ただし、移行にあわせてユーザー名やグループアドレスを変更する場合は、ドメイン部分だけでなく、ネーム部分も変わることがあります。例えば、移行元の group-sales@source.com を、移行先では sales-team@destination.com に対応させる、といったケースです。

このように、移行元と移行先でアカウントやグループの対応関係を明確にしておくことで、移行後も適切な権限を維持しやすくなります。

マッピング画面 — マッピング表はスプレッドシートで用意し、CSVにしてからアップロードします

support.cloudm.io

最後に

グループウェアのデータ移行は、単にデータをコピーするだけでなく、移行期間の見積もりから対象の洗い出し、権限のマッピング、外部ユーザーとの関係整理まで、事前に検討すべきことが多岐にわたります。
本記事で触れたポイントを押さえておくことで、移行プロジェクトを計画的に、そして手戻りなく進めやすくなります。

ZUNDAでは、CloudM Migrate を用いた Google Workspace のデータ移行の設計から、事前移行・本番移行の実行、移行後のサポートまで一貫してご支援しています。また、Microsoft 365 環境の引越しや、Webサーバーのメールサービスや他のグループウェアから GWS や M365 への移行もご支援しております。グループウェアのデータ移行でお困りの際は、ぜひ一度ZUNDAにご相談ください。

Google Workspaceのお引越しは「最初の一歩」が肝心