4.1 Migration Assessment
Official task mapping
SAP-C02 task 4.1: Portfolio and asset knowledge; migration strategy, wave planning and TCO assessment. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review migration overview, Migration Evaluator and discovery availability. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Assess before moving
Inventory applications, owners, dependencies, utilization, licensing, compliance, business deadlines and recovery objectives. Select among rehost, replatform, refactor, repurchase, relocate, retain and retire according to constraints. These are strategy categories, not a mandatory linear sequence.
Map dependency groups into migration waves. Compare TCO using infrastructure, licenses, migration effort, parallel operation, staff effort and residual data-center obligations. A discovery tool can supply evidence; it cannot infer every business-critical dependency or authorize retirement.
Application Discovery Service closed to new customers on November 7, 2025; existing customers retain documented access. AWS recommends Transform for new assessment needs. The retired Discovery Connector is distinct from Agentless Collector. Migration Evaluator is agentless assessment, not an invented process-telemetry agent. Treat historical exam service mentions separately from current procurement availability.
Seven-strategy comparison
| Strategy | Change | Suitable trigger | Key constraint |
|---|---|---|---|
| Rehost | Move infrastructure with limited application change | Tight deadline | Existing inefficiency/compatibility can remain |
| Replatform | Selectively change platform | Reduce operations with manageable change | Engine/runtime/application compatibility |
| Refactor | Redesign application/data boundaries | Required agility or scale | Delivery effort and risk |
| Repurchase | Adopt replacement product/SaaS | Replace undifferentiated capability | Data export, integration and vendor terms |
| Relocate | Move compatible platform estate | Preserve operating model | Current offering/channel and support |
| Retain | Keep for now | Dependency/compliance/business constraint | Explicit revisit date and residual cost |
| Retire | Decommission | Confirmed no longer required | Owner approval, dependencies and retention |
Retain is a decision, not “do nothing forever”; retire requires evidence, not low utilization alone. Rehost does not guarantee zero application changes.
Where available to existing customers, Discovery Agent and Agentless Collector supply different datasets; dependency/process telemetry is not identical. Migration Hub’s tracking/home-Region concepts must be checked against current customer availability rather than recommending it unconditionally to a new customer. Transform and Migration Evaluator serve current assessment needs under their respective requirements.
For wave planning, score business deadline, complexity, dependency strength and confidence in the inventory. Keep a low-risk pilot representative of real constraints rather than choosing only an empty VM that proves nothing about database/identity migration.
Scenario and rationale
A business must exit a data center in six months. Its payroll application has unsupported extensions, a replaceable collaboration tool and a low-use reporting system. Rehost or retain-with-exception decisions may fit payroll’s deadline; repurchase may suit collaboration; retire reporting only after confirming users/retention and dependencies.
Reject refactoring every application first: it threatens the deadline and may not create value. Reject assuming an idle server has no business dependency; month-end jobs can be missed by short collection windows.
Practice drill
Use the six synthetic profiles below, or an authorized inventory, to choose a 7R strategy and justify it against deadlines, compatibility and cost. Draw dependency groups, propose two waves and identify a rollback boundary. Build a TCO sensitivity table for utilization, license portability and parallel-running duration. No collector installation or shutdown is performed.
Six-profile self-study inventory
| Application | Constraints and evidence | Dependency/recovery boundary |
|---|---|---|
| Payroll | Six-month exit; unsupported database extension; monthly peak absent from two-week telemetry; vendor decision due in one month | Reads identity; retention obligations; payroll owner must validate engine/support before a rehost or exception |
| Identity | Supported directory stack; all apps depend on it; signed-in sessions and credentials cannot simply be copied blindly | Establish target connectivity/trust and recovery before dependent cutovers |
| Orders | Supported PostgreSQL, no required extensions; managed-engine compatibility test available; RPO 5 min/RTO 1 h | Identity and nightly billing export; CDC/validation and schema/write rollback boundaries |
| Analytics | Consumes Orders exports; nightly batch tolerates retries; management wants elastic scale, but redesign effort is four months | Keep export format compatible; replay from retained inputs; do not put critical Orders cutover behind refactoring |
| Collaboration | SaaS replacement approved in principle; SSO/export/legal-retention review incomplete | Repurchase only after export/SSO/retention acceptance; preserve rollback/export evidence |
| Legacy reporting | 2% average CPU; owner unknown; possible quarter-end job; two-week sample is not proof of non-use | Retain pending owner/dependency/retention evidence; retire only after authorized sign-off |
One defensible answer: resolve Identity connectivity in a pilot/foundation phase; put Orders plus its compatible Analytics export interface in wave 1; put Payroll (after vendor/peak validation) and Collaboration (after SaaS acceptance) in wave 2. Retain reporting with an owner/revisit deadline. Replatform Orders only after compatibility testing; retain Analytics’ current processing initially rather than forcing refactor before the exit. Other answers must explain equivalent constraints; “all six rehost” and “idle reporting means retire” are not justified by this inventory.
For a hypothetical us-east-1 study dated 2026-10-12, assume target recurring cost $8,000/month, one-time migration work $30,000 and source cost $10,000/month until exit. A 12-month plan with two overlap months costs $96,000 + $30,000 + $20,000 = $146,000; four overlap months give $166,000. Add license portability and residual data-center obligations explicitly rather than promising those figures are total savings. For Orders, stop writes and verify CDC catch-up/data correctness before traffic cutover; returning traffic alone does not undo writes already accepted on the target.
References
- Official Domain 4 task guide
- Migration strategies and 7Rs
- Discovery availability
- Migration Evaluator capabilities
Return to Domain 4. The drill is proposed study work, not a claim of a completed deployment.