Google

HOME
office
Google
Google Workspace MigrateでMicrosoft365からお引越し - 事前準備編

2025年1月6日 / 最終更新日時 : 2025年1月8日 officeの杜 Google

Google Workspace MigrateでMicrosoft365からお引越し - 事前準備編

Microsoft365が値上げに次ぐ値上げという事でGoogle Workspaceに移行しようという組織が増えているようです。ただこの引越し作業はGoogle公式から移行用ツールが出ているものの、ウェブ上に殆ど知見が存在しません。またCloudMやMigration Wizといったサードの引っ越しツールなどもある中で、実際に情シスがこのミッションをやるとなるとなかなか大変です。

ということで、実際に公式ツールを使っての移行をする上でのポイントをまとめてみました。本エントリーは実作業前の事前準備を中心としており、実際使うサーバ用の事前準備は移行編にてまとめる予定です。

1 今回利用するツール
2 移行対象や規模による使い分け
3 事前準備
4 移行検証
- 4.1 コスト感
- 4.2 スケジュール感
5 関連リンク

今回利用するツール

Google Workspace Migrate

このツールは本来、自社の情シスが使うためのツールであり、SIerなどのベンダーに依頼して使う為のツールではありません。よって、Google WorkspaceおよびMicrosoft365両方の特権管理者の権限が必要であり、双方に対して知識が要求される為なかなかハードルが高いです。コストも相応に掛かります。

また、個人的私見からした場合に「コストを理由にしての引っ越し」は失敗する可能性が非常に高いです。引っ越しをするに値する相応の理由と覚悟が必要となります。

また引っ越して終わりということにもならないので、まずは以下の2つのエントリーを見ていただいて自社で行けそうか？よくよく判断したほうが良いかと思います。特に文化的なハードルは技術でどうこうできるものではないので、無理に移行すると大混乱を招く可能性が高いです。、

Google WorkspaceとMicrosoft365の機能比較

Google Workspaceを新規に導入する時に押さえたいポイント

移行対象や規模による使い分け

今回のテーマはGoogle Workspace Migrateというツールについてなのですが、必ずしもこのツールでなければならないというわけではありません。引っ越しの規模やターゲットによっては別のツールも用意されていたりします。また、併用することもあるので選択肢としては頭に入れておく必要性があります。

小規模向け

GWMMO

小規模組織で使えるツールとして、GWMMO(Google Workspace Migration for Microsoft Outlook)があります。対象規模としては1〜100名規模の組織で、メール・カレンダー・タスクのみを移行対象とする場合に利用します。別途サーバなどは必要ありませんが、移行対象のユーザ個別のPCにインストールして、個別に移行してもらう必要があります。

利用はWindowsオンリーなのでmacOSなどでは使うことが出来ません。

制約事項として

クライアントはOutlookを利用してる必要性があります。
IMAP や Exchange 、ウェブ版の Outlook データの移行は対象外です。Windows 版の Outlook かつPOP3にてダウンロードされているもののみ対象。PSTファイルでもオッケーです。
また一斉にPSTファイルを複数でアップすると帯域の圧迫を起こす可能性があります。

現在のM365はPOP3での受信は出来なくなってるので、別の手段でPSTファイルを入手する必要性があります。それらについては以下のエントリーに別途纏めています。

Microsoft365のOutlookからPSTをエクスポートする手法

OneDrive Migration

2024年10月11日リリースされた、β版ですがMicrosoft365からGoogle Workspaceのマイドライブに対するマイグレーションツールが発表されました。上限100名でSharepointは対象外であるため、小規模な移行でしか使えませんが、別途サーバを立てる必要性はなく、管理コンソール上から行えますので、管理者レベルで行うことが可能です。

以下のエントリーで別途まとめていますので、個別移行が必要なケースではプランの1つとして考えても良いかもしれません。

OneDriveからGoogle Driveへ移行するツールを検証してみた

中規模向け

GWMME

100名以上〜1000名以下の規模でIMAPやExchange Serverからのメール・カレンダー・タスク・連絡先の移行を考えている場合に利用するツールがGWMME(Google Workspace Migration for Microsoft Exchange)となります。

