Moving to the cloud sounds like one big decision. In practice, it’s dozens, or even hundreds, of smaller ones.
One application may be stable enough to move with minimal changes. Another may need a deeper redesign before it can scale. An outdated internal tool might be replaced with a SaaS solution, while a regulated workload may need to stay exactly where it is for another year. Giving every system the same treatment can turn a promising migration into an expensive technical detour.
That’s where the 7 Rs of cloud migration come in. This cloud migration framework helps companies evaluate each application, database, and infrastructure workload before choosing one of seven strategies: rehost, relocate, replatform, refactor, repurchase, retain, or retire. Instead of starting with a preferred cloud platform or migration method, teams can match the approach to the workload’s business value, technical condition, dependencies, and long-term role.
The framework is especially useful for companies planning an application migration, a data center exit, a cloud infrastructure migration, or a broader legacy application modernization initiative. Some workloads may only need a faster route into AWS, Microsoft Azure, or Google Cloud. Others may benefit from cloud-native architecture, managed services, automation, or a complete product replacement.
The goal isn’t to choose one R for the entire company. It’s to make a deliberate decision for every workload. In this guide, we’ll explain how each cloud migration strategy works, when to use it, the trade-offs to consider, and which technical roles can help execute it.
Companies that need outside expertise can also explore South’s guide to the best cloud migration services and companies.
What Are the 7 Rs of Cloud Migration?
The 7 Rs of cloud migration are seven strategies companies can use to decide what should happen to each application or workload during a cloud transformation:
- Rehost: Move the application to the cloud with minimal changes.
- Relocate: Transfer an existing virtualized environment to cloud infrastructure.
- Replatform: Make targeted improvements while keeping the application’s core architecture.
- Refactor: Redesign the application to take greater advantage of cloud-native services.
- Repurchase: Replace the existing system with a commercial or SaaS product.
- Retain: Keep the workload in its current environment for now.
- Retire: Decommission an application that no longer provides enough business value.
Together, these cloud migration approaches give teams a structured way to assess an application portfolio. Rather than selecting a migration path based only on speed or technical preference, companies can consider the workload’s business importance, performance, security requirements, dependencies, operating costs, and future plans.
Each R represents a different level of effort, change, and long-term value. Rehosting may help a company complete a data center exit quickly, while replatforming can introduce managed cloud services without requiring a full application rewrite. Refactoring involves deeper engineering work but may support better scalability, resilience, and product development over time.
The terminology can vary slightly between cloud providers and migration frameworks. Some models combine refactoring and rearchitecting, while others list them separately or include rebuilding as an additional strategy. The underlying principle remains the same: every workload should follow the path that creates the strongest business and technical outcome.
For companies managing older systems, the 7 Rs can also complement a broader legacy application modernization strategy. The framework helps determine whether an application should move, change, remain in place, be replaced, or be removed from the portfolio entirely.
The 7 Rs of Cloud Migration at a Glance
The right cloud migration strategy depends on what a workload does, how much value it creates, and how extensively the company wants to change it. Some approaches prioritize speed, while others create more room for scalability, automation, and cloud-native development.
A single migration program may use every one of the 7 Rs across different applications. This overview can help teams identify the most suitable starting point for a cloud workload assessment.
This table offers a useful starting point, but the final choice should come from a broader assessment of the application portfolio. Teams should also review security requirements, technical debt, business criticality, dependencies, operating costs, internal skills, and the desired cloud operating model.
The fastest option won’t always create the greatest long-term value, and the most technically ambitious option won’t suit every workload. The strongest cloud migration plan balances immediate business priorities with how each application should operate in the future.
The 7 Cloud Migration Strategies Explained
The 7 Rs become most useful when teams apply them to real workloads rather than treating them as abstract cloud terminology. Each strategy reflects a different balance of speed, technical change, cost, risk, and future flexibility.
The following sections explain what each cloud migration approach looks like in practice, when it makes sense, and what companies should consider before committing to it.
1. Rehost: Move the Application With Minimal Changes
Rehosting, often called a lift-and-shift migration, moves an application from its current environment to cloud infrastructure with few changes to the code or architecture.
The application generally works much as it did before. The servers, storage, and networking move to a platform such as AWS, Microsoft Azure, or Google Cloud, while the application itself remains largely intact.
Rehosting is usually chosen when speed matters more than immediate modernization. A company may need to leave a data center, reduce hardware maintenance, support a merger, or move workloads before an infrastructure contract expires. In those situations, rebuilding every application first could delay the broader cloud migration program.
A rehost strategy may work well when:
- The application is stable and continues to support critical business processes.
- The company has a fixed data center exit deadline.
- The technical team wants to reduce migration complexity.
- The workload can operate effectively on virtual machines in the cloud.
- Deeper modernization is planned for a later phase.
For example, a company running an internal finance application on aging on-premises servers might move the system to cloud-based virtual machines. Employees continue using the same software and workflows, while the IT team gains access to cloud infrastructure, backups, monitoring, and disaster recovery options.
The main consideration is that rehosting moves the application’s current architecture as well. Performance bottlenecks, oversized servers, manual deployment processes, and legacy dependencies may remain after the migration. Cloud spending can also rise when workloads are transferred without being resized or optimized for actual usage.
That doesn’t make rehosting a weak strategy. It makes it a practical first step. Many companies use lift-and-shift to complete an urgent infrastructure migration, then replatform or refactor selected applications once they’re operating in the cloud.
Teams planning a large rehost project may work with cloud architects, migration engineers, infrastructure specialists, and DevOps engineers.
Companies evaluating external support can also review South’s guide to cloud migration services and providers before deciding how the work should be delivered.
2. Relocate: Move a Virtualized Environment to the Cloud
Relocation moves an existing virtualized environment to cloud infrastructure with minimal changes to the applications running inside it. Instead of migrating each workload separately, the company transfers the broader platform, including virtual machines, network configurations, and management tools.
This strategy is commonly associated with VMware cloud migration, although it can also apply to other virtualized environments. The goal is to preserve the existing operating model while moving it out of an on-premises data center.
Relocation can help companies move large groups of workloads quickly without redesigning every application. It’s especially useful when the current environment is stable, the team already has strong virtualization expertise, or the business needs to complete a data center migration within a fixed timeline.
A relocate strategy may be appropriate when:
- The company operates a large virtual machine environment.
- Applications have complex dependencies that are difficult to separate.
- The organization wants to preserve familiar infrastructure tools and processes.
- A hardware lease, hosting agreement, or data center contract is ending.
- Application modernization will happen after the initial move.
For example, a company may relocate its VMware environment to a compatible cloud platform rather than rebuilding hundreds of individual virtual machines. Employees and applications experience limited disruption, while the infrastructure team can continue using many of the same management processes.
Relocate and rehost are closely related, but they work at different levels. Rehosting typically moves individual applications or servers, while relocation transfers an existing virtualized environment as a larger unit. This distinction matters when teams are assessing migration effort, dependencies, and operational ownership.
The main trade-off is that relocation delivers limited application modernization. The company gains cloud-based infrastructure, but the workloads may continue relying on the same virtual machine architecture, licensing model, and administrative processes.
Relocation can still create a useful transition point. Once the environment is operating in the cloud, teams can assess which applications should remain virtualized and which ones should later be replatformed, refactored, replaced, or retired.
Cloud architects, virtualization engineers, network engineers, migration specialists, and cloud security professionals often support relocation projects. Their work includes mapping dependencies, configuring connectivity, planning migration waves, validating performance, and protecting business continuity during the move.
3. Replatform: Make Targeted Cloud Improvements
Replatforming moves an application to the cloud while making selected changes to improve its performance. The core architecture stays recognizable, but parts of the supporting platform are upgraded to use managed services, automation, or more efficient cloud infrastructure.
This approach is sometimes described as “lift, tinker, and shift.” It sits between rehosting and refactoring: the application receives meaningful improvements without requiring a complete redesign.
Replatforming works well when a company wants to derive more value from the cloud while keeping the migration scope under control. Teams can address specific operational pain points, reduce infrastructure management, and improve reliability without rebuilding the entire application.
A replatform strategy may make sense when:
- A self-managed database can move to a managed cloud database.
- An application can be containerized without changing its core logic.
- Local file storage can be replaced with cloud object storage.
- Autoscaling can improve performance during demand spikes.
- Deployment pipelines can be automated.
- Existing infrastructure requires too much manual maintenance.
For example, a SaaS company might move an application to cloud infrastructure, migrate its database to Amazon RDS or Azure SQL Database, place static files in cloud storage, and add automated deployment workflows. The product remains familiar to users, while the engineering team spends less time maintaining servers and handling routine infrastructure tasks.
The main advantage of replatforming is its balance between effort and impact. It can improve scalability, availability, security, and operational efficiency faster than a full cloud-native rebuild.
The application may still carry architectural constraints after the move. A monolithic system remains a monolith, and older code can continue limiting development speed. Even so, targeted platform changes can create immediate improvements and prepare the workload for deeper modernization later.
Replatforming usually requires close collaboration between cloud architects, DevOps engineers, software developers, database specialists, and QA engineers. These professionals help select appropriate managed services, update configurations, test integrations, automate infrastructure, and confirm that the application performs reliably in its new environment.
4. Refactor: Redesign the Application for the Cloud
Refactoring changes an application’s code, architecture, or both to take fuller advantage of cloud-native services. Rather than moving the existing system largely as-is, the engineering team redesigns key components to prioritize scalability, resilience, automation, and faster software delivery.
This is often the most technically ambitious of the 7 Rs of cloud migration. It can involve breaking a monolithic application into smaller services, introducing event-driven architecture, using serverless computing, automating infrastructure, or replacing custom components with managed cloud services.
Refactoring is best reserved for applications that create meaningful business value and need capabilities their current architecture can’t support. A customer-facing product experiencing rapid growth may require more flexible scaling, while a platform with frequent outages may need stronger fault tolerance and observability.
A refactor strategy may be appropriate when:
- The application is central to the company’s product or customer experience.
- The current architecture limits scalability or development speed.
- Engineering teams struggle to release updates safely.
- Performance issues affect users or revenue.
- The business needs greater resilience across regions or availability zones.
- Cloud-native services could reduce long-term operational work.
For example, a SaaS company may refactor a monolithic platform by separating high-demand features into independent services. Each service can scale according to usage, deploy on its own schedule, and recover without affecting the entire product. The team might also introduce managed messaging, serverless functions, container orchestration, and automated monitoring.
The potential gains are substantial, but so are the planning and engineering requirements. Refactoring can affect application logic, databases, integrations, security controls, testing processes, and deployment workflows. Teams also need a clear target architecture and a realistic understanding of which changes will create measurable business value.
A phased approach often works better than attempting to rebuild everything at once. Companies can begin with the components causing the greatest bottlenecks in performance, reliability, or development, then modernize additional areas as priorities and capacity evolve.
Refactoring typically requires experienced software developers, cloud architects, DevOps engineers, site reliability engineers, data engineers, security specialists, and QA automation engineers. Their combined work helps ensure the redesigned application performs reliably, integrates correctly, and remains maintainable after the migration.
5. Repurchase: Replace the Application With a New Product
Repurchasing means replacing an existing application with a commercial platform or software-as-a-service solution. Instead of moving the current system to the cloud, the company adopts a different product that delivers similar business capabilities.
This strategy is often described as “drop and shop.” It’s commonly used for standardized functions such as customer relationship management, human resources, accounting, collaboration, or project management, where mature cloud-based products already exist.
Repurchasing can make sense when maintaining or modernizing the current application would require more effort than replacing it. A legacy system may depend on outdated technology, require frequent manual fixes, or offer little competitive value to the business.
A repurchase strategy may be appropriate when:
- A proven SaaS product can meet most business requirements.
- The existing system has high maintenance costs.
- The company wants to reduce infrastructure ownership.
- Vendor support for the current application is ending.
- The application handles a standard business process.
- Internal teams have limited capacity to rebuild or refactor the system.
For example, a company using a heavily customized on-premises CRM might move to a cloud-based platform rather than migrating the original application. The new system may provide built-in automation, reporting, integrations, security updates, and mobile access without requiring the company to maintain the underlying infrastructure.
Repurchasing can simplify long-term application management, but the work extends far beyond buying a subscription. Teams must migrate historical data, configure workflows, rebuild integrations, define permissions, test business processes, and help users adapt to the new platform.
Customization is another important consideration. A replacement product may cover most existing requirements while handling certain workflows differently. Companies should decide which processes genuinely need to be preserved and which can be adapted to fit the new system.
Vendor pricing, contract terms, data portability, security controls, and future product limitations should also be evaluated before committing. The organization may trade internal maintenance for greater dependence on the software provider.
Repurchase projects often involve solutions architects, implementation specialists, data engineers, integration developers, business analysts, security professionals, and project managers. Their role is to connect the new platform with the company’s systems, migrate accurate data, configure workflows, and support a controlled transition.
6. Retain: Keep the Workload Where It Is for Now
Retaining means leaving an application in its current environment for a defined period rather than moving it during the cloud migration. The workload remains on-premises in a private data center or with its existing hosting provider while the company continues to evaluate its long-term direction.
Retain is an intentional cloud migration strategy when moving the workload now would create more risk, cost, or disruption than value. Some applications need additional preparation, while others depend on infrastructure, contracts, or compliance requirements that limit where they can operate.
A retain strategy may make sense when:
- Regulatory or data residency requirements restrict cloud deployment.
- The application depends on specialized hardware.
- A software license or hosting contract is still active.
- The vendor doesn’t support the target cloud environment.
- A replacement system is already planned.
- The workload has complex dependencies that require more analysis.
- The business can’t yet accept the operational risk of moving it.
For example, a manufacturing company may keep a production system on-site because it connects directly to factory equipment and requires extremely low-latency communication. The organization can still migrate surrounding workloads, such as reporting, collaboration, and analytics platforms, while the operational system remains in place.
Retaining can also support a phased hybrid cloud strategy. A company might keep sensitive databases or legacy applications in its current environment while moving customer-facing services and development tools to the cloud. This allows the migration program to progress without forcing every workload into the same timeline.
The key is to document why the application is being retained and when the decision should be reviewed. Without clear ownership, retained workloads can stay in place longer than intended, increasing infrastructure costs and creating additional security or maintenance work.
Teams should define:
- The business or technical reason for retaining the workload
- The person responsible for the application
- The conditions that would make migration possible
- A future review date
- The expected long-term strategy
Retained applications still require active maintenance, security updates, monitoring, backups, and operational support. Cloud architects, infrastructure engineers, security specialists, application owners, and compliance professionals often work together to manage these workloads and determine when they’re prepared for migration, replacement, or retirement.
7. Retire: Remove Applications the Business No Longer Needs
Retiring means decommissioning an application, workload, or infrastructure component instead of moving it to the cloud. The system is removed from the active technology portfolio once the company confirms that it no longer supports an essential business process.
This may apply to unused tools, duplicate applications, outdated internal systems, abandoned development environments, or software that has already been replaced. Retiring unnecessary workloads can reduce migration scope before technical work begins.
A retire strategy may make sense when:
- The application has few or no active users.
- Another system already provides the same functionality.
- The workload supports a discontinued product or process.
- Maintenance costs outweigh its remaining business value.
- The application contains outdated or unsupported technology.
- Usage data shows that the system is rarely accessed.
- Repurchasing or consolidating tools has made it redundant.
For example, a company may discover during its application portfolio assessment that several reporting tools produce similar information. Rather than migrating all of them, the team can preserve the most useful platform, move essential data, and retire the duplicates.
The potential savings extend beyond cloud infrastructure costs. Retiring an application can also reduce software licensing, security monitoring, maintenance, backup storage, vendor management, and technical support requirements. Every system removed from the migration plan gives the team more time to focus on workloads that create greater business value.
Still, an application shouldn’t be switched off based on low usage alone. Older systems may feed reports, store required records, support integrations, or run background processes that employees rarely see. Teams need to map these dependencies before beginning the decommissioning process.
A controlled retirement plan should include:
- Confirming the application owner and active users
- Reviewing integrations and downstream dependencies
- Identifying data retention requirements
- Archiving or transferring important records
- Removing user access and credentials
- Ending licenses, hosting agreements, and vendor contracts
- Monitoring connected systems after shutdown
- Documenting the final decommissioning date
Data deserves particular attention. Some records may need to remain accessible for legal, compliance, audit, or customer service purposes even after the original application is removed. The company should decide where that information will be stored, who can access it, and how long it must be retained.
Retirement typically involves application owners, business analysts, data engineers, security specialists, infrastructure teams, compliance professionals, and project managers. Their combined work helps the company remove the system safely while protecting important data and preventing disruptions to connected applications.
How to Choose the Right Cloud Migration Strategy
Understanding the 7 Rs is the easy part. The harder decision is matching each workload to the strategy that best balances business value, migration speed, technical effort, and long-term flexibility.
The right R usually becomes clearer when teams evaluate applications individually instead of making one decision for the entire portfolio. A customer-facing platform may justify refactoring, while an internal tool with limited strategic value may be better suited to rehosting, repurchasing, or retirement.
The following factors can help guide a cloud migration assessment.
Start With Business Value
Before reviewing architecture or infrastructure, determine what the workload contributes to the company.
Consider:
- Which business process or customer experience it supports
- How many employees, customers, or partners depend on it
- Whether it contributes directly to revenue
- How disruptive an outage would be
- Whether the capability creates a competitive advantage
- How long the business expects to keep using it
A strategic application that supports a core product may justify deeper modernization. A standard administrative system may be easier to replace with SaaS. A rarely used application with little remaining value may be a candidate for retirement.
Migration effort should reflect the importance of the workload. Companies gain little from heavily refactoring a system that may be replaced within the next year.
Evaluate the Application’s Technical Condition
Next, assess how healthy and adaptable the application is.
Review its:
- Architecture and programming language
- Code quality and documentation
- Vendor support status
- Security vulnerabilities
- Performance and reliability
- Test coverage
- Database structure
- Deployment process
- Infrastructure requirements
- Dependence on outdated libraries or operating systems
A stable application with limited technical issues may move through rehost or replatform. A system constrained by its architecture may require refactoring. Software built on unsupported technology may be more practical to replace or retire.
This is also where teams should review accumulated technical debt. Some debt can move safely with the application and be addressed later, while deeper architectural problems may continue to limit performance, security, and development speed after migration.
Map Dependencies Before Selecting an R
Applications rarely operate alone. They exchange data with other platforms, authentication services, databases, APIs, reporting tools, and background processes.
A cloud workload assessment should identify:
- Upstream and downstream applications
- Database connections
- Third-party integrations
- Identity and access systems
- Batch jobs and scheduled processes
- Reporting dependencies
- Shared file systems
- Network requirements
- Hardware connections
- Data residency or compliance restrictions
A workload that looks simple can become difficult to migrate once its dependencies are visible. Moving a single component without its connected systems may cause latency, integration failures, duplicate data, or unexpected operating costs.
Dependency mapping can also reveal which applications should move together as part of the same migration wave.
Define the Migration Deadline
Timing can significantly influence the strategy.
A company facing an expiring data center lease may prioritize rehost or relocate to complete the move quickly. A business with a longer transformation window may have enough time to replatform or refactor high-value applications before migration.
Common timing pressures include:
- Data center closures
- Hardware reaching the end of its useful life
- Vendor support deadlines
- Contract expirations
- Mergers and acquisitions
- Security remediation requirements
- Product launches
- Seasonal business periods
A deadline doesn’t automatically make the fastest strategy the best one. It may lead to a phased approach: move the workload first, stabilize it in the cloud, and modernize selected components later.
Decide How Much Change the Business Can Absorb
Every migration affects more than infrastructure. It can change employee workflows, user interfaces, integrations, support procedures, and operating responsibilities.
Teams should consider:
- Acceptable downtime
- User training requirements
- Process changes
- Data migration complexity
- Testing capacity
- Customer impact
- Internal change-management resources
- Whether old and new systems must run simultaneously
Repurchasing may look straightforward from a technical perspective, but it can require extensive workflow changes and user adoption. Refactoring can improve the product while introducing more testing and release risk. Rehosting usually creates less immediate disruption but delivers fewer application-level improvements.
The strongest strategy is one that the business and technical teams can support through implementation and daily operations.
Review Security and Compliance Requirements
Security, privacy, and regulatory obligations can limit which cloud migration options are practical.
Assess:
- Where data is allowed to reside
- How sensitive information must be encrypted
- Who can access the workload
- Which audit records must be retained
- Whether the target cloud services meet required standards
- How identity and permissions will be managed
- Whether the application depends on unsupported security controls
Some workloads may need to be retained temporarily while teams redesign security controls or obtain approval for the target environment. Others may benefit from replatforming onto managed cloud services with built-in encryption, backups, monitoring, and patching.
Compare Migration Effort With Long-Term Value
Migration decisions should account for what happens after the workload reaches the cloud.
Estimate:
- Initial migration effort
- Application modification requirements
- Testing and validation work
- Licensing costs
- Ongoing infrastructure costs
- Maintenance requirements
- Expected performance improvements
- Future development needs
- Internal operating capacity
Rehosting may have a lower initial cost but preserves manual administration and oversized infrastructure. Refactoring requires more investment but may improve scalability and product development over time. Repurchasing reduces infrastructure ownership while introducing subscription costs and vendor dependence.
The aim is to choose the approach that delivers the greatest value over the application’s expected remaining lifespan.
Confirm the Team Has the Required Skills
Each R requires a different mix of expertise.
Rehosting and relocation depend heavily on infrastructure, networking, virtualization, and migration skills. Replatforming adds knowledge of containers, managed databases, automation, and cloud services. Refactoring requires experienced software developers, cloud architects, DevOps engineers, security specialists, and QA professionals.
Before approving a strategy, companies should determine:
- Which skills already exist internally
- Whether current employees have enough capacity
- Which capabilities require hiring or external support
- Who will operate the workload after migration
- How knowledge will be transferred and documented
A technically sound migration plan can still fail when the team lacks the capacity to execute or maintain it. The final strategy should match both the desired outcome and the people available to deliver it.
Cloud Migration Decision Matrix
A cloud migration decision matrix helps teams narrow down the most suitable strategy for each workload. It won’t replace a full technical assessment, but it can reveal which of the 7 Rs deserves closer consideration.
The best starting point usually depends on the workload’s business value, technical condition, migration urgency, and expected lifespan.
The recommended strategy can change as teams uncover new information. For example, an application initially marked for rehosting may become a replatform candidate after engineers identify an easy move to a managed database. A system selected for repurchase may need to be retained temporarily while the business configures the new platform and migrates its data.
Companies can make the matrix more specific by adding scoring criteria for:
- Business criticality
- Revenue impact
- Application health
- Security exposure
- Dependency complexity
- Migration urgency
- Estimated effort
- Operating costs
- Internal technical capacity
- Expected remaining lifespan
Each workload can then receive a score or rating for every category. High-value applications with serious architectural limitations may rise to the top of the refactoring roadmap, while low-value systems with high maintenance costs may become stronger candidates for retirement.
The matrix should guide discussion rather than produce an automatic answer. Business owners, application teams, cloud architects, security professionals, and finance leaders should review the result together before approving the final cloud migration strategy.
It’s also useful to document the reasoning behind every decision. A workload record should show the selected R, key dependencies, expected outcome, estimated effort, responsible owner, and any assumptions that need to be validated during migration planning.
Can One Cloud Migration Use Several Rs?
Most cloud migration programs use several Rs simultaneously.
A company may have hundreds of applications, databases, virtual machines, and internal tools. Each one supports a different business process, relies on different technology, and carries a different level of risk. Applying one migration strategy across the entire portfolio can lead to unnecessary work, higher costs, and weaker outcomes.
Instead, teams can assign a separate R to each workload during the application portfolio assessment.
For example, a SaaS company might:
- Retire an outdated reporting tool that few employees still use.
- Retain a regulated database until new compliance controls are approved.
- Rehost stable internal applications to meet a data center exit deadline.
- Relocate its existing VMware environment to a compatible cloud infrastructure.
- Repurchase an on-premises HR platform and move to a SaaS product.
- Replatform its analytics application with managed databases and cloud storage.
- Refactor its customer-facing product to improve scalability and release speed.
The company is still following one broader cloud migration plan, but each workload takes the path that best matches its purpose and technical condition.
A mixed migration strategy also helps teams prioritize their engineering resources. Developers and cloud architects can focus deeper modernization work on strategic applications, while infrastructure teams move stable systems through faster approaches such as rehost or relocate.
This portfolio-based approach can also reduce migration risk. Lower-complexity workloads may move first, giving teams time to validate cloud security, networking, monitoring, backup, and deployment processes before handling more critical applications.
Companies often organize these workloads into migration waves based on:
- Business criticality
- Application dependencies
- Technical complexity
- Migration strategy
- Security requirements
- Downtime tolerance
- Team availability
- Target cloud environment
Applications that depend heavily on one another should usually move together or follow a coordinated sequence. A database, for example, may need to migrate alongside the applications that access it to prevent latency and integration issues.
The selected R can change as planning progresses. An application marked for rehosting may become a retirement candidate after the team finds that it duplicates another system. A retained workload may later undergo replatforming once a vendor withdraws cloud support.
The 7 Rs should be treated as a living decision framework. Teams can revisit each workload as business priorities, technical information, and migration constraints evolve.
Common Mistakes When Applying the 7 Rs
The 7 Rs provide teams with a useful structure, but the framework still depends on the quality of the underlying assessment. A poorly chosen strategy can move a workload to the cloud while preserving the same cost, performance, and maintenance problems it had before.
The following mistakes are especially common during cloud migration planning.
Rehosting Every Application to Meet a Deadline
Rehosting can help a company leave a data center quickly, but using it as the default strategy for every workload may transfer technical debt, oversized infrastructure, and manual processes directly into the cloud.
This can lead to:
- Higher-than-expected cloud spending
- Limited use of managed services
- The same performance bottlenecks
- Ongoing infrastructure maintenance
- A second modernization project shortly after migration
A deadline may justify rehosting selected applications, but teams should still identify which workloads can be retired, replaced, or improved with limited additional effort.
Refactoring More Applications Than the Team Can Support
Refactoring can create significant long-term value for strategic applications. It also requires experienced developers, extensive testing, a clear target architecture, and enough time to manage deeper changes.
Trying to refactor too many workloads at once can overwhelm engineering teams and delay the broader migration.
Companies should reserve this strategy for applications where better scalability, reliability, performance, or development speed supports a clear business objective. Stable internal tools may deliver more value through rehosting, replatforming, or repurchasing.
Treating Retain as a Permanent Decision
Some workloads need to remain in their current environment due to regulations, contracts, hardware dependencies, or operational risk. The problem begins when the company retains an application without documenting what happens next.
Every retained workload should have:
- A clear reason for staying in place
- A responsible owner
- A future review date
- Conditions that would make migration possible
- An expected long-term strategy
Without these details, retained applications can remain forgotten in aging infrastructure while maintenance and security risks continue to grow.
Confusing Rehost, Relocate, and Replatform
These strategies can look similar because each may involve moving an application without fully rebuilding it.
The distinction is important:
- Rehost moves an application or server with minimal changes.
- Relocate transfers a broader virtualized environment.
- Replatform introduces targeted cloud improvements during the move.
Using the wrong label can lead to inaccurate estimates of engineering effort, testing, timelines, and post-migration operations.
Assuming Repurchase Is a Simple Software Swap
Replacing a legacy application with SaaS can reduce infrastructure ownership, but the migration still requires substantial planning.
Teams may need to:
- Clean and transfer historical data
- Rebuild integrations
- Reconfigure workflows
- Redesign permissions
- Validate reporting
- Train users
- Manage parallel systems during the transition
The technical deployment may be straightforward, while the operational change is extensive. Business owners should be involved early, so the replacement system supports critical processes and adoption requirements.
Choosing an R Before Mapping Dependencies
An application may appear independent until teams identify its database connections, authentication services, scheduled jobs, shared files, reports, and downstream integrations.
Selecting a migration strategy too early can create:
- Unexpected latency
- Broken data flows
- Incomplete testing
- Longer downtime
- Additional migration waves
- Higher cloud connectivity costs
Dependency mapping should happen before the final R is approved, especially for business-critical applications.
Ignoring Post-Migration Ownership
The migration doesn’t end when the workload reaches the cloud. Someone must manage its security, monitoring, backups, performance, costs, releases, and incident response.
A refactored cloud-native application may require different skills than a relocated VMware environment. A repurchased SaaS platform may need an implementation specialist and system administrator rather than an infrastructure team.
The selected strategy should align with the company’s ability to manage the workload after migration. Teams should define ownership, staffing needs, support processes, and documentation before the move begins.
Treating the First Decision as Final
Cloud migration planning often reveals new information. A workload selected for rehosting may become a retirement candidate after usage data is reviewed. A retained application may become eligible for replatforming once a vendor releases cloud support.
The framework works best when teams revisit decisions as dependencies, risks, costs, and business priorities become clearer. Each R should represent the strongest current choice rather than an irreversible commitment.
Which Roles Support Each Cloud Migration Strategy?
Selecting the right R defines what should happen to a workload. The next step is assembling the people who can execute that decision safely.
Cloud migration rarely belongs to one role. Infrastructure specialists may handle a rehost or relocation, while a refactor requires deeper collaboration between software developers, cloud architects, DevOps engineers, data specialists, security professionals, and QA teams.
The required skills become more specialized as the level of application change increases.
Cloud Architects Set the Direction
A cloud architect helps translate business and technical requirements into a practical migration plan. They assess application dependencies, design the target cloud architecture, select services, and establish standards for security, networking, data, resilience, and cost management.
Their work is especially important when a migration uses several Rs. A consistent architectural direction keeps rehosted, replatformed, and refactored workloads from becoming disconnected cloud environments.
Migration and Infrastructure Engineers Handle the Move
Cloud migration engineers focus on transferring workloads and validating that they operate correctly in the target environment. Their responsibilities may include provisioning infrastructure, migrating virtual machines, configuring storage, establishing connectivity, and supporting cutover activities.
Virtualization and network engineers become particularly important during relocation projects involving VMware estates, private networks, hybrid cloud connections, or complex data center infrastructure.
Developers and DevOps Engineers Drive Modernization
Replatforming and refactoring usually require changes beyond infrastructure.
Software developers may update code, replace unsupported libraries, change database connections, rebuild integrations, or redesign application components. DevOps engineers create the automation surrounding that software, including infrastructure as code, continuous integration and deployment pipelines, observability, scaling, and release controls.
These roles help turn a basic cloud move into a more scalable and maintainable operating model.
Companies researching compensation and role differences can explore South’s guide to cloud engineer salaries.
Data Specialists Protect Information During the Transition
Data is involved in almost every migration strategy, even retirement.
Data engineers and database administrators help determine:
- Which information must move
- How records should be cleaned and transformed
- Where data will live in the target environment
- How systems will stay synchronized during migration
- Which records must be archived
- How accuracy will be validated after cutover
For repurchase projects, they may move information from a custom application into a SaaS platform. During retirement, they help preserve records that remain necessary for reporting, customer service, legal, or compliance purposes.
Security Engineers Review Every Active Workload
Cloud security shouldn’t be added after the migration design is complete. Security specialists help define identity and access controls, encryption, network segmentation, logging, secrets management, compliance requirements, and incident-response procedures.
Their involvement is particularly valuable when an application handles customer data, financial information, intellectual property, or regulated records.
QA Engineers Confirm the Migration Works
A technically successful transfer can still create business problems when features, integrations, reports, or workflows behave differently after the move.
QA engineers validate:
- Core application functionality
- API and system integrations
- Data accuracy
- User permissions
- Performance under expected demand
- Backup and recovery procedures
- Failover behavior
- Compatibility with connected systems
Automated testing becomes especially valuable during replatforming and refactoring, where application changes may introduce regression risk.
Business and Project Roles Keep the Work Grounded
Business analysts, application owners, and technical project managers connect migration activities with operational priorities. They help determine whether an application should remain in the portfolio, which processes must be preserved, and how much disruption users can absorb.
They also coordinate migration waves, dependencies, deadlines, communication, training, and final approval.
The strongest cloud migration teams combine infrastructure knowledge with application, data, security, testing, and business expertise. The exact mix should reflect the chosen strategy, the complexity of the workload, and who will operate it after the migration.
Build the Cloud Team That Your Migration Strategy Requires
Choosing the right R gives your migration a direction. Delivering it requires people with the skills to assess workloads, redesign systems, move data, automate infrastructure, test every dependency, and support the environment after launch.
A rehost project may depend on cloud migration engineers and infrastructure specialists. Replatforming often requires DevOps engineers, database experts, and software developers. Refactoring demands an even broader mix of expertise across cloud architecture, application development, security, data, and QA.
The team should match the strategy rather than forcing the strategy to fit the people already available.
South helps U.S. companies find full-time remote cloud and engineering professionals in Latin America, including:
- Cloud architects
- Cloud migration engineers
- DevOps engineers
- Software developers
- Data engineers
- Database administrators
- Cloud security engineers
- QA automation engineers
- Technical project managers
Latin American professionals can work closely with U.S.-based teams during workload assessments, migration planning, development, testing, cutovers, and post-migration optimization. Time-zone alignment also makes it easier to coordinate architecture decisions, resolve blockers, and manage complex migration waves in real time.
South supports the hiring process through candidate sourcing, salary benchmarking, and the selection of pre-vetted professionals aligned with the company’s technical requirements. That gives internal leaders more time to focus on the migration roadmap while building a dedicated team that can execute it.
Whether the plan involves rehosting stable applications, replatforming selected workloads, or refactoring a strategic product, the right technical hires can turn the 7 Rs from a planning framework into a workable cloud migration program.
Schedule a call with South to find cloud and engineering talent in Latin America.
Frequently Asked Questions (FAQs)
What are the 7 Rs of cloud migration?
The 7 Rs of cloud migration are rehost, relocate, replatform, refactor, repurchase, retain, and retire. They help companies decide what should happen to each application, database, or infrastructure workload during a cloud migration.
Each strategy represents a different level of technical change, effort, risk, and long-term value.
Why do some cloud migration frameworks have 6, 7, or 8 Rs?
Cloud providers and consulting frameworks sometimes group or name migration strategies differently. Some combine refactoring and rearchitecting, while others separate them or add options such as rebuilding.
The exact number matters less than the framework's purpose: evaluating every workload and selecting the most suitable migration path.
What’s the difference between rehost and relocate?
Rehosting usually moves an individual application, server, or workload to cloud infrastructure with minimal changes.
Relocation moves a broader virtualized environment, such as a VMware estate, while preserving much of its existing configuration and operating model.
Rehost works at the workload level, while relocate often works at the platform level.
What’s the difference between replatform and refactor?
Replatforming introduces targeted cloud improvements while keeping the application’s core architecture mostly intact. This could include moving to a managed database, adopting cloud storage, or containerizing the application.
Refactoring involves bigger changes to the code or architecture so the application can use cloud-native services and scale more effectively.
Which cloud migration strategy is the fastest?
Rehost and relocate are usually among the fastest cloud migration strategies because they require fewer application changes.
The actual timeline still depends on workload size, dependencies, data volume, security requirements, testing, and migration readiness.
Which of the 7 Rs offers the greatest modernization value?
Refactoring generally provides the greatest opportunity for cloud-native scalability, resilience, automation, and faster software delivery.
It also requires more engineering work than the other strategies, so companies typically reserve it for strategic applications where deeper modernization supports a clear business goal.
Can a company use different Rs for the same migration?
Yes. Most cloud migration programs use several strategies across the application portfolio.
A company may retire obsolete tools, retain regulated workloads, rehost stable applications, replatform healthy systems, and refactor customer-facing products as part of the same cloud transformation.
Can different parts of one application use different Rs?
In some cases, yes. A company might rehost the main application, replatform its database, replace a reporting component with SaaS, and retire an unused feature.
This approach requires careful dependency mapping so the components continue working together after migration.
Is retaining an application considered a cloud migration strategy?
Yes. Retain is a valid strategy when moving an application during the current migration wave would create excessive risk, cost, or disruption.
The decision should include a documented reason, a responsible owner, a review date, and a long-term plan.
When should a company retire an application?
An application may be suitable for retirement when it’s obsolete, duplicated, rarely used, unsupported, or no longer connected to an active business process.
Before decommissioning it, teams should review dependencies, data retention requirements, integrations, active users, and compliance obligations.
When should a company replace rather than migrate an application?
Repurchasing may be the better option when a mature SaaS platform can handle the business requirement more effectively than the current system.
Companies should evaluate data migration, integrations, workflow changes, user training, vendor terms, and customization needs before replacing the application.
How do you choose the right cloud migration strategy?
Start by assessing the workload’s business value, technical condition, dependencies, security requirements, migration urgency, expected lifespan, and operating costs.
Teams should also confirm that they have the cloud, development, data, security, and testing skills required to complete the migration and manage the workload afterward.
