変更要約: SAP-C02 第4章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
4.1移行戦略の選択（7 つの R）
移行アプローチ——7 つの R（リホスト／リプラットフォーム／リファクタ／リパーチェス／リタイア／リテイン／リロケート）と、Migration Hub／Application Discovery Service による評価——を理解します。各ワークロードに最適な道を選びます。
大規模移行は、まずポートフォリオを評価し、各アプリに 7 つの R から戦略を割り当てます。労力と価値はトレードオフです。
4.1.17 つの R
- リホスト（lift & shift）：変更せず EC2 へ。最速・最小労力（AWS MGN で自動化）。
- リプラットフォーム：少し最適化（例: 自前 DB → RDS マネージド）。
- リファクタ：クラウドネイティブに作り替え（サーバーレス/マイクロサービス）。労力大・価値大。
- リパーチェス：自前運用をやめ SaaS に乗り換え。リタイア：不要なものは廃止。リテイン：当面そのまま。リロケート：そのまま移設。
「無変更で素早く＝リホスト（lift & shift・MGN）」「DB をマネージドに等の小最適化＝リプラットフォーム」「クラウドネイティブに作り替え＝リファクタ」「SaaS 化＝リパーチェス」「廃止＝リタイア／据え置き＝リテイン」、評価は Discovery Service＋Migration Hub が SAP-C02 で頻出です。短納期・低リスクならリホスト、長期価値ならリファクタ。
Application Discovery Service が依存関係や使用状況を収集し、Migration Hub が移行の進捗を一元的に追跡します。まず可視化してから戦略を割り当てるのが定石です。
SAP-C02 では「制約（期限・予算・スキル・リスク許容度）から正しい R を選ぶ」設問が中心です。リホストは変更を加えないため最速・最低リスクで、データセンター撤退の期限が迫る大量移行に向きます。ただしクラウドの利点（マネージド化・弾力性）はあまり得られません。リプラットフォームは「触りすぎない最適化」で、典型は自己管理 DB を RDS/Aurora に載せ替えてパッチ・バックアップ・HA を肩代わりさせる形です。リファクタは最も労力が大きい一方、サーバーレス化やマイクロサービス化で長期の俊敏性・スケール・コストを最大化します——ただしビジネス価値が高いコアにだけ適用するのが定石です。リパーチェスは自前運用をやめ SaaS（例: 自社メール基盤→マネージド SaaS）へ。リタイアで不要資産を削れば移行対象そのものが減り、リテインは規制・依存・近い廃止予定などで「今は動かさない」判断、リロケートは VMware Cloud on AWS（2024 年 4 月末に AWS からの販売は終了し、現在は Broadcom 経由で提供）などでハイパーバイザ単位をそのまま移すケースです。評価フェーズでは Application Discovery Service（エージェント/エージェントレスで CPU・メモリ・ネットワーク依存を収集）の結果を Migration Hub に集約し、アプリ単位で進捗とステータスを一元管理します。
| 状況 | 選ぶ R | 理由 |
|---|---|---|
| DC 撤退期限が迫る・変更最小 | リホスト | 最速・最低リスク（MGN で自動化） |
| 運用負荷を下げたいが大改修は不可 | リプラットフォーム | DB をマネージドに等の小最適化 |
| コア機能で長期の俊敏性が欲しい | リファクタ | サーバーレス/マイクロで価値最大 |
| 自前運用をやめたい汎用機能 | リパーチェス | SaaS へ乗り換え |
シナリオ：データセンターの契約終了まで 6 か月、数百台のサーバーを移す必要がある。多くは枯れた業務アプリで改修予算は乏しいが、一部の自己管理 MySQL は運用負荷を下げたい。→ 大半は リホスト（MGN）で期限内に確実に移し、MySQL だけ リプラットフォームで RDS へ。先立って Discovery Service で依存関係を洗い出し、Migration Hub で波（wave）ごとの進捗を管理します。
FAQ：リロケートとリホストの違いは？ リホストは個々のサーバーを EC2 へ移す（lift & shift）のに対し、リロケートは VMware Cloud on AWS などで仮想化基盤ごと、OS やアプリを変えずにまとめて移設します。最も変更が少なく短期間で済む反面、クラウドネイティブの利点は得にくいです。
ひっかけ：「最も短期間で移行したい」のにリファクタを選ぶのは誤り。リファクタは最も労力と時間がかかります。短納期・低リスクは リホストが正解です。逆に「長期の俊敏性・コスト効率を最大化」ならリファクタが正解で、期限とのトレードオフを見極めます。
4.1.2この節のまとめ
- 7R＝リホスト/リプラットフォーム/リファクタ/リパーチェス/リタイア/リテイン/リロケート
- 評価＝Application Discovery Service＋Migration Hub
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 期限が厳しく、まずは変更を加えずに既存サーバーをそのまま AWS の EC2 へ素早く移したい。どの戦略ですか？
Q2. 自前管理の MySQL を、アプリのコードはほぼ変えずに Amazon RDS のマネージド DB へ移して運用負荷を下げたい。どの戦略ですか？
Q3. 大規模移行に先立ち、オンプレのサーバー依存関係や使用状況を収集し、移行の進捗を一元管理したい。何を使いますか？