オンプレのシステムをクラウドに持っていくとき、「丸ごとリフト」か「ちゃんと作り直す」か、その二択で考えているエンジニアは多い。だがその二択では、無駄なコストと後悔を生む。AWSが提唱する「6R」は、移行対象を6つのパターンに分類し、目的に合った移行戦略を選ぶための共通フレームワークだ。
この記事では、6つの移行パターンの定義・コスト感・向いているシステムの特徴を、オンプレ経験者の目線から整理する。自社の移行計画を立てる際の判断基準として活用してほしい。
なぜ移行パターンを整理するのか
オンプレ環境には、長年稼働してきた多種多様なシステムが混在している。最新のWebアプリもあれば、10年以上前のレガシーシステム、ベンダー提供のパッケージソフト、内製の業務ツールまで多岐にわたる。これらをすべて同じアプローチで移行しようとすると、必ずどこかで壁にぶつかる。
「リフト＆シフトですべてEC2に移したら、今度はクラウドのコスト最適化メリットをほとんど受けられなかった」という経験を持つエンジニアは多いはずだ。あるいは逆に、「せっかくだからフルリアーキテクト」と意気込んで工期が2倍になったというケースもある。
AWSが提唱する6Rは、移行プロジェクトの初期段階でシステムごとに移行パターンを分類し、工数・コスト・リスクを見える化するためのフレームワークだ。「全システムを一律に移行しようとする失敗」を防ぐための共通言語でもある。
AWSが定義する6Rとは
6つのパターンをそれぞれ解説する。
1. Retire（廃止）
移行作業を始める前に「そもそも使われているのか」を確認すると、想像以上の数のシステムが実質的に死んでいることがわかる。アクセスログを見ると誰も使っていないWebアプリ、担当者が退職してメンテナンスが止まったバッチ処理、似た機能の新システムが既にある古いシステム——これらはクラウドに移す前に廃止する。
移行コストゼロで運用コストを削減できる最も効率的な選択肢だ。棚卸し時に「廃止候補」のリストを先に作ることをすすめる。
2. Retain（保留）
技術的・法律的・コスト的な理由でクラウド移行をいったん見送るパターンだ。来年にはリプレースが決まっているシステム、法規制でデータをオンプレに置かなければならないシステム、クラウドより自社データセンターの方がコストが安いとわかっているシステムがこれにあたる。
「今は移行しない」と明示的に判断することが重要で、無計画に後回しにすることとは違う。1～2年後に再評価するタイミングをあらかじめ決めておくとよい。
3. Rehost（リホスト）
いわゆる「リフト＆シフト」だ。オンプレの仮想マシンをそのままAmazon EC2に移す。アプリケーションコードもOS設定もほぼ変えない。移行速度が最速で、技術リスクも最小限に抑えられる。
ただし、クラウドネイティブな最適化の恩恵（オートスケーリング、サーバーレス等）はほとんど受けられない。「まず移してから最適化する」という段階的戦略のファーストステップとして有効だ。AWS Application Migration Service（MGN）を使えば、オンプレのVMをほぼ無停止でEC2に移行できる。
4. Replatform（リプラットフォーム）
コアアーキテクチャは変えず、一部をマネージドサービスに置き換えるパターンだ。オンプレのMySQLをAmazon RDSに移行する、自前のロードバランサーをApplication Load Balancer（ALB）に切り替えるといった例がこれにあたる。
アプリケーションコードの大幅改修は不要で、OSパッチ・バックアップ・フェイルオーバーなどの運用負荷を減らせる。RehostよりもCloudの恩恵を受けやすく、MiddleWare層だけクラウドに最適化する、というイメージで捉えると理解しやすい。
5. Repurchase（購入）
自社で開発・維持してきたシステムをSaaSに置き換えるパターンだ。オンプレのCRMをSalesforceに、グループウェアをMicrosoft 365に移行するのが典型例だ。クラウド移行というより「サービス切り替え」に近い。
カスタマイズ性は下がるが、ライセンス費用と開発・運用コストの合算で大幅に安くなるケースが多い。自社固有のカスタマイズが少ないパッケージシステムは積極的に検討したい。
6. Refactor / Re-architect（リファクタリング）
アプリケーションを根本から再設計するパターンだ。モノリシックなアプリをマイクロサービス化する、Amazon ECSやAmazon EKSのコンテナ環境に対応させる、AWS Lambda＋Amazon API Gatewayのサーバーレス構成に置き換えるといった変更がこれにあたる。
コスト・工数・リスクは6つの中で最も高い。一方、クラウドネイティブの恩恵を最大化できる。ビジネスの中核を担い、スケーラビリティや機能追加頻度が高いシステムに対して選択する。移行後の保守コスト削減効果が長期的に大きい場合に正当化される。
6Rのコスト・工数・リスク比較
6つのパターンの特徴を一覧で整理する。
| パターン | 移行速度 | 技術リスク | 移行コスト | クラウド最適化効果 |
|---|---|---|---|---|
| Retire（廃止） | 即時 | なし | ゼロ | — |
| Retain（保留） | — | なし | ゼロ | なし |
| Rehost（リホスト） | 速い | 低 | 低 | 低 |
| Replatform（リプラットフォーム） | やや速い | 低～中 | 低～中 | 中 |
| Repurchase（購入） | 中 | 低（データ移行が鍵） | 低 | 中 |
| Refactor（リファクタリング） | 遅い | 高 | 高 | 高 |
実務での選び方：判断フロー
現場で6Rを適用するときの判断手順を示す。
・Step 1 — 使われているか？ アクセスログと担当者ヒアリングで確認する。使われていなければ → Retire
・Step 2 — 近い将来リプレースが決まっているか？ または法規制・コスト理由でオンプレが必要か → Retain
・Step 3 — SaaS代替があるか？ 自社カスタマイズが少なく、パッケージ依存度が高いか → Repurchase
・Step 4 — 移行期限が厳しいか？ データセンター退去や契約終了が迫っているか → Rehost（まず移してから最適化）
・Step 5 — MiddleWare層だけマネージドに切れるか？ コードは変えずに運用負荷を下げたいか → Replatform
・Step 6 — スケールと機能追加が中長期的に重要なシステムか？ 長期ROIを取れるか → Refactor/Re-architect
「まずRetire/Retainで対象をふるいにかけ、残りをRehost→Replatform→Refactorの順に検討する」という流れが現実的だ。全システムを最初から6つに分類しようとすると議論が長引くため、まずRetire/Retainで全体量を絞ることを優先するとよい。
よくある失敗と対処法
失敗①: すべてをRehostで移してしまう
「まず移す」という判断自体は正しい。しかしReplatform/Refactorへの移行計画を立てないまま放置すると、クラウドに移っただけでコストも運用負荷も変わらないシステムが量産される。移行後12か月以内に最適化フェーズを計画に組み込んでおくことを推奨する。
失敗②: 重要システムをいきなりRefactorに分類する
技術的な理想を優先して重要基幹システムをRefactor候補にすると、移行プロジェクトが長期化し、ビジネス部門の信頼を失う。重要度の高いシステムはRehost→Replatformと段階的に移行し、実績を積んでからRefactorを検討するのが現実的だ。
失敗③: RetainがずっとRetainになる
「いったん保留」のつもりが、担当者が変わると誰も再評価しなくなる。6か月または1年ごとに棚卸しのタイミングを決め、Retainリストを定期的に見直す仕組みを作ることが必要だ。
本記事のまとめ
・Retire（廃止）: 使われていないシステムを移行前に排除。コストゼロで最大の効果
・Retain（保留）: 法規制・コスト・タイミングで移行しない選択を明示的に判断
・Rehost（リホスト）: 丸ごとEC2へ。速度優先・短期デッドライン向き
・Replatform（リプラットフォーム）: MW層だけマネージドに。コード変更最小でOps削減
・Repurchase（購入）: 自社開発からSaaSへ。カスタマイズ少ないパッケージ向き
・Refactor（リファクタリング）: 根本から再設計。工数大だがクラウド最適化効果最大
6Rは「どれか一つを選ぶ」ものではない。100本のシステムがあれば、それぞれの特性に合わせて6つのパターンを組み合わせて適用するものだ。移行計画の初期段階でRetire/Retainでボリュームを減らし、残ったシステムをRehost→Replatform→Refactorと段階的に進めるアプローチが、最もリスクの低い移行戦略だ。
LinuxサーバーのEC2移行など、Rehostフェーズで必要なLinuxの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。
クラウド移行の戦略設計に悩んでいませんか？
クラウド実務に役立つ「Cloud Architecture」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