こちらは別途Google Cloud上のCompute EngineにてWindows Serverを構築し、その上で動かす必要性がある為、管理者が移行作業を行う必要性があります。サーバはGWSテナントの存在するGCP上に構築することで、GCP⇒GWS間はインバウンド通信扱いとなるため、ネットワーク通信に関してはコストが掛からないです。

制限事項としては

Windows ServerにもOutlookを別途インストールしておく必要性があります（しかも32bit版でなければエラーが出る）
個別ユーザのID/PWは必要ありません。M365およびGWS側の管理者権限が必要になります。
M365のセッション数制限やGoogle側のエラー項目などを元に事前に同時にどれくらいのユーザを処理できるのか？などはテストする必要があります。

共有メールボックスについてもGoogle Groupの共同トレイとして移行させることが可能です。

図：GWMMEセットアップ画面

大規模向け

Google Workspace Migrate

今回のテーマであるGoogle公式で出してるツール。1000名以上の規模で利用するためのツールで、Exchange以外にOneDrive・Sharepointにも対応している。別途複数のサーバを構築する必要があり、規模に応じてその台数も変わります。共有メールボックスやパブリックフォルダの移行も可能としています。

何故かBoxやオンプレのSambaからの移行にも対応している。

制約事項として以下のようなものがあります。

Teams→Google Chatへの移行については2025年1月時点では未対応。別のツールがGoogleからリリースされてるので後述のツールを使うことになる（ただし個別チャットは未対応なのでGraph APIなどを使って自前でツールを作る必要性がある）
1ファイル2GBが上限（仮想環境のファイルなどのバカでかいのは無理）
2GB超えるようなファイルは、rcloneを補完で使うと良い。PSD、ZIP、PSTなどはデカいのがあるでこれは注意。これらがSharepointなどにあるとエラーとなる
Sharepointのページ自体はGoogle Sitesに移行は出来ません（Google側にAPIが無い為）

CloudM

電算システムさんで採用してるCloudM。テナントのデータをGoogle Workspaceへの移行させるためのツールで、国内実績のある移行ツールになります。本家サイトはこちら。

Microsoft365だけじゃなく、様々なクラウドストレージにも対応している。逆方向のマイグレーションにも対応。

MigrationWiz

TD SYNNEXさんで採用してるMigrationWiz。CloudM同様にGoogle Workspaceへの移行をさせるためのツールで、国内実績のある移行ツールになります。逆方向のマイグレーションにも対応。

※JBSさんでも採用してるようだ。

CloudFuze

Google Workspace Blogでも頻繁に名前は出てくるものの、日本国内ではあまり馴染みの無い海外の企業の移行サービスがCloudFuze。

Microsoft365→Google Workspaceへの大規模移行のツールだけでなく、Teams → Google Chatへの移行ツールなども用意されており充実はしている（最近でもWorkplace for metaなどからの移行も対応）。

その他の移行手段

Mozilla Thunderbird

クライアントがmacOSであったり、Microsoft365からではない場合などのメールの移行ではMozilla Thunderbirdを使った移行手法が昔からあります。またこのケースの場合、クライアントが持ってるメールボックスはmbox形式であるため、ImportExportTools NGアドオンを併用して、mbox形式でアップロードが必要です。個別ユーザに引っ越ししてもらう必要があります。

メールボックスのサイズによってはデータが巨大であるため、多数で同時にインポート作業をしてしまうとネットワークがパンクする可能性があります。よって、移行スケジュールで班分けをし、同時に多数の人がアップロードしないような施策が必要になります。

※このツールは退職者のバックアップデータを閲覧する手段としても活用出来ます。

図：双方向でメールデータの移行が可能

MBOX形式のメールをThunderbirdを使ってOutlookにお引っ越し

rclone

様々なクラウドストレージサービスやNASなどにも対応してる超万能なファイルコピーツールがrcloneです。有名どころですと、BoxやDropbox、Google Drive、Sharepoint、OneDrive Businessなどなど。

単にアップロードするだけでなくエラーなどが発生した場合の差分アップロードにも対応しており、ローカル環境へクラウドストレージをドライブとしてマウントするなどの変わった機能も併せ持ちます。実際に自分もローカルNASからのアップロードを行いましたが、非常に優秀でエラーが発生しても、再度実行すれば差分でアップしてくれるのでやり直しが楽です。

