Migration Wave Planningと優先順位

移行候補、移行方針、TCOやBusiness Caseを整理しても、すべてのアプリケーションを同時にAWSへ移行できるとは限りません。

実際の移行では、

どのアプリケーションをまとめるか
どれを先に移すか
どの時期に移すか
どの程度のリスクを1つの移行単位へ持たせるか

を決める必要があります。

そこで利用するのが Migration Wave です。

このページでは、

Dependency
+
Business Criticality
+
Migration Complexity
+
Risk
+
業務上・運用上の条件
↓
Priority
↓
Migration Wave
↓
Migration Sequence

という流れで、移行対象を管理可能な単位へ分け、実行順序へ落とし込む考え方を理解します。

ここでは、個々のアプリケーションについて7Rsを選び直したり、TCOだけを使って最終的な移行可否を決定したりはしません。

1. Migration Waveは単なる「分割したバッチ」ではない

Migration Wave は、複数の移行対象を管理可能なグループへまとめ、移行時期を計画するための単位です。

例えば50個のアプリケーションを、

Migration Wave 1
Migration Wave 2
Migration Wave 3
...

のように分けます。

ただし、

50個ある
↓
10個ずつ5分割

という単純な均等分割ではありません。

移行ウェーブでは、

• 依存関係
• 業務上の重要度
• 移行複雑度
• リスク
• 優先順位
• 業務上の期限
• 切り替え可能時期
• 実施チームの準備状況

などを組み合わせて配置します。

つまりMigration Waveは、移行対象を実行可能な単位と時期へ変換する計画です。

2. 同じMigration Waveへ入れる理由を明確にする

複数のアプリケーションを同じウェーブへ入れる理由はさまざまです。

例えば、

• 強いDependencyがある
• 同じ業務領域に属する
• 同じ移行パターンを使う
• 同じ技術スタックを使う
• 同じ切り替え時期が必要

といった条件があります。

重要なのは、

同じMigration Wave
=
同じ特徴を1つ持っている

と機械的に判断しないことです。

例えば同じRehostであっても、互いに無関係で切り替え条件も異なれば、必ず同じウェーブにする必要はありません。

7Rsはウェーブ計画への入力の1つですが、ウェーブ配置そのものではありません。

3. Dependencyは「一緒に移すか」「どちらを先に移すか」に使う

Dependencyそのものを発見する作業は、すでにポートフォリオアセスメントで行っています。

Migration Waveでは、そのDependencyを使って、

• 同時に移す必要があるか
• 先に移す必要がある対象はあるか
• 一時的に旧環境と新環境をまたいで利用できるか

を判断します。

例えば、

注文アプリケーション
↓
在庫サービス

同期通信
低レイテンシー必須

という構成で、移行期間中に両者を旧環境とAWSへ分離すると業務影響が発生する場合があります。

この場合は、

同じDependencyグループとして扱う
↓
同じMigration Waveで調整

することが候補になります。

4. 共通サービスを使っているだけで全対象を同じウェーブにしない

Dependency情報を見ると、Active Directory、監視、バックアップ、共通DNSなどの共有サービスへ、多数のアプリケーションが接続している場合があります。

しかし、

同じ共有サービスを使用
=
すべて同じMigration Wave

ではありません。

共有サービスへの通信をそのままDependencyグループとして扱うと、数十個・数百個のアプリケーションが1つの巨大なグループになる可能性があります。

重要なのは、移行時に分離できない依存関係かを確認することです。

Dependencyは単なる通信の有無ではなく、Migration Sequenceへ影響する関係として利用します。

5. Business Criticalityはウェーブのリスクへ影響する

Business Criticality は、アプリケーション停止時の業務影響を表す重要な入力です。

例えば、決済、受注、顧客認証のように停止時の影響が大きいアプリケーションでは、切り替え可能時間が短い、ロールバック判断が厳しい、業務部門との調整が必要、テストや承認をより慎重に行う必要がある可能性があります。

したがってBusiness Criticalityは、

