Google Workspace から Microsoft 365 へ：メール移行の注意点とベストプラクティス

Google Workspace から Microsoft 365 への移行をご支援することがあります。具体的には親会社の考え方によって変更が必要となるケース／M＆Aでシステムを合わせる必要があるケース／従来から両方のサービスを使っており１つに片寄せするケース／取引する業界の商習慣に合わせて変更するケースなどがあります。

こういった移行の時にどういうことに気を付けたほうが良いのかという点を記載したいと思います。

この記事は、以下の読者を対象にしています。

今回はプロジェクトそのものではなく技術的な点にフォーカスをして記載をしていきます。

Google Workspace も Microsoft 365 もクラウドサービスですが、それぞれの製品の設計思想やつくりが違うので考慮点がたくさんあります。

わかりやすくするために今回はメール（Gmail と Exchange Online）にフォーカスしてみます。

用語整理
・Gmail：Google のメールサービス
・Exchange Online ：Microsoft 365 のビジネスメールサービス
・Outlook ： Exchange Online にアクセスするメールアプリ（WEBとクライアントがある）

Gmailでは受信トレイに入ったものにラベルを割り当てたりアーカイブをして受信トレイから減らしていくという運用が一般的です。Gmail のラベルは、1通のメールアイテムに対して複数割り当てることも可能です。

Outlook の場合にラベルという概念は無いため、フォルダーを作る必要があります。通常は１つのフォルダに振り分けられる仕組みのため、複数のフォルダに保管したい場合はコピーする必要があります。

ポイント：Gmail でラベル運用をしている場合に Outlook に移行をすると、ラベルとフォルダは１対１で対応するため、ラベルの数だけフォルダが作成されます。そのため、メールなどのアイテムが各フォルダにそれぞれコピーされるという仕様です。つまり移行前にラベルを整理することが推奨されます。

Gmail はプランによって異なりますが、プランとアカウント数に応じた容量が組織全体で共有される仕組みのため、意識をすることはほとんどありません。

Exchange Online の場合はプランごとに各ユーザーが使える容量が決まっており、組織全体では共有・合算されないため 50GB なら 50GB しか使えません。お金を払って上位ライセンスにしたとしてもユーザーあたり 100GB が上限となります。

100GB を超えた場合はどうするかというと一般的には「Exchange Online Archiving」というライセンスによって使えるようになる「オンラインアーカイブ」という領域に移動することになります（上に記載の 50GB や 100GB とは別の領域となる。昔は無制限だったが現在は最大1.5TBまで）

ポイント：容量管理は Gmail よりもシビア。メールをユーザーが保管する場合は「Exchange Online Archiving」を用いて「オンラインアーカイブ」を考慮する必要がある。

移行元の Gmail との容量差を補うために移行先の Outlook 側で「オンラインアーカイブ」を使う場合ですが、データ移行前に有効にする必要があります。また有効にした場合は領域が２つ（通常の領域とオンラインアーカイブの領域）となるのでこの間の自動移動の設定をする必要があります。既定では２年でオンラインアーカイブに移動するという仕様になっているため必要に応じて変更する必要があります。

仮に Gmail から５年分の150GBのデータを移行するとします。そもそもそのまま移行しようとすると Exchange Online の容量が最大 100GB（ライセンスによって異なる） なのであふれてしまいます。また、２年以上経過したものは移行したあとに特定タイミングで処理が動き「オンラインアーカイブ」に移動するため、通常のメールボックスからは確認できなくなります。

該当する場合は、移行タイミングを分割する必要があるということと、オンラインアーカイブに移動するタイミングまで考慮して移行する必要があります。

ポイント：「オンラインアーカイブ」は手動で有効化する必要がある。既定で２年でオンラインアーカイブ領域に移動する。

挙げた3点のみでも考慮すべきポイントは多いですが、当然他にもたくさんあります。またメールだけではなくドライブやカレンダーなど移行するサービスごとにたくさん考慮すべきポイントがあります。

