Migration ナレッジ
クロス プラットフォーム 移行
（Cross Platform Migration）
GWS ⇄ Microsoft 365 移行の設計と実装
Google Workspace と Microsoft 365 間の移行は、
単なるデータコピーではありません。
認証・権限・構造の違いを理解した設計が成功の鍵です。
こんな課題はありませんか？
- GWS → Microsoft 365 移行で何から始めればいいかわからない
- Drive の共有や権限が壊れるのが不安
- メール移行でトラブルを避けたい
- 業務停止を最小限に抑えたい
- どのツールを使えばいいかわからない
本ページで解決できること
- クロスプラットフォーム移行の基本
- GWS ⇄ Microsoft 365 の違い
- よくある失敗パターン
- 成功する設計のポイント
- 最適な移行ツールの選び方
1.
Microsoft 365 テナント移行とは
Microsoft 365 テナント移行とは、
1つの Microsoft 365 テナントから
別のテナントへユーザーデータを移行する作業です。
主に以下のようなケースで実施されます。
企業合併（M&A）
グループ会社統合
会社分割
テナント再設計
Microsoft 365 テナント移行とは
Microsoft 365 テナント移行とは、
1つの Microsoft 365 テナントから
別のテナントへユーザーデータを移行する作業です。
主に以下のようなケースで実施されます。
企業合併（M&A）
グループ会社統合
会社分割
テナント再設計
2.
テナント統合 / 分離のシナリオ
Microsoft 365 テナント移行の多くは、
企業の組織変更に伴って発生します。
代表的なシナリオは以下の通りです。
テナント統合（Tenant Consolidation）、
企業合併（M&A）や
グループ会社統合の際、
複数の Microsoft 365 テナントを1つのテナントへ統合するケースです。
この場合、
・ユーザーアカウント
・メールボックス（Exchange Online）
・OneDrive
・SharePoint
・Teams
などのデータを、安全に移行する必要があります。
また、統合後の運用を考慮し、
テナント分離（Tenant Separation）会社分割や事業売却などにより、
既存テナントから一部ユーザーやデータを
別のテナントへ移行するケースです。
このシナリオでは、
特に、SharePoint や Teams のデータは
複数ユーザーと共有されているケースが多いため、
移行設計には慎重な検討が必要です。
テナント統合 / 分離のシナリオ
Microsoft 365 テナント移行の多くは、
企業の組織変更に伴って発生します。
代表的なシナリオは以下の通りです。
テナント統合（Tenant Consolidation）、
企業合併（M&A）や
グループ会社統合の際、
複数の Microsoft 365 テナントを1つのテナントへ統合するケースです。
この場合、
・ユーザーアカウント
・メールボックス（Exchange Online）
・OneDrive
・SharePoint
・Teams
などのデータを、安全に移行する必要があります。
また、統合後の運用を考慮し、
- ドメインの整理
- ユーザーID設計
- 権限構造
テナント分離（Tenant Separation）会社分割や事業売却などにより、
既存テナントから一部ユーザーやデータを
別のテナントへ移行するケースです。
このシナリオでは、
- 移行対象ユーザーの特定
- データの選別
- ドメイン分離
特に、SharePoint や Teams のデータは
複数ユーザーと共有されているケースが多いため、
移行設計には慎重な検討が必要です。
3.
移行対象ワークロード（Exchange / OneDrive / SharePoint / Teams）
Microsoft 365 テナント移行では、
単一のサービスではなく、複数のワークロードを同時に扱う必要があります。
代表的な移行対象は以下の通りです。
■ Exchange Online（メールボックス）最も基本となる移行対象です。
特に、
In-Place Archive（アーカイブメール） の有無や容量によって、
移行設計やツール選定に影響が出ます。
■ OneDrive（個人ストレージ）ユーザーごとのファイルデータを移行します。
注意点として、
■ SharePoint（チーム・部門データ）組織単位で利用されているデータ基盤です。
特に、
👉 権限構造の再設計が必要になるケースが多い
ため、事前設計が非常に重要です。
■ Teams（コミュニケーション / コラボレーション）Microsoft Teamsは、
複数のサービス（Exchange / SharePoint / OneDrive）と連携しているため、
👉 最も複雑な移行対象の一つ
です。
移行対象には以下が含まれます。
👉 すべてを完全に移行できるとは限らない
ため、
重要ポイント（まとめ）Microsoft 365 テナント移行では、
👉 各ワークロードを個別にではなく、全体として設計することが重要
です。
例えば：
👉 ユーザー単位で“業務環境ごと移行する”設計
が求められます。
移行対象ワークロード（Exchange / OneDrive / SharePoint / Teams）
Microsoft 365 テナント移行では、
単一のサービスではなく、複数のワークロードを同時に扱う必要があります。
代表的な移行対象は以下の通りです。
■ Exchange Online（メールボックス）最も基本となる移行対象です。
- メールデータ（Inbox / Sent / Archive）
- 添付ファイル
- カレンダー
- 連絡先
特に、
In-Place Archive（アーカイブメール） の有無や容量によって、
移行設計やツール選定に影響が出ます。
■ OneDrive（個人ストレージ）ユーザーごとのファイルデータを移行します。
- ドキュメント
- デスクトップ同期データ
- 個人フォルダ
注意点として、
- 共有リンクの扱い
- 外部共有設定
- ユーザー紐付け
■ SharePoint（チーム・部門データ）組織単位で利用されているデータ基盤です。
- サイトコレクション
- ドキュメントライブラリ
- 権限設定
- メタデータ
特に、
👉 権限構造の再設計が必要になるケースが多い
ため、事前設計が非常に重要です。
■ Teams（コミュニケーション / コラボレーション）Microsoft Teamsは、
複数のサービス（Exchange / SharePoint / OneDrive）と連携しているため、
👉 最も複雑な移行対象の一つ
です。
移行対象には以下が含まれます。
- チーム / チャネル構成
- チャット履歴
- ファイル（SharePoint連携）
- 会議情報
👉 すべてを完全に移行できるとは限らない
ため、
- 移行範囲の定義
- 再構築（Rebuild）の判断
重要ポイント（まとめ）Microsoft 365 テナント移行では、
👉 各ワークロードを個別にではなく、全体として設計することが重要
です。
例えば：
- メールだけ移行 → NG
- ファイルだけ移行 → NG
👉 ユーザー単位で“業務環境ごと移行する”設計
が求められます。
4.
ドメイン移行の注意点
Microsoft 365 テナント移行において、
最も重要かつトラブルが発生しやすいのが「ドメイン移行」です。
メールやユーザーはツールで移行できますが、
ドメインは 一度に1つのテナントにしか紐付けられない ため、
慎重な設計と段取りが必要になります。
■ ドメインは同時に2つのテナントで使えないMicrosoft 365では、
👉 1つのドメイン（例：@example.com）は
👉 1つのテナントにしか登録できません
そのため、
■ 事前準備がすべてを決めるドメイン移行は「当日作業」ではなく、
事前準備が成功の9割です。
主な準備項目：
■ 切り替えタイミングの設計ドメイン移行では、
👉 「いつ切り替えるか」が非常に重要です。
一般的には：
また、
■ メール断絶リスクドメイン切り替えの瞬間には、
👉 一時的にメールが届かない可能性
があります。
そのため、
■ よくあるトラブルドメイン移行で発生しやすい問題：
■ 重要ポイント（まとめ）ドメイン移行は、
👉 ツールではなく「設計」で成功が決まる工程
です。
ドメイン移行の注意点
Microsoft 365 テナント移行において、
最も重要かつトラブルが発生しやすいのが「ドメイン移行」です。
メールやユーザーはツールで移行できますが、
ドメインは 一度に1つのテナントにしか紐付けられない ため、
慎重な設計と段取りが必要になります。
■ ドメインは同時に2つのテナントで使えないMicrosoft 365では、
👉 1つのドメイン（例：@example.com）は
👉 1つのテナントにしか登録できません
そのため、
- 旧テナントから削除
- 新テナントへ追加
■ 事前準備がすべてを決めるドメイン移行は「当日作業」ではなく、
事前準備が成功の9割です。
主な準備項目：
- すべてのユーザーのUPN変更（onmicrosoft.com化）
- メールアドレスの一時変更
- 配布グループ / 共有メールボックスの整理
- 旧テナント側のドメイン依存オブジェクトの削除
■ 切り替えタイミングの設計ドメイン移行では、
👉 「いつ切り替えるか」が非常に重要です。
一般的には：
- 業務時間外（夜間 / 週末）
- 影響範囲が最小の時間帯
また、
- MXレコード切り替え
- Autodiscover設定
- DNS反映時間（TTL）
■ メール断絶リスクドメイン切り替えの瞬間には、
👉 一時的にメールが届かない可能性
があります。
そのため、
- 一時的なルーティング設計（中継）
- 移行前後のテスト送信
- ユーザーへの事前周知
■ よくあるトラブルドメイン移行で発生しやすい問題：
- ドメインが削除できない（依存オブジェクト残存）
- 一部ユーザーのメールが届かない
- Outlook / Teams の再認証トラブル
- 旧テナントにデータが残ったまま
■ 重要ポイント（まとめ）ドメイン移行は、
👉 ツールではなく「設計」で成功が決まる工程
です。
- 準備（依存排除）
- タイミング設計
- DNS制御
- ユーザー影響の最小化
5.
In-Place Archive 移行
Microsoft 365 テナント移行において、
見落とされがちだが非常に重要なのが「In-Place Archive（オンラインアーカイブ）」の移行です。
通常のメールボックスとは別領域で管理されるため、
移行設計を誤ると データ欠損やユーザー混乱の原因になります。
■ In-Place ArchiveとはIn-Place Archive は、Exchange Online における
長期保存用のメール領域です。
■ 通常のメール移行との違いIn-Place Archive は、
👉 通常のメールボックスとは別オブジェクト
として扱われます。
そのため、
■ 移行時の注意点 ① ツール対応の確認すべての移行ツールが
In-Place Archive に対応しているわけではありません。
👉 事前に対応可否を必ず確認する必要があります
② 容量と時間の問題アーカイブは
👉 数十GB〜数百GBになるケースも多い
ため、
③ ユーザー体験への影響移行中または移行後に、
👉 ユーザーからの問い合わせが増えやすいポイント
■ 推奨される設計In-Place Archive 移行では、
👉 「移行する / しない」を明確に決めることが重要です。
選択肢として：
特に、
👉 コンプライアンス要件（保存義務）
がある場合は慎重な判断が必要です。
■ 重要ポイント（まとめ）In-Place Archive は、
👉 “見えにくいが重要なデータ”
です。
そのため、
In-Place Archive 移行
Microsoft 365 テナント移行において、
見落とされがちだが非常に重要なのが「In-Place Archive（オンラインアーカイブ）」の移行です。
通常のメールボックスとは別領域で管理されるため、
移行設計を誤ると データ欠損やユーザー混乱の原因になります。
■ In-Place ArchiveとはIn-Place Archive は、Exchange Online における
長期保存用のメール領域です。
- 古いメールの自動アーカイブ
- コンプライアンス対応（保存ポリシー）
- メールボックス容量の最適化
■ 通常のメール移行との違いIn-Place Archive は、
👉 通常のメールボックスとは別オブジェクト
として扱われます。
そのため、
- 通常メール → 移行できた
- アーカイブ → 未移行
■ 移行時の注意点 ① ツール対応の確認すべての移行ツールが
In-Place Archive に対応しているわけではありません。
👉 事前に対応可否を必ず確認する必要があります
② 容量と時間の問題アーカイブは
👉 数十GB〜数百GBになるケースも多い
ため、
- 移行時間の増加
- スロットリング（Microsoft側制限）
③ ユーザー体験への影響移行中または移行後に、
- アーカイブが見えない
- Outlookで表示されない
- 検索結果に出てこない
👉 ユーザーからの問い合わせが増えやすいポイント
■ 推奨される設計In-Place Archive 移行では、
👉 「移行する / しない」を明確に決めることが重要です。
選択肢として：
- すべて移行する
- 一部のみ移行する
- 移行せず再構築する
特に、
👉 コンプライアンス要件（保存義務）
がある場合は慎重な判断が必要です。
■ 重要ポイント（まとめ）In-Place Archive は、
👉 “見えにくいが重要なデータ”
です。
そのため、
- 対応ツールの確認
- 容量と時間の見積もり
- ユーザー影響の事前説明
6.
移行ツールの選び方
Microsoft 365 テナント移行では、
適切なツール選定がプロジェクト全体の成否を左右します。
単に「移行できるか」ではなく、
👉 どれだけ安全に・効率よく・確実に移行できるか
が重要なポイントになります。
■ 主な移行ツールの種類テナント移行で利用される代表的なツールには以下があります。
① 対応ワークロードツールによって、
👉 必要なワークロードをすべてカバーできるかが重要
② In-Place Archive対応前章で述べた通り、
👉 アーカイブ対応の有無は非常に重要
です。
特に大規模環境では、
👉 ここでツール選定を誤るとやり直しになる
ケースもあります。
③ 移行方式（自動化レベル）ツールによって、
👉 運用負荷・工数に直結するポイント
④ エラー処理・再実行性移行では必ずエラーが発生します。
重要なのは、
👉 エラー時にどれだけ簡単に再実行できるか
です。
⑤ サポート体制移行ツールは「使えればOK」ではなく、
👉 問題が発生したときにどう対応できるか
が重要です。
■ 代表的なツールの特徴
● MigrationWiz（BitTitan）幅広いワークロードに対応
実績が豊富
柔軟な設定が可能
👉 大規模・複雑な移行案件に強い
● CloudMシンプルで直感的な操作
Google Workspaceとの連携にも強い
自動化が進んでいる
👉 スピード重視・運用効率重視の案件に適している
■ 重要ポイント（まとめ）移行ツールの選定では、
👉 機能だけでなく「プロジェクト全体の設計」との適合性
が重要です。
対応範囲
自動化レベル
再実行性
サポート体制
これらを総合的に評価する必要があります。
■ 最後にMicrosoft 365 テナント移行は、
👉 ツールだけでは成功しません
設計
手順
実行管理
これらを組み合わせて、
初めて安全な移行が実現します。
(EOF)
移行ツールの選び方
Microsoft 365 テナント移行では、
適切なツール選定がプロジェクト全体の成否を左右します。
単に「移行できるか」ではなく、
👉 どれだけ安全に・効率よく・確実に移行できるか
が重要なポイントになります。
■ 主な移行ツールの種類テナント移行で利用される代表的なツールには以下があります。
- 専用移行ツール（例：MigrationWiz、CloudM など）
- Microsoft純正機能
- スクリプトベース（PowerShell等）
① 対応ワークロードツールによって、
- Exchange Online（メール）
- OneDrive
- SharePoint
- Teams
👉 必要なワークロードをすべてカバーできるかが重要
② In-Place Archive対応前章で述べた通り、
👉 アーカイブ対応の有無は非常に重要
です。
特に大規模環境では、
👉 ここでツール選定を誤るとやり直しになる
ケースもあります。
③ 移行方式（自動化レベル）ツールによって、
- 完全自動（並列処理）
- 手動作業が必要
- 段階的移行（バッチ処理）
👉 運用負荷・工数に直結するポイント
④ エラー処理・再実行性移行では必ずエラーが発生します。
重要なのは、
👉 エラー時にどれだけ簡単に再実行できるか
です。
- 差分再実行
- ログの可視性
- トラブルシュートのしやすさ
⑤ サポート体制移行ツールは「使えればOK」ではなく、
👉 問題が発生したときにどう対応できるか
が重要です。
- ベンダーサポートの品質
- ドキュメントの充実度
- 日本語対応の有無
■ 代表的なツールの特徴
● MigrationWiz（BitTitan）幅広いワークロードに対応
実績が豊富
柔軟な設定が可能
👉 大規模・複雑な移行案件に強い
● CloudMシンプルで直感的な操作
Google Workspaceとの連携にも強い
自動化が進んでいる
👉 スピード重視・運用効率重視の案件に適している
■ 重要ポイント（まとめ）移行ツールの選定では、
👉 機能だけでなく「プロジェクト全体の設計」との適合性
が重要です。
対応範囲
自動化レベル
再実行性
サポート体制
これらを総合的に評価する必要があります。
■ 最後にMicrosoft 365 テナント移行は、
👉 ツールだけでは成功しません
設計
手順
実行管理
これらを組み合わせて、
初めて安全な移行が実現します。
(EOF)