rclone自体はコンソールアプリなので通常はrclone browserと合わせて利用する。但し、バックアップタスクの設定はコマンドプロンプトから行う必要があります。GWMの制限により2GB超えのファイルなどを転送する必要がある場合などは併用することも考えられますし、無償で利用可能なGWM以外の手段の場合はNASからのアップロードは実質rclone一択となります。

※Google Driveへの移行の場合、1アカウント1日750GBの上限制限があるので、複数のサービスアカウントを用意し複数台のマシンで移行作業を行わせる必要性があります。

rclone browserでGoogle Driveにガッツリ同期させる

Teams→Google Chat移行ツール

2024年12月17日、Google公式からMicrosoft TeamsからGoogle Chatへのチャンネルデータ移行ツールがリリースされました。Google Chat APIとMicrosoft Graph APIを使って移行してるものと思います。

色々と制限事項や移行対象についてはこちらに一覧表でまとめられています。

管理コンソール上で完結する為、GWMのような面倒なサーバ立てや莫大な移行コストはありません。気になる制限事項としては、「Teamsのチャンネルへの投稿時の添付ファイルはSharepointにアップロードされたデータは移行されない」となっているので、ここは要注意です。

TeamsからGoogle Chatへ移行するツールを検証してみた

ドライブトランスファー

吉積情報さんの所で独自に開発してリリースしてるCmocyの機能の１つとして提供されてる「ドライブトランスファー」。有償だと思われますが、オンプレのNASからGoogle Driveへのバックアップを実現するツールとしてリリースされています。

Java14で構成されてるようで、Windows, Linux, macOSで動作するようです。

Transfer Appliance

特殊な用途で用いるGoogle Cloudのサービスの１つにTransfer Applianceがあります。ただし、Google Workspaceに用いることができるかどうかは不明。

こちらにレビューしてる方がいますが、このサービスはAzureで言うところのData Import/Exportサービスと同じように物理ディスクに格納して送付し、Cloud Storageに格納されるサービスのようです。手軽に頼めるものではないものの、ローカルのNASからGoogle Cloudにアップロードするための手段として、膨大なNASのデータを貧弱なネットワーク経由でアップするものではないので、大企業では需要があるかもしれない。

Google Driveへの移行は何らかの手段でCloud StorageからDriveへ別途移行が必要と思われます。

物理容量は100TBと480TBの2つがあるものの、圧縮で2倍程度まで格納ができるようだ。日本では2023年9月からGAになっているようです。

事前準備

アカウントの作成にあたって

Google Workspace Migrateは引っ越しツールではありますが、アカウント作成する機能は持っていません。新規のGoogle Workspaceのテナントに対して事前にアカウントを作っておく必要があります。

その際に考慮しなければならないのがActive DirectoryやEntra IDの存在、そして野良アカウントの存在です。Entra IDは活かしたままGWSを使うケースに於いてはEntra ID連携をすべきでしょう（同時にSSOも設定すべき）。

またアカウント作成時に遭遇する「野良アカウント対策」が必要です。会社が預かり知らない間に作られたフリーのGoogleアカウントで会社のドメインでメアドを持ってるものが存在して業務に使われる「シャドーIT化」してるものがあります。AnalyticsやAdsense、Youtubeなどなど。

これら考慮せずに移行を強行すると最悪アカウントとデータ諸共が消えますので要注意です。この対策と案内が時間かかる要素だったりします。

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - Provisioning編

Entra IDとGoogle Workspaceのメンバーを同期させる方法 - GDS編

Google Cloud Directory Syncを使ってOpenLDAPから同期させる

Google Workspaceの管理対象に含まれないユーザ用の移行ツールを検証してみた

グループや共有ドライブの作成

アカウントだけではなく、グループやSharepointのドライブのデータを収める共有ドライブについても、GWMは作ってくれるわけではありません。事前にGoogle Workspaceのテナントに対して用意しておく必要があります。グループについては前述のEntra ID連携などで自動作成可能ですが、メーリングリストとしてのグループアドレスではなく共有メールボックスとして移行先として使うグループアドレスも同じく手動で作っておきましょう。

共有ドライブについては更に注意が必要で