選択する観点としては主に時間／ユーザーの手間／管理者の手間／正確性／金額などになるかと思います。時間は短く、手間はかからず、正確に、安くできるのを望むのは皆さん一緒ですがそれが現実的には難しいのはお察しの通りです。一般的な項目を下記に洗い出してみます。

Gmail と Exchange Online は、どちらも IMAP というプロトコルに対応しています。それを利用し、ユーザーの端末上にデータを保持するタイプのメールクライアント経由で Gmail と Exchange Online の両方をつないで、メールデータを移動してしまうという方法です。

各端末ごとに設定をする手間の部分もそうですが、ユーザーが一気に行うことでダウンロード／アップロードをすることになるので回線をひっ迫するなんてことが考えられます。

また IMAP プロトコルの帯域幅はアカウント単位で制限されていますので（Gmail は1日あたり、ダウンロード 2,500MB、アップロード 500MB。Exchange Online は非公表）、容量が大きい場合は分割して少しずつ実行する必要があります。

時間も手間はかかりますが金額面でのメリットは大きい方法です。

Outlook クライアントを利用する考え方です。Gmail でOutlookクライアントを使っておらず、Exchange Online 移行後も使う想定がない場合は考慮不要かと思います。

Outlook クライアントで PC上にPSTファイル というメールボックスの入れ物を作ってそこに移動をしたり、場合によってはそれを移行せずにそのまま使うという運用です。

移行製品によってはこのPSTファイルをアップロードすることで移行ができるようなものもあります。

IMAP移行とやり方は違いますが同じようなメリット／デメリットになるかと思います。

上記のような手間を避けるために専用のツールを使う方法です。

移行先である Microsoft 365 の Exchange 管理センターにも機能はあり「Google Workspace（Gmail)の移行」があります。

参考：Microsoft 365 または Office 365 への Google ワークスペース (旧称 G Suite) の移行を実行する

オフィシャルが出しているのでそれを使えばいいと考えたくなるのですが、詳細なエラーログを出すことができないなど機能上の制限もあり、これに向いていない移行のケースもあります。移行対象の人数が多くスケジュールも短期間でやらなくてはいけない場合などは専用ツールを使うことを強く推奨します。

大企業が Microsoft に相談をした場合に移行製品の会社を紹介されているという事実からも察していただけるかと思います。

「移行っていつまでに何をするのか」というゴール設定は皆さんでバラバラなケースがほとんどです。

例えばメールであれば、MXレコード（メールアドレスに送った場合にどこのメールサーバーに届けるのかの設定値）をいつ変更するのか、というのが１つのポイントになります。

仮にユーザーが利用中のサービスを切り替える日を「業務切替日」とした場合にいろんなパターンがあります。

①業務切替日の当日や前日にMXレコードを変更する

②業務切替日より前に変更する（Exchange Online から Gmail に転送をする）

③業務切替日より後に変更する（Gmail から Exchange Online に転送をする）

メールも業務切替日にすべてのデータが移行先にないといけないのか、それとも古いメールは Gmail を見ていただくのか、事前に２週間～１か月程度は両方に存在するようにしてメールデータの移行は後にするのかなど、色々な方法があります。

ここに正解はありません！ご要望や費用やスケジュールや他システムの制約といった要素で選択肢が変わります。

ここまで読んでいただいて感じられた方も多いと思いますが、どういう移行を行うのかという考え方次第で、選択すべき移行方法が変わります。また、それによって移行のスケジュールや制約も変わります。

移行の考え方やスコープといった前提を途中で変更しようとすると、設計が大きく変わるので大きなトラブルになりかねません。一括移行を予定していたのに「やっぱり段階移行に変える」とか「移行スコープで〇〇を増やして」のような要件の変更が発生すると大きく手戻りが発生したり、場合によってはスケジュールが担保が出来なくなることもあります。

