Seven Migration Strategies (7 Rs) and Workload Selection

Why strategy selection is scored as architecture

SAP-C02 Domain 4, Accelerate Workload Migration and Modernization, is 20% of scored content. Task 4.1 asks you to assess existing workloads and select a migration approach. Independent SAP-C02 study material by OpenExamPrep treats that task as a portfolio decision, not as a single “move everything cloud-native” slide. AWS currently names seven migration strategies for moving applications to the AWS Cloud, collectively the 7 Rs: rehost, relocate, replatform, repurchase, refactor or re-architect, retire, and retain. You assign an R per workload, then you defend it with constraints: data-center lease dates, licensing, data residency, coupling, skills, and operational risk.

Consider Meridian Health Systems, a fictional 200-application portfolio used throughout this chapter: clinic portals, a claims mainframe, a commercial off-the-shelf (COTS) human-resources and payroll suite, departmental databases, VMware clusters, and a handful of unused virtual machines. Leadership wants every system “cloud-native by fiscal year-end.” That sentence is a wish, not a plan. If you refactor all 200 applications during the move, AWS Prescriptive Guidance for large migrations tells you that you chose the most complex strategy at the worst possible scale. Common strategies for a large migration are rehost, replatform, relocate, and retire. Refactor waits until after the move unless the other strategies are not an acceptable option.

Official 7 R names and use cases in this section come from AWS Prescriptive Guidance (“About the migration strategies”). Organizational readiness language comes from the AWS Cloud Adoption Framework (AWS CAF). This chapter does not claim AWS approval, partnership, or exact equivalence with AWS training.

The seven strategies AWS currently names

A migration strategy is the approach used to migrate a workload into the AWS Cloud. Nicknames in parentheses appear in conversation and in some stems; reason with the official R name.

Rehost (lift and shift)

Rehost moves applications from the source environment to AWS without making changes to the application. AWS Prescriptive Guidance emphasizes that you can migrate a large number of machines from physical, virtual, or another cloud without treating compatibility, long cutover windows, or long-distance replication as reasons to abandon the strategy. The application continues to serve users while replication runs; downtime is a cutover choice, not a rewrite. Rehost does not implement cloud optimizations that save money on day one. The Professional tradeoff is speed and scale now, then optimize after the estate is in AWS—because integrating AWS services is easier once the workload already runs in the cloud.

Current Prescriptive Guidance lists automation options including AWS Transform MGN, the AWS Cloud Migration Factory Solution, and VM Import/Export. AWS Application Migration Service (Application Migration Service) remains the lift-and-shift service AWS Migration Hub documents as the primary rehost tool for existing Hub customers. Deep cutover mechanics belong in the next chapter. Here you only need to know rehost is the factory-scale default for many of Meridian’s 200 applications.

Relocate

Relocate transfers a large number of servers, comprising one or more applications, from an on-premises platform to a cloud version of that platform. You can also relocate instances or objects to a different virtual private cloud (VPC), AWS Region, or AWS account. AWS’s published example is moving an Amazon RDS DB instance to another VPC or account. Relocate does not require purchasing new hardware, rewriting applications, or modifying existing operations. AWS describes it as the quickest way to operate the workload in the cloud because it does not change the overall application architecture.

Older study notes treat relocate almost exclusively as a hypervisor-level move of VMware virtual machines onto a VMware-on-AWS style platform. That story is still a relocate, not a rehost onto Amazon EC2. Rehost to EC2 changes the landing compute even when the application binary is unchanged. Do not mix the two names in a stem that still runs vSphere day-to-day after the move.

Replatform (lift and reshape)

Replatform moves the application and introduces some optimization so it operates efficiently, reduces cost, or uses a cloud capability. AWS’s canonical example is Microsoft SQL Server on a virtual machine to Amazon RDS for SQL Server. Other published use cases include moving to a fully managed or serverless service, upgrading an operating system for security and compliance, using AWS Graviton processors, moving Windows/.NET Framework workloads toward Linux/.NET with help from Porting Assistant for .NET, and containerizing virtual machines without code changes using AWS App2Container. Replatform is not a greenfield rewrite. If the stem requires a new data model, bounded contexts, and event-driven services, you have left replatform and entered refactor.

Repurchase (drop and shop)

Repurchase replaces the application with a different version or product that should provide more business value than the on-premises application: access from anywhere, no infrastructure to maintain, and pay-as-you-go pricing. AWS lists common use cases: moving from a traditional license to software as a service (SaaS); taking the vendor’s latest cloud version or a third-party equivalent; and replacing a custom application with vendor SaaS so you avoid recoding. Assess security and compliance before you buy. After purchase you train users, migrate data, integrate authentication (for example Microsoft Active Directory), and configure networking. The vendor typically helps with those steps.

Meridian’s COTS HR and payroll suite is the repurchase candidate: the vendor already sells a SaaS edition, the on-premises version is approaching end of support, and rewriting payroll is not a year-one migration-factory task.

