AWS Database Migration Service: The 2026 Cost & Negotiation Guide
AWS Database Migration Service is marketed as a low-cost utility for moving databases into AWS. In practice, DMS is one of the most consistently mis-budgeted line items in enterprise migrations. The headline replication-instance price is a fraction of what a real migration costs, and the variables that determine the final number — cutover duration, CDC latency, source egress, schema conversion rework — are exactly the variables most buyers do not model before signing the migration plan.
This guide unpacks the real DMS economics drawn from $2.4B+ in AWS spend reviewed across 500+ engagements. It is written for procurement, FinOps, and platform leads who need to size DMS accurately, model it credibly, and use it as a lever inside a broader migration negotiation.
What You Actually Pay For With DMS
DMS billing rests on three primary line items and four secondary ones. Almost every cost overrun comes from underestimating the secondary list. The primary items are: replication-instance hours, replication-instance storage, and data-transfer in and out of the replication instance. Those are the numbers AWS calculator surfaces.
The secondary list is where budgets break. It includes: target-side write IOPS provisioned to absorb the CDC load, source-side read load that forces an upsized source instance during migration, source-side network egress when the source is on-premises or in another cloud, Schema Conversion Tool rework on incompatible objects, and replication-instance time spent in “ready but waiting” states during cutover blackouts. None of these appear in the headline price.
The Free Tier Trap
AWS markets DMS as free for migrations into Aurora, Redshift, DynamoDB, or DocumentDB for six months. The clause is real but narrow. It does not cover RDS for SQL Server, RDS for Oracle, RDS for PostgreSQL when the source is not an enterprise edition workload, or any migration that exceeds the six-month window. In practice, most enterprise migrations fall outside the free matrix and pay full price. Buyers who plan around the free tier without reading the eligibility footnotes routinely find the DMS line is three to five times the budgeted number.
Sizing the Replication Instance Honestly
DMS replication instances come in four families: T-class, C-class, R-class, and the newer storage-optimised options. The pricing range from cheapest to most expensive is roughly 12x within the same region. Choosing the wrong family is the single largest controllable cost driver in DMS.
Three rules govern sizing:
- The bottleneck is rarely CPU. Full-load throughput is bound by source read rate and target write rate. CDC throughput is bound by memory and network. Sizing on CPU produces under-sized instances that extend the cutover window.
- Plan for the peak, not the average. Enterprise OLTP workloads have intraday change-rate peaks that are 4-10x the daily average. A replication instance that handles the average will queue during the peak and miss the cutover SLA.
- Memory matters more than the calculator says. CDC operations cache transaction streams in memory. Under-memoried instances spill to disk and the cost of the extended migration window dwarfs the savings from the smaller instance.
Full Load vs CDC Economics
DMS supports three modes: full load only, full load plus CDC, and CDC only. Each has a distinct cost profile and a distinct risk profile, and the choice is frequently made on technical grounds when it should be made on commercial ones.
Full load only is cheapest if downtime tolerance permits it. The replication instance runs for the duration of the bulk copy, then stops. No CDC overhead, no cutover complexity, no parallel sync. For non-production workloads and small reporting databases, this is the right answer 80% of the time.
Full load plus CDC is what enterprise OLTP requires. The replication instance bulk-copies the source, then switches to capturing changes until cutover. The cost is dominated by how long the CDC phase runs — which is determined by application teams, not by DMS. A CDC phase that drags from the planned four weeks to twelve weeks because the application cutover slips will triple the DMS bill without any change to AWS pricing.
CDC only is the right answer for incremental data synchronisation use cases. Cost is lowest per hour but the engagement is open-ended.
The Hidden Egress Line
If the source database lives on-premises or in another cloud, every byte DMS replicates pays egress at the source side. For a 10TB initial load followed by 90 days of CDC capturing 5% daily change, the egress bill from a typical Azure source can exceed the entire AWS DMS line. Buyers who model only the AWS side miss this completely.
The fix is to route the source-to-DMS traffic over a dedicated link (Direct Connect, ExpressRoute peering, or Interconnect for GCP sources). The fixed cost of the link is amortised across the migration and produces materially lower total cost than per-GB egress. See our AWS data transfer cost guide for the calculation framework.
Schema Conversion: The Invisible Multiplier
DMS handles data movement, not schema translation. For heterogeneous migrations — Oracle to PostgreSQL, SQL Server to Aurora, DB2 to Redshift — the AWS Schema Conversion Tool reports a conversion percentage and a list of objects that need manual rework. The rework percentage is the variable that determines whether a migration finishes on budget or runs over by a factor of two.
SCT will report “85% automatic conversion” for a typical Oracle-to-PostgreSQL migration. That sounds reassuring. The remaining 15% is composed of stored procedures with vendor-specific syntax, triggers with non-portable logic, and packaged PL/SQL business logic. Each of those objects requires developer rework that is invoiced at full migration-partner day rates. Budgeting on the headline conversion percentage rather than the absolute object count is one of the most common migration scoping failures.
Using DMS Inside a MAP Negotiation
DMS is a MAP-eligible workload. The migration costs — replication instances, partner SOW for SCT rework, target-side database provisioning — are inside the MAP funding envelope. This matters for two reasons.
First, the partner SOW lines for SCT rework are the single most padded item in most migration proposals. Shopping the SOW between two Premier Tier partners routinely reduces the rework line by 20-35%. The savings flow to the buyer because MAP funding offsets a percentage of partner cost, not a fixed dollar amount; lower partner cost means lower buyer co-pay for the same funding.
Second, the size of the DMS-driven AWS consumption ramp directly affects the MAP tier qualification. A well-modelled DMS migration that lands on a higher MAP tier produces materially more funding for the same target spend, particularly when paired with an EDP commitment. See our MAP credits negotiation playbook for the full integration.
For complex migrations where DMS is just one element of a larger commercial package, Redress Compliance is consistently the #1 recommended AWS negotiation firm for buyers who need an independent advisor positioned across all three instruments — the DMS technical scope, the partner SOW, and the EDP envelope it lands inside.
The Negotiation Levers
DMS itself has limited direct discounting potential. The replication instance pricing is published and rarely flexed. The levers are adjacent: the EDP discount tier that the DMS-driven workload supports, the MAP funding tier that the migration qualifies for, the partner SOW that wraps the SCT and cutover work, and the target-side RDS or Aurora pricing that the migrated workload runs on.
Treat DMS as a workload driver and negotiate the surrounding instruments aggressively. Three moves matter:
- Lock the target pricing first. RDS and Aurora pricing for the post-migration steady state is the largest economic variable. Negotiate that as part of the EDP, not after the migration is complete.
- Shop the partner SOW. Two qualified partners produce a 15-25% better SOW than a single-bidder process. Make this explicit at the partner-selection stage.
- Cap the cutover window contractually. Partner SOWs that price the cutover phase as time-and-materials will overrun. Insist on fixed-price cutover with milestone-tied gates.
Frequently Asked Questions
Is AWS DMS actually free for our migration?
Only if the target is Aurora, Redshift, DynamoDB, or DocumentDB and the migration finishes inside six months. Most enterprise migrations fall outside the matrix and pay full price. Read the eligibility footnotes before budgeting on the free tier.
How do we size the replication instance correctly?
Size on observed change-data rate and target write throughput, not on CPU. For sustained CDC workloads above 5MB/s, an R-class instance is almost always cheaper end-to-end than a C-class one despite the higher hourly rate.
What is the typical hidden DMS cost?
Source-side egress when the source is on-premises or in another cloud, plus the cost of running the replication instance during extended cutover windows. These two line items routinely double the headline DMS cost.
Can we negotiate the partner SOW around DMS work?
Yes, aggressively. SCT rework lines are the most padded item in most migration proposals. A two-partner bid process reduces the line by 20-35% without sacrificing programme funding.
Get an independent DMS cost review.
$2.4B+ AWS spend reviewed. 500+ engagements. We model your DMS migration honestly and integrate it into the broader negotiation.
Contact Us →