移行そのものには「コツ」というものがあります。コストが掛かったとしても必要なテストは行うべきですし、ステークホルダーから要望があったとしてもリスクが高いものは避けるというのが一般的な考え方です。企業様や移行ベンダーによってはそういった考えを無視して失敗するケースもかなり見ています。すべての要望を満たす「銀の矢」はありません。様々な失敗を元に確立された一般的な方法をとることをおススメします。

担当者が社内政治によって翻弄されるケースもあるかと思います。そういったリスクをなるべく避けるようにステークホルダー管理をしていただくことと、変更となりそうな部分があれば影響度が大きいかどうかを移行ベンダーに早めに相談できるような関係性を作るのが良いです。

グループウェアの移行を他のシステム移行（基幹システムなど）と同じで考えるのは避けたほうが良いです。コミュニケーションツール固有の考慮ポイントがあるからなのです。こういったポイントを外して移行をするとユーザー視点の欠如によりプロジェクトを炎上させる可能性があがります。

最も重要なのはステークホルダーを管理することです。その次に重要なのは、プロジェクトに必要な知見を持った人材のアサインです。

移行対象の製品（Google Workspace / Microsoft 365）および移行ツール について十分な知見があって、場合によっては関連するサードパーティ製品ツールについても知見がある人が必要です。

上のような人材が少人数で案件をまわすなんて理想的な環境はかなり少ないですが、必要な知見を持ったメンバーがいないとリスクは増えます。実際の引っ越しのように頭数がいればいいという話しでもありませんし、「やったことがないですが、がんばります！」といった会社が一定規模以上の案件でうまく回すことは非常に困難だと思います。

ユーザー目線での「時間は短く、手間はかからず、正確に、安く」は残念ですが非常に困難です。同様の経験やナレッジが豊富なベンダーの知見を積極的に利用することが、プロジェクトの成功への道しるべとなるでしょう。

まずはどういう移行がしたいのかという点をまとめていただいて相談いただければと思いますが、移行検討のなるべく早い段階で情報の整理のためにご相談いただくのも良いと考えています。

前提として、移行したいサービス・容量・人数・ライセンス（移行元・移行後）・グループウェアに関連するサードパーティ製品の情報などが揃っていることが移行設計の前提となり、そこが変わるとあとから大きく作業内容が変わってしまいます。要件が早い段階から明確であることで現実的な価格帯での提案が出来るかと思っています。

M＆Aやライセンス期限の制約でスケジュールが決まっていて考慮する時間があまりない場合はリスクが少ない方法をとるため、移行製品なども多機能なものを選択することになります（ライセンス費用が高くなる場合が多いです）。失敗すると業務インパクトが大きいのがグループウェアであり、要件に少しでも柔軟に対応できるようにという思いがありますのでご容赦ください。

メールにフォーカスをして移行についての概要を書いてみました。移行が簡単に見えて考慮ポイントが多いということにお気付きいただけましたでしょうか。移行が一定規模になると、Google Workspace / Microsoft 365 両方の知見と移行の経験があるエンジニアがプロジェクトに参画していることというのが、移行をスムーズに進めるための条件になるかと思っています。移行はいきあたりばったりではなく計画や設計に時間をかけてください。しっかりやらないと考慮不足で「行くも地獄、戻るも地獄」となることがあります。しっかりと準備して移行を実施してください。

ZUNDA は、Google Workspace / Microsoft 365 の導入支援・運用サポートに豊富な経験を持つ、Google 認定プレミアパートナー / Microsoft ソリューションパートナーです。Google Workspace / Microsoft 365 間の移行や平行稼働のお困りごとなどは、ぜひ当社までご相談ください。お客様の要件を詳しくヒアリングし、おすすめの支援プランをご提案します。

まずはお気軽にお問い合わせください。 お客様のグループウェア利用を全力でサポートいたします。