Refactor or re-architect

Refactor or re-architect moves an application and modifies its architecture to take full advantage of cloud-native features for agility, performance, and scalability. AWS lists strong business demand as the driver. Published use cases include a legacy mainframe that can no longer meet demand or is too expensive to maintain; a monolith that blocks product delivery; a legacy application nobody can maintain or whose source is missing; software that is difficult to test; and a database that must split tables (for example patient-identifiable tables retained on premises) while other tables move.

AWS is explicit: refactoring is the most complex and costly strategy because you modernize during the migration. For a large migration, refactor only when the other migration strategies are not an acceptable option. Prefer rehost, relocate, or replatform, then modernize after the migration is complete.

Retire

Retire decommissions or archives an application so you can shut down the servers in that stack. Use cases include no business value in keeping or moving the application, eliminating hosting cost, and reducing security risk from unsupported operating-system components. Discovery data helps find zombie applications (AWS example: average CPU and memory usage below 5 percent) and idle applications (example: average CPU and memory between 5 and 20 percent over 90 days). Another published signal is no inbound connection for the last 90 days. Retire is a first-class R. It shrinks the denominator of the 200-application program and removes patching debt you would otherwise replicate in Amazon EC2.

Retain

Retain keeps the application in the source environment, or postpones migration. You may migrate it later. AWS use cases that map directly to Professional stems include security and compliance such as data-residency requirements; high risk that needs a detailed assessment and plan; dependencies on applications that must move first; a system recently upgraded, so you wait for the next technical refresh; few internal users and no business value to move; waiting for a vendor SaaS release; unresolved physical dependencies such as specialized plant-floor hardware; mainframe or mid-range applications and non-x86 Unix that need careful assessment (AWS examples include IBM AS/400 and Oracle Solaris); and keeping zombie or idle systems in the source environment rather than paying to move them.

Meridian’s claims mainframe is retain-until-assessed. It is not “rehost onto a single Amazon EC2 instance this weekend.” A later dedicated program may still refactor or replatform that estate. Task 4.1 rewards naming retain when the stem has not finished that assessment.

CAF perspectives: readiness is not an eighth R

The AWS Cloud Adoption Framework (AWS CAF) groups organizational capabilities into six perspectives: Business, People, Governance, Platform, Security, and Operations. CAF is how AWS describes cloud readiness and transformation planning. It is not a seventh-plus R, and this OpenExamPrep material does not treat CAF as a partnership badge.

AWS CAF’s published transformation phases are Envision, Align, Launch, and Scale. Align is AWS’s official phase name for identifying capability gaps and cross-organizational dependencies. Large-migration delivery still uses the assess, mobilize, and migrate sequence from AWS Prescriptive Guidance: assess the portfolio, mobilize people and the landing zone, then migrate in waves.

A 7 R chosen without Platform and Security is a cutover incident. A 7 R chosen without Business and Governance is a science project that finance will not fund twice.

Selecting workloads in the 200-application portfolio

Selection is a decision tree, not a popularity contest.

1. Inventory and utilization first. You cannot retire zombies you have not measured, and you cannot rehost what you have not grouped into applications. That is the next section’s tooling.
2. Score business value against technical difficulty. Easy, noncritical applications prove the factory. Hard, critical systems need dependency maps and a retain or targeted-refactor path—not wave 1 heroics.
3. Honor coupling. If the COTS HR suite talks to an identity directory that also serves the clinic portal, repurchase of HR still waits on identity design.
4. Honor constraints AWS lists for retain: residency, physical hardware, mainframe and mid-range, recent capital refresh, missing SaaS offering.
5. Prefer factory Rs at scale: rehost, replatform, relocate, retire. Use repurchase where the vendor already solved the problem. Use refactor as a targeted exception.

A first-pass Meridian allocation might look like: 20 retire (idle departmental boxes), 15 retain (mainframe, lab instruments, a residency-bound imaging archive), 8 repurchase (COTS HR, email, IT service desk), 120 rehost (Windows and Linux line-of-business), 30 replatform (databases to Amazon RDS, a few containers), 5 relocate (VMware clusters that must keep a VMware control plane), 2 refactor (only the patient-portal bottleneck that cannot meet product velocity—and even those two may rehost first if the data-center exit is the binding constraint). Those counts are a teaching sketch, not an AWS quota. The exam will change the mix. Your job is to name the R that matches the constraint.

Strategy traps

1. One R for the entire 200-application estate.
2. Refactor-at-scale during a large migration.
3. Calling every Amazon EC2 move “relocate.”
4. Rehosting a mainframe because “retain is not cloud.”
5. Rewriting COTS instead of repurchase when the vendor SaaS exists.
6. Forgetting retire, which shrinks scope and risk.
7. Treating CAF perspectives as optional slides after the first cutover.
8. Inventing an unpublished AWS exam pass-rate percentage as a migration success metric. AWS does not publish exam-level pass-rate percentages.