--- title: AWS DMS to Aurora Migration Playbook (2026): Homogeneous, Heterogeneous, and CDC Cutover description: For an on-prem MySQL estate (~1.1 TB, 340 tables), DMS full load + CDC into Aurora MySQL cut planned downtime from 6h → 18 min — LOB misconfiguration added 11 hours of rework before cutover. url: https://www.factualminds.com/blog/aws-database-migration-dms-aurora-playbook-2026/ datePublished: 2026-07-10T00:00:00.000Z dateModified: 2026-07-10T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: aws, aws-dms, amazon-aurora, amazon-rds, database-migration, migration, architecture --- # AWS DMS to Aurora Migration Playbook (2026): Homogeneous, Heterogeneous, and CDC Cutover > For an on-prem MySQL estate (~1.1 TB, 340 tables), DMS full load + CDC into Aurora MySQL cut planned downtime from 6h → 18 min — LOB misconfiguration added 11 hours of rework before 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](https://docs.aws.amazon.com/prescriptive-guidance/latest/aurora-postgresql-integration/migration.html), [Aurora console DMS migration](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_DMS_migration.html)). **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](https://aws.amazon.com/blogs/database/understanding-how-acu-minimum-and-maximum-range-impacts-scaling-in-amazon-aurora-serverless-v2/)). This is the **migration playbook** — path selection, CDC cutover, LOB traps. It is **not** the [managed database ops buyer guide](/blog/aws-managed-database-ops-rds-aurora-buyer-guide-2026/), **not** the [6 Rs strategy overview](/blog/aws-migration-strategy-choose-right-approach/), and **not** a Limitless design deep-dive. Artifacts: [path decision matrix](https://www.factualminds.com/examples/architecture-blog-2026/dms-aurora-migration/migration-path-decision-matrix.md), [cutover checklist](https://www.factualminds.com/examples/architecture-blog-2026/dms-aurora-migration/cutover-checklist.md), [cost worksheet](https://www.factualminds.com/examples/architecture-blog-2026/dms-aurora-migration/migration-cost-worksheet.csv), [architecture diagram (draw.io)](https://www.factualminds.com/examples/architecture-blog-2026/dms-aurora-migration/dms-aurora-migration-architecture.drawio). > **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](https://www.factualminds.com/examples/architecture-blog-2026/dms-aurora-migration/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](https://aws.amazon.com/blogs/database/introducing-the-amazon-database-migration-accelerator/)) | **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](https://aws.amazon.com/blogs/database/perform-cross-account-amazon-aurora-mysql-migration-with-minimal-downtime/)). ## 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](https://www.factualminds.com/examples/architecture-blog-2026/dms-aurora-migration/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](/blog/aws-managed-database-ops-rds-aurora-buyer-guide-2026/)) - Aurora Limitless shard design - NoSQL / DynamoDB migrations - Application ORM rewrite patterns beyond "fix what SCT flags" ## FAQ ### When should we NOT use AWS DMS as the primary data mover? Skip DMS for small homogeneous copies with acceptable downtime (pg_dump/mysqldump), Aurora-to-Aurora clones/Blue-Green, or indefinite bi-directional sync. DMS is a migration service, not a multi-master fabric. ### Homogeneous vs heterogeneous — how do we choose? Same engine family (MySQL→Aurora MySQL, PostgreSQL→Aurora PostgreSQL): homogeneous DMS. Oracle/SQL Server→Aurora: run AWS SCT first, then heterogeneous DMS. If PL/SQL or T-SQL debt is large, evaluate Amazon Database Migration Accelerator for fixed-price scope. ### What Aurora capacity should the target use during migration? Prefer Multi-AZ for production cutovers. Aurora Serverless v2 supports 0–256 ACUs (with optional scale-to-zero); size max ACU for cutover load tests, then tighten. This playbook is not a managed-ops buyer guide — see the RDS/Aurora ops post for day-2 operations. ### What could go wrong with CDC cutover? Flipping while CDCLatencyTarget is elevated, LOB truncation with LimitedLobMode, DDL during freeze, and validation gaps on money tables. Treat lag=0 (or agreed RPO) as a hard STOP gate. ### Do we need AWS SCT for MySQL to Aurora MySQL? Usually no. SCT matters for heterogeneous conversions (Oracle/SQL Server → Aurora PostgreSQL/MySQL) and for assessing stored-procedure rewrite effort. ### How is this different from the managed database ops buyer guide? That post covers who runs RDS/Aurora day-2. This playbook covers getting data onto Aurora with DMS/SCT and surviving cutover. --- *Source: https://www.factualminds.com/blog/aws-database-migration-dms-aurora-playbook-2026/*