3.4.1. Migration Planning & Discovery (Discovery Tools, Migration Readiness Assessment)

💡 First Principle: A successful cloud migration is built upon a foundation of thorough discovery and meticulous planning, which minimizes risks, accurately forecasts costs, and ensures alignment with business objectives.

Scenario: A large enterprise with a complex on-premises environment needs to plan its cloud migration. Before moving any workloads, they need to inventory all their physical and virtual servers, understand application dependencies, and assess their overall readiness for migration.

Effective migration begins long before data starts moving. It requires comprehensive assessment and detailed planning.

• Discovery Tools:
  • "AWS Application Discovery Service": Collects server configuration, performance, and usage data from on-premises data centers. (Closed to new customers on November 7, 2025; AWS recommends AWS Transform for new discovery and assessment projects. Still on the SAP-C02 in-scope list.)
  • Practical Relevance: Helps identify dependencies, determine right-sizing for cloud instances, and plan migration waves.
  • "AWS Migration Hub": Centralized dashboard to track progress of application migrations from on-premises to AWS. Integrates with various migration tools. (Closed to new customers on November 7, 2025; AWS Transform provides its capabilities for new projects. Still on the SAP-C02 in-scope list.)
  • "AWS Migration Evaluator": Provides migration readiness assessments and "TCO" analysis.
• Migration Readiness Assessment ("MRA"): A structured assessment of an organization's readiness across various dimensions (e.g., business, people, process, platform, security, operations).
  • Practical Relevance: Identifies gaps and areas for improvement before migration begins. Helps develop a migration roadmap and addresses non-technical challenges.
• Portfolio Assessment: Categorizing applications based on complexity, criticality, and migration strategy (e.g., "6 Rs").
• Dependencies Mapping: Identify all inter-application and intra-application dependencies to plan migration waves that minimize disruption.
• Business Case and "TCO" Analysis: Quantify the benefits and costs of migration to justify the investment.

Visual: Migration Planning & Discovery Process

Discovery Modes, Cost Tools and Wave Rules:

• Agentless vs agent discovery: The "Application Discovery Service" Agentless Collector is a virtual appliance in VMware vCenter that inventories VMs and their CPU, memory and disk utilization without touching the guest operating systems (optional modules add database metadata and network traffic among servers). The Discovery Agent is installed on each Windows or Linux server, physical or virtual, and also captures running processes and TCP connections for dependency mapping. Where agents are forbidden use the collector, and use agents wherever allowed. Results flow to "Migration Hub", where you group discovered servers into applications and then track each application's status as one unit across migration tools ("MGN", "DMS"). "Detective", "SSM Inventory" and "CloudWatch" are not migration discovery tools. (SAP-C02 questions still name both services; see their availability notes above.)
• Which cost tool: "Migration Evaluator" builds the data-driven on-premises-versus-AWS business case from actual utilization (including licensing) and is the TCO answer; the "Pricing Calculator" prices a target architecture you specify service by service (an EC2 inventory can be bulk-imported), so it suits a quick estimate when you already know the inventory and sizing; "Cost Explorer" and "Budgets" analyze AWS spend you already have and cannot model an on-premises comparison.
• What a TCO must include: Direct hardware and software are usually captured. Often omitted are IT labor (patching, backups, on-call), facilities (space, power, cooling, physical security), hardware refresh and redundancy for DR. Managed services remove this undifferentiated heavy lifting, which is the main soft-cost saving; data transfer is a cloud-only cost that is easy to remember.
• Wave rules: Choose a first workload that is loosely coupled, low risk and visibly valuable, not the most mission-critical or most entangled system. Group applications that are tightly coupled (high-volume calls between them, a shared database) into the same wave so they are migrated and tested together and chatty traffic does not cross the on-premises-to-AWS link during the move; migrating a shared database alone first, or splitting coupled apps across waves, splits them across that link.

⚠️ Common Pitfall: Focusing only on the technical discovery and ignoring the business and people aspects. A migration can fail due to a lack of business buy-in or an operations team that isn't trained for the cloud, even if the technology is perfect.

Key Trade-Offs:

• Depth of Discovery vs. Speed of Migration: A very deep discovery phase takes longer but significantly de-risks the migration. A faster, more shallow discovery might accelerate the start but increases the risk of unforeseen issues later.

Reflection Question: How would you utilize "AWS Application Discovery Service" and a "Migration Readiness Assessment" to gather the necessary data and prepare a comprehensive migration plan for a large enterprise with a complex on-premises environment, ensuring all physical and virtual servers are inventoried, application dependencies are understood, and overall readiness is assessed before initiating any workload moves?