Migration Wave
↓
Risk
↓
必要な準備・実施条件

へ影響します。

重要度の高低を単純な移行順序へ変換するのではなく、切り替え条件、ロールバック条件、承認条件などへ反映します。

6. Migration Complexityは「移行する難しさ」を表す

Migration Complexity は、アプリケーションをAWSへ移行する際の難しさです。

例えば、対象サーバー数、アプリケーション構成、Dependencyの数、OSやミドルウェア、移行戦略、変更量、セキュリティ・コンプライアンス条件、関係するチーム数などが複雑度へ影響します。

アプリケーションA
少数サーバー
Rehost
Dependency少

アプリケーションB
多数コンポーネント
Refactor / Re-architect
複数部門との調整

であれば、一般にアプリケーションBの方がMigration Complexityは高くなります。

重要なのは、サーバー台数だけで複雑度を決めないことです。

7. 初期ウェーブでは未知要素を増やしすぎない

移行チームがまだ移行手順や運用モデルを十分に経験していない段階で、最重要システム、最も複雑なアプリケーション、最大規模の依存関係を同時に扱うと、ウェーブ全体のリスクが高くなります。

そのため初期ウェーブでは、

比較的低いMigration Complexity
+
限定されたDependency
+
許容可能な業務影響

を持つ対象から始め、

移行
↓
結果確認
↓
得られた知見
↓
後続ウェーブへ反映

する考え方が有効です。

これは、簡単なものだけ永遠に移行するという意味ではありません。経験を積みながら、後続ウェーブでより複雑な対象を扱えるようにします。

8. Riskは1つの属性だけでは決まらない

Migration Waveのリスクは、Business Criticality、Migration Complexity、Dependency、切り替え条件、準備状況などを組み合わせて評価します。

Business Criticality
→ 高

Migration Complexity
→ 高

Dependency
→ 未解決

切り替え可能時間
→ 短い

という対象を複数まとめると、1つのMigration Waveへリスクを集中させることになります。

一方、Business CriticalityとMigration Complexityが低く、Dependencyが明確で切り替え条件が柔軟な対象は、初期ウェーブの候補になりやすくなります。

つまり、Migration Waveでは個々のアプリケーションのリスクだけでなく、ウェーブ全体へリスクを集中させすぎていないかを考えます。

9. PriorityはBusiness Criticalityと同じではない

Priority は、どの対象をより早く移行計画へ載せるべきかを表します。

Business Criticalityは、その判断材料の1つです。

Priorityには、データセンター退去期限、契約終了日、ハードウェア更新期限、事業部門の要求、Migration Complexity、Risk、Dependencyなども影響します。

Business Criticalityが中でもデータセンター退去が3か月後なら、期限によってPriorityが高くなる可能性があります。反対にBusiness Criticalityが高くても、期限がなくDependencyが未解決なら、すぐに移行できるとは限りません。

10. Priorityが高くても、そのまま最初のウェーブに入るとは限らない

重要なのは、

Priority
=
実際のMigration Wave番号

ではないことです。

最上位PriorityでもDependencyが未準備で、アプリケーション担当者が切り替え日に対応できないなら予定しているウェーブへ入れられない可能性があります。一方、次順位でもDependencyが解決済みで実施チームが準備済みなら、先に実施する方が現実的な場合があります。

Priority
+
Dependency
+
Risk
+
準備状況
+
運用条件
↓
実際のMigration Wave

11. Migration SequenceはDependencyを時間軸へ変換する

Migration Sequence は、どの順序で移行するかを表します。

例えば、アプリケーションAがAWS上の共通サービスBを必要とし、サービスBが利用可能でないと起動できないなら、

サービスB
↓
アプリケーションA

というMigration Sequenceが候補になります。

Dependency
=
関係

Migration Sequence
=
その関係を移行順序へ変換したもの

12. Dependencyによって「同じウェーブ」と「前後のウェーブ」を使い分ける

Dependencyがあるからといって、必ず同時移行するわけではありません。

