WorkloadからMigration Candidateと7Rsを決定する

これまでの移行評価では、Application Assessment、Dependency、TCO、Business Requirement、7Rs、Wave Planningをそれぞれ確認してきました。

実際の移行計画では、これらを個別に評価するだけでは不十分です。

最終的には、

Application Assessment
+
Dependency
+
TCO
+
Business Requirement
↓
移行候補として進めるか
↓
7Rs
↓
Wave Planning
↓
Migration Decision

という一続きの判断へ統合します。

重要なのは、1つの評価結果だけでMigration Decisionを決めないことです。

1. Migration Decisionは複数の評価結果を統合する

例えば、あるアプリケーションについて技術的にはAWSへ移行可能だったとしても、TCO、Business Requirement、Dependencyまで含めると、今回の移行対象として適切ではない場合があります。

反対に、移行が少し複雑であっても、データセンター退去期限、製品サポート終了、事業上の重要な目標があれば、移行優先度が高くなる可能性があります。

したがってMigration Decisionでは、

技術的に可能か
+
業務上必要か
+
経済的に妥当か
+
依存関係を処理できるか
+
実行できる時期があるか

を組み合わせます。

2. Application AssessmentはMigration Decisionの証拠を集める

Application Assessment では、現在の構成、OS / ミドルウェア、データベース、利用状況、依存関係、業務要件、運用要件、技術的制約などを確認します。

ここで重要なのは、

Application Assessment完了
=
AWSへ移行することが確定

ではないことです。

Application Assessmentは、Migration Decisionを行うために必要な情報を高精度化する作業です。

評価結果から、移行できる、移行できない、追加調査が必要、現在は移行しない、廃止できるなどの判断材料を得ます。

3. 移行候補は「移行確定」と同じではない

評価の結果、移行候補として扱う対象を絞り込みます。

移行候補とは、具体的な移行計画へ進める候補です。

移行候補
=
必ずAWSへ移行する

ではありません。

詳細な評価によって、新しいDependency、予想外のライセンスコスト、規制上の制約、利用実態の変化などが分かれば、判断を変更できます。

4. Dependencyは「移行できるか」だけでなく判断範囲を変える

DependencyはWave Planningだけに使う情報ではありません。

例えば、

アプリケーションA
↓
データベースB
↓
認証サービスC

という関係がある場合、アプリケーションAだけを見てAWSへ移行可能と判断しても不十分です。

データベースBや認証サービスCが、一緒に移行できるか、先に準備できるか、旧環境から利用できるか、移行後も残す必要があるかを確認する必要があります。

つまりDependencyは、

移行候補
7Rs
Wave Planning

のすべてへ影響する可能性があります。

5. Business RequirementはMigration Decisionの目的を決める

Business Requirement は、「なぜ移行するのか」を判断する重要な入力です。

例えば、データセンターを9か月後に退去する、製品サポート終了を回避する、ライセンスコストを削減する、リリース速度を改善する、運用負荷を削減する、耐障害性を改善する、などがあります。

同じアプリケーションでも、Business Requirementが違えば、適切な7Rsが異なる場合があります。

短期間でデータセンターから退出したい場合と、アプリケーション構造そのものを改善したい場合では、許容できる変更量が異なります。

したがって、7Rsは技術構成だけで決めるものではありません。

6. TCOは重要だが単独の決定条件ではない

TCOは、現在環境と移行後環境の定常コストを比較する重要な入力です。

最もTCOが低い
=
必ず採用するMigration Decision

ではありません。

経済性だけでなく、Business Requirement、Dependency、技術的な実現性、移行コストなどもMigration Decisionへ影響します。

反対に、高い事業価値が期待できても、Dependencyや技術的制約によってその時点では実行できない場合があります。

TCO
+
Business Requirement
+
技術条件
+
Dependency

を合わせて判断します。

7. 7RsはMigration Decisionの「処置」を表す

移行候補や評価対象について、Rehost、Replatform、Refactor / Re-architect、Repurchase、Relocate、Retain、Retireのどの処置を適用するかを整理します。

ここでは7Rsそのものの定義を再び覚えることが目的ではありません。

重要なのは、評価結果を7Rsへ変換することです。

Business Requirement
+
Dependency
+
TCO
+
技術的制約
↓
7Rs

8. 1つのアプリケーションで複数の7Rsが必要な場合がある

Migration Decisionでは、

アプリケーション全体
=
必ず1つの7Rs

とは限りません。

例えば、ウェブ層、アプリケーション層、データベースで構成されるアプリケーションを考えます。

ウェブ層とアプリケーション層は変更を最小化したい一方、データベースはライセンスコスト削減や運用負荷削減のためマネージドサービスへ変更したい場合があります。

ウェブ / アプリケーション層
→ Rehost

データベース
→ Replatform

のように、コンポーネントごとに異なる判断が必要になる可能性があります。

