Migration Assessment, 7Rs Strategy, and Wave Planning

Migration assessment for AWS Solutions Architect Professional (SAP-C02) is the discipline of turning an unstructured on-premises estate into a prioritized, funded, wave-planned migration program. At Pro depth, the migration assessment 7Rs exercise is not a vocabulary quiz — it is a portfolio-scale decision pipeline that starts with the AWS Cloud Adoption Framework (CAF) readiness review, qualifies for AWS Migration Acceleration Program (MAP) funding, discovers every workload with AWS Application Discovery Service, builds TCO with AWS Migration Evaluator, classifies each application against the 7 Rs decision matrix, and then orchestrates execution through AWS Migration Hub with dependency-aware wave planning.

SAP-C02 Domain 4 task statement 4.1 tests whether you can run this end-to-end migration assessment on a realistic enterprise scenario. A canonical exam stem looks like this: "A company has 500 applications across 12 data centers with an 18-month data-center-exit deadline and a mixed tech stack (Windows, Linux, AS/400, Oracle, VMware, SaaS-replaceable CRM). The CFO demands a business case before approving spend." If you can read that stem and immediately map it to CAF → MAP Mobilize → Migration Evaluator → MPA → 7Rs classification → wave planning, you will pass the migration assessment questions cleanly.

The Migration Assessment Problem at Pro Scale

Migration assessment is fundamentally different from Associate-level "pick the right R for this one app" questions. At Pro scale, you are not assessing one application — you are assessing a portfolio, and portfolio-level migration assessment requires distinct data structures, funding vehicles, and governance models.

A 500-application migration assessment exposes three problems that do not exist at small scale:

1. Heterogeneity — the 500 apps span COTS, bespoke Java, .NET, AS/400, SaaS, and shadow IT. No single R fits; you need a decision matrix that maps workload characteristics to R strategy systematically.
2. Interdependencies — applications share databases, message queues, and authentication services. A naive "one app per wave" plan breaks because Wave 3 still reads from a Wave 7 database. You need dependency-aware wave sequencing.
3. Capital constraints — 500 apps × 18 months means you cannot self-fund the assessment. You need AWS MAP funding, which in turn requires a Migration Evaluator TCO business case signed off by the CFO before the first wave starts.

These three problems are why SAP-C02 migration assessment questions always mention portfolio size (100+, 500+, 1000+), a deadline (12-24 months), and a mixed stack. The exam is probing whether you know the program-level answer, not just the per-app R.

Analogy 3 — Wave Planning as Construction Site Scheduling

Migration 的 wave planning 就像大型工地 (construction site) 的施工順序。你不能同時挖地基、蓋屋頂、裝玻璃——必須依據相依性排序。Wave 1 是獨立小樓（standalone apps），Wave 2 是共用地下停車場的連棟（shared database groups，叫做 affinity groups），Wave 3 是複雜地標建築（complex interdependencies with legacy mainframe）。Dependency graph 就是工地的鋼筋配筋圖——告訴你哪些梁柱先上、哪些後上。AWS Migration Hub 就是工地的指揮中心 (command centre)——每個 wave 的進度、每個 app 的 status、每個 dependency 的 risk 都集中在這裡看。

AWS Cloud Adoption Framework (CAF) — 6 Perspectives at Pro Depth

AWS CAF is the organizational readiness layer of migration assessment. At SAP-C02 depth, CAF is not "there are 6 perspectives, name them" — it is "given this enterprise pain point, which CAF perspective owns the remediation, and what capabilities are involved?"

Business Perspective — Strategy and Investment

Owners: CEO, CFO, COO, CIO, line-of-business leaders.

Capabilities tested at Pro depth: strategy management, portfolio management, innovation management, product management, strategic partnership, data monetization, business insights.

SAP-C02 exam cue: "The CEO wants to tie the migration to new revenue streams within 24 months" → Business perspective. The scenario is asking about strategy-to-outcome alignment, which is Business not Governance.

People Perspective — Culture and Cloud Fluency

Owners: CHRO, CIO, Cloud Center of Excellence (CCoE) lead.

Capabilities at Pro depth: culture evolution, transformational leadership, cloud fluency, workforce transformation, change management, organization design, talent management.

SAP-C02 exam cue: "500 legacy sysadmins need to become cloud engineers in 12 months; retention is a risk" → People perspective. Cloud fluency training, reskilling pathways, and CCoE formation are People concerns.

Governance Perspective — Program and Risk Management

Owners: CIO, CTO, CFO, Chief Risk Officer (CRO), Chief Data Officer (CDO).

Capabilities: program and project management, benefits management, risk management, cloud financial management (CFM), application portfolio management (APM), data governance.

SAP-C02 exam cue: "Migration must stay within $12M budget across 18 months with monthly showback to business units" → Governance perspective. Cloud financial management and benefits realization sit here.

Platform Perspective — Landing Zone and Engineering