共有ドライブのファイル数および階層の上限を意識する必要がある
事前にSharepointのサイト側を調査してもし上限に抵触する可能性がある場合には、サイト側を分割する必要があります。
GWMでは1ファイル2GB上限があるため巨大なファイルはrcloneで個別に移動が必要です（Google Drive側上限は1ファイル5TBまで）。
対象の共有ドライブに書き込みができるように、サービスアカウントもしくはシャーディングユーザとなるGWSアカウントのコンテンツ管理者（もしくは管理者）の権限を個別に付与。
この権限付与するアカウントは、1アカウント1日750GBの移行上限があるので１つのドライブに複数のユーザアカウントを追加して切り替えられるようにしておく必要があります。

特にこのシャーディングユーザについてですが、GWMでは750GBを超えると予めシャーディングユーザとしてリストしておいたものの中から別のユーザに切り替えてアップロードを継続する機能がある為、1ドライブ1アカウントだと上限到達時に継続アップが出来なくなります（rcloneはこういった便利機能がありません）。

シャーディングユーザも複数GWSのテナントに作っておくか？必要な数だけサービスアカウントを作っておき、ドライブに割り当てしておきましょう。

Google Workspaceの共有ドライブ管理を極める

サーバ構築用Terraform

例えばフルで43台の移行用マシンをCompute Engine上にて手動でスペックを指定したりして作成や、ノードサーバを40台も手作業で作ってはRDPで入ってインストーラでサーバソフトウェア入れたり・・・はとてつもなく大変です。

そこで使うのがTerraform。GWM用の構成としては

PlatformおよびDB2台については通常通り固定IP指定でTerraformで作成し、RDPで入ってセットアップ
ノードサーバは1台手動で作成し、RDPで入ってセットアップ。その後ディスクのイメージを取っておく（スナップショットではない）
取得したディスクイメージからTerraformを使って内部IPレンジ指定で指定して、VMを40台複製する。
ディスクイメージ作成時のVMは最後は削除してしまって問題ない。

スナップショットの場合、Compute Engineの制約に引っ掛かり40台作るといったことが出来ないので、ディスクイメージからVMを複製しています。

Terraformを使うことでサーバ構築の時間の削減やケアレスミスを防ぐ事が出来ますので、GWMを使って引っ越しをする場合には、Terraformを活用するようにしましょう。

TerraformでCompute Engineのデプロイを自動化する - 基礎編

TerraformでCompute Engineのデプロイを自動化する - 応用編

移行検証

コスト感

ざっくり1ヶ月分コスト

Google Workspace Migrateは1プロジェクトあたりノードサーバは最大で40台まで設置することが出来ます。この他に必須であるプラットフォーム、MySQL、CouchDBの3個のサーバを立てて稼働させる必要性があります。

1000名を超える大規模な移行の場合、ノードサーバを何台立てる必要があるのか？は、M365側の全ユーザのオブジェクト数と移行したいスケジュールにより変動することになります。この時、最大40台で動かした場合のトータルのコスト感がざっくり300万円/1ヶ月。

また、MySQLやCouchDBのログのサイズによっては、ディスクのサイズを大きくする必要性があります。上記金額はいずれも2TBのSSDディスクの場合の値として含まれていますが、それ以上のログが発生する場合後でディスクサイズを拡張が必要です。拡張した分だけ当然コストは増加する事になります（しかも結構いい金額になります）。

公式のコスト計算ツール

Google公式でCompute Engine上でのサーバ構築と走らせた場合に掛かるコストの計算を行うツールが用意されています。これらを利用して、Platformx1, DBx2, Nodex40の場合において、DBのみ2TBのディスク容量で計算した場合のコスト計算結果といったものを作っておくと良いでしょう。

DB用のディスクは後から拡張はできるので何ヶ月も以降に掛かる場合には、最初から大きなサイズを確保しておくのではなく状況に応じて拡張するとコストを低く抑えることが可能です。

図：コスト算定をするのに便利なツールです

コスト抑えるテクニック

GWMはCompute Engine上にサーバを構築するわけなのですが、単純にユーザのリストを用意して実行するだけですと色々と無駄が生じます。とりわけExchange Onlineからの移行時は

1アカウント1ノードが専業で担当する。
オブジェクト数の多いユーザが移行作業後半に来ると処理する対象が無い遊んでる状態のノードサーバが生まれてしまう。

