オンプレミスのExchange環境からGoogle Workspaceへの移行は、
単なるデータ移動ではなく、
「メール基盤そのものの置き換え」を伴うプロジェクトです。

そのため、移行の成否はツール選定ではなく、
事前設計の精度と進め方（プロセス設計）に大きく依存します。

まず前提として、オンプレミス環境では、

• Active Directoryによるユーザー管理
• Exchangeサーバーによるメール運用
• 社内ネットワークを前提としたアクセス制御

といった構成が一般的です。

一方、Google Workspaceでは、

• クラウド上でのユーザー管理
• Gmailによるメール提供
• インターネット前提のアクセス設計

へと、構造自体が大きく変化します。

この違いを踏まえずに移行を進めると、

• メールの不整合（未同期・重複）
• 権限・共有設定の崩れ
• 想定以上の移行時間の発生
• カットオーバー時の業務停止

といった問題が発生する可能性があります。

そのため、実務においては以下のステップが重要となります。

① テスト移行
（小規模な本番）実データを用いて移行時間・挙動を確認し、
本番時のリスクを事前に洗い出します。

② 移行設計（順序・並列・方式）
ユーザー単位・部門単位での移行順序、
同時実行数（スロットリング対策）を設計します。

③ 段階移行（差分同期）
一度で切り替えるのではなく、
差分同期を前提とした段階的な移行を行います。

④ カットオーバー設計
MXレコード切替のタイミングと影響範囲を整理し、
業務への影響を最小限に抑えます。

オンプレミスからクラウドへの移行は、
「一度きりで失敗が許されないプロジェクト」です。
だからこそ、
“設計された移行”を行うことが成功の鍵となります。

本ページでは、オンプレミスのExchange環境からGoogle Workspaceへの移行において、
実務で直面する課題とその対処方法を、設計視点で整理しています。

特に以下のような疑問・不安を解消することを目的としています。

• オンプレExchangeからGoogle Workspaceへの移行は、どのような手順で進めるべきか
• 大規模環境（数百ユーザー）における現実的な移行スケジュールの考え方
• 一括移行と段階移行の違いと、それぞれの適用判断
• テスト移行はなぜ必要か、どの範囲まで実施すべきか
• 移行時間が読めない原因と、その見積もり方法
• スロットリング（同時接続制限）を踏まえた並列実行設計のポイント
• MXレコード切替時に発生する影響と安全なカットオーバー手順
• よくある失敗パターンと、その回避策
• BitTitanなどの移行ツールをどう使い分けるべきか

本ページの内容は、単なる手順解説ではなく、
実際の移行プロジェクトにおいて「判断が必要になるポイント」にフォーカスしています。

そのため、
「ツールをどう使うか」ではなく
「どう設計すれば安全に移行できるか」
という観点で読み進めていただくことをおすすめします。

オンプレミスからGoogle Workspaceへの移行においては、
事前に十分な準備を行わずに進めてしまうことで、
本番移行時に深刻な問題が発生するケースが少なくありません。

ここでは、実務で頻発する失敗とその背景を整理します。

① テスト移行を行わない
最も多いのが、いきなり本番移行を開始してしまうケースです。
移行ツールが動作することと、実環境で問題なく完了することは別問題です。

特に、

• 実際のメール容量
• フォルダ構成の複雑さ
• ネットワーク帯域
• Exchange側の制限（EWS）

といった要素は、テストを行わない限り把握できません。
結果として、
「想定より何倍も時間がかかる」

という事態に陥ります。

② 移行時間を正しく見積もれない
「1ユーザーあたり○GBだから、このくらいで終わるだろう」
という単純な計算でスケジュールを組むケースです。

しかし実際には、

• 同時接続制限（スロットリング）
• API制限
• ネットワーク負荷

により、理論値通りには進みません。

その結果、

• 移行が終わらない
• カットオーバーに間に合わない

といった問題が発生します。

③ 一括移行を前提にしてしまう
全ユーザーを一度に切り替える「一括移行」を前提とするケースです。

一見シンプルですが、

• トラブル時の影響範囲が大きい
• ロールバックが困難
• ユーザーサポートが追いつかない

というリスクを伴います。
実務では、差分同期を前提とした段階移行が現実的です。

④ カットオーバー設計が曖昧
MXレコード切替のタイミングを曖昧にしたまま進めてしまうケースです。
これにより、

• 一部ユーザーだけ新旧混在
• メールの取りこぼし
• 送受信の遅延

といった問題が発生します。
カットオーバーは「DNS変更」ではなく、
業務影響を含めた設計作業として扱う必要があります。

⑤ ユーザー・権限設計を後回しにする
メールデータの移行だけに注目し、

• ユーザー作成
• グループ
• 共有設定

を後回しにしてしまうケースです。
その結果、

• ログインできない
• メールが見えない
• 共有が壊れる

といった、業務に直結する問題が発生します。

⑥ 「ツールで解決できる」と考えてしまう
最も根本的な誤解です。
移行ツールはあくまで「実行手段」であり、
成功を保証するものではありません。
実際には、
設計 ＝ 80%
ツール ＝ 20%

という比率で結果が決まります。

オンプレミスからGoogle Workspaceへの移行は、
ツールの操作ではなく「設計」で成否が決まるプロジェクトです。

ここでは、実務で重要となる設計ポイントを整理します。

① テスト移行を前提に設計する
本番前に必ず「小規模な本番」を実施します。

• 実データで移行時間を測定
• エラー発生箇所の特定
• ネットワーク負荷の確認

これにより、
👉 本番時の「想定外」を事前に潰すことができます。

② 移行順序と単位を設計する
移行は「誰から・どの単位で」行うかが重要です。

• 部門単位
• ユーザー単位
• 優先度（業務影響）

さらに、

• 同時実行数（並列数）
• スロットリング対策

を設計することで、現実的なスピードで進行できます。

③ 差分同期を前提とした段階移行
一度で移行を完了させるのではなく、

• 初回：全体移行（ベース）
• その後：差分同期（増分）

という構成にすることで、
👉 業務を止めずに移行を進めることが可能になります。

④ カットオーバー設計（最重要）
カットオーバーは単なるDNS変更ではありません。

• MXレコード切替のタイミング
• 切替対象ユーザー範囲
• 影響時間の最小化

を事前に設計することで、
👉 「メール止まった」という最悪の事態を防ぎます。

⑤ ユーザー・権限の事前設計
移行前に必ず以下を整備します：

• ユーザーアカウント作成
• グループ設計
• 共有設定（Drive / メール）

これを後回しにすると、
👉 「使えない状態」で移行が完了してしまいます。

⑥ 移行後の運用を見据える
移行はゴールではなく「スタート」です。

• 管理方法（管理者権限）
• セキュリティポリシー
• ユーザー教育

まで含めて設計することで、
👉 移行後も安定運用が可能になります。


本件のようなオンプレミスからの移行は、
設計次第で成功率・工数・期間が大きく変わります。

ご状況をお伺いした上で、最適な進め方をご提案可能です。

まずは、お気軽にご相談ください。


なお、本ページの内容に加えて、
以下のナレッジもあわせてご参照いただくことで、
より全体像を把握いただけます。

・テナント移行の設計と実装
・ファイルサーバ移行のポイント
・クラウドストレージ移行の考え方