Migration Strategy Framework — The 7 Rs & Migration Hub
Recap — Where Phase 3 Left Us
Phase 3 closed on a synthesis day that pulled together three threads that had been running in parallel for six weeks: observability, chaos engineering, and disaster-recovery pattern selection. The observability thread ended with X-Ray's service map as the tool that isolates a slow hop inside a distributed call chain, and with the recognition that internal metrics alone cannot tell you whether a user flow actually works. The chaos thread ended with FIS experiment templates and their mandatory stop conditions, and with the Game Day as the mechanism that converts a documented runbook into a tested fact. The recovery thread ended with the backup/restore through active-active spectrum, and with Route 53 ARC as the control plane that makes failover deterministic rather than ad hoc.
Today extends that material rather than replacing it. Everything Phase 3 built assumed the workload was already running on AWS and needed to survive failure there. Phase 4 opens the question that comes before all of it: how does a workload get onto AWS in the first place, and who decides which of the seven migration strategies applies to it? The same discipline that produced tested recovery procedures now has to produce a defensible per-application migration decision — and a system of record for tracking it.
Foundations You'll Need Today
This lesson is about deciding what to do with each application in a company's estate as it moves to AWS. That decision uses a handful of terms that the rest of the curriculum treats as already known, so it is worth pinning them down first.
Applications, Workloads and Portfolios
An application here means a distinct piece of software that does a job for the business — a customer portal, an internal reporting tool, a payroll system. A workload is the same idea viewed from the infrastructure side: the servers, databases, and supporting pieces that together make that application run. A portfolio is simply the full collection of applications a company owns. Migration planning happens at the portfolio level because a company rarely moves one application in isolation; it moves dozens or hundreds, and each one needs its own decision about how it will get to AWS.
EC2 Instances and AMIs
An EC2 instance is a virtual server running in AWS. It behaves like a physical server — it has an operating system, CPU, memory, and disk — but it exists as software on AWS hardware rather than as a machine in a rack. An AMI (Amazon Machine Image) is the template an instance is created from: it bundles the operating system and any pre-installed software, so launching an instance from an AMI produces a server that is already configured the way you want. When this lesson says a server is "converted to a native EC2 instance or AMI," it means the original server's contents are repackaged so AWS can run them directly, rather than running them inside whatever platform they came from.
Managed Services vs Self-Managed
A self-managed system is one where you install, patch, back up, and scale the software yourself — for example, running MySQL on a server you control. A managed service is one where AWS operates the underlying software for you and exposes only the parts you need to configure; Amazon RDS is the managed version of MySQL, so AWS handles patching, backups, and failover while you still design your tables and queries. The distinction matters because moving from self-managed to managed is a real change in who carries the operational burden, even when the application's own code does not change at all.
Virtualization, Hypervisors and VMware
Virtualization is the technique of running multiple virtual machines on one physical machine, each believing it has its own hardware. The software layer that makes this possible is the hypervisor. VMware is the most widely used commercial hypervisor product, and many companies run their entire data center on it. A virtual machine's format is the specific file layout the hypervisor uses to store that machine — and formats are not interchangeable, which is why moving a VMware virtual machine to AWS normally requires converting it into something AWS can run natively. That conversion step is exactly what the Relocate strategy avoids.
SaaS
SaaS (Software as a Service) means buying a piece of software as a subscription that the vendor hosts and operates, rather than running your own copy. Salesforce, Workday, and Microsoft 365 are familiar examples. When a company replaces its own application with a SaaS product, the application itself stops existing in its current form — what remains is the data, which has to be exported from the old system and loaded into the vendor's. That is why replacing an application with SaaS is a fundamentally different kind of migration from moving it to AWS unchanged.
With that grounding, here is why the 7 Rs exist and what problem they actually solve.
1. Why This Is on the Exam
The 7 Rs are not a taxonomy exercise. They are the vocabulary SAP-C02 uses to describe the single most common class of scenario in Domain 3 (Migration and Modernization): a company with a portfolio of applications, a hard constraint, and a set of plausible-sounding migration options that differ mainly in how much work they require and how much of the existing application they preserve. The exam does not usually ask you to name the seven strategies. It gives you a business constraint — a data center lease expiring, a licensing dispute, a compliance requirement, a team with no Kubernetes experience — and asks which strategy is appropriate for a specific application under that constraint.
That framing matters because the strategies are not ranked. There is no "best" R. Rehost is the right answer when the deadline is the binding constraint and the application is not worth touching. Refactor is the right answer when the application is strategically important and the business is willing to fund a rewrite. Retain is the right answer when neither is true yet. The exam rewards candidates who can read a constraint and select the strategy that satisfies it at the lowest cost and risk, and it penalizes candidates who reflexively pick the most modern-sounding option.
Migration Hub sits alongside the 7 Rs because the exam also tests the operational question: once you have decided on a strategy per application, how do you track hundreds of applications across multiple migration tools and multiple waves? Migration Hub is the answer, and it appears in scenarios where the requirement is a single view of migration status across a portfolio rather than a single application's cutover mechanics. The two topics belong together because the 7 Rs produce the plan and Migration Hub is where the plan's execution is observed.
2. How the Framework Actually Works
The 7 Rs are best understood as a decision procedure applied per application, not per data center. Each application in the portfolio gets classified independently, and the classification is driven by two questions asked in order. First: does this application need to exist at all in the target state? If the answer is no, the strategy is Retire and the work is decommissioning rather than migrating. If the answer is yes but the timing is wrong — a licensing negotiation is open, a vendor contract runs for another eighteen months, a replacement system is mid-build — the strategy is Retain, which is an explicit decision to do nothing yet rather than an oversight. Retain is the strategy most often forgotten in practice and most often tested on the exam, because candidates tend to assume every application must move.
Second, for applications that do need to exist and do need to move: how much of the application is allowed to change? The answer to that question splits the remaining five strategies along a spectrum of change. Rehost changes nothing about the application — the same binaries, the same OS, the same configuration, moved to EC2. Relocate also changes nothing about the application, but moves it without converting it out of its existing virtualization format, which in AWS terms means VMware workloads landing on VMware Cloud on AWS. Repurchase changes the application entirely by replacing it with a SaaS product, so the "migration" is really a data migration plus a decommissioning. Replatform changes the application's runtime substrate without changing its code — self-managed MySQL becomes RDS, a self-managed Tomcat cluster becomes Elastic Beanstalk. Refactor changes the application's architecture, typically decomposing a monolith into services or moving to serverless.
The ordering of that spectrum is the useful part. Rehost and Relocate are the cheapest per application and the fastest to execute, and they preserve technical debt along with the application. Refactor is the most expensive and slowest, and it is the only strategy that removes technical debt. Replatform sits in the middle and is the strategy most often misapplied, because "lift-tinker-and-shift" sounds like a small change and frequently is not — moving a database engine is a schema conversion project, not a configuration change. The exam's scenario language usually signals the intended strategy through the constraint it names: a deadline signals Rehost, a licensing blocker signals Retain or Repurchase, a desire to reduce operational overhead without a rewrite signals Replatform, and a strategic modernization mandate signals Refactor.
3. The Core Decision Boundary
Every 7 Rs scenario reduces to one fork: is the binding constraint time, or is it the value of the application's future state? When time binds, the strategies that preserve the application win, because they require the least engineering work per application and can be executed in parallel across a large portfolio. When future-state value binds, the strategies that change the application win, because preserving a poorly-architected application into the cloud simply relocates the problem. The exam rarely presents a scenario where both constraints are equally weighted; one of them is always the stated driver, and the correct answer follows from identifying which.
The second-order fork is whether the application is worth the change. A legacy internal reporting tool that runs once a month and is used by four people is not a Refactor candidate regardless of how much technical debt it carries, because the business value of modernizing it does not cover the cost. The same application under a data center exit deadline is a Rehost candidate, and under a vendor end-of-life notice is a Repurchase candidate. The strategy follows the application's role in the business, not its technical quality.
| Strategy | What changes | Typical driver | Relative effort |
|---|---|---|---|
| Retire | Nothing — the app is decommissioned | Redundant or unused application | Lowest |
| Retain | Nothing — the app stays where it is | Licensing, contract, or timing blocker | None yet |
| Rehost | Hosting location only | Deadline, data center exit | Low |
| Relocate | Hosting platform, not the VM format | VMware estate, no conversion appetite | Low |
| Repurchase | The application itself (replaced by SaaS) | Vendor EOL, commodity function | Medium |
| Replatform | Runtime substrate, not the code | Reduce ops overhead without a rewrite | Medium |
| Refactor | Architecture and code | Strategic modernization mandate | Highest |
4. What Each Strategy Costs You
The cost of a migration strategy is not only the engineering hours it consumes. Each strategy carries a distinct set of downstream consequences that outlive the migration itself, and those consequences are what the exam is usually probing when it presents two strategies that both technically satisfy the stated constraint. Rehost is cheap to execute and expensive to operate, because the application arrives on AWS with all of its original operational characteristics intact — the same manual patching, the same single-instance database, the same lack of autoscaling. The migration cost is low and the run cost is high, and the exam expects you to recognize that tradeoff rather than treat Rehost as free.
Relocate carries the same operational profile as Rehost but adds a licensing dimension: VMware Cloud on AWS is a paid service with its own commercial terms, and the strategy only makes sense when the organization already has a VMware investment it wants to preserve. Repurchase inverts the tradeoff — the migration cost is high because data must be extracted, transformed, and loaded into a SaaS product, and the operational cost is low because the vendor runs everything. Replatform is the strategy with the widest variance: moving a stateless application tier to containers is genuinely low-effort, while moving a database engine is a project with its own schema conversion and validation phases.
Refactor is the only strategy whose cost is front-loaded and whose benefit is structural. It is also the only strategy that can fail in a way that leaves the organization worse off than before, because a half-completed refactor produces an application that is neither the old monolith nor the new architecture. The exam's Refactor scenarios usually include a signal that the organization has the appetite and the runway for it — a multi-year mandate, a dedicated platform team, a product owner who owns the outcome. Absent those signals, the correct answer is usually Replatform or Rehost.
5. Sizing, Sequencing and Portfolio Scale
The 7 Rs operate at the application level, but migrations are executed at the wave level, and the gap between those two scales is where most real migration programs get into trouble. A portfolio of three hundred applications classified individually produces three hundred strategy decisions, but those decisions have to be grouped into waves that respect dependencies, shared infrastructure, and the organization's capacity to absorb change. Migration Hub exists precisely because that grouping is not obvious from the individual classifications and because the status of each application across each tool needs a single home.
The sequencing constraint that matters most is dependency. An application that depends on a shared database cannot be cut over before that database is migrated, and a database migration is usually a Replatform or Refactor decision with its own timeline. This is why migration programs typically front-load the shared infrastructure — identity, networking, logging, the database tier — and back-load the applications that depend on it. The 7 Rs classification for an individual application is therefore necessary but not sufficient; the wave plan is what turns a set of classifications into an executable schedule.
| Portfolio scale | Practical implication |
|---|---|
| Under ~20 applications | Classifications can be tracked in a spreadsheet; Migration Hub is optional |
| 20-100 applications | Wave planning becomes necessary; Migration Hub's single view starts paying for itself |
| 100-500 applications | Automated discovery and dependency mapping are prerequisites, not nice-to-haves |
| 500+ applications | Portfolio-level tooling and a dedicated migration factory pattern are the norm |
Migration Hub's role in this picture is deliberately narrow. It does not perform migrations; it aggregates status from the tools that do — MGN for rehost, DMS for database migration, and the discovery tools that feed the plan. Its value is the single pane of glass, and the exam tests it in scenarios where the requirement is visibility across a portfolio rather than the mechanics of any single application's move.
6. Failure Modes and What They Look Like
The characteristic failure of a 7 Rs program is not a technical failure at all; it is a classification failure that surfaces months later. The most common form is the accidental Refactor — an application classified as Replatform that turns out to require code changes, which pushes it into a rewrite the organization did not budget for. The symptom appears during the migration wave as an application that keeps slipping its cutover date while the team reports "just a few more changes." The first diagnostic move is to re-examine the classification against the actual work being done: if the team is modifying application code, the strategy is Refactor regardless of what the plan says, and the schedule needs to be re-baselined.
The second common failure is the Retain that nobody owns. An application classified as Retain is, by definition, not being worked on, which means it is also not being tracked, which means it can be forgotten entirely until the data center lease expires and it is discovered still running. The symptom is a late-breaking discovery during the final wave. The mitigation is procedural: Retain decisions need an owner and a review date, and they need to appear in Migration Hub alongside the applications that are actively moving.
The third failure is the Rehost that was supposed to be temporary. Rehost is frequently justified as a first step before a later Refactor, and that later Refactor frequently never happens because the application is now running and no longer urgent. The symptom is a cloud estate that carries the same operational burden as the data center it replaced. This is not a migration failure in the narrow sense, but it is the failure mode the exam is most likely to describe when it asks why a Rehost-first strategy can be a mistake.
7. The Operational and SRE Angle
From an SRE perspective, the 7 Rs are a decision about which operational model the application will have after the migration, and that decision has direct consequences for on-call load. A Rehosted application arrives with its existing runbooks, its existing failure modes, and its existing alerting, none of which improve because the application is now on EC2. A Replatformed application typically arrives with a reduced operational surface — a managed database removes patching and backup work — but also with new failure modes that the team has not seen before, such as a managed service's own maintenance windows and failover behavior. A Refactored application arrives with a different operational model entirely, usually one that requires the team to learn distributed tracing and per-service SLOs.
The practical implication is that migration planning and operational readiness planning are the same activity viewed from two angles. Every application's classification implies a target operational model, and that model implies a set of runbooks, alarms, and SLOs that must exist before cutover. The exam tests this indirectly through scenarios that ask what must be in place before a migration wave proceeds, and the answer is usually that the target environment's monitoring and recovery procedures must be validated first — the same discipline Phase 3 established for steady-state workloads, applied to the moment of transition.
Migration Hub's contribution to this angle is measurement. Because it aggregates status across tools, it can answer the question that matters during a wave: how many applications are actually cut over, how many are in progress, and how many have slipped. That is a program-level SLO, and it is the one that determines whether the data center exit date is met.
8. Edge Cases and Exam Gotchas
The most frequently missed distinction is between Rehost and Relocate. Both preserve the application unchanged, and both are low-effort, but Relocate specifically means moving a VMware workload to VMware Cloud on AWS without converting it to a native EC2 instance or AMI. If a scenario mentions preserving the hypervisor, keeping VMware tooling, or avoiding any conversion step, the answer is Relocate. If it mentions moving servers to EC2 with minimal change, the answer is Rehost, and the tool is MGN.
The second gotcha is treating Retain as a failure to decide. Retain is a legitimate strategy with a legitimate trigger — an open licensing negotiation, a contract that has not expired, a replacement system that is mid-build — and the exam will present scenarios where Retain is the correct answer precisely because the other options would waste money or create risk. Candidates who assume every application must move will pick Rehost or Repurchase and be wrong.
The third gotcha is conflating Repurchase with Replatform. Repurchase replaces the application with a SaaS product, which means the application ceases to exist in its current form and its data must be migrated to the vendor. Replatform keeps the application and changes its runtime substrate. A scenario about moving an on-premises CRM to a SaaS CRM is Repurchase; a scenario about moving a self-managed MySQL database to RDS is Replatform.
The fourth gotcha is assuming Migration Hub performs migrations. It does not. It aggregates status from the tools that do, and its value is visibility. A scenario that asks how to track migration progress across a portfolio of applications and multiple tools is a Migration Hub scenario; a scenario that asks how to move a specific server is not.
9. This vs. the Services It Gets Confused With
The 7 Rs framework is frequently confused with the tools that implement individual strategies, and the exam exploits that confusion by offering a tool as an answer to a strategy question or vice versa. The framework answers "what should we do with this application"; the tools answer "how do we execute that decision." Keeping those two layers separate is the single most useful habit for these scenarios.
| Confusion | Distinguishing question | Pick which |
|---|---|---|
| Rehost vs Relocate | Is the VM converted to a native EC2 instance/AMI? | Converted = Rehost (MGN); not converted = Relocate (VMware Cloud on AWS) |
| Repurchase vs Replatform | Does the application still exist in its current form? | Replaced by SaaS = Repurchase; same app, new substrate = Replatform |
| Retain vs Retire | Will the application exist in the target state at all? | Yes, later = Retain; no = Retire |
| 7 Rs vs Migration Hub | Is the question about deciding or about tracking? | Deciding = 7 Rs; tracking across tools = Migration Hub |
| Replatform vs Refactor | Is application code being modified? | No = Replatform; yes = Refactor |
The rule that resolves most of these quickly: if the scenario describes a change to the application's code or architecture, the strategy is Refactor. If it describes a change to where or on what the application runs, the strategy is Rehost, Relocate, or Replatform depending on whether the runtime substrate changes. If it describes the application being replaced or removed, the strategy is Repurchase or Retire. And if it describes the application staying put, the strategy is Retain.
Hands-On Lab — Classifying a Ten-Application Portfolio
This lab takes the classification exercise from the original brief and turns it into a full portfolio exercise with a wave plan. The goal is not to produce a correct answer key — there is no single correct answer — but to produce a defensible classification for each application and to discover where the classifications conflict with each other. Work through it on paper or in a spreadsheet; no AWS account is required.
Step 1 — Build the portfolio. Write down ten applications with the following characteristics, one per row: name, business function, current hosting (physical, VM, container), database engine, monthly active users, and whether the application is on a vendor support contract. Keep the descriptions short; the point is to have enough detail to classify against, not to document the estate.
Step 2 — Add the constraints. Add three columns that represent the business constraints the classification depends on: a hard deadline (if any), a licensing or contract blocker (if any), and a strategic value rating from one to five. These three columns are what turn a technical inventory into a migration plan, and they are the columns the exam's scenarios always imply even when they do not state them explicitly.
Step 3 — Classify each application. For each row, apply the decision procedure from section 2 in order. First ask whether the application needs to exist in the target state; if not, mark it Retire. If it does exist but has a blocker, mark it Retain and record the blocker and a review date. For the remainder, ask how much of the application is allowed to change and assign Rehost, Relocate, Repurchase, Replatform, or Refactor. Write one sentence of justification per application — the justification is the deliverable, not the label.
Step 4 — Find the conflicts. Review the classifications for internal contradictions. A Retain decision on an application that shares a database with a Rehosted application is a conflict, because the database is moving and the Retained application depends on it. A Refactor decision on an application with a one-to-five strategic value of one is a conflict, because the business case does not support it. List every conflict you find and resolve it by changing one of the two classifications.
Step 5 — Build the wave plan. Group the applications into three waves. Wave one should contain shared infrastructure and any application that others depend on. Wave two should contain the applications with the fewest dependencies and the clearest classifications. Wave three should contain the applications with the most dependencies, the Retain decisions that have resolved, and anything classified as Refactor. The wave plan is the artifact that a real migration program would actually execute against.
Step 6 — Define the tracking view. Decide what you would record in Migration Hub for each application: its classification, its target wave, its owning team, and its current status. Then decide which of those fields would change during execution and which are fixed at classification time. The fixed fields are the plan; the changing fields are what Migration Hub is for.
Step 7 — Write the one-page summary. Produce a single page that states the portfolio's classification counts, the wave plan, the top three risks, and the applications whose classification you are least confident about. That last item is the most valuable output of the exercise, because it is the list you would take into a discovery engagement.
Scenario Question Drills
Q1. A data center lease expires in six months, forcing a fast migration, but two legacy applications have unresolved software licensing blockers. What is the correct 7 Rs plan?
Q2. A company wants to move its VMware estate to AWS but has no appetite for converting VMs to native EC2 instances or AMIs, and wants to keep its existing VMware management tooling. Which strategy applies?
Q3. An internal reporting tool is used by four people once a month and carries significant technical debt. The company is not under a data center exit deadline. What is the most defensible strategy?
Q4. A team is migrating a self-managed MySQL database to Amazon RDS with no application code changes. Which strategy is this?
Q5. A company is replacing its on-premises CRM with a SaaS CRM and migrating the customer records to the vendor. Which strategy is this?
Q6. A migration program has 240 applications across four migration tools and needs a single view of which applications are cut over, in progress, or slipped. What provides this?
Q7. An application was classified as Replatform, but during the migration wave the team keeps modifying application code to make it work on the new substrate. What does this indicate?
Q8. A company Rehosts 80 applications to meet a data center exit deadline, intending to modernize them later. Two years later the applications are still running unchanged on EC2. What failure mode does this illustrate?
Q9. An application is classified as Retain because of an open licensing negotiation. What must accompany that decision for it to be operationally sound?
Q10. A Retained application shares a database with an application being Rehosted in wave one. What is the problem?
Q11. Which strategy is the only one that removes technical debt from an application?
Q12. A company has an application that is genuinely redundant — its function is fully covered by another system. Which strategy applies?
Q13. A migration program is planning waves. Which applications should generally be placed in the first wave?
Q14. A scenario asks how to move a specific on-premises server to EC2 with minimal change and minimal downtime. Which tool and strategy pairing is correct?
Q15. Which statement best describes the relationship between the 7 Rs and Migration Hub?
Peek into Tomorrow
Every classification in this lesson assumed you already knew what was in the portfolio. That assumption is doing a lot of work, and it is the assumption that most real migration programs get wrong first. A ten-application exercise can be classified from memory, but a two-hundred-application estate cannot, and the classifications are only as good as the inventory behind them. The open question is where that inventory comes from: which servers exist, what runs on them, which applications talk to which other applications, and how much CPU and memory each one actually consumes rather than how much it was provisioned with.
The dependency question is the sharper one. A classification that looks correct in isolation can be wrong the moment you discover the application shares a database with three others, or that it makes nightly calls to a system nobody remembered was still running. Utilization data matters for a different reason: right-sizing a target instance requires knowing the source's actual peak and average load, not its allocated capacity, and getting that wrong produces either an over-provisioned target or a cutover that fails under real traffic. Tomorrow's topic is the discovery layer that produces both the dependency map and the utilization data — and the question of whether to collect it with an agent on every server or without one.
Sources
- AWS Prescriptive Guidance — Migration Strategy Framework
- AWS Prescriptive Guidance — Migration Strategies (the 7 Rs)
- AWS Application Migration Service — User Guide
- AWS Migration Hub — User Guide
- VMware Cloud on AWS — User Guide
- AWS Database Migration Service — User Guide
- AWS Cloud Migration — Product Overview
- AWS Well-Architected Framework