Chapter 82: AWS Migration
AWS Migration
This is not just “copy-paste servers to the cloud”. It is a strategic, phased, multi-tool, risk-managed process that — when done well — can cut costs 30–70 %, increase reliability dramatically, and make compliance & scaling much easier.
When done poorly, it can cause weeks of downtime, data loss, huge bills, angry customers, and very awkward calls with investors.
So let’s do this like a real classroom session — slow, step-by-step, with everyday Hyderabad analogies, actual 2026 examples from Telangana startups / enterprises, the most-used AWS migration tools, the real pricing impact, and the exact patterns most Indian teams follow today.
1. What do we actually mean by “AWS Migration” in 2026?
AWS Migration = moving workloads, data, applications, databases, or entire data centers to AWS (or between AWS accounts / regions) in a controlled, low-risk, cost-effective way.
The four most common migration scenarios in India right now:
- On-premises → AWS (classic lift-and-shift or re-platform)
- Legacy database / engine → modern AWS database (Oracle → Aurora PostgreSQL, SQL Server → Aurora MySQL)
- One AWS account / region → another (e.g., ap-south-1 Mumbai → ap-south-2 Hyderabad for data residency)
- One cloud provider → AWS (Azure / GCP → AWS)
2. The Famous “6 Rs” Migration Strategies (Still the Bible in 2026)
AWS uses these six strategies — almost every Indian team picks one or mixes them:
| Strategy | What it means (simple) | Effort & Risk level | Typical Hyderabad example (2026) |
|---|---|---|---|
| Rehost | Lift-and-shift — move as-is | Low effort, low risk | VMware VMs → EC2 via AWS Migration Hub / VM Import |
| Replatform | Minor changes (e.g., change DB engine, containerize) | Medium effort, medium risk | Self-managed MySQL → RDS MySQL / Aurora |
| Refactor | Rewrite / redesign parts of the app | High effort, high risk | Monolith → microservices on ECS / EKS |
| Repurchase | Replace with SaaS equivalent | Medium effort, low risk | On-premise Jira → Atlassian Cloud (via Marketplace) |
| Retire | Turn off the workload — no migration needed | Very low effort | Old internal reporting tool no one uses anymore |
| Retain | Keep it where it is (hybrid / multi-cloud) | Very low effort | Legacy mainframe stays on-prem for now |
Most common path in Hyderabad 2026:
- First wave — Rehost + Replatform (lift-and-shift + move to managed services)
- Second wave (1–2 years later) — Refactor key parts (monolith → microservices, RDS → Aurora Serverless)
- Ongoing — Repurchase commodity apps (Jira, Confluence, Datadog, Snowflake via Marketplace)
3. The Most Important AWS Migration Tools (The Toolbox 2026)
Almost every real migration in India uses some combination of these:
| Tool / Service | Primary purpose (in plain language) | Typical Hyderabad use-case (2026) | Cost style |
|---|---|---|---|
| AWS Migration Hub | Central dashboard for all migrations | Track progress of 20+ server migrations at once | Free |
| AWS Application Migration Service (MGN) | Rehost servers (VMs or physical) to EC2 | VMware / Hyper-V → EC2 with minimal downtime | Free (pay for target EC2) |
| AWS Database Migration Service (DMS) | Migrate databases (full load + ongoing CDC) | Oracle → Aurora PostgreSQL, on-prem MySQL → RDS | Pay for replication instance |
| AWS Schema Conversion Tool (SCT) | Convert database schema & code between engines | SQL Server stored procedures → Aurora PostgreSQL | Free |
| AWS Server Migration Service (SMS) (legacy) | Older tool — mostly replaced by MGN | Rarely used now | — |
| AWS Snow Family | Physical data transfer (petabytes) | First 100 TB of historical data to S3 | Pay for device rental + shipping |
| AWS DataSync | Fast, secure data transfer (on-prem ↔ AWS or AWS ↔ AWS) | Sync 5 TB file share to S3 | Pay per GB transferred |
4. Real Hyderabad Example — Full Migration Story (Fintech 2026)
Your fintech startup “PayTelugu” (UPI wallet & payment app):
Current situation (2025):
- On-premise SQL Server 2019 in Hyderabad data center
- ~1.2 TB data, 10,000–30,000 transactions/day
- Frequent maintenance downtime → angry users
- Scaling hard → buying more licenses & servers expensive
Goal: Move to Aurora PostgreSQL in ap-south-2 (Hyderabad Region) → Multi-AZ, auto-backups, read replicas, cheaper, scalable
Migration plan using AWS tools (very typical 2026):
- Preparation (2–4 weeks)
- Run AWS Schema Conversion Tool (SCT) → convert SQL Server schema → PostgreSQL compatible
- Fix incompatible objects (stored procs, triggers) manually
- Replication setup
- Launch AWS DMS replication instance (dms.m6g.large) in ap-south-2
- Create source endpoint: on-premise SQL Server (via VPN / Direct Connect)
- Create target endpoint: Aurora PostgreSQL cluster
- Create DMS task: Full Load + CDC (ongoing replication)
- Execution
- Task starts → full load copies 1.2 TB (takes ~18–36 hours depending on bandwidth)
- While full load runs → old app still writes to SQL Server
- CDC captures every new transaction → applies to Aurora in near real-time
- Validation → compare row counts & sample data
- Cut-over (maintenance window: 1–2 hours)
- Stop writes to old SQL Server
- Let CDC catch up (usually seconds–minutes)
- Point application to Aurora endpoint
- Start writes to Aurora → app back live
Result:
- Downtime: ~60–90 minutes (planned)
- Zero data loss
- App now runs on Aurora → Multi-AZ, auto-backups, read replicas for reports
- Monthly database bill: ~₹18,000–35,000 vs previous on-prem ~₹60,000–90,000
5. Quick Hands-On — Feel a Mini Migration
- Launch two small RDS instances (PostgreSQL source & target)
- Create DMS replication instance
- Create source & target endpoints
- Create task: Full Load only → watch tables copy over
- Insert new rows in source → see CDC task catch up
Cost? Usually ₹100–500 for this learning experiment.
Summary Table — AWS Migration Cheat Sheet (2026 – India Focus)
| Question | Answer (Beginner-Friendly) |
|---|---|
| What is AWS Migration? | Moving workloads, databases, apps from on-prem / other cloud / old AWS setup to modern AWS |
| Most common strategy in India? | Rehost + Replatform first, then Refactor later |
| Main tools for server migration? | AWS Application Migration Service (MGN) |
| Main tools for database migration? | AWS DMS + Schema Conversion Tool (SCT) |
| Data transfer for large volumes? | AWS Snow Family (physical device) or AWS DataSync |
| Best practice for Hyderabad startup? | Use ap-south-2 for target, start with Rehost/Replatform, use DMS for DBs |
| First thing to try today? | Launch DMS → migrate small PostgreSQL table from one RDS to another |
Teacher’s final note (real talk – Hyderabad 2026):
AWS Migration is 30 % tools and 70 % planning & testing.
The biggest failures in India right now are not the 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
Smart Hyderabad teams follow this order:
- Rehost / Replatform first (fast wins, low risk)
- Use DMS for databases — it is battle-tested
- Test cut-over in staging at least twice
- Have rollback plan (DNS TTL, traffic switch)
Got it? This is the “how to move to the cloud without losing 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! 🚚🗄️
