Chapter 84: AWS Migration Strategies
AWS Migration Strategies
This is not just a list of buzzwords or a theoretical slide deck. Migration strategy is the actual decision framework that determines whether your company moves to the cloud in 3 months with minimal risk or spends 18 months, burns ₹50–200 lakh, and still has angry customers + compliance issues.
Every serious Indian company (fintech, edtech, SaaS, retail, manufacturing, government-linked projects) that is either moving from on-premise → AWS, from another cloud → AWS, or re-architecting inside AWS has to choose one (or a mix) of these strategies.
Let’s do this properly — like we’re sitting together with a whiteboard, drawing the famous 6 Rs diagram, and going through real 2026 Hyderabad examples so you truly understand when to pick which strategy and why most teams combine them.
1. The Famous “6 Rs” — The Standard AWS Migration Strategies (Still the Bible in 2026)
AWS officially defines six strategies. Every Indian migration project picks one or more of these — usually starting with the left side and moving right over time.
| Strategy | What it really means (plain language) | Effort / Risk / Time | Cost impact | Typical Hyderabad company choosing this in 2026 |
|---|---|---|---|---|
| Rehost | Lift-and-shift: move applications as-is (minimal or no code change) | Low effort, low risk, fast | Lowest | Most common first step — VMware / physical servers → EC2 |
| Replatform | Lift, tinker & shift: minor changes (e.g., switch to managed DB, containerize) | Medium effort, medium risk | Low–medium | On-prem MySQL → RDS MySQL / Aurora, VM → ECS Fargate |
| Refactor | Re-architect / rewrite parts of the application | High effort, high risk, slow | Medium–high | Monolith → microservices on EKS, legacy Java → serverless |
| Repurchase | Replace with SaaS / Marketplace equivalent | Medium effort, low risk | Medium | On-prem Jira → Atlassian Cloud, custom monitoring → Datadog |
| Retire | Turn off the workload — no migration needed | Very low effort, no risk | Saves money | Old internal reporting tool no one uses anymore |
| Retain | Keep it where it is (hybrid / multi-cloud / leave on-prem) | Very low effort, no risk | Neutral | Legacy mainframe or ultra-sensitive workload stays on-prem |
2026 India reality (especially Hyderabad / Bengaluru):
- 80–85 % of first migrations are Rehost + Replatform (fast, low risk, quick ROI)
- Only 15–20 % start with Refactor (usually only for brand-new greenfield products)
- Repurchase is exploding — teams love moving commodity apps (monitoring, CI/CD, SSO, backup) to SaaS via Marketplace
- Retire is surprisingly common — companies discover 20–40 % of workloads can simply be turned off
2. Real Hyderabad Examples — Which Strategy Companies Actually Choose & Why
Example 1 — Classic Rehost (Lift-and-shift)
Company: Mid-size fintech in Financial District (payment gateway) Current state: 25 physical servers + VMware cluster in Hyderabad data center Goal: Move to AWS for scalability & disaster recovery (RBI guideline)
Chosen strategy: Rehost using AWS Application Migration Service (MGN)
- Replicated all 25 VMs to AWS EC2 with near-zero downtime
- Cut-over window: 4 hours (DNS switch + final sync)
- Result: same OS, same app code, same DB → now on EC2 + EBS
- Monthly infra bill: down from ~₹9 lakh (on-prem) → ~₹5.5 lakh (AWS)
- Time: 3.5 months end-to-end
Example 2 — Replatform (Lift, tinker & shift)
Company: Edtech platform in Kukatpally (online courses) Current state: Self-managed MySQL on EC2 + EC2 web servers Goal: Reduce ops burden & improve HA
Chosen strategy: Replatform
- Moved MySQL → Amazon Aurora PostgreSQL (using AWS DMS + SCT)
- Moved web servers → ECS Fargate (containerized the app)
- Result: no more OS patching, automatic backups, Multi-AZ HA
- Monthly DB cost: ~₹12,000 vs previous ~₹28,000
- Time: 5 months (schema conversion took longest)
Example 3 — Repurchase (Replace with SaaS)
Company: SaaS product company in Hi-Tech City Current state: Self-hosted Jenkins + self-hosted Grafana + self-hosted Confluence Goal: Reduce maintenance & improve uptime
Chosen strategy: Repurchase
- Jenkins → GitHub Actions or AWS CodeBuild (via Marketplace integration)
- Grafana → Amazon Managed Grafana
- Confluence → Atlassian Cloud (subscribed via Marketplace)
- Result: everything on one AWS bill, automatic updates, 99.99 % SLA
- Monthly cost: ~₹18,000–35,000 vs previous ~₹45,000 + 2 FTE ops effort
Example 4 — Refactor (Re-architect)
Company: Growing e-commerce platform in Madhapur Current state: Monolithic Java Spring Boot app on EC2 Goal: Faster feature releases & better scalability
Chosen strategy: Refactor
- Broke monolith into microservices → deployed on Amazon EKS
- Replaced RDS with Aurora Serverless v2 + DynamoDB for read-heavy parts
- Added API Gateway + Lambda for some endpoints
- Result: deploys in minutes instead of hours, auto-scaling, cost down 35 %
- Time: 11 months (biggest effort)
5. Quick Hands-On — Feel a Mini Migration (Rehost style)
- Launch two small EC2 instances (source & target simulation)
- Use AWS Application Migration Service (MGN) console → install replication agent on “source” EC2
- Replicate to “target” EC2 → launch test instance → see near-zero downtime replication
- (In real life) → cut-over by updating DNS / load balancer
Cost? Usually ₹100–500 for this learning experiment.
Summary Table — AWS Migration Strategies Cheat Sheet (2026 – India Focus)
| Strategy | Effort / Risk / Time | Cost impact | When Hyderabad teams usually choose it | Most common tool(s) |
|---|---|---|---|---|
| Rehost | Low / Low / Fast | Lowest | First migration wave | MGN, VM Import |
| Replatform | Medium / Medium / Medium | Low–medium | Second wave (after lift-and-shift) | DMS + SCT |
| Refactor | High / High / Slow | Medium–high | Greenfield or strategic products | EKS, Lambda, Aurora Serverless |
| Repurchase | Medium / Low / Medium | Medium | Commodity workloads | Marketplace SaaS |
| Retire | Very low / None | Saves money | Unused legacy systems | — |
| Retain | Very low / None | Neutral | Ultra-sensitive or legacy mainframes | Hybrid / Direct Connect |
Teacher’s final note (real talk – Hyderabad 2026):
Migration strategy is 30 % tools and 70 % planning, testing, and rollback thinking.
The biggest failures in India right now are not the migration tools failing — they are:
- No proper cut-over plan → extended downtime
- No validation after full load → data mismatch
- No rollback plan → can’t go back to old system
- Trying to Refactor everything on day 1 → project takes 18 months instead of 3–6
Smart Hyderabad teams follow this order:
- Rehost / Replatform first — fast wins, prove value
- Use DMS for databases — it is very reliable
- Test cut-over in staging at least twice
- Have rollback plan (DNS TTL, traffic switch, backup restore tested)
Got it? This is the “how to move to the cloud without losing your job or your sleep” lesson.
Next?
- Step-by-step: Real Oracle → Aurora PostgreSQL migration walkthrough with DMS?
- Deep dive: MGN vs DMS vs Snowball — when to use which?
- Or how to plan a low-downtime cut-over window?
Tell me — next whiteboard ready! 🚚🗄️
