AWS DMS replicates a running production database into RDS, Aurora, or another target while the source keeps serving traffic. This guide covers what DMS actually does, where you also need the Schema Conversion Tool for heterogeneous moves like Oracle→Aurora, the full assess→convert→full-load→CDC→cutover→validate workflow, replication instances vs DMS Serverless, the pitfalls that derail real migrations (LOBs, huge tables, schema edge cases), and what it costs. A vetted AWS partner runs it for you, MAP-funded.
DMS is a managed replication service. You point it at a source database and a target database, and it moves the data between them. The thing that makes it useful for production migrations rather than just one-time copies is that it does two phases back to back: a full load of existing data, then continuous change data capture.
In the full load phase, DMS reads every row of the tables you selected and writes them into the target. This is a straight bulk copy — it can run multiple tables in parallel, and for a large database it is the slowest phase (hours to a day or two depending on volume, indexes, and the size of the replication instance).
In the change data capture (CDC) phase, DMS reads the source database's transaction log — the redo log on Oracle, the binlog on MySQL, the WAL on PostgreSQL, the transaction log on SQL Server — and replays every committed change onto the target. CDC starts capturing from a log position recorded at the moment full load began, so nothing is missed in the handoff. The target stays continuously caught up to the source, typically within seconds of replication lag.
This two-phase design is why DMS migrations have such short cutover windows. The bulk of the data and all the ongoing writes are already on the target before you cut over. The actual cutover is: stop writes on the source, wait for CDC lag to hit zero (drain the last few transactions), validate, then repoint the application connection string at the new database. For most workloads that is a window of minutes, scheduled into a low-traffic period, rather than the multi-hour outage a dump-and-restore would require.
DMS does not touch your application code, your VPC routing, or your DNS — it moves data only. The surrounding work (networking between source and AWS, the application cutover, rollback planning) sits around DMS, not inside it. That is the part a migration partner orchestrates.
DMS bulk-copies your data once (full load), then live-streams every subsequent change off the transaction log (CDC) until you flip the application to the new database — so the source never goes down during the migration and the cutover itself is measured in minutes.
Almost every DMS question reduces to one fork: are the source and target the same database engine, or different ones? The answer determines whether DMS alone is enough or whether you also need the AWS Schema Conversion Tool, and it is the single biggest driver of project effort and risk.
A homogeneous migration keeps the same engine: PostgreSQL→RDS for PostgreSQL, MySQL→Aurora MySQL, SQL Server on-prem→RDS for SQL Server, MongoDB→Amazon DocumentDB. Because the engines match, the schema, data types, functions, and stored procedures are already compatible. You typically migrate the schema with the engine's own native tools (pg_dump --schema-only, mysqldump --no-data) and then use DMS purely to move the data with full load + CDC. These are the fast ones — frequently a one-to-three-week engagement end to end.
A heterogeneous migration changes the engine: Oracle→Aurora PostgreSQL, SQL Server→Aurora PostgreSQL or Aurora MySQL, Oracle→RDS for PostgreSQL, Db2→Aurora. Here the schema is not portable. Oracle's NUMBER, DATE, CLOB, sequences, PL/SQL packages, triggers, and proprietary functions have no one-to-one PostgreSQL equivalent. This is where the AWS Schema Conversion Tool (SCT) does the heavy lifting.
The workflow ordering matters: for heterogeneous migrations you run SCT first to convert and deploy the schema onto the empty target, fix the manual items, and only then point DMS at the source to load and replicate the data into that prepared schema. DMS moves data into a schema that already exists; it is not a schema-conversion tool itself. SCT and DMS are two tools doing two jobs, and the Oracle→Aurora path needs both — which is exactly why that migration is a senior engagement, not a weekend task.
Assesses convertibility first. SCT connects to the source and produces a Migration Assessment Report that scores how much of the schema converts automatically and itemizes what does not. This report is the honest readout of how hard the migration will be — a clean Oracle schema might be 90%+ auto-convertible; one stuffed with PL/SQL business logic might be 60%.
Converts the schema. SCT translates tables, indexes, views, sequences, and data types into the target dialect, and converts stored procedures, functions, and triggers from PL/SQL or T-SQL into PL/pgSQL (for Aurora/RDS PostgreSQL) or the target equivalent.
Flags the manual remainder. Anything SCT cannot auto-convert — complex PL/SQL packages, Oracle-specific features like autonomous transactions, certain analytic functions — is listed as an action item for an engineer to rewrite by hand. This manual remainder is the actual work and the actual schedule risk in a heterogeneous migration. Anyone who tells you Oracle→Aurora is "just point DMS at it" has not done one.
A production DMS migration follows the same six-stage arc whether it is homogeneous or heterogeneous — the heterogeneous version just spends real time inside the "convert schema" stage. Here is what each stage involves.
A migration partner runs this as a rehearsed sequence: every stage before cutover is repeatable and reversible, so the team does it on a staging target first, measures it, fixes what breaks, and only then runs the production cutover with known timings.
Until validation passes, the original source database stays untouched and writable. If the new target misbehaves, you repoint the application back to the source — which never went anywhere — and the blast radius is the few minutes of writes that happened post-cutover. A migration without a tested rollback path is not a finished plan.
DMS has a small set of moving parts. Understanding them tells you what you are provisioning, what it costs, and why instance sizing is the lever that decides how fast the migration runs.
A replication instance is the managed compute that does the actual reading, transforming, and writing. You pick an instance class (the dms.r-family memory-optimized sizes are typical, e.g. dms.r6i.large up through dms.r6i.4xlarge for heavy loads) and it runs inside your VPC. Bigger instances run full load and CDC faster and hold more in-flight changes in memory, which matters for high write volumes and for LOB-heavy tables. Under-sizing the replication instance is one of the most common reasons a migration runs slow or a CDC backlog builds up.
An endpoint is a connection definition — one for the source, one for the target — holding the host, port, credentials, and engine type. You can test endpoint connectivity from the console before running anything, which catches the usual networking and security-group problems early rather than mid-load.
A migration task binds a source endpoint, a target endpoint, and a replication instance together with the rules: which schemas and tables to include (table mappings), what to rename or filter (transformation rules), the migration type (full load only, CDC only, or full load + CDC), and LOB-handling settings. A migration is usually one or more tasks running on the instance.
DMS Serverless removes the need to pick and manage a replication instance. Instead of provisioning a fixed size, you set a capacity range in DMS capacity units and DMS automatically provisions, scales, and shuts down the underlying compute for the migration. It scales up during a heavy full load and back down during a quiet CDC tail.
When to use Serverless: you do not want to hand-tune instance sizing, your load profile is uneven, or you are running many tasks and would rather not capacity-plan each one. When a provisioned instance still wins: very large, sustained, predictable loads where a hand-picked instance class is more cost-predictable, or migrations needing fine-grained control over instance-level settings. For most teams in 2026, Serverless is the sensible default and a provisioned instance is the deliberate exception.
DMS is reliable, but production databases are messy, and a handful of issues account for most stalled migrations. None of them are mysteries — they are known traps that an experienced partner plans around from day one rather than discovering at 2am during cutover.
The common thread: none of these are reasons not to use DMS — they are reasons to have someone who has hit all of them before run the migration. A partner who has done a dozen Oracle→Aurora cutovers already has the LOB strategy, the large-table segmentation, the sequence-reset checklist, and the rollback rehearsal as standard practice.
DMS pricing surprises people in a good way: the service itself is inexpensive. The cost of a migration is overwhelmingly the engineering around it, and that is exactly the part AWS MAP funding is designed to offset.
You pay for the replication instance (per hour for the instance class, on only for the migration window — days to a few weeks, then you delete it) or for DMS Serverless capacity (per DMS capacity unit-hour, scaling with the load). You also pay for the instance's storage and for data transfer if the source is outside AWS or crosses regions. The Schema Conversion Tool itself is free to download and run. For a typical mid-size migration the raw DMS bill is often in the low hundreds of dollars for the whole engagement — a rounding error next to the value of the database.
The target database is a separate, ongoing cost — your new RDS or Aurora instance, which you would be paying for anyway as the home of the migrated workload. And for Oracle→Aurora specifically, the headline economics are not the DMS bill at all: they are eliminating Oracle licensing. Moving off Oracle to Aurora PostgreSQL can remove six- or seven-figure annual license and support costs, which is why heterogeneous migrations off Oracle have such a strong business case even though they are the hardest engineering.
The real spend is people: schema conversion, resolving SCT's manual items, building and validating the DMS tasks, rehearsing the cutover, and the on-call cutover itself. That engineering is what a partner provides — and under AWS MAP it is what AWS funds.
The AWS Migration Acceleration Program (MAP) funds migrations in phases — AWS frequently covers the Assess phase outright and credits a large share of the Mobilize and Migrate work, with the partner paid through MAP. For qualifying migrations (typically a meaningful post-migration AWS-spend commitment) that means the database move is run for you at little-to-no cost. Where MAP funding does not apply, CloudRoute is still a vetted-partner referral that de-risks the cutover. See how AWS credits/MAP funding works and AWS POC funding explained.
You do not have to run DMS yourself, and for anything heterogeneous you probably should not learn SCT on your production Oracle database. CloudRoute routes you to a vetted AWS partner who has done your exact source→target migration and runs it end to end.
CloudRoute is a routing layer, not an agency. You tell us the source (Oracle, SQL Server, MySQL, on-prem Postgres, MongoDB) and the target you want (Aurora PostgreSQL, RDS, DocumentDB), your rough data size, and your downtime tolerance. We match you to a partner with a track record on that specific pair and the regions you operate in, and the partner runs the full workflow — assess, SCT conversion, DMS task build, CDC validation, rehearsed cutover, post-migration soak — with you.
Because the partner is funded through AWS MAP for qualifying migrations, the cost to you is little-to-nothing: AWS pays for the assessment and credits the bulk of the migration work. You get a senior team who has hit every LOB, large-table, and sequence-reset pitfall before, instead of discovering them live. The honest version: MAP funding applies to qualifying migrations; where it does not, this is still a de-risked, vetted referral rather than you hiring blind.
If you want the persona-level detail on how migrations are scoped, funded, and run, see the CloudRoute migration track. For the surrounding AWS foundation a migration lands into — networking, accounts, guardrails — the AWS landing zone and AWS DevOps guides cover what a partner sets up around the database.
The fork that decides everything: same engine or different engine. Homogeneous is mostly a DMS-only data move; heterogeneous adds SCT, manual schema work, and real schedule risk. Here is how the two compare across the variables that actually matter.
| Variable | Homogeneous (e.g. MySQL→Aurora MySQL) | Heterogeneous (e.g. Oracle→Aurora PostgreSQL) |
|---|---|---|
| Engine change | Same engine, same dialect | Different engine and SQL dialect |
| Tools needed | DMS only (+ native schema dump) | SCT to convert schema/code, then DMS to move data |
| Schema portability | Carries over directly | Must be translated; some of it by hand |
| Stored procs / triggers | Compatible as-is | PL/SQL → PL/pgSQL conversion; complex ones rewritten manually |
| Main effort driver | Data volume + LOBs + large tables | SCT's manual remainder + validation of converted code |
| Cutover downtime | Minutes (full load + CDC) | Minutes (full load + CDC) — same cutover mechanics |
| Typical timeline | 1–3 weeks end to end | 6–16+ weeks depending on schema complexity |
| Headline business case | Managed service, less ops, scale | Eliminate Oracle licensing (often six/seven figures/yr) |
| Risk profile | Low — well-trodden path | Higher — schema edge cases dominate; assess first |
Situation: Oracle license renewal was the single largest line item on the infra budget and growing. The schema was heavy: ~40 PL/SQL packages, sequences everywhere, a handful of CLOB-heavy document tables, and three tables over 200M rows. The team wanted Aurora PostgreSQL to kill the license cost but had no in-house Oracle-to-Postgres conversion experience and could not afford more than a short maintenance window on a 24/7 product.
What CloudRoute did: Routed within 24 hours to a partner with multiple Oracle→Aurora cutovers on record. Partner ran SCT first: assessment report scored the schema ~82% auto-convertible and itemized the rest. Over the engagement they converted the schema, hand-rewrote the complex PL/SQL packages into PL/pgSQL, set DMS to full-LOB mode for the document tables and range-segmented the three large tables into parallel sub-tasks, then ran full load + CDC into the prepared Aurora schema. The whole flow was rehearsed twice on staging to measure cutover timing and confirm rollback. Filed under AWS MAP — AWS funded the Assess phase and credited the bulk of the Migrate work.
Outcome: Production cutover ran in a planned ~12-minute write-freeze: CDC lag drained to zero, sequences were advanced past the migrated max, validation checksums passed, app repointed to Aurora. Oracle license eliminated at the next renewal (~$280K/yr removed). DMS's own bill for the migration window was under $400; the engineering was MAP-funded, so cost to the customer was effectively zero.
engine: Oracle 19c → Aurora PostgreSQL · data: ~900 GB · cutover downtime: ~12 min · license saved: ~$280K/yr · cost to customer: ~$0 (MAP-funded)
Tell us your source and target. CloudRoute routes you to a vetted AWS partner who has run your exact migration with DMS and SCT — full load, CDC, rehearsed cutover, validated. For qualifying migrations AWS MAP funds the work, so the cost to you is little-to-nothing.