# DMS → Aurora migration path decision matrix (2026)

Score each row 0–2; highest column sum is your primary path. Tie-break toward the path with lower cutover risk.

| Scenario | Homogeneous DMS (same engine) | Heterogeneous DMS + SCT | Native dump/restore + DMS CDC | Amazon DMA (fixed-price program) |
|----------|-------------------------------|-------------------------|-------------------------------|----------------------------------|
| MySQL/PostgreSQL → Aurora same engine | **2** | 0 | **2** if <500 GB and downtime OK | 1 |
| Oracle/SQL Server → Aurora PostgreSQL/MySQL | 0 | **2** | 0 | **2** if budget risk is primary |
| Need near-zero downtime | **2** full load + CDC | **2** after SCT | **2** CDC-only after seed | 1 |
| Heavy PL/SQL / T-SQL / packages | 1 | **2** SCT assessment first | 0 | **2** |
| LOB-heavy tables (>1 MB avg) | 1 — tune `LobMaxSize` / limited LOB | 1 | **2** seed LOBs offline | 1 |
| Cross-account Aurora MySQL | **2** snapshot + CDC start LSN | 1 | 1 | 0 |
| Target needs Aurora Serverless v2 (0–256 ACU) | **2** | **2** | **2** | 1 |

## Opinionated default

1. **Homogeneous:** DMS full load + CDC into Aurora Multi-AZ (or Serverless v2). Skip SCT.
2. **Heterogeneous:** Run **AWS SCT** assessment before any DMS task. If conversion effort > 8 engineer-weeks of stored-proc debt, evaluate **Amazon Database Migration Accelerator** for fixed-price scope.
3. Prefer **Aurora PostgreSQL** as heterogeneous target unless the app is MySQL-native and rewrite cost favors Aurora MySQL.

## When NOT to use DMS as the primary mover

- Source is already Aurora and you only need clone/Blue-Green — use Aurora cloning / Blue/Green deployments.
- One-time <50 GB homogeneous with acceptable downtime — `pg_dump` / `mysqldump` is simpler and cheaper.
- You need bi-directional sync indefinitely — DMS is a migration tool, not a multi-master fabric.