1.
Archive Migration の基本

■ Archive Migrationは「データ移行」ではない
Archive Migrationは単なるメールデータのコピーではありません。
通常のメール移行とは異なり、

• アーカイブ構造
• 保存ポリシー（Retention Policy）
• 容量制限（Quota）
• パフォーマンス制約

といった複数の要素を同時に考慮する必要があります。

■ 対象となる主なデータ
Archive Migrationでは、以下のようなデータが対象になります：

• Exchange Online の In-Place Archive
• PST ファイル（ローカル保存データ）
• 長期間保存されたメールデータ
• 大容量メールボックス（50GB以上）

■ なぜ難しいのか
Archive Migrationが難しい理由は以下の通りです：

• 通常の移行ツールでは完全に扱えないケースがある
• Archive構造が環境ごとに異なる
• 容量・スロットリング制限に影響される
• 不適切な設計によりデータ欠損が発生する可能性がある

■ 最も重要なポイント
Archive Migrationにおいて最も重要なのは：
👉 「移行前の設計」
です。
設計なしに実施された移行は、

• データの欠損
• アーカイブの崩壊
• パフォーマンス低下

といった問題を引き起こす可能性があります。

2.
対象となる主な移行パターン

Archive Migrationが必要になるのは、限られた特殊なケースではありません。
多くの企業環境で、すでに該当しています。

■ Exchange Online（In-Place Archive）を含む移行
Microsoft 365 環境において、
In-Place Archive を利用している場合、

• メールボックス本体とアーカイブの関係性
• 保存ポリシーの維持
• 容量制限の考慮

が必要となり、通常のメール移行とは異なる設計が求められます。

■ PSTファイルを含む移行
旧環境やローカル運用において、
PSTファイルが多数存在するケースです。

• ユーザーごとに分散したPST
• 長期間蓄積されたメールデータ
• 管理されていないアーカイブ

これらを適切に整理・統合しながら移行する必要があります。

■ 大容量メールボックスの移行
50GBを超えるような大容量メールボックスでは、

• 移行時間の長期化
• パフォーマンスへの影響
• スロットリング制限

といった問題が発生しやすく、
分割移行や段階的な設計が必要になります。

■ コンプライアンス・保持要件がある環境
企業によっては、

• 一定期間のメール保存義務
• 監査対応
• データ改ざん防止

といった要件があり、
Archiveの構造や保持ポリシーを維持したまま移行する必要があります。

■ テナント間移行（Tenant to Tenant Migration）
M&Aや組織再編に伴う移行では、

• 異なるポリシーの統合
• アーカイブ構造の再設計
• 大量データの安全な移行

が必要となり、
Archive Migrationの難易度が大きく上がります。

■ ハイブリッド・混在環境からの移行
オンプレミスとクラウドが混在する環境では、

• Exchange On-Premise + Exchange Online
• ローカルPST + クラウドArchive

といった複雑な構成となり、
移行設計の重要性がさらに高まります。

■ 共通するポイント上記のいずれのケースにおいても共通するのは、
👉 「Archiveをどう扱うか」で移行の成否が決まる
という点です。

act2では、これらの複雑な移行パターンに対し、
最適な設計と実装を一貫して提供しています。

3.
よくある失敗パターン

Archive Migrationは、
一見シンプルに見えて、実際には多くの落とし穴があります。

実務で頻発する代表的な失敗パターンを紹介します。

■ Archiveを考慮せずに移行を開始してしまう
最も多い失敗がこれです。
通常のメール移行と同じ感覚で進めてしまい、

• Archiveが移行されていない
• 構造が崩れている
• 一部データが欠損している

といった問題が発生します。
👉 Archiveは“別物”として設計する必要があります

■ PSTファイルの扱いを後回しにする
PSTは後から対応すればよい、と考えてしまうケースです。
結果として：

• 移行後に大量の未統合データが残る
• ユーザーごとにデータが分散する
• 管理不能な状態になる

👉 PSTは移行設計の初期段階で扱うべき対象です

■ 容量制限・スロットリングを軽視する
大容量データを一括で移行しようとして、

• 移行が極端に遅くなる
• エラーが頻発する
• 一部データが未移行になる

といった問題が発生します。
👉 段階的な移行設計が必須です

■ アーカイブ構造を再現できていない
移行後に、

• フォルダ構造が崩れる
• Archiveと本体の関係が失われる
• 検索性が低下する

といった問題が起きます。
👉 構造の維持は“品質”に直結します

■ 保持ポリシー・コンプライアンスを無視する
移行時にポリシーが適用されていないと、

• 保存期間が変わってしまう
• データ削除リスクが発生する
• 監査対応に問題が出る

👉 設計段階での確認が不可欠です

■ ツール任せで設計を行わない
「ツールがあるから大丈夫」と考えてしまうケース。
しかし実際には：

