Large cloud migrations are not simply a sequence of server moves. They are portfolio programs in which business criticality, application dependencies, migration strategy, landing-zone readiness, data movement, cutover risk, and operating-model change all have to converge. The AWS SAP-C02 exam tests that systems-level judgment rather than a memorized list of migration tools.
As of October 2026, SAP-C02 is in its final testing window: AWS says the last day to take SAP-C02 is November 16, 2026, while registration for SAP-C03 opens October 27. That makes the architecture principles especially important because they survive the exam-version transition even as individual objectives and service emphasis evolve.
The right way to think about migration at scale is to turn a heterogeneous estate into controlled waves. Each wave should have a defensible migration strategy, an understood dependency graph, a prepared target environment, measurable acceptance criteria, and a rollback or containment plan.
Start with portfolio discovery, not a preferred migration tool
A migration program fails early when the target architecture is selected before the source estate is understood. Discovery must establish what applications exist, who owns them, what they depend on, which data stores they use, what performance they actually require, and which contractual or regulatory constraints shape the move.
Inventory is only the first layer. A server list does not reveal that a finance application calls an authentication service, reads a file share, publishes to a message broker, and depends on a batch job that runs from a different data center. Dependencies determine wave boundaries. Moving a server without its dependency chain can produce a technically successful replication and an operationally broken application.
For a professional-level architect, uncertainty is itself a design input. Systems with poor documentation need discovery, instrumentation, and stakeholder validation before they are placed into an aggressive migration wave. Critical workloads with unverified dependencies should not be treated like low-risk stateless services.
Use the migration strategy to control how much changes at once
AWS commonly frames migration choices through the seven Rs: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. The important SAP-C02 skill is not reciting the labels; it is recognizing how each choice changes delivery risk, time, operational benefit, and required testing.
Rehosting minimizes application change and can be appropriate when the business priority is exiting a data center quickly. Replatforming accepts limited architectural change to gain managed-service benefits, such as moving a self-managed database to Amazon RDS. Refactoring can create the largest long-term improvement but also expands the amount of code, data, deployment, and behavior that must be validated.
At large scale, modernization is often sequenced after relocation rather than forced into the same event. That keeps migration waves predictable and avoids combining infrastructure change, application redesign, organizational retraining, and production cutover into one unmanageable risk envelope.
Build the landing zone before application waves arrive
Migration at scale requires a target environment that can accept workloads repeatedly. Account vending, network connectivity, identity federation, centralized logging, encryption standards, security controls, tagging, backup expectations, and cost ownership should exist before hundreds of application teams begin provisioning independently.
This is where the AWS architecture certifications becomes relevant: professional architecture is as much about the platform surrounding an application as it is about the application itself. A landing zone reduces variation so each migration wave does not reinvent basic governance.
Networking deserves particular attention. Address-space collisions, incomplete DNS design, insufficient Direct Connect or VPN capacity, missing routes, and overlooked firewall dependencies can stall a migration even when replication is healthy. Shared services must be capacity-tested for the number of workloads expected after cutover, not only for a pilot.
Choose migration tooling by workload and target state
AWS Application Migration Service is the primary AWS service for many lift-and-shift server migrations because it continuously replicates source servers and supports test and cutover launches. Database moves often require a different plan: AWS Database Migration Service can support database migration and change data capture, while native database tools may still be appropriate for engine-specific requirements.
AWS Migration Hub historically provided migration tracking and strategy capabilities, but AWS stopped accepting new Migration Hub customers in November 2025 and directs new customers toward AWS Transform for next-generation migration and modernization workflows. That change is a useful reminder not to anchor architecture knowledge to a product name when the durable requirement is portfolio discovery, orchestration, dependency management, and migration-wave control.
Tool choice should follow the migration pattern. A rehost, a database replatform, a VMware relocation, and a container modernization problem have different technical constraints. Using one tool everywhere usually transfers complexity rather than reducing it.
Design migration waves around dependency and business risk
A good wave is small enough to control and large enough to create operational momentum. Group applications that share dependencies, owners, maintenance windows, or technical migration patterns. Separate systems whose failure would create an unacceptable compound business impact.
Early waves should validate the factory itself: discovery quality, landing-zone provisioning, connectivity, security controls, replication, test execution, cutover communication, monitoring, and support handoff. The goal is not merely to prove that one application can move. It is to prove that the organization can repeat the process.
Wave planning also needs sequence logic. Shared identity, DNS, integration services, databases, and network dependencies may need to move before the applications that consume them—or remain temporarily connected to the source environment through a carefully designed hybrid model. The cutover plan should make that dependency order explicit.
Data movement often determines the real critical path
Compute can be relatively easy to replicate; data consistency is usually harder. Large databases, file systems, and object stores must be moved while controlling change, bandwidth, downtime, validation, and rollback. The architecture should identify whether the application can tolerate a long outage, requires continuous replication, or needs a final delta synchronization during cutover.
Database engine changes add another dimension. Moving a database unchanged and changing engines are different projects. Schema conversion, stored procedures, indexing, data types, application drivers, and performance behavior can all change during a heterogeneous migration. Treating those as mere data-copy tasks creates hidden risk.
Testing must prove not only that data arrived but that the application behaves correctly against it. Reconciliation, transaction counts, checksums where appropriate, business reports, and application-level smoke tests are stronger evidence than a green replication status.
Cutover is an operational event, not just a technical switch
A production cutover needs entry criteria: replication lag within tolerance, target monitoring active, backups verified, security findings reviewed, support staff available, DNS or routing changes prepared, and business owners ready to validate the service. If those conditions are not met, the safest decision may be to delay rather than force the window.
Rollback also needs to be designed before the change. The longer both source and target accept writes independently, the harder a rollback becomes because data diverges. Some migrations can roll back by routing traffic to the source; others need explicit reverse replication or a forward-fix strategy.
Post-cutover validation should watch functional errors, latency, queue depth, database load, network paths, authentication, external integrations, and cost. A service that is reachable is not necessarily healthy.
Modernization should be driven by business and operational evidence
After a workload is stable in AWS, modernization choices become easier to evaluate with real operating data. A monolithic application might move from fixed EC2 capacity to containers, serverless components, managed databases, asynchronous messaging, or a more event-driven design. The objective is not to use more AWS services; it is to improve a measurable constraint.
That constraint may be deployment frequency, recovery time, operational effort, licensing cost, scaling limits, or security exposure. Modernization should remove a real bottleneck or reduce lifecycle cost. Otherwise, architectural complexity can rise without delivering meaningful value.
The broader cloud architecture certification perspective reinforces this: migration and modernization are architecture decisions shaped by reliability, security, performance, operations, and cost at the same time.
SAP-C02 migration scenarios reward sequence and tradeoff thinking
When a scenario describes hundreds of applications, ask what must be standardized centrally, what must be discovered per workload, what can be automated, and where business risk forces a more conservative path. A correct answer usually aligns the migration method with the workload rather than selecting the newest service.
Also separate migration from modernization. If the requirement is to exit a facility in six months, a large refactor may be the wrong first move even if it is the ideal long-term architecture. If the workload is already constrained by an unsupported database or licensing model, replatforming during the move may be justified.
That distinction is what makes migration at scale an architecture discipline. The solution must move an estate while preserving control, then create a foundation that supports modernization after the deadline pressure is gone.
Migration factory metrics reveal whether the program can scale
A mature migration program measures more than servers moved. Track discovery completion, dependency validation, replication readiness, test pass rate, cutover duration, rollback frequency, defect escape, and time from wave approval to production acceptance. These measures expose bottlenecks in the process itself.
They also help distinguish a workload problem from a factory problem. If many unrelated applications are delayed by account provisioning or firewall approvals, the constraint is not the applications. The shared platform or governance workflow needs improvement before the next wave increases volume.