Owners: CTO, cloud architects, engineering leads.

Capabilities: platform architecture (landing zone), data architecture, platform engineering, data engineering, provisioning and orchestration (Control Tower, Account Factory), modern application development, CI/CD.

SAP-C02 exam cue: "Before the first migration wave, we need Control Tower landing zone, shared services account, and CI/CD pipelines ready" → Platform perspective.

Security Perspective — Confidentiality, Integrity, Availability, Privacy, Resilience

Owners: CISO, Chief Compliance Officer (CCO), internal audit.

Capabilities: security governance, security assurance, identity and access management, threat detection, vulnerability management, infrastructure protection, data protection, application security, incident response.

SAP-C02 exam cue: "Migration must satisfy HIPAA, PCI-DSS, and SOC 2 across all landing zone accounts" → Security perspective.

Operations Perspective — Run and Operate

Owners: CIO, COO, SRE / platform teams.

Capabilities: observability, event management (AIOps), incident and problem management, change and release management, performance and capacity management, configuration management, patch management, availability and continuity management, application management.

SAP-C02 exam cue: "Post-migration, 24/7 on-call must cover 500 workloads with 15-minute MTTA" → Operations perspective.

AWS Migration Acceleration Program (MAP) — 3 Phases and Funding Qualification

MAP is AWS's flagship migration program and funding vehicle. At Pro depth, you must know the three phases, the funding qualification criteria, and the tooling AWS provides at each phase.

Phase 1 — Assess

Objective: Determine migration readiness and build the business case.

Activities: CAF readiness assessment, Migration Readiness Assessment (MRA) workshop, Migration Evaluator (formerly TSO Logic) TCO analysis, directional business case, executive alignment.

Deliverables:

• MRA report across CAF 6 perspectives
• Directional TCO (typically 3-year or 5-year projection)
• Initial application inventory (high-level)
• Executive sign-off to proceed to Mobilize

Funding: Limited — typically AWS Professional Services or AWS Partner Network (APN) Migration Competency partner credits for the assessment itself.

Phase 2 — Mobilize

Objective: Close organizational gaps identified in Assess and prepare for at-scale migration.

Activities:

• Landing zone build (AWS Control Tower, Account Factory, shared services account)
• Detailed Application Discovery using Application Discovery Service (agentless + agent-based)
• Migration Portfolio Assessment (MPA) to score every application
• Migration Experience Building — typically 5-15 pilot applications migrated to prove the factory
• Cloud Center of Excellence (CCoE) formation and staffing
• Operating model definition (who operates what post-migration)

Deliverables:

• Production-ready landing zone
• Complete application portfolio inventory with 7Rs assignment
• Wave plan with dependency graph
• Cutover runbook templates
• Signed detailed business case

Funding: MAP Mobilize funding — AWS provides cash credits (typically 15-25% of projected 12-month AWS spend) against qualifying expenses. Requires commitment letter and executive sponsorship.

Phase 3 — Migrate and Modernize

Objective: Execute the wave plan and decommission the source data centers.

Activities:

• Wave-by-wave execution using AWS Application Migration Service (MGN) for Rehost, AWS DMS for database moves, AWS DataSync for file data, AWS Snow Family for bulk offline
• Migration Hub tracking of each workload status
• Post-migration Well-Architected Framework review per workload
• Modernization overlays (Refactor waves after initial Rehost)
• Data center decommissioning

Deliverables:

• All in-scope workloads migrated or retired
• Source data centers decommissioned
• Realized savings vs business case
• Modernization backlog for ongoing waves

Funding: MAP Migrate funding — larger credit pool (typically 25-50% of projected AWS spend during migration window), gated by wave milestones and partner involvement.

MAP Funding Qualification at Pro Depth

SAP-C02 migration assessment questions sometimes probe who qualifies for MAP funding. The answer is not every customer — MAP is a commercial program with criteria:

• Minimum migration size: typically 1000+ servers or equivalent workload footprint, though smaller programs qualify via MAP Small Segment (MAP-SS) or MAP for Windows.
• Committed AWS spend: a forecast of annual recurring AWS consumption post-migration (typically $1M+ for full MAP).
• Executive sponsorship: C-level sign-off that the migration is strategic.
• Partner engagement: most MAP programs run through an AWS Migration Competency partner who provides Professional Services and co-invests.
• Assessment completion: you cannot skip to Migrate funding; Mobilize must be complete first.

Exam cue: If a scenario says "the company wants AWS to fund the migration but has only 40 servers and no existing AWS spend" — MAP is NOT the right answer; they should pursue AWS Migration Hub Strategy Recommendations with self-funded Prof Services or use an APN partner's SMB migration offering.

AWS Application Discovery Service — Agentless Connector vs Agent

AWS Application Discovery Service (ADS) is the technical discovery engine that populates Migration Hub with on-premises workload data. At SAP-C02 depth you must distinguish the two discovery modes, their prerequisites, and the data each collects.

