Migration AssessmentとTrackingの全体像

AWSへの移行を始めるとき、

このServerをAWSへ移そう

だけでは十分ではありません。

実際の環境には、

Application
Server
Database
Network
外部System
業務要件

などが関係しています。

さらに、Application単位の現行環境だけでなく、

組織としてCloud Migrationへ進む準備ができているか

も確認する必要があります。

移行開始後は、

どのApplicationが
どこまで移行したのか

を継続して把握します。

そこで移行全体を、

Current Environment
↓
Application Migration Assessment
↓
Migration Readiness Assessment
↓
詳細なMigration Planning
↓
Migration実行
↓
Migration Status
↓
Centralized Visibility

という流れで捉えます。

ゴール

このページでは、

Application Migration Assessment
↓
Current Environment
├─ Application Inventory
├─ Infrastructure Inventory
├─ Dependency
└─ Business Requirement

────────────

Migration Readiness Assessment
↓
AWS CAF 6 Perspectives
├─ Business
├─ People
├─ Governance
├─ Platform
├─ Security
└─ Operations
↓
Strength / Weakness
↓
Gap
↓
Action Plan

────────────

Migration開始後
↓
Migration Tool
↓
Migration Status
↓
AWS Migration Hub
↓
Centralized Visibility

という全体像を理解することがゴールです。

ここでは、個々のApplicationについて7Rsを決定したり、Migration Waveを組んだりするところまでは扱いません。

1. AssessmentとTrackingは役割が異なる

まず、

Assessment

と、

Tracking

を分けます。

Assessmentでは、

現在何が存在するか

何と接続しているか

どのような業務要件があるか

組織としてCloud Migrationへ進む準備はできているか

どのGapを解消する必要があるか

を確認します。

一方、Migration Trackingでは、

移行開始済み？

進行中？

完了？

どのResourceまで進んだ？

を追跡します。

つまり、

Assessment
=
移行前の現状把握と準備評価

Tracking
=
移行開始後の進捗把握

です。

2. Application Migration AssessmentはCurrent Environmentから始める

Application Migrationを評価するには、

現在の環境を正しく把握すること

が必要です。

例えば、

Applicationは何個ある？

どのServerで動いている？

Databaseはどこ？

外部接続はある？

どの業務で使う？

停止できる？

といった情報です。

Current Environmentが不明確なまま、

AWSでのTarget Architecture

だけを先に決めると、

必要なServerを見落とす

Dependencyを切断する

停止できないSystemを止める

といった問題につながる可能性があります。

3. Application Inventoryで対象を把握する

Application Inventoryでは、

どのApplicationが存在するか

を整理します。

例えば、

販売管理

会計

認証

社内Portal

Batch System

などです。

Application単位で整理することで、

このServerは何のために存在する？

このDatabaseはどのApplicationが使う？

という関係を把握しやすくなります。

ここではまだ、

移行する

移行しない

Rehostする

Refactorする

まで決定するわけではありません。

まずは現在存在するApplicationを把握する段階です。

4. Infrastructure Inventoryで構成要素を把握する

Applicationだけでなく、そのApplicationを構成するInfrastructureも確認します。

例えば、

Physical Server

Virtual Machine

CPU

Memory

Storage

Operating System

Database

Network

などです。

Application Inventoryが、

何のSystemか

を見るものなら、

Infrastructure Inventoryは、

何で構成されているか

を見るものです。

例えば、

Application A
├─ Web Server
├─ Application Server
└─ Database Server

という形で、ApplicationとInfrastructureを関連付けて把握します。

5. DependencyもApplication Assessmentの入力になる

ApplicationやServerは、単独で動いているとは限りません。

例えば、

Application A
↓
Database B

Application A
↓
Authentication System C

Batch D
↓
File Server E

のようなDependencyがあります。

そのため、

Server Aだけ先に移行

すると、

Databaseへ接続できない

認証できない

連携Fileを取得できない

といった問題が発生する可能性があります。

この段階では詳細なDependency分析方法まで扱いません。

まず、

Application Migration AssessmentにはDependency情報が必要

だと理解します。

6. Business RequirementもApplication Assessmentの入力になる

技術的に移行可能でも、業務条件を満たさなければ適切なMigration Planにはなりません。

例えば、

停止可能時間

移行期限

Compliance

Data Residency

性能要件

重要業務期間

Application Ownerの条件

などがあります。

例えば技術的には、

8時間停止して移行可能

でも、

業務上
停止可能時間は30分

なら、そのまま実施できません。

したがって、

Technical Information
+
Business Requirement

の両方をApplication Migration Assessmentへ含めます。

7. Application AssessmentとMigration Readiness Assessmentは同じものではない

ここが重要です。

Application Inventory
Infrastructure Inventory
Dependency
Business Requirement

がそろうと、

Application単位のCurrent Environmentを評価する材料

