導入
「オンプレのシステムをAWSに移す」と一口に言っても、そのやり方は1つではありません。移行戦略には定番の分類があり、SAPでは状況に応じて最適な戦略を選ばせる問題が繰り返し出ます。まずはこの分類、通称「7つのR」を押さえましょう。
説明
移行戦略の7つのRは、移行にかける労力と移行後に得られる恩恵のトレードオフで並べると理解しやすくなります。
| 戦略 | 内容 | 労力 | 得られる恩恵 |
|---|---|---|---|
| Retire | 使われていないので廃止する | なし | コスト削減 |
| Retain | 今はそのまま残す（後で判断） | なし | 一旦の先送り |
| Rehost（リフト＆シフト） | そのままEC2等へ移す | 小 | 早く移行できる |
| Relocate | VMwareごと等、環境ごとそのまま移す | 小 | ほぼ無停止で移せる |
| Replatform（リフト＆リシェイプ） | 一部だけクラウド最適化（DBをRDS化等） | 中 | 運用負荷を減らしつつ移行 |
| Repurchase | SaaSなど別製品に置き換える | 中 | 自社運用からの解放 |
| Refactor / Re-architect | クラウドネイティブに作り替える | 大 | スケーラビリティ・俊敏性を最大化 |
flowchart LR
Retire["Retire<br/>（廃止）"] --> Retain["Retain<br/>（保留）"]
Retain --> Rehost["Rehost<br/>（そのまま移す）"]
Rehost --> Replatform["Replatform<br/>（一部最適化）"]
Replatform --> Repurchase["Repurchase<br/>（SaaSへ）"]
Repurchase --> Refactor["Refactor<br/>（作り替え）"]
判断のコツは、問題文の時間軸と目的を読み取ることです。
- 「データセンターの契約終了が迫っている」「とにかく早く移したい」→ Rehost（労力最小・移行速度最優先）
- 「まず移してから、運用負荷を下げたい」「DBの管理から解放されたい」→ Replatform（RDSへの移行など）
- 「自社でメール/CRMを運用する必要はない」→ Repurchase（SaaSへの切り替え）
- 「長期的にスケーラビリティと俊敏性を最大化したい」「マイクロサービス化したい」→ Refactor
- 「使われていないと分かった」→ Retire、「判断保留、今は触らない」→ Retain
- 「VMware環境をそのままクラウドへ、アプリの変更なしに移したい」→ Relocate（VMware Cloud on AWS等）
具体例
「データセンターの契約が3か月後に切れる」という期限付きで、10のシステムを移す企業の判断を見ましょう。全部Refactorが正解ではないのが肝です。
| システム | 制約・状況 | 選ぶR |
|---|---|---|
| 主力Webアプリ | 期限が近い、まず動かしたい | Rehost（後でRefactor） |
| 自前運用のメール・CRM | 運用から解放されたい | Repurchase（SaaSへ） |
| オンプレのMySQL | DB管理の手間を減らしたい | Replatform（RDS化） |
| VMware上の多数のVM | アプリを変えず環境ごと移したい | Relocate（VMware Cloud on AWS） |
| 誰も使っていない旧ツール | 不要と判明 | Retire（廃止） |
| 規制で今は動かせない基幹系 | 判断保留 | Retain |
ここでのSAPの罠が「Refactor（作り替え）が一番良い」という思い込み。期限が近くリスクを取れないなら、作り替えは間に合わずRehostが正解。逆に長期的な俊敏性が目的ならRefactor。7つのRは優劣でなく、制約（時間軸・目的）に応じた使い分けです。まず全部Rehostで運び、落ち着いてからRefactorへ、という段階戦略も定石。
読んでみよう
SAPの移行問題は「Refactorが一番良い」と決めつけると誤ります。期限が近い・リスクを取りたくないという制約が付けば Rehost が正解になりますし、長期的な俊敏性を求めるなら Refactor が正解になります。7つのRは優劣ではなく、状況に応じた使い分けの選択肢として捉えてください。