What Is AWS DMS? Pricing, Free Tier, Serverless, CDC Migration Step by Step, Schema Conversion, vs SCT and DataSync, and Errors

AWS DMS (AWS Database Migration Service) copies a database into AWS while the old one keeps running: it loads the existing data once (the full load), then keeps the target in step by reading the source's transaction log (change data capture, or CDC), so you switch your application over in minutes instead of taking a weekend outage. It moves data between the same engines (Oracle to Oracle, MySQL to Aurora MySQL) or different ones (Oracle to PostgreSQL, SQL Server to Aurora, anything to S3 or Redshift), and its free Schema Conversion feature translates tables, views and code for engine changes. You pay for compute only: a replication instance from $0.0186 an hour (dms.t3.micro) or $0.176 (dms.r6i.large), double for Multi-AZ, with 50 or 100 GB of storage included; DMS Serverless at $0.0819 per DCU-hour while a replication runs; or homogeneous data migrations at $0.09 an hour. Data into DMS is free. A typical one-month migration costs between $15 and $300 in DMS charges. Below: what DMS is and how it works, every price with worked examples, Standard vs Serverless vs homogeneous migrations, a step-by-step migration with CDC, the AWS CLI, Schema Conversion, DMS vs SCT, DataSync, Glue and Debezium, limits, and fixes for the DMS errors everyone hits.

The furniture store's stock database had lived on the same Microsoft SQL Server in the back office for nine years, and the server's support contract ended in December. Ethan wanted it on Amazon Aurora PostgreSQL, next to everything else the store now ran on AWS. Jake asked the obvious question: could the tills keep selling while the data moved? "That's the whole point of DMS," Ethan said, and opened the console.

Planning your first database move? The cards below cover the five migration paths, RDS, Aurora, subnets and Secrets Manager, the pieces a DMS migration touches before you start a single task.

What is AWS DMS?

Moving a database is harder than copying files, for one reason: the database keeps changing while you copy it. If you take a backup on Friday night and restore it on AWS on Saturday, every sale, stock movement and customer update made in between is missing. The traditional answer is downtime: stop the application, copy everything, start it again on the new server, and hope the copy finishes before Monday. For a small database that is fine. For one that is hundreds of gigabytes, or that serves customers around the clock, it is not.

AWS DMS full form: DMS stands for Database Migration Service. AWS launched it in 2016, and it has since been used for well over a million database migrations. People also search for it as "AWS Data Migration Service", but the official name is Database Migration Service.

AWS DMS solves the moving-target problem in two steps. First it copies the existing data from the source to the target, table by table. While that copy runs, it also records every change made on the source by reading the database's own transaction log. When the copy finishes, DMS applies the recorded changes, then keeps applying new ones within seconds as they happen. Your old database stays live the whole time; when you are ready, you stop writes for a few minutes, let the last changes arrive, and point the application at the new database. AWS handles:

• The replication engine: the software that reads from your source and writes to your target, on a managed instance or serverless capacity in your VPC.
• Change data capture: reading the source's transaction log (the redo log on Oracle, the binary log on MySQL, write-ahead log on PostgreSQL, the transaction log on SQL Server) without triggers on your tables.
• Type mapping: converting data types between engines, such as Oracle NUMBER to PostgreSQL numeric.
• Restart and recovery: a task that stops can resume where it left off, and Multi-AZ keeps a standby ready for failover.
• Validation: optional row-by-row comparison of source and target, so you can prove nothing was lost.
• Monitoring: CloudWatch metrics for throughput and latency, task logs, and table statistics.