がそろってきます。

しかし、

これらがそろった
=
組織全体がMigration Ready

ではありません。

AWSのMigration Readiness Assessmentでは、

組織として
Cloud Migrationへ進む準備状態

をより広い視点で評価します。

つまり、

Application Migration Assessment
=
対象ApplicationとCurrent Environmentの把握

Migration Readiness Assessment
=
組織全体のCloud Readiness評価

と分けます。

8. Migration Readiness AssessmentはAWS CAFの6 Perspectivesで評価する

Migration Readiness Assessmentでは、AWS Cloud Adoption Frameworkの6 Perspectivesを使って組織の準備状態を確認します。

Business

People

Governance

Platform

Security

Operations

です。

例えば、

Business
→ Business Caseや成果目標は明確か

People
→ 必要なSkillや役割があるか

Governance
→ 意思決定や管理方法が整っているか

Platform
→ Cloud Platformを構築・運用する準備があるか

Security
→ Security / Compliance要件へ対応できるか

Operations
→ Cloud環境を運用する体制があるか

という観点で評価します。

したがってMRAは、

Server情報を集めるだけ

のAssessmentではありません。

9. MRAではStrength / WeaknessとGapを明確にする

Migration Readiness Assessmentの目的は、

Ready
or
Not Ready

だけを付けることではありません。

各Perspectiveを評価して、

Strength

Weakness

を把握します。

例えば、

Platform
→ 技術検証は進んでいる

Security
→ Cloud向けControlが未整理

People
→ AWS Skillが不足

Governance
→ Cloud上の責任分担が未定義

という状態なら、

不足している部分を、

Readiness Gap

として整理します。

10. Readiness GapからAction Planへつなげる

MRAでGapが見つかった場合、

Migrationできない

と即断するのではありません。

例えば、

Cloud Skill不足

Security Control未定義

運用体制未整備

が確認されたなら、

Training

Security設計

Operating Model整備

など、

Migrationへ進むためのAction Plan

を作ります。

したがって、

Migration Readiness Assessment
↓
Strength / Weakness
↓
Gap
↓
Action Plan

という流れで考えます。

11. Application AssessmentとMRAの結果をPlanningへつなげる

Application側では、

Current Environment

Application Inventory

Infrastructure Inventory

Dependency

Business Requirement

を把握します。

組織側では、

Business

People

Governance

Platform

Security

Operations

からReadinessを確認します。

これらを基に、

どのApplicationをMigration Candidateにするか

どのMigration Strategyを採用するか

どの順序で移行するか

など、後続の詳細なMigration Planningへ進みます。

このページでは、その前提となるAssessmentの全体像までを扱います。

12. Migration開始後は「進捗」を追跡する

移行を開始すると、必要な情報が変わります。

Assessment段階では、

何がある？

どのようなGapがある？

移行準備をどう進める？

を見ていました。

Migration実行中は、

Not Started

In Progress

Completed

など、

現在どこまで移行しているか

が重要になります。

ここで扱うのが、

Migration Status

です。

13. AWS Migration HubはMigration Statusを一元的に把握する

AWS Migration Hubは、

複数のMigration Tool
↓
Migration Update
↓
AWS Migration Hub
↓
Application単位で確認

という形でMigration Statusを確認するために利用できます。

例えば、

AWS Application Migration Service

AWS Database Migration Service

などのMigration ToolからStatus Updateを受け取り、

Application A

Application B

Application C

の進捗をまとめて確認できます。

重要なのは、

Migration Toolごとにバラバラに進捗を見るのではなく、Application単位でCentralized Visibilityを得られる

ことです。

14. AWS Migration Hub自体がServerを移行するわけではない

ここは重要な混同ポイントです。

AWS Migration Hub
=
Migration実行Tool

ではありません。

実際のMigrationは、

AWS Application Migration Service

AWS Database Migration Service

その他のMigration Tool

などが実行します。

Migration Toolから送信されたUpdateをMigration Hubで確認します。

つまり、

Migration Tool
↓
Migration実行

AWS Migration Hub
↓
進捗を集約・Tracking

という役割分担です。

15. ResourceをApplicationへまとめてTrackingする

Migration Hubでは、

Server

Database

その他のResource

をApplicationの単位で扱えます。

例えば、

Application A
├─ Web Server
├─ Application Server
└─ Database

としてGroupingされていれば、

Application Aの移行は
どこまで進んでいる？

という視点でStatusを確認できます。

個々のServerだけを見るのではなく、

Business上意味のあるApplication単位へまとめてTrackingできる

点が重要です。

16. Centralized Visibilityは複数Tool・複数RegionのTrackingをまとめる

大規模Migrationでは、

Server Migration
↓
AWS Application Migration Service

Database Migration
↓
AWS DMS

のように複数Toolを利用することがあります。