• ツールではカバーできない部分がある
• 環境依存の問題が発生する
• 想定外のエラーに対応できない

👉 ツールは手段であり、設計が本質です

■ ソース環境の準備不足により移行が開始できない
見落とされがちですが、
移行の成否は「ソース側の状態」に大きく依存します。
例えば、

• SharePointの大規模ライブラリ（TB級データ）
• 未整理のフォルダ構造
• 不適切なアクセス権設定

といった状態のまま移行を実行すると、
移行ツールが最初に実施する「スキャン処理」の段階で
処理が完了せず、実質的に移行が開始できないケースがあります。
結果として：

• スケジュールの大幅遅延
• 移行計画の再設計
• 想定外のコスト増加

といった問題につながります。
👉 移行は“実行前の準備”で成否の大半が決まります

act2では、移行前の環境診断・事前整理を含めた設計を行い、
こうしたリスクを未然に回避します。

■ テスト移行を行わない
いきなり本番移行を行い、

• 想定外の挙動が発生
• リカバリーが困難
• スケジュールが崩壊

👉 検証フェーズは必須です

■ 共通する本質的な問題
これらの失敗に共通するのは、
👉 「Archiveを含めた設計が不足している」
という点です。

Archive Migrationは、
適切な設計なしに成功することはほぼありません。

act2では、これらの失敗を回避するための
設計・検証・実装を一貫して提供しています。

4.
成功する設計のポイント

これまで見てきた失敗の多くは、
事前設計によって回避することが可能です。

👉 クロスプラットフォーム移行は「設計で9割決まる」と言われます。

■ ポイント①：構造を揃えるのではなく「再設計する」

• Gmail → Exchange は単純変換ではなく設計が必要
• Drive → SharePoint は“置き換え”ではなく“再構築”

👉 「そのまま移す」という発想を捨てることが重要

■ ポイント②：権限・共有を事前に設計する

• ユーザー / グループ / ロールの整理
• 共有範囲の定義
• セキュリティポリシーの適用

👉 移行後に調整すると、

• 混乱
• セキュリティリスク

が発生する

■ ポイント③：段階移行（フェーズ設計）を行う

• 一括移行ではなく分割移行
• 部門単位 / ユーザー単位で実施

👉 メリット：

• リスク低減
• トラブル時の切り戻しが可能

■ ポイント④：パイロット移行を必ず実施する

• 一部ユーザーでテスト
• 実際の運用で検証

👉 ここで問題を潰せるかが勝負

■ ポイント⑤：ユーザー影響を最小化する事前告知

• 操作変更の説明
• 移行後サポート

👉 技術よりも“体験”が重要

■ ポイント⑥：適切なツールを選定する　

• 移行対象（メール / Drive / Archive）
• データ量
• スケジュール

👉 ツール選定も設計の一部

■ まとめ👉 適切な設計を行えば、移行は安全に進めることができます。

5.
最適な移行ツールの選び方

クロスプラットフォーム移行では、
ツール選定が成功を左右する重要な要素のひとつです。

👉 ただし、ツールは“目的”ではなく“手段”です。

■ ポイント①：移行対象で選ぶ

• メール（Gmail ⇄ Exchange）
• ストレージ（Drive ⇄ OneDrive / SharePoint）
• アーカイブ（In-Place Archive）

👉 すべてを1つのツールで完結できるとは限らない

■ ポイント②：データ量・規模で選ぶ

• 数十ユーザー規模
• 数百〜数千ユーザー規模

👉 大規模案件では：

• 並列処理
• スロットリング対策

が重要になる

■ ポイント③：移行方式で選ぶ

• 一括移行
• 段階移行（フェーズ）
• 差分移行（デルタ）

👉 要件によって最適解が変わる

■ ポイント④：対応範囲で選ぶメールのみ

• Drive / SharePoint 含む
• Teams / 権限まで対応

👉 「どこまでやるか」でツールは変わる

■ ポイント⑤：運用性・サポートで選ぶUIの使いやすさ

• ログ・トラブルシュート
• ベンダーサポート

👉 トラブル時に差が出る

■ 代表的なツール 🔧
BitTitan（MigrationWiz）

• クロスプラットフォーム移行の定番
• メール / Drive / Teams 対応
• 大規模案件に強い

• 🔧 CloudM
• Google Workspace 移行に強み
• シンプルなUI
• 自動化に強い

👉 案件に応じて使い分けが必要

■ まとめ（最重要🔥）👉 ツール選定も「設計の一部」です。

■ クロスプラットフォーム移行でお悩みですか？
GWS ⇄ Microsoft 365 移行は、
設計次第で成功率が大きく変わります。
👉 無料でご相談いただけます
👉 案件規模に応じた最適な移行プランをご提案します