故にExchangeからの移行時は特に戦略が必要になります。この時、コストを抑える手法としては以下のようなテクニックが利用できます。地味なテクニックですが平均稼働率を上げることで実質移行時間の低減やコストの低減に繋がります。

オブジェクト数の多いグループとそうではないグループとで2つに分けておく。
先に重たいグループの移行を実施。次に軽いグループを実施すると遊んでる状態のノードが生じにくくなります。
遊んでる状態のノードはもう処理対象が無いので実は停止することが可能です（ストレージのコストだけは掛かります）。

停止中の待機コスト

サーバ構築中の場合まだ移行作業をしていない状態なので、そのまま走らせたままにすると当然稼働コストが掛かります（特に土日など）。また検証作業などで一旦動かしてみた後再度検証時までの間も稼働させたままというのはコストが鰻登り。これを避けるために、移行作業中以外はサーバを停止させておくべきでしょう。

Platform, DB2台, Nodeを40台を停止させている場合、ざっくり1日1万円程度のストレージコストは掛かり続けます。

停止させて暫くは使わないけれど再度使う予定がある場合には、スナップショットやイメージを取っておき（Nodeについては1個取っておけば良い。それを39台複製すればオッケー）、必要になった場合にはスナップショット等から再度サーバを構築しなおせば最短で復元が可能です。

スケジュール感

注意点

指示を出すのはPlatformサーバですが、実際の移行作業を行うのはノードサーバです。このノードサーバですがGWMでは最大で40台までの制限というのは前述の通りですが、利用する上では以下のようなことを考慮する必要があります。

ノードサーバのスペックを上げても処理能力がスケールして上がるわけじゃない。
ノードサーバを増やせば処理数は上がるのでスケールするけれど、M365側やGWS側のAPIのQuotaに抵触する可能性がある。
複数プロジェクトを立てて80台動かせば早いか？どうかはやってみないとわからない

特に2つ目のAPIのQuotaについてはGoogle Cloud側はAPIの上限引き上げ申請は出来ません。Google曰く使用量に応じてスケールして上限が広がるらしい。MS側のほうがAPIのQuota上限は大きいので、注意すべきはGoogle Cloud側のGmail APIやDrive APIなどの上限値。

ノード当たり処理能力

スケジュールを立てるに当たって最も考慮しなければならないのが、1台当たりのノードサーバの処理能力。前述にあるようにスペックを増やしても処理能力はスケールする事にはなりません。既定値のスペックで構成した場合の1台当たりの処理能力を元に、M365側の全オブジェクト数を調べて割ることで、単純移行に何日掛かるか？を調べる必要があります。

Exchange Onlineで検証時にはおおよそ1台1日80,000オブジェクト処理可能（ただし中央値）。Sharepointではざっくり1台1日50,000オブジェクトといった所。ファイルサイズやユーザ数の大小で変わってくる要素なので、実際に200名程度で移行検証を行ってみて、自分の組織の場合の1日当たり1ノードサーバの処理能力を見極める必要があるでしょう。

処理オブジェクト数についてはGWMのPartition Logから調べることが可能です。

それ以外の考慮すべき要素

実際に移行作業以外にも時間が掛かる要素がありますし、移行後にもあります。当然サーバ処理能力は期待通りになるとは限らないため、安全マージンも取っておく必要があります。主に移行作業以外での時間を考慮すべき内容は以下の通りです。

Google Workspace Migrateの各種サーバの構築時間
移行検証作業に伴うトータル時間
GWM実行時のスキャン実行時の時間（結構掛かります。この後にブリッジを実行する必要がある）
移行実行後のエラー対処のための再実行に掛かる時間（再実行することでエラーとなったものが通過する可能性があるため）
エラーで移行できなかったものを他の手段で移行させる場合の時間（rclone併用で移行など）
目的に応じて複数ブリッジに分けた場合の、他のブリッジ実行に掛かるオーバーヘッド時間。
エラーログの解析するための時間
移行作業が期待通り行かない場合の安全マージン分の日数

これらを考慮して移行スケジュールを作成する必要があります。特に安全マージン削ってピッチリなスケジュールを作ると100%失敗します。

Google Workspace MigrateでMicrosoft365からお引越し - 事前準備編

今回利用するツール