重要なのは、アプリケーション名だけを単位として機械的に1つの7Rsを割り当てないことです。

9. 7Rsのすべてが有効なMigration Decisionになり得る

Migration Decisionでは、AWSへ移動する戦略だけが有効な結果とは限りません。

Application Assessment、Dependency、TCO、Business Requirementを統合した結果として、AWSへ移動しない7Rsが適切になる場合もあります。

ここで重要なのは個々の7Rsの意味を再確認することではなく、

評価結果
↓
適切な7Rs
↓
Migration Decision

として、すべての選択肢を同じ意思決定プロセスの中で扱うことです。

10. 移行候補と7RsはWave Planningへ渡す

AWSへ移行する対象と7Rsが整理できたら、Wave Planningへつなげます。

移行候補
↓
7Rs
↓
すぐMigration Wave 1

とはなりません。

例えば、移行候補としてReplatformする方針でも、依存先の準備、業務部門の対応可能時期、変更凍結期間、Migration Complexityなどによって、後続ウェーブになる場合があります。

移行候補
+
7Rs
+
Dependency
+
実行条件
↓
Wave Planning

11. ウェーブが遅れることとRetainは同じではない

これは混同しやすいポイントです。

アプリケーションAを移行候補として扱い7RsをReplatformまで決めていても、認証基盤のAWS側準備が3か月後になる場合があります。

現在予定しているMigration Waveに入れられないからといって、7Rsを自動的に変更するわけではありません。

移行候補
→ 維持

7Rs
→ Replatform

Migration Wave
→ 依存先準備後へ調整

移行戦略と実施時期を分けて考えることが重要です。

12. Migration Decisionでは判断結果を一続きに整理する

Migration Decisionを整理するときは、少なくとも、

① 今回の移行候補として進めるか

② どの7Rsを適用するか

③ DependencyやBusiness Requirementに
   どのような制約があるか

④ Wave Planningへ
   どの条件を引き継ぐか

を明確にします。

例えば、

アプリケーションA

移行候補
→ 対象

7Rs
→ Replatform

Dependency
→ 認証サービス

Business Requirement
→ 6か月以内にデータセンター退去

TCO
→ 現在環境より削減見込み

ウェーブ条件
→ 認証サービス準備後

のように整理できます。

このように、個々の評価結果ではなく、評価結果同士の関係を残すことが重要です。

13. 矛盾する評価結果を解決する

実際のMigration Decisionでは、すべての情報が同じ方向を示すとは限りません。

SAP-C02では、どれか1つの数字や属性だけで決める選択肢に注意します。

14. Migration Decisionを確定できない場合もある

Application Assessmentを進めても、必要な情報がすべて揃っているとは限りません。

例えば、

重要なバッチ処理のDependency
→ 未確認

Business Requirement
→ 確認済み

TCO
→ 概算済み

という状態で、7RsやMigration Waveを確定しようとすると、重要な前提が不足したままMigration Decisionを固定することになります。

この場合は、

不足している情報を特定
↓
追加のApplication Assessment
↓
判断に必要な前提を確認
↓
Migration Decisionを確定

とします。

つまりMigration Decisionでは、情報が不足している状態で無理に最終判断を作らないことも重要です。

「追加調査が必要」という状態も、Application Assessmentから得られる有効な判断結果です。

15. Migration Decisionと具体的な実行設計を分ける

ここまでで整理するのは、移行候補として進めるか、どの7Rsを適用するか、どの条件をWave Planningへ渡すかです。

ただし、これらが決まったからといって、具体的にどの移行方式を使うか、どのサービスやツールを使うか、どのような切り替え手順にするかまで自動的に確定するわけではありません。

Migration Decision
≠
具体的な移行実行方式

Migration Decisionでは、後続の実行設計に必要な前提条件を明確にして渡します。

16. 全体の判断フロー

Application Assessment
↓
現在状態・制約・情報精度を確認
↓
Dependency
↓
Business Requirement
↓
TCO
↓
移行候補を判断
↓
7Rsを割り当てる
↓
Dependency / 実行条件を再確認
↓
Wave Planning
↓
Migration Decision
↓
具体的な実行設計へ引き継ぐ

重要なのは、Application Assessment、移行候補、7Rs、TCO、Wave Planningを別々のチェック項目として終わらせず、1つのMigration Decisionへつなげることです。

混同ポイント

SAP-C02での判断

何が分かっている？
↓
Application Assessmentは十分？
↓
重要なDependencyは？
↓
Business Requirementは？
↓
TCOは？
↓
今回の移行候補か？
↓
適切な7Rsは？
↓
コンポーネントで7Rsを分ける必要は？
↓
どの条件をWave Planningへ渡す？
↓
Migration Decision

決定打は、1つの評価値から答えを決めるのではなく、Application Assessment・Dependency・TCO・Business Requirementを統合し、移行候補・7Rs・Wave Planningへ一貫してつなげることです。