AWS DMS to Aurora Migration Playbook (2026): Homogeneous, Heterogeneous, and CDC Cutover

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–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. It is not the managed database ops buyer guide, not the 6 Rs strategy overview, and not a Limitless design deep-dive.

Artifacts: path decision matrix, cutover checklist, cost worksheet, architecture diagram (draw.io).

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. After LimitedLobMode + separate LOB pass, full load + CDC held CDCLatencyTarget near 0 for 40 minutes. Cutover window: planned 6 h → actual 18 min writer freeze. Modeled DMS compute on dms.r6i.xlarge ≈ $96 for the migration window (see worksheet).

Pick the path before you click Start task

Walk the migration-path-decision-matrix.md:

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

What broke — Hour 14 of full load. Validation failed on 11 JSON-heavy tables. Root cause: LOB mode truncated payloads the app treated as authoritative. Detection: DMS table statistics + row checksum mismatch on documents PK sample. Fix: reconfigure LOB handling, reload those tables, extend CDC. Cutover slipped one business day — still better than shipping truncated blobs.

Treat CDCLatencySource / CDCLatencyTarget as STOP gates, not dashboards for screenshots. If lag is not inside your RPO, do not flip.

Cutover runbook

Use cutover-checklist.md:

1. Schema freeze on source
2. Lag stable near zero
3. Quiesce writers
4. Final validation on money / identity tables
5. Flip Secrets Manager ARN / DNS
6. Smoke write path
7. Keep source rollback hot for the agreed window

What to Do This Week

1. Classify every database: homogeneous, heterogeneous, or seed+CDC.
2. For heterogeneous sources, schedule an SCT assessment before buying DMS instance hours.
3. Draft the cutover checklist with named STOP owners.
4. 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”