Agentless Discovery Connector

• Form factor: OVA deployed into VMware vCenter (ESXi).
• Collects: VM-level inventory (VM name, CPU, memory, disk, NIC), VM performance metrics (CPU utilization, memory utilization, network throughput), basic dependency from vCenter metadata.
• Does NOT collect: Process-level inventory, network connection details, application-level dependencies.
• Use when: Source estate is VMware-only, you cannot install agents (compliance, change windows, operational risk), you need fast coverage.
• Latency to usable data: Typically 2 weeks of observation for meaningful utilization patterns.

Application Discovery Agent

• Form factor: Lightweight agent installed on each Windows or Linux server (physical, VMware, Hyper-V, KVM, or cloud).
• Collects: Everything agentless collects plus running processes, TCP/UDP connections (source IP, dest IP, port, process name), installed applications, performance at higher fidelity.
• Use when: You need process-level dependency mapping, non-VMware hypervisors (Hyper-V, KVM), physical servers, or accurate application-to-application traffic maps.
• Trade-off: Requires agent deployment across every server — operationally heavier but yields the high-fidelity dependency data that wave planning depends on.

AWS Migration Hub Strategy Recommendations (Modernization Assessment)

On top of ADS, Migration Hub Strategy Recommendations analyzes the discovered data and produces 7Rs recommendations per application with modernization paths (e.g., "this Java EE monolith on WebLogic is a candidate for Refactor to containers with ECS, Aurora PostgreSQL, and Lambda"). It consumes ADS data plus optional anti-pattern analysis binaries.

AWS Migration Evaluator — The TCO Engine

AWS Migration Evaluator (formerly TSO Logic) is the business-case engine. It ingests discovery data, combines it with AWS pricing, Reserved Instance / Savings Plans modeling, and Graviton / managed-service assumptions, then produces a defensible TCO that the CFO will sign.

What Migration Evaluator Produces

• Directional TCO (during Assess phase): 3-year or 5-year projection with assumed Rehost-heavy mix, +/- 20% accuracy band.
• Detailed TCO (during Mobilize phase): Per-application target architecture, right-sized instances, Reserved Instance / Savings Plans coverage assumptions, storage class assumptions, data transfer modeling.
• Comparison view: On-prem steady-state cost (including hardware refresh cycle, data center lease, power, cooling, staff) vs AWS target-state cost.
• Sensitivity analysis: Impact of +/- 10% utilization, +/- 20% Savings Plan coverage, Graviton adoption rate.

Migration Evaluator vs TCO Calculator vs Pricing Calculator

Three tools, three purposes — SAP-C02 sometimes distinguishes these:

• AWS Pricing Calculator: What-if estimates for a specific architecture. Input you specify; no discovery data, no on-prem comparison.
• TCO Calculator (legacy Simple Monthly Calculator successor): High-level CapEx-vs-OpEx comparison; not used for portfolio migration at SAP scale.
• Migration Evaluator: Portfolio-scale TCO driven by actual discovery data and utilization. The correct answer for "CFO wants a defensible business case for a 500-application migration."

7 Rs Decision Matrix — Pro Depth

At SAP-C02 depth, each R has a precise trigger profile — a set of workload characteristics that make that R the right answer. Below is the decision matrix in exam-usable form.

Retire — Decommission (No Migration)

Trigger profile: Application has not been accessed in 12+ months; functionality is duplicated by another system; technology is end-of-life with no business owner; the data contained is redundant or can be archived to S3 Glacier.

SAP-C02 scenario cues: "no logins in 18 months", "duplicate wiki systems", "superseded by the SaaS rollout last year", "the business unit it served was divested".

Assessment action: Confirm with business owner, archive data to S3 Glacier Deep Archive (or S3 Glacier Instant Retrieval if occasional read required), shut down, remove from migration scope. A healthy enterprise Retire rate during discovery is 10-20% of the portfolio.

Retain — Keep On-Premises (Defer)

Trigger profile: Regulatory or data-sovereignty blocker (data must physically remain on-prem); mainframe workload with no cost-effective cloud equivalent; latency constraint to physical hardware (factory floor, medical device, HFT); active multi-year vendor contract that penalizes early exit.

SAP-C02 scenario cues: "contract expires in 2027", "regulator requires data on-premises", "<1ms latency to PLC floor", "mainframe COBOL with no vendor cloud offering".

Assessment action: Document the Retain reason with a revisit date tied to the blocker expiry. Retain is not "we gave up" — it is a deliberate, time-bounded deferral.

Relocate — Hypervisor-Level Lift (VMware Cloud on AWS)

Trigger profile: Estate is VMware-heavy, team skilled in vSphere not EC2, data-center-exit deadline is too tight to re-platform at Rehost level, acceptable to keep paying VMware licensing in AWS.

SAP-C02 scenario cues: "600 VMware VMs, team not retrained for EC2, 6 months to data-center exit", "preserve IP addresses across cutover", "no agents allowed".

