AWS DMS to Aurora Migration Playbook (2026): Homogeneous, Heterogeneous, and CDC Cutover
Quick summary: For an on-prem MySQL estate (~1.1 TB, 340 tables), DMS full load + CDC into Aurora MySQL cut planned downtime from 6h to 18 min, though LOB misconfiguration added 11 hours of rework before cutover.
Key Takeaways
- For an on-prem MySQL estate (~1.1 TB, 340 tables), DMS full load + CDC into Aurora MySQL cut planned downtime from 6h to 18 min, though LOB misconfiguration added 11 hours of rework before cutover
- Aurora Serverless v2 capacity spans 0 to 256 ACUs (about 2 GiB memory per ACU), so targets can absorb cutover spikes without a permanent oversized class (ACU scaling)
- For day-2 operations see the managed database ops buyer guide, and for strategy see the 6 Rs overview
- Benchmark silhouette (not a cited client): B2B SaaS, on-prem MySQL 8, ~1.1 TB, 340 tables, peak ~4k TPS
- First DMS task used default LOB settings; 11 tables with large JSON documents failed validation
Table of Contents
AWS DMS remains the default managed path to move relational estates onto Amazon Aurora with full load + change data capture (CDC) while the source stays online (Aurora ↔ DMS integration, Aurora console DMS migration). Aurora Serverless v2 capacity spans 0 to 256 ACUs (about 2 GiB memory per ACU), so targets can absorb cutover spikes without a permanent oversized class (ACU scaling).
This is the migration playbook: path selection, CDC cutover, LOB traps. For day-2 operations see the managed database ops buyer guide, and for strategy see the 6 Rs overview. Limitless design is out of scope.
Artifacts: path decision matrix, cutover checklist, cost worksheet, architecture diagram (draw.io).
Pick the path before you click Start task
Walk the migration-path-decision-matrix.md:
| Path | Use when |
|---|---|
| Homogeneous DMS | MySQL→Aurora MySQL or PostgreSQL→Aurora PostgreSQL |
| Heterogeneous DMS + SCT | Oracle/SQL Server → Aurora; SCT assessment first |
| Seed + CDC-only | Multi-TB where bulk seed (Snowball/snapshot) is faster than DMS full load |
| Amazon DMA | Fixed-price commercial→Aurora programs when rewrite risk dominates (DMA intro) |
Opinionated take: Run SCT before any heterogeneous DMS task. Teams that “start replication and fix SQL later” usually discover conversion debt in the cutover week.
Reference flow
Source DB (on-prem / EC2 / other cloud)
│
├──► AWS SCT (heterogeneous only) ──► conversion report
│
└──► AWS DMS replication instance
│
├── full load ──► Aurora cluster (Multi-AZ / Serverless v2)
└── CDC ─────────► until lag gate ──► cutover (secret/DNS flip)For cross-account Aurora MySQL, prefer snapshot share/restore plus CDC-only from a captured LSN rather than a blind full load across accounts (cross-account pattern).
What broke: LOBs and lag vanity
Treat CDCLatencySource / CDCLatencyTarget as STOP gates. If lag is not inside your RPO, do not flip.
Cutover runbook
Use cutover-checklist.md:
- Schema freeze on source
- Lag stable near zero
- Quiesce writers
- Final validation on money / identity tables
- Flip Secrets Manager ARN / DNS
- Smoke write path
- Keep source rollback hot for the agreed window
What to Do This Week
- Classify every database: homogeneous, heterogeneous, or seed+CDC.
- For heterogeneous sources, schedule an SCT assessment before buying DMS instance hours.
- Draft the cutover checklist with named STOP owners.
- Size a Serverless v2 max ACU for a load test that mimics cutover traffic.
What This Post Doesn’t Cover
- Day-2 Aurora operations, patching, and MSP vs in-house ops (buyer guide)
- Aurora Limitless shard design
- NoSQL / DynamoDB migrations
- Application ORM rewrite patterns beyond “fix what SCT flags”
Frequently asked questions
When should we NOT use AWS DMS as the primary data mover?
Homogeneous vs heterogeneous — how do we choose?
What Aurora capacity should the target use during migration?
What could go wrong with CDC cutover?
Do we need AWS SCT for MySQL to Aurora MySQL?
How is this different from the managed database ops buyer guide?
AWS Cloud Architect & AI Expert
AWS-certified cloud architect and AI expert with deep expertise in cloud migrations, cost optimization, and generative AI on AWS.
