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.
安全に進めるための設計ポイント

Archive Migrationを安全かつ確実に実行するためには、
事前の設計がすべてを左右します。

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

■ 移行対象の正確な把握（スコープ定義）
まず最初に行うべきは、移行対象の明確化です。

• Archiveの有無と構造
• PSTファイルの分布状況
• メールボックス容量
• 対象ユーザー数

👉 「何をどこまで移行するのか」を定義しない限り、設計は成立しません

■ ソース環境の事前診断・整理
移行の成否は、ソース環境の状態に大きく依存します。

• 不要データの整理
• 大規模ライブラリの分割・最適化
• アクセス権の整理
• フォルダ構造の見直し

👉 “そのまま移行する”のではなく、“移行できる状態に整える”ことが重要です

■ Archive構造の設計
Archive Migrationでは、

• 本体メールとArchiveの関係性
• フォルダ構造の維持
• データの配置先

を明確に設計する必要があります。
👉 構造設計がそのままユーザー体験に直結します

■ 容量・パフォーマンス設計
大容量データの移行では、

• 分割移行（バッチ処理）
• 並列数の調整
• スロットリング対策

といった設計が不可欠です。
👉 速度と安定性はトレードオフであり、バランス設計が必要です

■ 保持ポリシー・コンプライアンス設計
移行後も、

• Retention Policy
• データ保存期間
• 監査要件

を維持する必要があります。
👉 ポリシーの不整合は重大なリスクになります

■ ツール選定と適用範囲の判断
移行ツールは万能ではありません。

• 対応範囲の確認
• 制約条件の把握
• 補完手段の検討

が必要です。
👉 ツールに合わせるのではなく、設計に合わせて使い分けることが重要です

■ テスト移行（検証フェーズ）の実施
本番前に、

• 小規模テスト
• パフォーマンス確認
• エラー検証

を実施することで、リスクを大幅に低減できます。
👉 テストなしの本番移行は極めて危険です

■ 設計の本質これらのポイントに共通するのは、
👉 「移行は設計で決まる」
という事実です。
Archive Migrationは、
ツールや手順ではなく、設計によって成否が決まります。

act2では、これらすべての要素を踏まえた上で、
設計・検証・実装を一貫して提供しています。

5.
移行ツールの選び方

Archive Migrationでは、
ツール選定がプロジェクト全体の成否に大きく影響します。
ただし重要なのは、
👉 ツールは“目的”ではなく“手段”である
という点です。

■ ポイント①：対象データで選ぶ

• In-Place Archive に対応しているか
• PSTの取り込み・統合が可能か
• 大容量メールボックスに対応できるか

👉 Archive対応の可否は最優先で確認すべき項目です

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

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

大規模移行では、

• 並列処理
• スロットリング制御
• 安定性

が重要になります。

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

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

👉 業務影響を最小化するには方式選定が重要です

■ ポイント④：制約条件・限界を理解する

• API制限
• データサイズ制限
• 機能的な制約

👉 ツールの限界を理解しない設計は必ず破綻します

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

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

👉 トラブル時の対応力がプロジェクトを左右します

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

• Microsoft 365 / Google Workspace 両対応
• Archive / PST移行にも対応
• 大規模案件・複雑案件に強い

🔧 CloudM

• Google Workspace系に強み
• シンプルなUI
• 自動化・運用効率が高い

👉 案件の内容に応じて適切に使い分ける必要があります

■ まとめ　👉 ツール選定も“設計の一部”です
Archive Migrationは、
ツールだけで解決できるものではありません。

👉 設計・ツール選定・実装のすべてが揃って初めて成功します


Archive Migrationでお悩みの場合は、まずはご相談ください。
案件に応じた最適な設計・ツール選定をご提案します（無料）