Assessment action: Procure VMware Cloud on AWS (VMC) SDDC, use VMware HCX for migration, cutover at hypervisor level. Trade-off: VMC licensing cost vs speed.

Rehost — Lift-and-Shift to EC2 (No Code Change)

Trigger profile: Data-center-exit deadline dominates every other consideration; application is reasonably well-behaved (stateful but not exotic); database is supported by RDS or can run on EC2; team does not have capacity for Replatform effort during the migration window.

SAP-C02 scenario cues: "exit data center in 12 months", "no code changes, move as-is", "budget for optimization later".

Assessment action: Use AWS Application Migration Service (MGN) for agent-based block-level replication, cutover window of hours per application, optimize post-migration. Typical large-migration Rehost rate: 50-70% of portfolio.

Replatform — Lift-Tinker-and-Shift

Trigger profile: Workload benefits meaningfully from a managed service swap without full rewrite; self-managed database is operational burden; self-managed middleware has known scaling pain; modest code/config changes are acceptable within migration window.

SAP-C02 scenario cues: "self-managed MySQL → Amazon RDS", "Apache + Tomcat on EC2 → Elastic Beanstalk", "self-managed Redis → ElastiCache", "connection string change acceptable".

Assessment action: Combine MGN for the app tier with AWS DMS + SCT for database, or Elastic Beanstalk / ECS for web tier. Typical large-migration Replatform rate: 15-25% of portfolio.

Repurchase — Drop-and-Shop (SaaS Replacement)

Trigger profile: Workload is a commodity business function (CRM, ERP, HRIS, email, collaboration, ITSM); mature SaaS market exists; TCO of SaaS subscription is lower than Rehost + operate; business is open to process change.

SAP-C02 scenario cues: "legacy Siebel CRM", "on-prem Exchange", "custom HRIS", "ServiceNow replacement of legacy ticketing".

Assessment action: Identify SaaS target (Salesforce, Workday, Microsoft 365, ServiceNow), plan data migration and user provisioning (SCIM to IAM Identity Center), retire the source. Typical rate: 5-10% of portfolio.

Refactor / Re-architect — Cloud-Native Redesign

Trigger profile: Existing architecture is a scaling blocker for business growth; current cost structure is unsustainable at projected scale; feature velocity is constrained by monolith; strategic application where cloud-native benefits (serverless scale, event-driven cost) justify rebuild investment.

SAP-C02 scenario cues: "monolith cannot scale past 10K RPS", "release frequency stuck at monthly", "strategic digital product", "cost per transaction must drop 60%".

Assessment action: Refactor is almost never a migration-phase activity for 500 apps — it is a post-migration modernization wave. Typical plan: Rehost the monolith in Wave 2, stand up Strangler Fig with API Gateway + Lambda + DynamoDB, migrate capability by capability over 12-18 months post-migration. Typical rate during the migration window: 5% of portfolio; much higher in the post-migration modernization backlog.

7 Rs Decision Matrix Table

Migration Portfolio Assessment (MPA)

Migration Portfolio Assessment (MPA) is the scoring methodology that turns discovery data plus business context into a per-application 7Rs recommendation with confidence scores. MPA is typically delivered during MAP Mobilize phase.

What MPA Scores

Each application receives scores across multiple dimensions:

• Business criticality (1-5): Impact of downtime on revenue or operations.
• Technical complexity (1-5): Architecture complexity, stateful vs stateless, clustering, integrations.
• Cloud readiness (1-5): Proximity to cloud-native patterns (12-factor, container-friendly, stateless).
• Data gravity: Volume of data and affinity to other applications.
• Compliance profile: HIPAA, PCI-DSS, SOX, GDPR tags.
• Dependencies: Count and nature of upstream/downstream integrations.

MPA Output

• Recommended R per application with confidence.
• Affinity group membership (applications that should migrate together).
• Preliminary wave assignment.
• Estimated migration effort (person-days).
• Modernization opportunity flag (post-Rehost Refactor candidates).

MPA output feeds directly into Migration Hub as the master portfolio record and into the wave planner as the sequencing input.

Wave Planning — Dependency Graph, Affinity Groups, Wave Sequencing

Wave planning is where discovery and classification become an executable schedule. At SAP-C02 depth you must know the three primitives: dependency graph, affinity groups, and wave sequencing rules.

Dependency Graph