同じMigration Waveが適する例

AとBを分離すると低レイテンシー要件を満たせない、一方だけ移すと業務処理が成立しない場合は、同じDependencyグループとして同じMigration Waveで扱うことが候補になります。

順序を分けられる例

サービスBを単独で先に移行して動作検証でき、アプリケーションAをBが利用可能になった後に移行できるなら、BからAの順でウェーブを分けられます。

決定打は、移行期間中に依存関係を安全に分離できるかです。

13. 技術条件だけでなく運用上の条件もウェーブ配置へ影響する

技術的に移行可能でも、業務部門の承認、アプリケーション担当者の参加、変更凍結期間、繁忙期、切り替え可能時間、移行チームのキャパシティによって予定したウェーブへ入れられないことがあります。

したがって、技術的な準備状況だけではなく、

技術的な準備
+
業務上の準備
+
運用上の準備

を確認します。

Migration Waveはアーキテクチャだけでなく、実行可能性まで含む計画です。

14. Wave Planningは一度決めて固定する作業ではない

移行を進めると、追加アセスメントで新しいDependencyを発見したり、Migration Wave 1の実施で想定以上に切り替え作業が長いと判明したりすることがあります。

この場合、最初に作ったウェーブ計画を絶対に変更しないとはしません。

直近の複数ウェーブを先行して計画しながら、新しいDependency、Migration Complexityの再評価、業務条件、準備状況、実施結果に合わせて後続ウェーブ計画を更新します。

Wave Planningは継続的な活動です。

15. 7RsやTCOはMigration Waveへの入力として使う

すでに評価した7Rs、TCO、Migration Cost、Business Benefitは、ウェーブ計画でも入力として利用できます。

例えばRefactor / Re-architectでは、Rehostよりも変更量や必要期間が大きくなる場合があります。また、大きなMigration Costや業務上の期限もPriorityへ影響する可能性があります。

しかし、

Rehost
=
必ずWave 1

TCOが最も低い
=
必ず最初に移行

ではありません。

TCOは移行候補やBusiness Caseを評価する重要な材料ですが、実際のMigration WaveではDependency、Risk、準備状況、期限なども合わせて判断します。

16. Migration Wave Planningの全体フロー

移行候補
+
既存アセスメント結果
↓
Dependencyを確認
↓
同時移行が必要なグループを確認
↓
Business Criticality
↓
Migration Complexity
↓
Risk
↓
事業上の要因 / 期限
↓
Priority
↓
準備状況・運用条件を確認
↓
Migration Waveへ配置
↓
Migration Sequenceを決定
↓
移行結果・新情報
↓
後続ウェーブ計画を更新

混同ポイント

SAP-C02での判断

何を一緒に移す必要がある？
↓
Dependencyは？
↓
Business Criticalityは？
↓
Migration Complexityは？
↓
どこにRiskが集中する？
↓
事業上の要因 / 期限は？
↓
Priorityは？
↓
今その対象を実行できる状態？
↓
同じウェーブ？
それとも先行 / 後続？
↓
Migration Sequence

決定打は、Priorityだけで順番を決めず、Dependency・Business Criticality・Migration Complexity・Risk・実行可能性を組み合わせて、管理可能なMigration WaveとMigration Sequenceへ変換することです。

まとめ

Migration Waveは、移行対象を管理可能なグループと時期へ変換するための計画単位です。

Dependencyは、何を一緒に移すか、何を先に移すかを判断するために使います。

Business CriticalityとMigration Complexityは、Migration WaveのRisk評価へ影響します。

Priorityは移行順序を考える重要な入力ですが、Dependencyや準備状況を無視して、そのままMigration Wave番号へ変換するものではありません。

Dependency
+
Business Criticality
+
Migration Complexity
+
Risk
+
Priority
+
実行条件
↓
Migration Wave
↓
Migration Sequence

また、Wave Planningは一度作成して固定するものではなく、移行の進行、新しいDependency、準備状況、実施結果に応じて継続的に更新します。