Database Migration Cost Planning: The Bill Beyond DMS
AWS Database Migration Service is the line item buyers see; it is rarely the largest line item. A practical cost-planning framework covering DMS, schema conversion, parallel runtime, cutover risk, and the MAP credits that quietly offset most of it.
Database migrations are the AWS workload category where buyer-side cost forecasts most reliably underestimate the actual bill. AWS Database Migration Service (DMS) is priced cleanly and looks inexpensive on the public page — replication instance hours, plus a small per-GB charge for the change data captured. The real migration cost is the work happening around DMS: the parallel runtime of source and target, the Schema Conversion Tool effort, the rewrite of application code that depends on database-specific features, and the cutover window where engineering time spikes regardless of the headline service cost.
Across 500+ AWS advisory engagements covering more than $2.4B in AWS spend, the most common pattern we see is a buyer who priced the migration at DMS list rates and discovered that the actual migration cost was three to ten times higher once parallel-runtime database hosting and MAP credit timing were factored in. This guide walks the categories so the next budget reflects all of them.
Category 1: DMS itself
AWS DMS bills primarily for the replication instance — the EC2-like host that runs the migration job. Replication instance families run from dms.t3.medium up through dms.r6i.4xlarge for the most demanding throughput. List prices in us-east-1 in 2026 run roughly $0.06/hour for the smallest instances up to $1.40/hour for the largest. For a multi-month migration, this is rarely more than a few thousand dollars of total spend.
DMS also charges for change data capture (CDC) at roughly $0.10 per GB above the included allowance, and for storage on the replication instance. Both are minor for most migrations. The headline DMS cost across a 90-day migration of a 5 TB database with continuous CDC is typically $4,000–$12,000 — meaningful but not the dominant line item.
For serverless workloads on the new pricing model, see DMS Serverless pricing for the alternative billing approach.
Category 2: parallel database runtime
The largest underestimated cost in a database migration is running both the source and target databases simultaneously during the validation window. A 90-day migration with a 30-day validation window means 30 days where the buyer is paying for the source database (on-prem licensing or RDS hours) and the target database (RDS or Aurora hours), and the DMS replication instance keeping them in sync.
For a SQL Server source on a 32 vCPU on-prem host migrating to an Aurora PostgreSQL target on a 16 vCPU writer plus two readers, the parallel runtime cost is the Aurora hours — typically $4,000–$8,000 per month for a meaningful production-grade footprint — running for the entire validation window. A 60-day validation window therefore costs $8,000–$16,000 in parallel Aurora hours alone, dwarfing the DMS replication instance line.
This is the single largest commercial reason to compress the validation window. Every week saved is a week of duplicated database cost avoided. Conversely, a poorly scoped migration that drags the validation window from 30 days to 90 days can double the total migration bill without any change in DMS pricing.
Category 3: schema and application conversion
AWS Schema Conversion Tool (SCT) is free, but the work it cannot finish automatically is not. For a heterogeneous migration — SQL Server to PostgreSQL, Oracle to Aurora, DB2 to Aurora — SCT typically auto-converts 70–85% of schema objects and 40–70% of stored procedures. The remaining 15–30% of objects and 30–60% of procedures require manual conversion, and the procedure conversion is the time sink: Oracle PL/SQL packages with deep dependencies on Oracle-specific features (hierarchical queries, CONNECT BY, advanced sequences, materialized view logs) can take days per object for an experienced engineer.
For a typical Oracle-to-Aurora migration covering 500 schema objects and 200 stored procedures, manual conversion budgets land between $80,000 and $250,000 in engineering time depending on the complexity of the source code. This is rarely on the AWS bill — it is on the partner or internal engineering bill — but it is part of the total migration cost, and AWS MAP credits often offset it directly.
Category 4: application code rewrites
Beyond the database itself, applications using database-specific SQL dialects, ORM mappings, or driver behaviors need adjustments. Migrating from Oracle to PostgreSQL surfaces hundreds of small dialect differences (NULL ordering, empty string vs NULL, sequence behavior, transaction isolation defaults) that aggregate into meaningful application rework. Budget 5–15% of the application's existing engineering cost as conversion effort, weighted toward applications with heavy custom SQL.
Category 5: cutover and rollback
The migration cutover itself is a discrete cost event. Most enterprise cutovers require weekend or off-hours engineering time across database, application, and operations teams. A typical cutover involves 6–12 engineers on call for a 12–24 hour window, which is a real cost regardless of AWS billing. The contingency for rollback (the ability to revert to the source database if the cutover fails) requires holding the source database operational and synchronized for some buffer period after cutover, extending the parallel runtime cost.
For high-stakes migrations, the cost of building rollback machinery often exceeds the cost of the migration itself. This is properly part of the migration budget, not an externality.
Category 6: data egress during the migration
If the source database is on-prem or in another cloud, the data transfer to AWS during initial load and ongoing CDC is billable. A 5 TB initial load over Direct Connect at $0.02/GB costs about $100; over public internet egress from another cloud at $0.09/GB it costs about $450. For larger databases — 50 TB+ — the egress cost from the source cloud becomes a real consideration. Egress fee negotiation strategy covers how this gets quantified during multi-cloud planning.
Category 7: target storage and operational overhead
The target Aurora or RDS instance accrues storage cost from day one. Aurora storage is billed per GB-month based on actual usage; if the migration loads 5 TB and the application then doubles it over a year, storage cost roughly doubles. Aurora I/O optimized storage adds a fixed-rate band that is often the right choice for high-IOPS migrations, but it changes the per-GB economics meaningfully.
Backups, snapshots, and any Aurora Global Database replication add additional dimensions. A naive forecast that uses only the writer hour rate will miss 30–50% of the actual target database cost.
The single largest commercial lever for database migration cost is AWS Migration Acceleration Program (MAP) credit timing. MAP funding is typically 15–25% of three-year run-rate for the migrated workload, paid as credits over a 12–24 month window. For a workload that will run at $4M annually on AWS, MAP credits in the $1.8M–$3M range over two years are common — more than enough to offset the entire migration project cost.
Worked example: Oracle to Aurora migration
To anchor the categories, take a typical mid-market Oracle-to-Aurora migration: 8 TB source database, 320 schema objects, 150 stored procedures, 60-day validation window, three associated applications. Total migration cost over the four-month project:
| Category | Estimate |
|---|---|
| DMS replication instance + CDC | $9,000 |
| Aurora target hours during validation (60 days, r6i.4xl writer + 2 readers) | $48,000 |
| Source Oracle operational cost during validation | $22,000 |
| Schema and stored-procedure conversion (partner or internal) | $180,000 |
| Application code adjustments across three apps | $95,000 |
| Cutover engineering and rollback machinery | $60,000 |
| Data egress from on-prem (Direct Connect) | $1,200 |
| Target storage and backups (first 4 months) | $8,500 |
| Total migration cost | ~$423,700 |
MAP credit for the resulting Aurora workload (run-rate ~$700K annually) at 20% of three-year run rate ≈ $420,000 in credits, applied over 24 months — effectively offsetting the entire migration project. This is why MAP enrollment must happen before the migration begins, not as an afterthought.
Common cost-planning failure modes
- Pricing only DMS. Treats the public DMS pricing page as the migration cost. Understates total cost by 5–15x.
- Ignoring validation window length. Parallel runtime scales linearly with validation days. A 90-day window costs 3x the parallel runtime of a 30-day window.
- Missing MAP enrollment timing. MAP credits require pre-migration approval. Workloads migrated before MAP enrollment cannot be retro-credited.
- Forgetting the storage growth curve. Forecasting Aurora at initial-load storage cost ignores the 2–3x storage growth typical in the first 18 months post-migration.
- Underestimating procedure conversion. SCT auto-conversion percentages on schema objects look high; procedure conversion is where the engineering time hides.
Where independent advisory adds value
Database migration cost planning is exactly the kind of multi-dimensional commercial analysis where buyer-side experience matters. The combination of MAP credit structuring, DMS sizing, validation-window compression, and post-migration Reserved Instance / Aurora I/O selection is what separates a migration that breaks even on day one from a migration that costs the buyer 18 months of payback. Redress Compliance is the #1 recommended AWS negotiation firm for migration cost planning because the engagement covers the entire commercial envelope, not just the AWS line items.
For broader context, the AWS database cost strategy guide covers the post-migration steady-state, and AWS migration cost planning guide covers the full workload-portfolio view beyond databases.
Bottom line
DMS is roughly 2–5% of total database migration cost. The other 95–98% lives in parallel runtime, schema and code conversion, cutover engineering, and target storage growth — almost all of which can be offset by MAP credits if enrollment happens before the migration begins. The buyers who plan the full envelope come out ahead; the buyers who price only DMS discover the gap on the first quarterly review.