Gartner's 6R strategies — Rehost, Replatform, Repurchase, Refactor, Retire, and Retain — each carry a distinct security posture, migration risk, and compliance consideration relevant to the Indian enterprise context.
Sign in to mark this article as read and track your progress.
The path you choose to move a workload into the cloud determines what security controls you can apply, when you can apply them, and who is responsible for maintaining them. A poorly chosen migration strategy can lock an organisation into a security posture that is inferior to what was possible on-premises.
Gartner introduced the "5Rs" framework; AWS popularised the "6Rs" by splitting the original "Re-purchase" category. The six strategies form a spectrum from minimal change to complete redesign.
The workload is moved to cloud VMs with no code changes. On-premises VMware VMs are converted to Amazon EC2 instances using AWS Application Migration Service (MGN) or Azure Migrate.
Security implications:
Suitable for: Legacy systems with tight timelines, government portals requiring minimal change for compliance, disaster recovery use cases.
The application moves to cloud infrastructure with minor optimisations — typically replacing a self-managed database with RDS, or self-managed Tomcat with Elastic Beanstalk — without changing core architecture.
Security implications:
The existing on-premises application is replaced with a SaaS equivalent. An organisation migrates from self-hosted Jira to Atlassian Cloud, or from on-premises Exchange to Microsoft 365.
Security implications:
The application is redesigned to be cloud-native — microservices, containers, managed databases, event-driven architecture. This is the highest effort and longest timeline.
Security implications:
The application is decommissioned entirely. No further cloud migration is required.
Security implications:
The workload stays on-premises, at least for now. Common for highly regulated systems, mainframe applications, or those with hardware dependencies.
Security implications:
| Strategy | Effort | Time | Security Control Gain | Primary Risk |
|---|---|---|---|---|
| Rehost | Low | Weeks | Low — inherits existing posture | Accidental exposure, unchanged vulnerabilities |
| Replatform | Medium | Months | Medium — provider handles patched managed services | Misconfigured managed service defaults |
| Repurchase | Low-Medium | Weeks-Months | Variable (SaaS provider dependent) | Data residency, shadow IT |
| Refactor | High | 6-18 months | High — security by design | Supply chain, DevSecOps maturity required |
| Retire | Low | Weeks | N/A | Data sanitisation |
| Retain | Low | N/A | As-is | Hybrid connectivity threat surface |
India's Ministry of Electronics and Information Technology (MeitY) classifies government workloads into three tiers: data that must stay on MeghRaj (National Cloud), data that may use empanelled commercial cloud providers, and data approved for international cloud. When a government agency migrates, the strategy choice is constrained by this classification — not just technical preference. A Rehost of a critical citizen-data system to AWS ap-south-1 may still be non-compliant if the data classification requires MeghRaj.