さらに、Migration先が複数AWS Regionになる場合もあります。

AWS Migration HubではMigration StatusをHome Regionへ集約し、

複数Tool

複数Migration対象

複数Target Region

にまたがる進捗を一元的に確認できます。

これが、

Centralized Visibility

の役割です。

17. Assessment DataとMigration Statusは同じものではない

Migration Hub周辺では、

Discovery / Assessment Data

と、

Migration Status

を混同しないことも重要です。

Assessment Dataは、

Server情報

Application情報

構成

利用状況

Dependency

など、

Migration PlanningのためにCurrent Environmentを把握する情報

です。

一方Migration Statusは、

移行開始済みか

どこまで進んだか

完了したか

という実行中の進捗情報です。

したがって、

Assessment
↓
Planning
↓
Migration
↓
Tracking

という段階を分けて考えます。

18. 現在のAWSではMigration Hubの利用状況に注意する

現在のAWSでは、AWS Migration Hubは2025年11月7日以降、新規顧客の受付を終了しています。

既存のAWS Migration Hub利用者は、進行中のMigration Projectで引き続き利用できます。

新規のMigration / Modernizationでは、AWSは次世代サービスとして AWS Transform を提供しています。

AWS Transformでは、

Discovery

Assessment

Application Grouping

Dependencyを考慮したPlanning

Migration Wave Planning

Migration実行支援

など、Migration Hub周辺で提供されていた機能を含む、より新しいMigration Workflowを利用できます。

ただし、現在のSAP-C02試験ガイドではTask 4.1のMigration Assessment / Tracking Toolの例として、引き続き AWS Migration Hub が明記されています。

したがって学習上は、

SAP-C02
↓
AWS Migration Hubの
Assessment / Tracking上の役割を理解

現在のAWS
↓
新規利用ではAWS Transformも理解

と整理します。

19. Migration AssessmentとTrackingの全体フロー

全体をまとめると、

Current Environment
↓
Application Migration Assessment
├─ Application Inventory
├─ Infrastructure Inventory
├─ Dependency
└─ Business Requirement

+

Migration Readiness Assessment
↓
AWS CAF 6 Perspectives
↓
Strength / Weakness
↓
Readiness Gap
↓
Action Plan

↓
詳細なMigration Planning
↓
Migration実行
↓
Migration ToolからStatus Update
↓
AWS Migration Hub
↓
Migration Status
↓
Centralized Visibility

となります。

20. この段階ではMigration Strategyを決め切らない

Assessmentによって、

このApplicationは存在する

このInfrastructureで動く

このDependencyがある

このBusiness Requirementがある

組織にはこのReadiness Gapがある

と分かったからといって、すぐに、

Rehost

Replatform

Refactor

まで決定する必要はありません。

まず、

Current Environment
+
Organizational Readiness

を把握します。

その情報を使って、後からMigration CandidateやMigration Strategyを評価します。

混同ポイント

SAP-C02での判断

Application Migration Assessmentが必要なScenarioでは、

Current Environmentは分かっている？
↓
Application Inventoryは？
Infrastructure Inventoryは？
↓
Dependencyは？
↓
Business Requirementは？

と考えます。

組織全体のMigration Readinessを問われたら、

AWS CAF
↓
Business
People
Governance
Platform
Security
Operations
↓
Strength / Weakness
↓
Gap
↓
Action Plan

です。

Migration実行中のTrackingが必要なら、

複数Migration Tool
↓
Status Update
↓
AWS Migration Hub
↓
Application単位の
Migration Status
↓
Centralized Visibility

と判断します。

決定打は、

Application単位のCurrent Environment評価と、組織全体のMigration Readiness Assessmentを分け、移行開始後はMigration Statusを一元的に追跡すること

です。

まとめ

Application Migrationを評価する前に、

Application Inventory

Infrastructure Inventory

Dependency

Business Requirement

からCurrent Environmentを把握します。

一方、組織としてCloud Migrationへ進む準備状態は、

Business

People

Governance

Platform

Security

Operations

というAWS CAFの6 Perspectivesから評価します。

Migration Readiness Assessmentでは、

Strength / Weakness
↓
Readiness Gap
↓
Action Plan

を明確にします。

Migration開始後は、Migration Toolが送るStatus Updateを利用して進捗を追跡します。

AWS Migration Hubは、

Application
+
Resource
+
Migration Status

を集約し、Migration ProjectへCentralized Visibilityを提供します。

ただし現在のAWSではMigration Hubは新規顧客を受け付けておらず、新規MigrationではAWS Transformが後継サービスとして提供されています。

SAP-C02では現在もMigration Assessment / Tracking Toolの例としてMigration Hubが明記されているため、

Application Assessment
↓
Migration Readiness Assessment
↓
Planning
↓
Migration
↓
Tracking

の中で、それぞれの役割を分けて理解しておきます。