Chapter 50: AWS DMS

AWS DMS (full name: AWS Database Migration Service)

Many people hear “DMS” and think: “Oh, it’s just a tool to move data from one database to another.” That sentence is technically correct — but it’s like saying “a car is just something with four wheels that moves.” It completely misses the power, the real-world pain it solves, and why thousands of companies in India (including many right here in Hyderabad) use it every single day.

Let me explain it like we’re sitting together in a Hi-Tech City café with a whiteboard — slow, step-by-step, full of real analogies, actual 2026 Hyderabad startup / enterprise examples, pricing reality in ap-south-1 / ap-south-2, common gotchas, and exactly how it works in practice.

1. What is AWS Database Migration Service (DMS)? (Plain Language First)

AWS DMS is a fully managed cloud service that helps you migrate databases to AWS (or between different engines) with minimal downtime and near-zero data loss.

It supports:

• Homogeneous migrations (same engine: MySQL → RDS MySQL, Oracle → RDS Oracle)
• Heterogeneous migrations (different engines: Oracle → Aurora PostgreSQL, SQL Server → Aurora MySQL, MySQL → DynamoDB)
• Ongoing replication / CDC (Change Data Capture) — keep target database in sync after initial migration
• Full load + ongoing changes in one go
• Schema conversion (with help from AWS Schema Conversion Tool – SCT)

Official short line (still accurate in 2026): “AWS Database Migration Service helps you migrate databases to AWS quickly and securely. The source database remains fully operational during the migration, minimizing downtime to applications using the database.”

In plain Hyderabad language: Imagine you run a very popular biryani restaurant in Banjara Hills (on-premise Oracle / SQL Server database). Business is booming → you want to move to the cloud (AWS RDS / Aurora) for auto-backups, scalability, Multi-AZ, cheaper storage.

But:

• You cannot close the restaurant for 2 days to copy data
• You cannot afford to lose even one order record
• You want old customers to keep ordering while migration happens

AWS DMS = the magical night-shift moving company that:

• Copies all existing biryani recipes & customer orders to the new cloud kitchen while the old kitchen is still open
• Keeps copying new orders in real time (CDC)
• When ready → you flip a switch → new orders go to cloud kitchen
• Customers never notice anything changed

2. Core Components of AWS DMS (The Building Blocks – 2026 View)

3. The Most Common Migration Scenarios (2026 – India Reality)

4. Real Hyderabad Example – Full Migration Story

Your fintech startup in Financial District (UPI / wallet app):

Current situation (2025):

• On-premise SQL Server 2019 in Hyderabad data center
• ~800 GB data, 5,000–15,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 DMS (very typical 2026):

1. Preparation
   • Use AWS Schema Conversion Tool (SCT) → convert SQL Server schema → PostgreSQL compatible
   • Fix any incompatible objects (stored procs, triggers) manually
2. DMS setup
   • Launch replication instance: dms.m6g.large in ap-south-2
   • Create source endpoint: SQL Server on-premise (via VPN / Direct Connect)
   • Create target endpoint: Aurora PostgreSQL cluster
   • Create task: Full Load + CDC (ongoing replication)
3. Migration execution
   • Task starts → full load copies 800 GB (takes ~12–18 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
4. Cut-over
   • Stop writes to old SQL Server (short maintenance window: 15–60 min)
   • Let CDC catch up (usually seconds–minutes)
   • Point application to Aurora endpoint
   • Start writes to Aurora → app back live

Result:

• Downtime: ~30–60 minutes (planned)
• Zero data loss
• App now runs on Aurora → Multi-AZ, auto-backups, read replicas for reports
• Monthly database bill: ~₹12,000–25,000 vs previous on-prem ~₹40,000–60,000

5. Pricing Reality (2026 – ap-south-1 / ap-south-2)

• Replication instance — charged per hour (e.g., dms.m6g.large ~₹4–6/hour)
• Data transfer — free within same region, cross-region or internet = standard rates
• Storage — only for target database (RDS/Aurora/S3) — DMS itself doesn’t store data
• Typical migration cost (one-time 800 GB migration):
  • Replication instance running 48 hours → ~₹200–300
  • Data transfer (if cross-region) → ~₹500–2,000
  • Total: ₹1,000–5,000 (very cheap compared to downtime cost)

6. Quick Hands-On – Feel a Mini Migration

1. Launch two small RDS instances (PostgreSQL source & target)
2. Create DMS replication instance
3. Create source & target endpoints
4. Create task: Full Load only → watch tables copy over
5. Insert new rows in source → see CDC task catch up

Cost? Usually ₹50–200 for this learning experiment.

Summary Table – AWS DMS Cheat Sheet (2026 – India Focus)

Teacher’s final note: AWS DMS is the “moving company with zero furniture damage & minimal downtime” for databases. In 2026, almost every Hyderabad company that has on-premise databases or legacy RDS instances eventually uses DMS — either for full migration or ongoing replication for disaster recovery.

Got it? This is the “how do I safely move my database to the cloud (or to a better engine)?” lesson.

Next?

• Step-by-step: Real Oracle → Aurora PostgreSQL migration walkthrough?
• DMS vs AWS Database Migration alternatives (Snowball, SCT alone, manual)?
• Or how to monitor & troubleshoot a live DMS task?

Tell me — next whiteboard ready! 🚚🗄️