Chapter 85: AWS Migration Services
AWS Migration Services
When people ask “What are AWS Migration Services?”, they usually mean:
“AWS has so many migration tools — DMS, MGN, SMS, Snowball, DataSync, Migration Hub, Transfer Family… which one do I use, when, and how do they actually work in real life?”
So today we’re going to do a clear, honest, practical overview — like a real classroom session — with everyday Hyderabad analogies, actual 2026 examples from Telangana startups / enterprises, when to choose which tool, rough pricing in ap-south-2, common mistakes, and the exact patterns most Indian teams follow right now.
No fluff. Just the truth.
1. The Big Picture — Why So Many Migration Services Exist?
AWS does not believe in “one migration tool fits all”.
Different workloads need completely different approaches:
- Moving 50 VMs from VMware → fast & low-downtime?
- Moving 5 TB Oracle database with zero data loss?
- Moving 100 PB of historical files from on-prem tape?
- Moving from Azure SQL to Aurora PostgreSQL?
- Moving from self-managed Kafka to MSK?
Each scenario needs a different tool (or combination).
2. The Most Important AWS Migration Services in 2026 (The Ones You Actually Use)
Here is the realistic list that 95 % of Hyderabad companies actually choose from:
| Rank | Service / Tool | Primary Workload / Scenario | Downtime possible? | Approx Cost (moderate usage, ap-south-2) | Typical Hyderabad use-case (2026) |
|---|---|---|---|---|---|
| 1 | AWS Application Migration Service (MGN) | Rehost VMs / physical servers → EC2 | Near-zero (with proper planning) | Free (pay only for target EC2) | VMware / Hyper-V → EC2 lift-and-shift |
| 2 | AWS Database Migration Service (DMS) | Migrate databases (full load + ongoing CDC) | Near-zero (with CDC) | Replication instance ~₹2,000–8,000/month | Oracle → Aurora PostgreSQL, on-prem MySQL → RDS |
| 3 | AWS DataSync | Fast, secure file transfer (on-prem ↔ AWS or AWS ↔ AWS) | N/A (data copy) | ~₹0.0125/GB transferred | Sync 10 TB NFS share to S3 |
| 4 | AWS Snow Family (Snowball, Snowcone, Snowmobile) | Petabyte-scale offline data transfer | N/A (physical ship) | Device rental + shipping (~₹50,000–₹5 lakh) | First 100 TB historical data to S3 |
| 5 | AWS Migration Hub | Central dashboard & tracking for all migrations | N/A | Free | Track progress of 20+ server + DB migrations |
| 6 | AWS Schema Conversion Tool (SCT) | Convert database schema & code between engines | N/A | Free | SQL Server stored procs → Aurora PostgreSQL |
| 7 | AWS Transfer Family | Managed file transfer (SFTP, FTPS, AS2) | N/A | ~₹0.30/hour + data transfer | Partners upload daily sales CSV securely |
| 8 | AWS Server Migration Service (SMS) | Older VM migration tool (mostly replaced by MGN) | Low–medium | Rarely used now | Legacy users still on it |
3. Quick Decision Tree — Which Migration Service Should You Pick? (2026 Hyderabad Reality)
Ask these questions in order — this is the exact path most Indian teams follow:
- Are you moving servers / VMs / physical machines?
- Yes → AWS Application Migration Service (MGN) (modern choice) or SMS (legacy)
- No → continue
- Are you moving databases (with minimal downtime)?
- Yes → AWS DMS (full load + ongoing CDC) + SCT (schema conversion)
- No → continue
- Are you moving large file shares / file data (NFS, SMB, on-prem storage)?
- Small–medium volume → AWS DataSync
- Petabytes → AWS Snowball / Snowmobile
- Need managed SFTP/FTPS → AWS Transfer Family
- Are you doing multiple migrations at once and want one dashboard?
- Yes → AWS Migration Hub (tracks everything)
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 (DMS style)
- 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 Services Cheat Sheet (2026 – India Focus)
| Question | Answer (Beginner-Friendly) |
|---|---|
| What are AWS Migration Services? | Tools to move workloads, databases, apps from on-prem / other cloud / old AWS setup to modern AWS |
| Most common first step in India? | Rehost servers with MGN + Replatform databases with DMS |
| Main tool for server migration? | AWS Application Migration Service (MGN) |
| Main tool for database migration? | AWS DMS + Schema Conversion Tool (SCT) |
| Large file transfer? | AWS DataSync (online) or Snowball (offline) |
| Best Region for target? | ap-south-2 (Hyderabad) — lowest latency + compliance |
| First thing to try today? | Launch DMS → migrate small PostgreSQL table from one RDS to another |
Teacher’s final note (real talk – Hyderabad 2026):
Migration is 30 % tools and 70 % planning, testing, validation, and rollback thinking.
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–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! 🚚🗄️
