Select workloads, sequence migration, design target architecture, manage cutover, and choose modernization opportunities from business and technical evidence.
Assess portfolio dependencies, business value, constraints, readiness, compliance, data, licensing, and operational ownership.
Choose and sequence migration strategies, tooling, waves, data transfer, testing, cutover, rollback, and stakeholder decisions.
Translate source dependencies and future requirements into a secure, resilient, operable, and cost-aware AWS target.
Evaluate managed, serverless, container, event-driven, data, integration, and operating-model changes after business constraints are understood.
Migration is a business and operating-model change expressed through technology. Begin with outcomes, constraints, dependencies, data, licensing, risk, timeline, and ownership. Do not choose a migration tool or modernization target before understanding the workload and its surrounding processes.
Separate the decision to move from the decision to modernize. Rehosting can reduce data-center urgency while preserving technical debt. Refactoring during a fixed exit deadline can expand risk. A phased strategy may rehost first, stabilize operations, then modernize components with clear business value.
| Objective | Required judgment | Proof |
|---|---|---|
| 4.1 Select workloads and processes for migration | Assess portfolio dependencies, value, readiness, compliance, data, licensing, and ownership | Each workload has a disposition, owner, dependency map, and decision rationale |
| 4.2 Select migration approaches | Choose strategies, tools, waves, data movement, testing, cutover, rollback, and stakeholders | A pilot and wave plan demonstrate repeatable migration and recovery |
| 4.3 Design the target architecture | Translate source behavior and future requirements into secure, resilient, operable AWS design | Target acceptance tests cover business, data, security, performance, and recovery |
| 4.4 Identify modernization opportunities | Evaluate managed, serverless, container, event, data, integration, and operating changes | Modernization has a measurable benefit and an owned transition plan |
Inventory applications, servers, databases, data stores, network flows, identity, certificates, batch jobs, schedules, interfaces, users, owners, support status, licensing, compliance, availability, RTO/RPO, performance, cost, and business calendars. Use automated discovery and existing configuration sources, then validate with application owners. Technical scans rarely capture manual processes, informal dependencies, peak business events, or contractual constraints.
Map dependencies in both directions. A low-priority application can block a critical one through DNS, identity, shared database, file transfer, license server, message broker, or operator workflow. Identify latency-sensitive coupling and data consistency. Decide whether dependencies move in the same wave, use temporary connectivity, or are decoupled before migration.
Assess organization readiness: landing zone, identity, network, security, logging, backup, deployment, operations, skills, support, FinOps, and incident response. Migrating faster than the platform can govern creates rework and risk.
Use the common migration dispositions as decision vocabulary: retire, retain, relocate, rehost, replatform, repurchase, or refactor/re-architect. Names vary across guidance, so focus on what changes and who operates the result. Retire unused systems after confirming dependencies and records obligations. Retain when constraints or value do not justify movement. Rehost changes hosting with minimal application change. Replatform changes selected components. Repurchase adopts a different product. Refactor changes architecture for a justified outcome. Relocate moves supported virtualized environments with minimal conversion.
Select tools by source, target, downtime, change tolerance, data volume, network, validation, and rollback. AWS Application Migration Service supports eligible server migrations. AWS Database Migration Service can move and replicate supported databases; AWS Schema Conversion Tool or related conversion capabilities help when engines differ. DataSync, Snow Family, Transfer Family, storage gateways, backup, replication, and native database tools serve different transfer constraints. A tool does not choose the cutover or validate application correctness.
Build waves from business priority, dependencies, pattern repeatability, risk, team capacity, and change windows. Start with a pilot representative enough to test the landing zone, factory, monitoring, support, security, and rollback. Avoid making the pilot so trivial that it proves nothing.
Define entry and exit criteria. Rehearse data synchronization, DNS or routing changes, identity, certificates, secrets, jobs, integrations, monitoring, backup, recovery, performance, security, and user acceptance. Set freeze and rollback thresholds. Communicate owners and decision times.
Do not reproduce source flaws automatically. Re-evaluate availability, scaling, data, access, logging, network, deployment, recovery, and support. Preserve necessary behavior while replacing assumptions tied to the old environment. Use infrastructure as code and approved account patterns.
Choose a data target from access patterns, transactions, compatibility, latency, analytics, and operations. Size compute from measured workload and test results. Plan quotas and scaling. Use Multi-AZ or cross-Region patterns only where business requirements justify them. Establish backups and restore tests before cutover. Protect migration roles and replication channels because they often receive broad source and target access.
Modernize for measurable value: faster change, reduced operational burden, elasticity, resilience, cost, supportability, security, or new product capability. Containers can standardize packaging but retain cluster and application responsibilities. Serverless can remove server management and scale by demand, but requires event, quota, latency, observability, and service-limit design. Managed databases reduce engine operations but may require compatibility and behavior change. Event-driven architecture can decouple teams and absorb bursts but introduces asynchronous consistency, replay, ordering, and idempotency.
Use a strangler pattern to replace bounded capabilities over time. Establish routing, data ownership, compatibility, observability, and rollback between old and new. Avoid a distributed monolith where services deploy separately but share synchronous dependencies and one database. Modernization includes team ownership, CI/CD, security, support, and cost—not only runtime selection.
The SAP-C02 guide lists emerging AI topics as possible unscored pretest content. Keep those separate from the scored four-domain blueprint and do not let an emerging feature displace core migration reasoning.
| Constraint | Likely strategy | Caution |
|---|---|---|
| Fixed data-center exit, low change tolerance | Rehost or relocate, then optimize | Preserve a modernization backlog and operating plan |
| Unsupported commercial platform with SaaS alternative | Repurchase | Data migration, integration, contract, and exit risk |
| Database engine change for managed value | Replatform or refactor | Schema, feature, performance, and cutover compatibility |
| Elastic event workload | Serverless/event modernization | Quotas, idempotency, ordering, and observability |
| Stable application with no migration value | Retain | Record owner, risk, lifecycle, and revisit trigger |
| No business use | Retire | Confirm dependencies, legal hold, retention, and users |
A company must leave a data center in nine months. It has 180 applications, shared Active Directory and databases, several unsupported operating systems, a 10 TB transactional database, and limited cloud operations experience.
