Chapter 86: AWS Database Migrations

AWS Database Migration Service (officially called AWS DMS — Database Migration Service)

Many people hear “DMS” and immediately panic:

• “It’s going to take months and cost lakhs!”
• “What if we lose even one transaction?”
• “What if the schema conversion fails?”
• “Is it really zero-downtime or is that just marketing?”

All those fears are valid — but most of them are avoidable when you understand exactly what DMS can and cannot do, how the process really works, and how serious Indian teams (fintech, edtech, e-commerce, SaaS, banks, NBFCs) actually use it in 2026.

Let me teach it like we’re sitting together in a Madhapur café with a big whiteboard — slow, step-by-step, full of real analogies, actual 2026 Hyderabad examples, current pricing in ap-south-2, common pitfalls, and the exact patterns that work.

1. What is AWS DMS? (Very Simple First)

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

It can do two main things at the same time:

• Full load — copy all existing data from source to target (one-time bulk copy)
• Change Data Capture (CDC) — continuously capture and apply new changes (inserts, updates, deletes) from source to target in near real-time

So you can:

• Start the migration → copy everything while the old database is still live
• Keep the old database open for writes → new changes flow to the new database automatically
• When ready → switch the application to the new database → cut-over with very little (or zero) downtime

Official short line (still perfect): “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 (old SQL Server database).

Business is booming → you want to move to a new, bigger cloud kitchen (Aurora PostgreSQL) with automatic backups, Multi-AZ, read replicas, cheaper storage.

But:

• You cannot close the restaurant for 2 days to copy 1.2 TB of order 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 kitchen while the old kitchen is still open
• Keeps copying every new order in real time (CDC)
• When ready → you flip a switch → new orders go to the cloud kitchen
• Customers never notice anything changed

2. What DMS Can Migrate (2026 Supported Engines)

Source databases (where you are coming from):

• On-premise / self-managed: Oracle, SQL Server, MySQL, PostgreSQL, MariaDB, Db2, SAP ASE
• AWS: RDS (any engine), Aurora, DynamoDB, DocumentDB, Redshift
• Other clouds: Azure SQL, Google Cloud SQL, etc. (via JDBC/ODBC)

Target databases (where you are going to):

• AWS managed: Aurora (MySQL/PostgreSQL compatible), RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server), Redshift, DynamoDB, DocumentDB, OpenSearch, S3 (as Parquet/CSV), Kinesis Data Streams
• Also supports: Babelfish for Aurora PostgreSQL (SQL Server compatibility), Amazon Timestream, Neptune, etc.

Most common routes in Hyderabad 2026:

• Oracle / SQL Server → Aurora PostgreSQL (most popular for fintech / RBI compliance)
• Self-managed MySQL → RDS MySQL or Aurora MySQL
• On-prem PostgreSQL → Aurora PostgreSQL Serverless v2
• DynamoDB → DynamoDB (cross-region / cross-account replication)

3. How DMS Really Works (The Process Step-by-Step)

Typical zero/minimal-downtime migration (2026 pattern):

1. Preparation (1–4 weeks)
   • Run AWS Schema Conversion Tool (SCT) → convert schema & code (stored procs, triggers, views)
   • Fix incompatible objects manually (usually 5–20 % of objects need tweaks)
2. DMS setup
   • Launch replication instance (dms.m6g.large / dms.c6g.xlarge etc.) in target region
   • Create source endpoint (old database — on-prem via VPN/Direct Connect or RDS)
   • Create target endpoint (new Aurora / RDS / DynamoDB)
   • Create task: Full Load + CDC (ongoing replication)
3. Full load phase
   • DMS copies all existing tables/data → can take hours to days (depends on size & bandwidth)
   • Old app/database still fully live — writes continue
4. CDC phase (ongoing replication)
   • DMS captures every new transaction (via log reading — Oracle LogMiner, SQL Server CDC, MySQL binlog, PostgreSQL logical replication)
   • Applies changes to target in near real-time (usually < 1–5 seconds lag)
   • You monitor lag via CloudWatch metrics
5. Validation
   • Compare row counts, checksums, sample data
   • Run business queries on both → ensure results match
6. Cut-over (maintenance window — 15 min to 4 hours)
   • Stop writes to old database (short app downtime or read-only mode)
   • Let CDC catch up (usually seconds–minutes)
   • Point application to new database endpoint
   • Start writes → go live
7. Post-migration
   • Monitor for 1–2 weeks
   • Decommission old database
   • Turn off DMS replication instance

4. Real Hyderabad Fintech Example (2026 – Very Typical)

Company: Mid-size payment gateway in Financial District Old system: On-premise Oracle 19c + 1.8 TB data, 25,000 tx/day Goal: Move to Aurora PostgreSQL in ap-south-2 → Multi-AZ, auto-scaling, cheaper, RBI-compliant

What they did:

• Used SCT → converted schema (90 % auto, 10 % manual fixes for PL/SQL → PL/pgSQL)
• Launched DMS replication instance (dms.c6g.2xlarge)
• Full load took ~28 hours
• CDC ran for 4 weeks (monitored lag < 2 seconds)
• Cut-over window: Saturday 02:00–04:00 IST → 45 min actual downtime
• Application pointed to Aurora endpoint → live

Result:

• Downtime: 45 min planned (no data loss)
• Monthly DB cost: ~₹22,000–38,000 vs previous ~₹85,000–1.2 lakh
• HA improved → Multi-AZ + read replicas
• Passed RBI audit faster (Aurora is RBI cloud-compliant)

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

• Replication instance — charged per hour (e.g., dms.m6g.large ~₹3.5–5/hour)
• Data transfer — free within same region, cross-region = standard rates
• Storage — only for target database (RDS/Aurora/S3) — DMS itself doesn’t store data
• Typical migration cost (1 TB DB, 2 weeks CDC): ₹5,000–15,000 (mostly replication instance hours)

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

Teacher’s final note (real talk – Hyderabad 2026):

DMS is the “moving company with zero furniture damage & minimal downtime” for databases.

The biggest success factor is not the tool — it’s planning:

• Test schema conversion thoroughly
• Run full-load + CDC in staging first
• Validate data after full load
• Have rollback plan (keep old DB running 1–2 weeks after cut-over)
• Monitor replication lag obsessively during CDC phase

Smart Hyderabad teams treat DMS as the safest bridge between old and new world.

Got it? This is the “how to move your database to the cloud without losing data or customers” lesson.

Next?

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

Tell me — next whiteboard ready! 🚚🗄️