What the 6R model is in cloud migration and why to use it The 6R model is a foundational classification framework in cloud migration strategies. Developed by AWS, it offers six distinct approaches for transforming each application as it moves to the cloud, rather than applying a single method to every resource. Each application, database, or business service has a different technical profile and different business constraints: some are critical and must migrate quickly, others are obsolete or redundant, some gain enormously from a redesign into microservices while others run better as they are. The 6R model acknowledges this reality and helps you make the right decision for each case, minimizing risk and unexpected costs. Without this framework, teams grope in the dark, start migrating an app too ambitiously (refactoring when a rehost would have been enough), then get discouraged by the complexity, or conversely rebuild every path identically in AWS without capitalizing on the advantages of the cloud. A prior cloud infrastructure assessment reveals precisely the technical and business characteristics of each application (dependencies, load, criticality, technical debt) that feed this 6R classification. You are then equipped to build a clear roadmap: knowing which ones to migrate first, which to shut down, which to redesign deeply, and which to keep as they are temporarily. This accelerates the transition and reduces unpredictable costs. ## Rehost: migrate as-is to AWS with lift-and-shift Rehost, often called lift-and-shift, is the fastest and least invasive strategy: you take the application, the virtual machine, the database, and you migrate them to AWS identical to themselves. No architectural redesign, no code rewrite. This approach is a perfect fit when you have a stable, well-performing on-premises application, you want to migrate quickly to shrink the data center or rapidly cut operating costs, and you have no urgent technical or business reason to transform it. Typically: a mature ERP system that works well, an established Oracle database, an internal business application with no changes planned in the short term. Migration time is counted in weeks, not months. Technical risks are minor because you do not touch the code. The challenges are more operational: correctly sizing the equivalent EC2 instance, configuring network security (VPC, security groups), planning the cutover and the validation tests. A poorly executed rehost can be expensive in the cloud (you keep oversized legacy instances) because you did not adjust resources to the reality of the cloud. This is why a cloud infrastructure assessment catches these cases: it identifies the applications where rehost genuinely fits, distinguishes real workloads from inherited on-premises provisioning, and helps you size correctly right from the migration. Rehost is not a "non-strategy": it is a pragmatic choice for the 40 to 50% of a typical infrastructure where transformation does not bring enough business value to justify the effort. ## Replatform: adapt the infrastructure without redesigning the application Replatform is a smart middle ground between rehost and refactor. The idea is to keep the application and its business code largely intact, but to modernize its infrastructure layer by taking advantage of AWS managed services. For example: you have a monolithic Java application running on a Tomcat server and Oracle on-premises. Instead of leaving it on EC2 as-is (rehost), you migrate it to AWS Elastic Beanstalk, which manages the infrastructure, the updates, and auto-scaling for you. Or you replace your self-managed Oracle database with Amazon RDS, which offers automatic backups, high availability, and optimized performance without you having to worry about maintenance. You may also do a little refactoring on the critical services (authentication, logging) to integrate them with native AWS tools (IAM, CloudWatch). The business application code itself remains essentially untouched. The benefits are direct and measurable: less operational effort post-migration (no OS patches to apply manually, no backups to orchestrate), reduced costs because managed services eliminate the overhead of on-premises management, and increased flexibility (auto-scaling saves you unused resources). Replatform spans a migration duration of a few weeks to 2 to 3 months depending on complexity. It suits strategic or critical applications worth the effort of light modernization, but which do not justify a complete redesign. It is often the right compromise when you migrate a system that works well but whose infrastructure layer is aging or consuming too many resources. ## Refactor: modernize the architecture to exploit cloud-native Refactor (also called rearchitect) is the most ambitious strategy: you rethink the application to make it cloud-native. This means breaking it into microservices, making it stateless, deploying it in containers on ECS or EKS, using serverless AWS services (Lambda, DynamoDB, SNS/SQS) in place of central databases, implementing granular auto-scaling and resilience at the application level. A well-executed cloud-native redesign offers enormous benefits: near-unlimited scalability, drastic cost reduction by tying consumed resources to actual demand, faster and more frequent deployments, natural resilience. But it is also the most expensive and longest option. Expect 4 to 9 months for a complex application, significant code rewriting, new methodologies (CI/CD, Infrastructure-as-Code, cloud-native observability), and a learning curve for teams. Refactor is appropriate when the application is strategic for business growth, when its load varies sharply (cloud-native excels at this), when your team can absorb the learning curve, or when on-premises technical debt hampers business evolution so much that only a redesign truly frees it. It is rarely the first move in a migration: many organizations refactor 5 to 15% of their portfolio, often new or priority applications and services, after stabilizing the rehost and replatform efforts. A well-built AWS migration strategy sequences the effort to free up teams and budget for progressive refactors. ## Repurchase: replace the application with a SaaS Repurchase means abandoning the existing application to adopt a ready-to-use SaaS product that meets the same business need. For example: you built an internal leave-management application in 2010, it works but you maintain it, patch it, and deploy it yourself. Repurchase would say: "Let's stop maintaining it, let's adopt Workday or Monday.com or a niche SaaS tool, in the cloud, no infrastructure needed." Or you have an old proprietary emailing system: replace it with SendGrid or AWS SES. This approach makes technical debt and maintenance effort vanish at a stroke, you gain the maturity and updates of the SaaS vendor, and often you pay less than what internal maintenance plus infrastructure would cost. The challenges are different: integration with other systems (APIs, webhooks), data migration, and adapting business workflows to the logic of the SaaS (not always a 1:1 mapping). Repurchase fits when the application is a standard business function (no competitive differentiation), when a market SaaS covers 80% of your needs, when you are willing to accept a business constraint to gain operational simplicity, or when the cost of the SaaS is competitive with internal maintenance plus cloud infrastructure. Be careful: do not repurchase everything on the pretext that it is simpler. The applications that make your competitive difference, those hyper-specialized to your business, those deeply integrated into your unique ecosystem, must stay in-house (refactor or rehost/replatform). ## Retire: shut down obsolete or redundant applications Retire is often the hardest decision but the most rewarding: identifying the applications you no longer use, or that are redundant because another application does the same job better, and shutting them down. Many organizations discover that they are dragging along 10 to 30% zombie applications that cost money in infrastructure, maintenance, security (patches, audits) and cognitive overhead (the IT team has to know them, monitor them, maintain support). During a migration, this is the perfect moment to clean house: you had that old reporting app no one uses anymore? Shut it down. You had two different document management systems because a department deployed one in isolation? Consolidate onto a single one, shut down the other. Retire saves money (infrastructure costs), reduces operational complexity (fewer systems to monitor, patch, audit), and frees up teams for higher-value work. A cloud infrastructure assessment typically identifies these candidates: few users, disproportionate costs, few or no critical dependencies (otherwise shutting down would be risky). Before retiring, always check that there are no hidden dependencies, that critical data is archived or migrated, and that users accept the transition. A well-executed retire can save 15 to 20% of the IT budget without losing a single business capability. ## Retain: keep on-premises what does not migrate Retain means keeping an application on-premises temporarily or permanently, or even not migrating it at all. It is a pragmatic decision: the application is very expensive or risky to migrate, it is not a business priority, or you do not yet have the capacity to transform it. For example: a large proprietary database with complex dependencies, an ultra-critical real-time system with tight performance requirements, or a homegrown app with little documentation and a high risk of regression. Retain is not a "non-choice": it is an informed decision based on the risk/benefit ratio. Many organizations, after a first successful migration wave, intentionally keep 10 to 20% of the portfolio on-premises (or at least keep it a few more years) to diversify risk and spread out the effort. The trap of retain is letting this on-premises layer drag on with no action plan. The ideal is to schedule the retain for a defined period ("we keep this app 2 more years, then reassess") and to include a medium-term modernization plan (in 2 years, we will refactor or repurchase it). In other words, retain is never a "never": it is a "not now, but with a clear horizon." A good AWS migration strategy incorporates the retained applications, prioritizes them in the roadmap, and reassesses them regularly as capabilities and business priorities evolve. ## How to decide: criteria and a 6R selection matrix Choosing the right 6R for an application requires evaluating several cross-cutting criteria. A prior cloud infrastructure assessment collects this data, but here is how to interpret it. First, business criticality: applications that are highly critical to operational continuity must migrate quickly and safely (rehost or replatform are safer than refactor) or not migrate at all (retain). Non-critical applications can take more risks (refactor). Second criterion, technical complexity and technical debt: an application with many dependencies, legacy code, and little documentation is riskier to refactor. It is a candidate for rehost or replatform. A well-architected, tested, documented app can support a redesign. Third, load variability: if your application has seasonal peaks or unpredictable spikes (e-commerce on Black Friday, a B2B platform with sudden surges), refactoring to cloud-native excels. Rehost or replatform does not give you that benefit. Fourth, business alignment: an app that makes your competitive difference justifies a refactor to modernize it. A standard or commoditized app is a candidate for SaaS repurchase. Fifth, team maturity: refactor demands cloud-native skills (Kubernetes, Lambda, serverless patterns). If your team does not have them, a refactor becomes a high-risk project. Sixth, cost: rehost is the cheapest in engineering, refactor the most expensive. Repurchase can be expensive in SaaS budget but less so in engineering. Seventh, timing: if you are in a hurry, rehost or repurchase, not refactor. A simple approach is to build a matrix: each application on a row, its characteristics (criticality, complexity, load, business alignment, costs) in columns, and you color cell by cell according to degree (critical vs. non-critical, complex vs. simple, and so on). The pattern of colors naturally points toward the candidate 6Rs. The evaluation is never absolute: it is a guide for the conversation between the IT team, the business, and your engineering partners to decide with full awareness. ## Integrating the 6R into your migration strategy and roadmap Once you have classified your application portfolio according to the 6R, the next step is to build your AWS migration strategy to order and sequence the work. You cannot do everything at once: you have limited bandwidth (teams, budget, maintenance windows, operational risk). The migration order depends on several factors. First, start with the simple, non-critical rehost applications. They give you a quick win, you break in the migration processes (automation, validation, rollback), you demonstrate business value and train your teams. Then step up in complexity: replatform the strategic applications. At this stage, you have feedback from the first rehosts, you begin to refine your AWS infrastructure, your security patterns, your networking. Then come the refactors and repurchases: more effort, more risk, but you have the experience and confidence to carry them out. Finally, retain and retire can be handled as you go: retire the zombie apps as soon as you identify them (no need to wait), and reassess the retained ones each quarter to shift new ones toward migration if their criticality changes. This sequence is not set in stone: depending on your context (business urgency, regulatory constraints, team availability), you can resequence. But broadly, starting simple and accelerating progressively minimizes risk and maximizes learning. A good migration strategy also plans for dependencies between applications: if app A depends on app B, migrate B before A. Otherwise you complicate testing and risk regressions. This is a planning effort that relies on the cloud infrastructure assessment to build the exact dependency graph. Finally, do not underestimate the value of regularly communicating the roadmap to teams, business, and leadership. A migration is a long project (12 to 36 months for a mid-sized infrastructure), highly visible, with impacts on users' daily work. Transparency and quick wins keep up the momentum and the trust.