Every application is a node; every integration is an edge. Edges have types (synchronous API, async queue, shared database, shared auth, file share) and directions (A calls B, A writes to B's DB). Dependency graph is built from Application Discovery Service agent data (TCP/UDP connection observations) combined with business-owner interviews.

Exam principle: You cannot migrate an application before its hard dependencies — shared databases, authentication services, message brokers — are in place. Soft dependencies (analytics feeds, read-only reports) can migrate later.

Affinity Groups

An affinity group is a set of applications that must migrate together because they share stateful dependencies (a shared database cluster, a shared file server, a tightly coupled message bus) or because they undergo synchronized cutover (billing + invoicing + GL must be consistent at cutover instant).

Affinity groups typically range from 3 to 20 applications and become the unit of wave assignment — you assign the whole group to a wave, not individual apps.

Wave Sequencing Rules

1. Wave 0 — Foundation: Landing zone, shared services (AD, DNS, monitoring, logging, network). Never migrate business apps before foundation is in place.
2. Wave 1 — Pilot / Low-risk standalone: 5-15 applications that are independent, non-critical, and well-documented. Proves the factory and builds team muscle memory.
3. Waves 2-N — Dependency-ordered business waves: Topologically sort the dependency graph; apps with no remaining on-prem dependencies go earliest; apps with many on-prem dependencies go later.
4. Final Wave — Complex / high-risk: Mainframe adjacency, SAP, Oracle clusters, high-compliance workloads. Migrate last when team is experienced and patterns are proven.
5. Retire and Retain waves: Retires happen continuously during discovery; Retains are flagged with revisit dates and excluded from waves.

Wave Size and Cadence at 500-App Scale

For a 500-app / 18-month program, typical planning looks like this:

• Month 0-3: Mobilize, landing zone, discovery (Wave 0).
• Month 3-5: Pilot (Wave 1, ~10 apps).
• Month 5-16: Business waves (Waves 2-12, ~40-50 apps per wave, 2 waves per month running in parallel).
• Month 16-18: Final complex waves, retain-set validation, data center decommissioning.

AWS Migration Hub — Portfolio View and Orchestration

AWS Migration Hub is the single pane of glass for portfolio-scale migration assessment and execution. At SAP-C02 depth you must know what Migration Hub integrates and what it orchestrates.

Migration Hub Integrations (Data Sources)

• AWS Application Discovery Service — server inventory, performance, dependencies.
• Migration Hub Strategy Recommendations — 7Rs recommendations per app.
• AWS Application Migration Service (MGN) — Rehost status per server.
• AWS Database Migration Service (DMS) — database migration task status.
• AWS Migration Hub Orchestrator — workflow templates for SAP on AWS, Windows IIS, and generic migration patterns.
• Partner tools — Carbonite, CloudEndure (legacy), Cloudscape, Risc Networks (via Migration Hub Import API).

Migration Hub Orchestrator

Migration Hub Orchestrator is the workflow engine that coordinates multi-step migration procedures across services. Example workflow:

1. MGN: test-launch instance in AWS.
2. DMS: verify database replication lag < 30 seconds.
3. Route 53: lower TTL to 60 seconds.
4. MGN: cutover to production target.
5. DMS: switch replication direction (reverse replication for rollback safety).
6. DNS cutover.
7. Post-cutover validation tests.
8. MGN: decommission source server.

Orchestrator makes this repeatable across waves — you do not rebuild the runbook for each app.

Migration Hub Home Region

Migration Hub has a home region concept — you pick one AWS region where portfolio data is stored. This is the region where Strategy Recommendations, Import, and Orchestrator operate. Actual migration targets can be any region; the home region is just where the portfolio metadata lives.

Scenario Walkthrough — 500 Apps, 12 Data Centers, 18-Month Deadline

Let us run the complete migration assessment against the canonical SAP-C02 scenario: 500 applications across 12 data centers, 18-month deadline, mixed tech stack (Windows, Linux, VMware, Oracle, SQL Server, legacy Siebel CRM, AS/400 mainframe workloads).

Step 1 — CAF Readiness (Month 0-1)

Run MRA workshops with the enterprise leadership team across the six CAF perspectives. Expected findings for an organization of this size:

• Business: Strategy aligned (CFO already supports, ROI case needed) — ready.
• People: Only 15% of 400 sysadmins have AWS certifications. Gap — needs 12-month reskilling plan plus CCoE formation.
• Governance: No cloud financial management tooling. Gap — needs FinOps function.
• Platform: No AWS landing zone. Gap — Control Tower deployment required.
• Security: Existing SOC handles on-prem; AWS-native tooling (GuardDuty, Security Hub) not configured. Gap — security retrofitted during Mobilize.
• Operations: Existing ITIL-based ops; no cloud observability. Gap — CloudWatch / X-Ray retrofit.

Step 2 — MAP Assess → Mobilize Qualification (Month 1-2)

With 500 apps and projected $8M annual AWS spend post-migration, this program clearly qualifies for full MAP. Engage an AWS Migration Competency partner, sign the MAP commitment letter, unlock Mobilize funding.

Step 3 — Discovery (Month 2-4)

Deploy Application Discovery Service Agentless Connector to all 12 VMware vCenters for breadth. Deploy ADS Agents to the 120 physical servers and the top 200 business-critical VMs for process-level dependency data. Let discovery run for 3-4 weeks to accumulate meaningful utilization and dependency data.

Step 4 — TCO (Month 3-4 in parallel)

Pipe discovery data into Migration Evaluator. Output:

• On-prem 3-year TCO: $84M (hardware refresh, DC lease, power, staff).
• AWS target 3-year TCO (75% Rehost + 20% Replatform + 5% Retire/Repurchase/Retain): $52M.
• Projected 3-year savings: $32M, payback period: 14 months.
• Migration one-time cost: $9M (Prof Services + tooling + cutover labor, partially offset by MAP credits).

CFO signs.

Step 5 — MPA and 7Rs Classification (Month 4-5)

Run Migration Portfolio Assessment against all 500 applications. Typical outcome:

• Retire: 75 apps (15%) — duplicate wikis, unused reporting tools, decommissioned product lines.
• Retain: 30 apps (6%) — AS/400 mainframe workloads (vendor cloud offering planned for 2027), 5 apps blocked by regulatory data sovereignty.
• Relocate: 40 apps (8%) — VMware-bound legacy with no time to re-platform.
• Rehost: 280 apps (56%) — majority of standard Windows/Linux VMs.
• Replatform: 55 apps (11%) — self-managed SQL Server → RDS, self-managed PostgreSQL → Aurora, Tomcat → Elastic Beanstalk.
• Repurchase: 15 apps (3%) — legacy Siebel → Salesforce, on-prem Exchange → Microsoft 365, custom HRIS → Workday.
• Refactor: 5 apps (1%) — 5 strategic customer-facing monoliths slated for post-migration Strangler Fig modernization. Rehost first, Refactor after Wave 12.

Step 6 — Wave Plan (Month 5)

Using dependency graph from ADS Agent data, topologically sort into 12 business waves:

• Wave 0 (Month 3-5): Foundation — landing zone, shared services account, AD, centralized DNS, logging.
• Wave 1 (Month 5-6): Pilot — 10 standalone internal tools.
• Waves 2-11 (Month 6-16): Business waves, 40-50 apps per wave, dependency-ordered. Affinity groups (billing+invoicing+GL is one group of 8 apps; customer-portal+auth+profile is another group of 12) migrate together.
• Wave 12 (Month 16-17): Complex / high-compliance — Oracle clusters, HIPAA workloads, Siebel → Salesforce cutover.
• Month 17-18: Data center decommissioning, Retain-set validation, post-migration Well-Architected reviews, modernization backlog kickoff.

Step 7 — Execution and Tracking (Month 5-18)

All waves tracked in AWS Migration Hub. MGN replicates Rehost candidates continuously; Orchestrator runs cutover runbooks; DMS migrates databases with CDC. Real-time status per app visible to the Program Office.

Business Case and TCO Modeling at Pro Depth

A defensible business case is the gate for every dollar of migration investment. At Pro depth, the business case has four components:

1. Steady-State On-Prem Cost

Not just the current-year cost. You must include:

• Hardware refresh cycle (typically every 4-5 years — amortize the CapEx hit).
• Data center lease escalation (typically 3-5% annual).
• Power and cooling cost trends.
• Staff cost (sysadmins, network engineers, DC technicians).
• Software licensing true cost (Oracle, SQL Server, VMware, Windows Datacenter).

2. AWS Target-State Cost

Modeled using Migration Evaluator:

• Right-sized EC2 (not one-for-one like-to-like from on-prem over-provisioned specs).
• Reserved Instances / Savings Plans assumptions (typically 70% coverage of steady workloads).
• Managed service savings from Replatform targets.
• Data transfer cost modeling (egress, inter-region, inter-AZ).
• Storage class optimization (S3 IA, Glacier for cold).

3. One-Time Migration Cost

• Professional Services (partner + AWS ProServe).
• Tooling (MGN, DMS, DataSync — mostly free but metered data transfer applies).
• Snow Family offline data transfer (if applicable).
• Cutover labor (internal team + contractors).
• Training and certification investment.
• Offset by MAP credits.

4. Business Benefits (Beyond Cost)

• Agility: time-to-market improvement, projected new revenue enabled.
• Risk reduction: DR improvement, security posture uplift.
• Sustainability: carbon footprint reduction (AWS publishes region-level carbon intensity).

Governance, Program Office, and Change Management

Migration assessment does not end at the wave plan — execution requires ongoing governance.

Program Office (Migration Office)

A dedicated team that owns:

• Migration Hub portfolio integrity.
• Wave schedule and risk register.
• Partner and vendor coordination.
• Executive status reporting.
• MAP funding milestone tracking.

Governance Guardrails

• SCPs applied at OU level (per wave OU or per business-unit OU) to prevent drift.
• Control Tower Account Factory for consistent landing zone per migrated business unit.
• AWS Config rules for compliance enforcement.
• AWS Budgets with alerts per wave / per business unit.

Change Management and Training

• CCoE operational model — cloud engineering center of excellence that owns patterns, training, and internal consulting.
• Cloud fluency training across IT staff (AWS Cloud Practitioner for 100%, Solutions Architect Associate for technical staff, Specialty certifications for platform team).
• Stakeholder communication plan — business owners briefed before their app's wave; cutover runbooks walked through before cutover day.
• Post-cutover support — hypercare period (typically 2 weeks) with elevated on-call coverage.

Common Traps in SAP-C02 Migration Assessment Questions

Trap 1 — Confusing CAF with Well-Architected Framework

CAF is organizational transformation (before/during migration, across 6 perspectives). Well-Architected is per-workload architecture review (after workload is on AWS, across 6 pillars). SAP-C02 loves to mix both into a stem — read carefully for "organization-wide transformation" (CAF) vs "specific workload architecture" (WAF).

Trap 2 — Choosing Migration Evaluator vs Pricing Calculator

For a 500-app portfolio business case: Migration Evaluator. For a single new architecture what-if: Pricing Calculator. The exam often bundles both into answer choices.

Trap 3 — Skipping Mobilize

A scenario says "the company wants to start migrating next month". Candidates pick Migrate phase immediately. Wrong — without Mobilize (landing zone, CCoE, pilot wave), the migration fails. The correct answer often includes a short Mobilize sprint before Wave 1.

Trap 4 — Relocate vs Rehost Confusion

Both feel like lift-and-shift. Relocate = hypervisor-level (VMware Cloud on AWS), keeps vSphere. Rehost = OS-level (EC2), uses MGN, leaves vSphere behind. If the stem mentions "preserve VMware operations", it is Relocate. If it mentions "move to EC2", it is Rehost.

Trap 5 — Refactor in the Migration Window

Refactor is rarely completed in an 18-month data-center-exit window at 500-app scale. Pro-level answers typically Rehost first, Refactor later as a modernization wave. Watch for answer choices that try to Refactor everything — they are usually wrong.

Trap 6 — Assuming Full Discovery Coverage Is Mandatory

At Pro depth, you do not always need agent on every server. Agentless covers 80% of the estate for VMware environments. Pushing agent everywhere delays discovery by weeks and alienates operations teams. The right answer balances coverage with practicality.

FAQ — Migration Assessment and 7Rs at Pro Depth

Q1: What is the difference between MAP Mobilize and the Migration phase?

MAP Mobilize is the preparation phase — landing zone, detailed discovery, MPA, CCoE formation, pilot waves (5-15 apps), detailed business case. MAP Migrate is the execution phase — at-scale wave execution, data center decommissioning, post-migration Well-Architected reviews. Mobilize is gated by MAP Assess sign-off; Migrate is gated by Mobilize completion and pilot success. SAP-C02 scenarios often ask which phase a described activity belongs to — landing zone build is Mobilize, data center decommissioning is Migrate.

Q2: When should I use Application Discovery Service Agent vs Agentless Connector?

Use Agentless Connector when the estate is VMware-heavy and you need fast, low-operational-overhead discovery. It gives you VM inventory and VM-level performance but not process-level dependencies. Use Agent when you need process-level dependency mapping, TCP/UDP connection data for accurate application-to-application traffic maps, or when servers are not on VMware (physical, Hyper-V, KVM, cloud). Large migrations typically use both — agentless for breadth, agent on critical apps for depth.

Q3: The CFO demands a TCO comparison before approving the migration budget. Which AWS service do I use?

AWS Migration Evaluator (formerly TSO Logic). Migration Evaluator ingests on-premises discovery data (server specs, utilization, software inventory), combines it with AWS pricing, Reserved Instance and Savings Plans assumptions, and managed-service target architectures, and produces a defensible 3-year or 5-year TCO that the CFO can sign. AWS Pricing Calculator is for what-if architecture estimates, not portfolio TCO. Migration Evaluator is the correct answer for portfolio-scale business cases and is the gate for MAP funding qualification.

Q4: How do I sequence migration waves for a 500-application portfolio with complex interdependencies?

Sequence by dependency order plus risk ramp, not by business criticality or application size. Start with Wave 0 (foundation) — landing zone and shared services. Wave 1 (pilot) — 5-15 low-risk standalone apps to prove the factory. Waves 2-N (business) — topologically sort the dependency graph so applications migrate after their hard dependencies; use affinity groups (apps that share stateful dependencies) as the migration unit. Final wave — complex / high-compliance / mainframe-adjacent apps when the team is most experienced. Business criticality influences cutover window length and testing rigor but not wave order.

Q5: What qualifies an organization for AWS Migration Acceleration Program (MAP) funding?

MAP funding qualification typically requires: minimum migration size (1000+ servers for full MAP, smaller for MAP-SS or MAP for Windows), committed AWS spend forecast (typically $1M+ annual recurring post-migration), C-level executive sponsorship, engagement with an AWS Migration Competency partner, and completion of the MAP Assess phase deliverables (MRA report, directional TCO). MAP Mobilize funding is provided as AWS credits against qualifying Professional Services and tooling expenses; MAP Migrate funding is larger and gated by wave milestones. Small migrations (under ~200 servers or $500K projected annual AWS spend) typically do not qualify for MAP and should pursue APN partner offerings or self-funded migration.

Q6: Should the 5 strategic customer-facing monolith applications be Refactored during the 18-month migration window?

No — at Pro depth the correct answer is Rehost first, Refactor later. Refactoring 5 strategic monoliths during an 18-month data-center-exit window competes with the wave factory for engineering attention and typically delays the data center exit. The recommended pattern is: Rehost the monoliths in their assigned business waves, complete data center exit on schedule, then run a dedicated post-migration modernization program using Strangler Fig patterns (API Gateway as facade, incremental replacement with Lambda + DynamoDB + containers) over the following 12-18 months. The migration assessment should flag these 5 apps as Rehost with Refactor modernization backlog entries, not as Refactor during migration.

Q7: How does Migration Hub differ from Application Discovery Service and Migration Evaluator?

They are complementary, not competing:

• Application Discovery Service is the technical data collector — agentless or agent-based inventory, performance, and dependency data from on-premises servers.
• Migration Evaluator is the business case engine — consumes ADS data (or its own collector) plus AWS pricing to produce portfolio TCO.
• Migration Hub is the portfolio view and orchestrator — integrates ADS data, Strategy Recommendations, MGN, DMS, and partner tools into a single console with per-application status tracking and cutover runbook execution.

A full migration assessment uses all three: ADS collects, Migration Evaluator justifies, Migration Hub executes.

Q8: Which CAF perspective owns migration funding and portfolio cost control?

The Governance perspective. Governance capabilities include program and project management, benefits management, risk management, and cloud financial management (CFM). During migration, Governance owns budget vs actuals tracking, FinOps tooling (Cost Explorer, Cost and Usage Reports, Budgets, Cost Anomaly Detection), chargeback/showback design, and MAP funding milestone reporting. Do not confuse with Business perspective (strategy alignment) or Platform perspective (landing zone).

Further Reading and Official Sources

• AWS Cloud Adoption Framework (CAF) v3 Whitepaper: https://docs.aws.amazon.com/pdfs/whitepapers/latest/overview-aws-cloud-adoption-framework/overview-aws-cloud-adoption-framework.pdf
• AWS Migration Acceleration Program (MAP): https://aws.amazon.com/migration-acceleration-program/
• AWS Migration Hub User Guide: https://docs.aws.amazon.com/migrationhub/latest/ug/whatishub.html
• AWS Application Discovery Service User Guide: https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html
• AWS Migration Evaluator: https://aws.amazon.com/migration-evaluator/
• AWS Prescriptive Guidance — Large Migrations: https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/welcome.html
• AWS Prescriptive Guidance — Migration Strategies (7 Rs): https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
• AWS Application Migration Service (MGN): https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html
• AWS SAP-C02 Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-sap-pro/AWS-Certified-Solutions-Architect-Professional_Exam-Guide.pdf

Summary — Migration Assessment Pro-Depth Cheat Sheet

• CAF 6 perspectives: Business, People, Governance, Platform, Security, Operations — map pain points to primary owner.
• MAP 3 phases: Assess (is it worth it?) → Mobilize (are we ready?) → Migrate (execute). Do not skip Mobilize.
• 7 Rs decision matrix: Retire (no usage), Retain (blocker), Relocate (VMware lift), Rehost (EC2 as-is), Replatform (managed-service swap), Repurchase (SaaS), Refactor (cloud-native rebuild). Typical portfolio split: 10-20% Retire, 5-10% Retain, 5-15% Relocate, 50-70% Rehost, 15-25% Replatform, 5-10% Repurchase, 5% Refactor-in-window.
• Discovery: Agentless Connector (VMware breadth, no process data) vs Agent (process-level dependency, any hypervisor). Use both.
• Migration Evaluator: Portfolio TCO engine, gate for MAP funding, CFO-defensible business case. Not Pricing Calculator.
• MPA: Per-app scoring across criticality, complexity, readiness, dependencies. Output drives wave assignment.
• Wave planning: Foundation (Wave 0) → Pilot (Wave 1) → Dependency-ordered business waves → Complex/high-compliance last. Affinity groups migrate together.
• Migration Hub: Single-pane portfolio view, integrates ADS + MGN + DMS + partner tools, Orchestrator runs cutover runbooks.
• Governance: Control Tower + Organizations SCPs + Config Rules + Security Hub — layered guardrails per wave.
• Change management: CCoE formation, cloud fluency training, hypercare post-cutover.

Master migration assessment and you master 20% of the SAP-C02 exam (Domain 4) plus a sizable portion of Domain 1 (organizational complexity) and Domain 3 (continuous improvement). The 7Rs decision matrix, CAF perspectives, MAP phases, and wave planning primitives are load-bearing knowledge for every enterprise migration question the exam will throw at you.