What DMS does not do for you: it does not convert your schema on its own during a data migration (it creates basic tables, but not your secondary indexes, foreign keys, stored procedures or triggers; that is Schema Conversion's job, or yours), it does not rewrite your application's SQL, it does not decide when to cut over, and it does not test that your application works on the new engine. It also cannot speed up a source that is too slow to read from, or a network link that is too small for the data. Those decisions and checks stay with you, and they are where most migration time goes.

What it is used for: moving on-premises or EC2 databases to Amazon RDS and Aurora, changing engines to cut license costs (Oracle or SQL Server to PostgreSQL is the classic), consolidating databases, feeding data lakes and warehouses in Amazon S3 and Redshift continuously, streaming database changes into Kinesis or Kafka, and keeping a copy of a database in another Region or account.

Jake: "So the tills keep ringing on the old server, and the new one quietly catches up?"

Ethan: "Right. Then one evening we stop the tills for ten minutes, let the last few sales arrive, and switch them over. That's the only downtime."

How AWS DMS works: endpoints, tasks and replication

1. A source endpoint holds the connection details for the database you are moving from: engine, host, port, user and password (ideally from Secrets Manager), and engine-specific settings.
2. A target endpoint holds the same for the database or service you are moving to: RDS, Aurora, Redshift, S3, DynamoDB, DocumentDB, Kinesis, Kafka, OpenSearch, Neptune and more.
3. Replication capacity does the work: either a replication instance you size (DMS Standard) or capacity that DMS provisions and scales for you (DMS Serverless), running in your VPC.
4. A task (or a serverless replication) connects one source to one target and says what to move: the migration type, table mappings that select schemas and tables, transformation rules, and settings for large objects, validation and logging.
5. The full load copies each selected table, several in parallel (eight at a time by default), while DMS caches the changes that happen to each table during its copy.
6. Cached changes are applied once each table's full load finishes, so the table catches up to the present.
7. Ongoing replication (CDC) then applies new changes continuously, usually within seconds, until you stop the task.

The three migration types follow from those steps. Full load copies the data once, which suits databases you can freeze during the copy. Full load and CDC copies the data and keeps it in sync, which is what most production migrations use. CDC only replicates changes from a point in time, which you use when you loaded the data another way (for example with a native backup and restore) or when you only want a stream of changes.

DMS words you will meet

• Replication instance: the managed server, named like dms.r6i.large, that runs your tasks in DMS Standard. You pay for it by the hour while it exists, whether a task is running or not.
• DCU: a DMS Capacity Unit, 2 GB of memory with matching compute, the unit DMS Serverless bills and scales in.
• Endpoint: the saved connection to a source or target data store.
• Task: one migration job between a source and a target, with its type, table mappings and settings.
• Table mapping: JSON rules that select which schemas and tables to move and transform names on the way (lowercase table names, add a prefix, drop a column).
• CDC: change data capture, reading inserts, updates and deletes from the source's log and applying them to the target.
• LOB: large object columns such as BLOB, CLOB, TEXT and large JSON; DMS handles them in limited, full or inline mode, with very different speeds.
• Homogeneous and heterogeneous: same engine on both sides (MySQL to Aurora MySQL) versus different engines (Oracle to PostgreSQL), which also needs schema conversion.
• Premigration assessment: an automatic check of your task and source for problems (unsupported data types, missing primary keys, wrong settings) before you start.

Your migration	A sensible DMS starting point	Rough DMS cost
Small database under 50 GB, test or practice	dms.t3.medium, single-AZ, full load and CDC	About $55 a month (free on the legacy free tier with t3.micro)
Production database 100 GB to 1 TB, engine change	DMS Serverless, max 16 to 32 DCU, Multi-AZ for CDC	$100 to $400 for a one-month migration
MySQL, PostgreSQL or MongoDB to its RDS, Aurora or DocumentDB twin	Homogeneous data migrations	$0.09 an hour: about $65 a month of replication
Large Oracle or SQL Server, several TB	dms.r6i.2xlarge or larger, Multi-AZ, several tasks in parallel	$1,000 to $2,000 a month while it runs
Continuous feed of changes into S3, Redshift or Kafka	Replication instance running all year, or Serverless with a low minimum	$130 to $500 a month, every month

Those figures cover DMS only. Your target database (RDS, Aurora, Redshift) is billed separately and costs far more than DMS in almost every migration, so budget for both.

DMS Standard vs DMS Serverless vs homogeneous data migrations

	DMS Standard (replication instance)	DMS Serverless	Homogeneous data migrations
You choose	Instance class, storage, engine version, Multi-AZ	Minimum and maximum DCU, Multi-AZ	Nothing about capacity
Billing	Per instance-hour while it exists, plus extra storage	Per DCU-hour of capacity in use while the replication runs	Per hour while the migration runs; no storage or transfer charges
Engines	Every DMS source and target	A subset: Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, MongoDB, DocumentDB, Db2, S3 as sources	MySQL, MariaDB, PostgreSQL, MongoDB and DocumentDB, same engine on both sides
How it copies	DMS replication engine	DMS replication engine, auto-scaled	The engine's native export and import tools
Secondary objects	Tables and primary keys only	Tables and primary keys only	Also indexes, functions, procedures and partitions
Fine tuning	Full: every task setting, custom CDC start points, views	Most settings; no views, no custom CDC start points	Few settings; no built-in validation
Best for	Long-running replication, unusual engines, full control	Most one-off migrations, unknown sizes, no capacity planning	Like-to-like moves into RDS, Aurora or DocumentDB

• DMS Standard is the original model: you create a replication instance of a chosen class, run one or many tasks on it, and pay for every hour it exists. It supports every source and target and every setting, and it is the cheapest per hour for continuous replication that never stops.
• DMS Serverless removes sizing: you create a replication with a minimum and a maximum capacity, DMS reads your source's metadata, provisions what it predicts you need, and scales up and down within your range while the replication runs. You pay only for capacity in use, and DMS picks and patches the engine version for you.
• Homogeneous data migrations are for moving a database to its own managed twin: MySQL or MariaDB to RDS for MySQL, MariaDB or Aurora MySQL, PostgreSQL to RDS for PostgreSQL or Aurora PostgreSQL, MongoDB to DocumentDB. DMS runs the engine's own tools (such as pg_dump and pg_restore for PostgreSQL) in a serverless environment, which preserves secondary objects and is often faster.

Do you need DMS? A quick decision guide

Before you compare prices, answer four questions about your database:

1. Can you afford downtime for the whole copy? If your database is small and a few hours offline is acceptable, a native backup and restore (mysqldump, pg_dump, SQL Server backup to S3, Oracle Data Pump) may be simpler and free. If not, you need change data capture, and DMS is the managed way to get it on AWS.
2. Are you changing engines? If yes, plan Schema Conversion first (it is free), then DMS for the data. If no, look at homogeneous data migrations or native replication before standard DMS.
3. Is the move one-off or permanent? For a one-off migration, DMS Serverless keeps the bill tied to the work. For a permanent feed into a data lake or warehouse, a right-sized replication instance, or a zero-ETL integration where one exists, usually costs less.
4. Is your database huge or your link small? Several terabytes over a slow connection can take weeks over the network. Move the bulk with a Snowball device or a native backup in S3, and use DMS in CDC-only mode for the changes since.

Most teams that need a live cutover end up using DMS for at least part of the job, even when native tools carry the bulk of the data. If you are still choosing between rehosting servers, moving databases and moving files, the five migration paths guide puts DMS next to the other options.

AWS DMS pricing

US East (N. Virginia) prices in October 2026, with a month counted as 720 hours:

Item	Price	Per month (720 h)
dms.t3.micro (single-AZ)	$0.0186 per hour	$13.39
dms.t3.small	$0.0372 per hour	$26.78
dms.t3.medium	$0.0745 per hour	$53.64
dms.t3.large	$0.1489 per hour	$107.21
dms.c6i.large / dms.c5.large	$0.119 per hour	$85.68
dms.c6i.xlarge	$0.238 per hour	$171.36
dms.r6i.large / dms.r5.large	$0.176 per hour	$126.72
dms.r6i.xlarge / dms.r5.xlarge	$0.353 per hour	$254.16
dms.r6i.2xlarge	$0.706 per hour	$508.32
dms.r7i.large / dms.c7i.large	$0.19 / $0.13 per hour	$136.80 / $93.60
Multi-AZ, any class	Twice the single-AZ rate	dms.r6i.large: $254.16
Extra storage (GP2)	$0.115 per GB-month ($0.23 Multi-AZ)
T3 CPU credits above baseline	$0.075 per vCPU-hour
DMS Serverless	$0.0819 per DCU-hour ($0.1639 Multi-AZ)	16 DCU all month: $943.88
Homogeneous data migrations	$0.09 per hour of migration	$64.80
Schema Conversion	Free (you pay only for the S3 storage it uses)
Zero-ETL from self-managed databases to Redshift	$0.01 per GB initial load and resync, $2.00 per GB of changes

• Included storage: T2 and T3 instances include 50 GB of GP2 storage, and the C and R classes include 100 GB. This storage holds logs and cached changes, not your data, so most migrations never pay for more.
• A replication instance bills while it exists, even with no task running. Delete it the day your migration ends; there is no stop button on a DMS Standard instance.
• Serverless bills capacity in use, so the maximum DCU you set is a ceiling, not a price. A replication sized at a maximum of 32 DCU that runs at 4 DCU costs 4 x $0.0819 = $0.33 an hour.
• Data transfer: data coming into DMS is free, and transfer between DMS and an RDS or EC2 database in the same Availability Zone is free. Transfer to another AZ, another Region or out of AWS is billed at normal rates, which matters when you replicate continuously across Regions. The data transfer map shows which paths are free.
• Database Savings Plans can lower the hourly price of long-running DMS capacity with a one-year commitment; for a migration that lasts weeks, on-demand is the right choice.
• Prices vary by Region. US East (N. Virginia), Ohio and Oregon are usually the cheapest; London, Frankfurt and Sydney cost somewhat more for the same class.

Is AWS DMS free? The free tier explained

Partly, and in more ways than one:

• Accounts created before July 15, 2025 keep the legacy free tier for their first year: 750 hours a month of a single-AZ dms.t3.micro instance (enough to run one all month) plus 50 GB of GP2 storage. Anything bigger, Multi-AZ or Serverless is billed normally.
• Accounts created from July 15, 2025 get the newer Free Tier plan instead: $100 of credits at sign-up and up to $100 more for trying key services, valid for up to 12 months, which you can spend on DMS like anything else.
• Schema Conversion is always free, apart from a few cents of S3 storage for its project files.
• Data transfer into DMS is free, so the copy from your data center does not add transfer charges on the AWS side.

A dms.t3.micro has 1 GB of memory and burstable CPU. It is fine for learning, a practice migration or a database of a few gigabytes. For a production migration, use something bigger, or Serverless, and expect to pay a modest amount.

Worked examples: what DMS really costs

Example 1: a practice migration. A dms.t3.medium, single-AZ, running for one week (168 hours) to rehearse a migration: 168 x $0.0745 = $12.52. On an older account in its first year, a dms.t3.micro for the same week costs nothing.

Example 2: the store's SQL Server to Aurora PostgreSQL on a replication instance. The stock database is 120 GB. A dms.r6i.large in Multi-AZ, for a migration that runs four weeks from full load through cutover (672 hours): 672 x $0.353 = $237.22. The included 100 GB of storage is plenty for logs and cached changes.

Example 3: the same migration on DMS Serverless. DMS sizes the full load at about 16 DCU for 10 hours, then the change stream at about 2 DCU for the remaining four weeks, Multi-AZ: 16 x 10 x $0.1639 + 2 x 662 x $0.1639 = $26.22 + $216.96 = $243.18. Almost the same as the instance, with nothing to size, and cheaper still if you cut over sooner.

Example 4: a one-week cutover on Serverless. The same 16 DCU full load, then one week of CDC at 2 DCU (158 hours), single-AZ: 160 x $0.0819 + 316 x $0.0819 = $13.11 + $25.89 = $39.00.

Ethan: "Two hundred thirty-seven on the instance, two hundred forty-three serverless, thirty-nine if we cut over in a week."

Jake: "And the new database?"

Ethan: "That's the real bill. Aurora is about four hundred a month for us. DMS is a one-off."

Example 5: a homogeneous PostgreSQL move. A 200 GB PostgreSQL database on EC2 moving to Aurora PostgreSQL with homogeneous data migrations, full load and ongoing replication for 10 days (240 hours): 240 x $0.09 = $21.60, with no storage or transfer charges on the DMS side.

Example 6: continuous replication into a data lake. A dms.c6i.large running all year, streaming changes from the production database into S3 as Parquet for analytics: $85.68 a month, or $1,028 a year, plus S3 storage. A Multi-AZ instance doubles it, which is worth it when the feed matters to the business.

Example 7: the forgotten instance. A dms.r6i.2xlarge Multi-AZ left running for three months after a migration finished: 3 x 720 x $1.411 = $3,047.76 for nothing. This is the single most common DMS billing surprise. A billing alert and a calendar reminder to delete the instance cost nothing.

How big a replication instance do you need?

DMS does its work in memory: it reads rows from your source, holds them in buffers, and writes them to your target, and during the full load it also holds the changes it is caching for each table. Memory, not CPU, is usually what runs out, which is why the R (memory-optimized) classes are the usual production choice. As a starting rule of thumb, you can plan on:

• dms.t3.medium or dms.t3.large for databases under about 100 GB with light change traffic, and for testing. T3 instances run in unlimited mode, so long, busy full loads add CPU credit charges at $0.075 per vCPU-hour above the baseline.
• dms.r6i.large or dms.r6i.xlarge for typical production migrations of a few hundred gigabytes to a terabyte, especially with LOB columns or many tables loading in parallel.
• dms.r6i.2xlarge and up for multi-terabyte databases, heavy CDC traffic, or several tasks sharing one instance.
• The C classes when your tasks are CPU-bound (many transformation rules, heavy validation) rather than memory-bound.

Watch three CloudWatch metrics during your first full load: FreeableMemory (if it drops near zero, go up a size), CPUUtilization, and SwapUsage (any steady swapping means the instance is too small). You can change the instance class later; the change restarts the instance, and tasks resume where they stopped. If you would rather not think about any of this, DMS Serverless does the sizing for you.

How to migrate a database with AWS DMS, step by step

1. Prepare the source: create a DMS user with read access, turn on what CDC needs (for SQL Server, MS-CDC or MS-Replication on the tables; for MySQL, binary logging in ROW format; for PostgreSQL, logical replication; for Oracle, supplemental logging and ARCHIVELOG mode), and keep logs long enough for DMS to read them (24 hours or more).
2. Prepare the target: create the RDS or Aurora database, and create the schema with Schema Conversion (for an engine change) or a native schema-only export (for the same engine). Leave foreign keys and triggers off until after the cutover.
3. Prepare the network: DMS runs in your VPC, in private subnets, and must reach both databases. For an on-premises source, that means a VPN or Direct Connect, and firewall rules that allow the DMS security group to the database port.
4. Open AWS DMS in the console and create a subnet group listing the subnets DMS may use.
5. Create the replication capacity: a replication instance (class, storage, Multi-AZ, engine version), or skip this step for DMS Serverless.
6. Create the endpoints: a source endpoint and a target endpoint, with credentials in Secrets Manager, and use Test connection on each until both show "successful".
7. Create the task (or serverless replication): migration type Full load and CDC, target table preparation mode Do nothing (because your schema already exists) or Truncate, LOB mode Limited with a maximum LOB size that fits your data, validation on, and CloudWatch logging on.
8. Add table mappings: a selection rule for each schema to include, plus transformation rules if you need them, such as lowercasing names for PostgreSQL.
9. Run a premigration assessment and fix what it reports: unsupported data types, tables without primary keys, and settings that will hurt performance.
10. Start the task and watch the table statistics: each table moves from "Before load" to "Table completed", then CDC takes over and latency should settle at a few seconds.
11. Validate: check validation status per table, compare row counts, and test your application against the target, read-only, while CDC keeps it current.
12. Cut over: stop writes on the source, wait until CDCLatencySource and CDCLatencyTarget reach zero, stop the task, add foreign keys, triggers and sequences on the target, then point your application at the new database.
13. Clean up: keep the old database read-only for a safe period, then delete the task, the endpoints and, above all, the replication instance.

Rehearse the whole thing at least once on a copy before the real cutover. The first run always finds something: a table without a primary key, a LOB column larger than you thought, or a sequence that was not reset.

AWS DMS with the AWS CLI

Everything in the console has a CLI equivalent, which is how you script repeatable migrations or create them from CloudFormation and Terraform. Before your first CLI call, check two IAM roles that the console creates for you but the CLI does not: dms-vpc-role (with the AmazonDMSVPCManagementRole managed policy), which DMS needs to place replication instances in your VPC, and dms-cloudwatch-logs-role (with AmazonDMSCloudWatchLogsRole), which it needs to write task logs. Both must trust dms.amazonaws.com and use exactly those names. If your first create-replication-instance fails with "The IAM Role arn:aws:iam::...:role/dms-vpc-role is not configured properly", this is why. You also need an IAM role that lets DMS read your endpoint secrets from Secrets Manager. The essentials:

# 1. Replication instance (Standard)
aws dms create-replication-instance \
  --replication-instance-identifier store-migration \
  --replication-instance-class dms.r6i.large \
  --allocated-storage 100 --multi-az \
  --replication-subnet-group-identifier dms-private \
  --vpc-security-group-ids sg-0abc1234def567890

# 2. Endpoints, with credentials from Secrets Manager
aws dms create-endpoint --endpoint-identifier stock-sqlserver \
  --endpoint-type source --engine-name sqlserver \
  --microsoft-sql-server-settings SecretsManagerSecretId=arn:aws:secretsmanager:us-east-1:111122223333:secret:dms-src,SecretsManagerAccessRoleArn=arn:aws:iam::111122223333:role/dms-secrets,DatabaseName=stock

aws dms create-endpoint --endpoint-identifier stock-aurora \
  --endpoint-type target --engine-name aurora-postgresql \
  --postgre-sql-settings SecretsManagerSecretId=arn:aws:secretsmanager:us-east-1:111122223333:secret:dms-tgt,SecretsManagerAccessRoleArn=arn:aws:iam::111122223333:role/dms-secrets,DatabaseName=stock

# 3. Test both connections
aws dms test-connection --replication-instance-arn arn:aws:dms:us-east-1:111122223333:rep:STOREMIGRATION \
  --endpoint-arn arn:aws:dms:us-east-1:111122223333:endpoint:STOCKSQLSERVER

# 4. Task: full load and CDC, with table mappings from a file
aws dms create-replication-task --replication-task-identifier stock-full-cdc \
  --source-endpoint-arn arn:aws:dms:us-east-1:111122223333:endpoint:STOCKSQLSERVER \
  --target-endpoint-arn arn:aws:dms:us-east-1:111122223333:endpoint:STOCKAURORA \
  --replication-instance-arn arn:aws:dms:us-east-1:111122223333:rep:STOREMIGRATION \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-task-settings file://settings.json

aws dms start-replication-task --replication-task-arn arn:aws:dms:us-east-1:111122223333:task:STOCKFULLCDC \
  --start-replication-task-type start-replication

# 5. Watch progress per table
aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:111122223333:task:STOCKFULLCDC

A minimal mappings.json selects one schema and lowercases every table name for PostgreSQL:

{
  "rules": [
    {"rule-type": "selection", "rule-id": "1", "rule-name": "include-dbo",
     "object-locator": {"schema-name": "dbo", "table-name": "%"},
     "rule-action": "include"},
    {"rule-type": "transformation", "rule-id": "2", "rule-name": "lower-tables",
     "rule-target": "table",
     "object-locator": {"schema-name": "dbo", "table-name": "%"},
     "rule-action": "convert-lowercase"}
  ]
}

For DMS Serverless, the commands are create-replication-config (with --compute-config MinCapacityUnits=2,MaxCapacityUnits=32,MultiAZ=true and your subnet group) and start-replication. Restarting a stopped serverless replication uses --start-replication-type resume-processing; you cannot start it fresh a second time. In Python, the same calls are on the boto3.client("dms") client, such as describe_replication_tasks and start_replication_task.

In infrastructure as code, the CloudFormation resource types are AWS::DMS::ReplicationInstance, AWS::DMS::Endpoint, AWS::DMS::ReplicationTask and AWS::DMS::ReplicationConfig for Serverless; in Terraform they are aws_dms_replication_instance, aws_dms_endpoint, aws_dms_replication_task and aws_dms_replication_config. Keep the table mappings and task settings as JSON files in the same repository, so a rehearsal and the real migration run with identical settings. One caution: stopping and starting a task from code is different from creating it. Tools that recreate a task on every deploy can restart a full load you did not want, so treat a running migration task as something you change by hand, carefully, once it has started.

DMS Schema Conversion and the AWS Schema Conversion Tool

When you change engines, the data is the easy part. Your tables, indexes, views, stored procedures, functions and triggers are written in one database's dialect and need translating into the other's. DMS Schema Conversion does that inside the DMS console:

1. Create an instance profile (the network and S3 bucket Schema Conversion uses) and data providers for your source and target databases.
2. Create a migration project that connects the two.
3. Run an assessment report: it lists every object, how much converts automatically, and what needs manual work, with an estimate of the effort.
4. Convert the schema, review the generated code, fix what it flags, and apply it to the target.

Schema Conversion supports the common engine changes: Oracle and SQL Server to PostgreSQL and MySQL (including Aurora and RDS), Db2 and SAP ASE to PostgreSQL, and more. A generative AI option, built on Amazon Bedrock models and available in a growing list of Regions, converts objects that rule-based conversion cannot handle, such as complex procedures, and since July 2026 Schema Conversion can also be driven by AI coding agents through the AWS MCP Server. The conversion itself is free; review every generated object before you trust it in production.

DMS vs SCT: the AWS Schema Conversion Tool (SCT) is the older, downloadable desktop application for the same job. It runs on your own Windows or Linux machine, supports a few conversions Schema Conversion does not (including data warehouse sources such as Teradata, Netezza and Greenplum to Redshift), and can extract data from warehouses with its own agents. For OLTP databases, Schema Conversion in the console is now the simpler choice; SCT remains for warehouse migrations and cases it alone supports. Neither moves your ongoing data; that is DMS.

Fleet Advisor, DMS's tool for inventorying databases across a data center, reached end of support on May 20, 2026; the 2026 retirements list covers it and the alternatives.

Change data capture: how DMS CDC works and how to set it up

CDC is why you use DMS rather than a backup. DMS reads committed changes from the source's log, in order, and applies them to the target as inserts, updates and deletes. What each source needs:

Source	What CDC reads	What you must turn on
MySQL and MariaDB	Binary log	binlog_format=ROW, binlog_row_image=FULL, binlog retention of 24 hours or more (on RDS: mysql.rds_set_configuration)
PostgreSQL	Write-ahead log through a logical replication slot	wal_level=logical (on RDS: rds.logical_replication=1), enough max_replication_slots, primary keys on tables
SQL Server	Transaction log	Full recovery model, a full backup, MS-Replication or MS-CDC on the tables (MS-CDC for tables without primary keys)
Oracle	Redo and archived logs, through LogMiner or Binary Reader	ARCHIVELOG mode, supplemental logging at database and table level; Binary Reader for heavy change rates
MongoDB and DocumentDB	Oplog or change streams	A replica set (not a standalone server); change streams on DocumentDB
Db2	Database logs	Archive logging and the right authorities for the DMS user

• Primary keys matter. DMS applies updates and deletes by key; a table without a primary key or unique index replicates updates slowly or not at all on many targets. Add keys, or exclude those tables and move them another way.
• Log retention is your safety net. If DMS stops for longer than the source keeps its logs, it cannot resume CDC and you must reload. Keep at least 24 hours, more for long weekends.
• Batch apply (the BatchApplyEnabled setting) groups changes into bulk operations, which is much faster for Redshift and busy targets.
• Latency has two halves. CDCLatencySource rising means DMS is slow to read from the source; CDCLatencyTarget rising alone means the target is slow to apply, usually because of missing indexes, triggers or an undersized target.
• Is DMS built on Debezium? No. DMS uses its own replication engine. Debezium is a separate open-source CDC project that runs on Kafka Connect, for example on MSK Connect.

Sources and targets AWS DMS supports

• Sources: Oracle, Microsoft SQL Server (including Azure SQL Database and Managed Instance), MySQL, MariaDB, PostgreSQL, MongoDB, SAP ASE, IBM Db2 for LUW and for z/OS, Amazon RDS and Aurora, Amazon DocumentDB, Amazon S3, and Google Cloud SQL for MySQL and PostgreSQL, among others.
• Relational targets: Oracle, SQL Server, MySQL, MariaDB, PostgreSQL, Amazon RDS, Aurora and Aurora Serverless, Babelfish for Aurora PostgreSQL, and SAP ASE.
• Analytics and storage targets: Amazon Redshift and Redshift Serverless, and Amazon S3 (CSV or Parquet, ready for Athena and Glue).
• NoSQL and streaming targets: DynamoDB, DocumentDB, Neptune, OpenSearch Service, ElastiCache and MemoryDB for Redis OSS, Kinesis Data Streams, Amazon MSK and self-managed Apache Kafka.

Snowflake, BigQuery and Azure targets are not supported directly. The usual pattern for Snowflake is DMS to S3 as Parquet, then Snowpipe into Snowflake. Each source and target has its own supported versions and limitations, so check the list for your engine pair before you plan the timeline.

AWS DMS vs DataSync, Glue, MGN, zero-ETL and Debezium

• DMS vs DataSync: DataSync copies files and objects (NFS, SMB, HDFS, S3) and knows nothing about databases. DMS copies rows from live databases and keeps them in sync. Moving a file share, use DataSync; moving a database, use DMS.
• DMS vs Glue: AWS Glue is an ETL service for transforming data in batches with Spark and Python, cataloguing it, and loading it into a data lake. DMS is for moving and continuously replicating databases with light transformations. Many pipelines use both: DMS lands changes in S3, Glue turns them into clean tables.
• DMS vs MGN: AWS Application Migration Service (MGN) copies whole servers, operating system and all, block by block. If you rehost the database server as an EC2 instance, MGN moves it; if you move the database onto RDS or Aurora, DMS does.
• DMS vs zero-ETL integrations: zero-ETL integrations replicate Aurora, RDS and DynamoDB into Redshift (and some sources into SageMaker lakehouses) with almost no setup, and are the simpler choice where they exist. DMS covers the many source and target combinations zero-ETL does not, and its own zero-ETL option brings self-managed databases into Redshift.
• DMS vs Debezium: Debezium is open-source CDC on Kafka Connect: flexible, free to run, and Kafka-centric, but you run and monitor it yourself. DMS is managed, AWS-billed and supports many targets beyond Kafka.
• DMS vs Oracle GoldenGate and Qlik Replicate: both are commercial replication products with richer bidirectional and conflict-handling features, licensed per core. DMS is far cheaper and simpler, and enough for most one-way migrations.
• The Azure equivalent of DMS is the Azure Database Migration Service, and Google Cloud's is Database Migration Service; each is built for moving data into its own cloud.

AWS DMS limits and quotas

• Replication instances: 60 per account per Region by default; 6 TB of storage per instance.
• Endpoints and tasks: 1,000 endpoints, 600 tasks per account, and 100 endpoints per replication instance by default; all can be raised.
• Tables per task: DMS loads up to 49 tables in parallel per task (MaxFullLoadSubTasks, default 8); very large table counts are better split across several tasks.
• DMS Serverless: capacity from 1 to 384 DCU per replication, 100 GB of storage at start that grows automatically, no views, no custom CDC start points, and a replication that is not resumed within 48 hours after stopping is deprovisioned.
• LOBs: in limited LOB mode, values above your maximum LOB size are truncated; full LOB mode moves any size but much more slowly.
• Engine versions: replication engine 3.6.1 is the newest, 3.5.4 the default; older versions reach end of life on announced dates (3.5.3 on June 30, 2026, 3.6.0 on July 27, 2026), after which instances are upgraded.
• DDL changes: DMS replicates some DDL (adding columns, for example) on some engines; drops, renames and complex changes during CDC are safer done on both sides by hand.

Common AWS DMS errors and fixes

• Test connection fails or "endpoint is disconnected": the replication instance cannot reach the database. Check the security group on the database allows the DMS security group on the right port, the route from the DMS subnets (VPN, Direct Connect or peering), DNS for the host name, and the credentials. For SSL, the endpoint needs the right certificate and SSL mode.
• Task fails with "Last Error ... Stop Reason FATAL_ERROR": open the task's CloudWatch logs and search for the first ]E: line; the real cause is almost always above the final message.
• "Table was errored/suspended": one table failed while others continue, typically from a data type the target cannot accept, a missing target column, or a LOB larger than the maximum. Fix the cause, then use Reload table for that table.
• CDC not working or no changes arriving: CDC prerequisites are missing (binlog not in ROW format, rds.logical_replication off, MS-CDC not enabled, supplemental logging off) or the logs DMS needed were already purged. Fix the setting and restart, which may mean a full reload.
• SQL Server "found backup broken chain for your database": the source has no full backup in the current log chain, or is in simple recovery mode. Switch to the full recovery model, take a full backup, and restart the task.
• MySQL "Unexpected charset utf8mb3 for column": a character set the replication engine does not map; upgrade to a recent engine version or convert the column to utf8mb4 on the source.
• Out of memory or the instance swaps: too many tables loading in parallel, large LOBs, or a big cache of changes. Use a larger R-class instance, lower MaxFullLoadSubTasks, or use limited LOB mode with a sensible size.
• Load very slow on tables without primary keys: each update scans the target. Add a primary key or unique index on the target before CDC starts.
• Validation failures: mismatches are listed in the awsdms_validation_failures_v1 table on the target; most come from rounding, time zones or LOB truncation, and a validation-only task can recheck after you fix them.

Best practices

• Convert and create the schema first, with target table preparation set to "Do nothing", and add foreign keys and triggers only after the cutover.
• Use Multi-AZ for any task with CDC that you cannot afford to restart from scratch.
• Keep source logs for at least 24 hours, longer over weekends and holidays.
• Use limited LOB mode with a maximum size based on your real data, and full LOB mode only for the tables that need it.
• Split big migrations into several tasks by table size, so one huge table does not hold up everything else.
• Turn on validation and CloudWatch logs from the start; you cannot debug what you did not log.
• Rehearse the cutover on a copy, with a written runbook and a rollback plan.
• Delete the replication instance the day you finish, and set a billing alert so a forgotten one never runs for months.

A security checklist for your migration: your replication runs in private subnets; your security groups allow only DMS to reach the databases, on only the database ports; your endpoint credentials live in Secrets Manager, not in endpoint settings; your connections use SSL; your DMS storage is encrypted with a KMS key you control if your compliance rules require it; your DMS user on the source has read and log access only, never full administrator rights; and you delete the endpoints and their secrets when the migration ends. If you can tick every item, your migration is safer than most.

Finally, write down what you did: the task settings, the table mappings, the CDC prerequisites on the source, the cutover steps and the timings from your rehearsal. Your next migration, or your colleague's, will take half the time.

Frequently asked questions

The stock database moved on DMS Serverless. The full load took nine hours on a Tuesday night while the tills kept selling, CDC held latency under five seconds for the rest of the week, and validation found two mismatched rows, both from a time-zone setting Ethan fixed before the cutover. On Sunday evening the store stopped the tills for twelve minutes, the last changes arrived, and the tills came back pointing at Aurora. The DMS bill was $31.46 (nine hours of full load at about 16 DCU, then five days of CDC at 2 DCU), less than the plan because the cutover came two days early. Jake asked what happened to the old server. "Read-only for a month," Ethan said, "then it goes, and so does its support contract."

Revision note. Written October 21, 2026. Prices are US East (N. Virginia) list prices on that date. We will update this page when DMS prices or features change.