AWS Database Migration Service (DMS): move a live database to AWS with minutes of downtime.

IWhat AWS DMS does: full load, then CDC

DMS is a managed replication service. You point it at a source and a target, and it moves the data in two phases back to back.

In the full load, DMS reads every row of the selected tables and writes them to the target, in parallel across tables. For a large database this is the slowest phase, depending on volume, indexes and replication capacity.

In change data capture (CDC), DMS reads the source's transaction log (redo on Oracle, binlog on MySQL, WAL on PostgreSQL, the transaction log on SQL Server) and replays each committed change on the target. CDC starts from a log position recorded when the full load began, so nothing is missed. The target stays close behind the source.

That design is why cutovers are short: stop writes on the source, wait for CDC lag to reach zero, validate, and repoint the application. DMS moves data only; networking, the application cutover and rollback planning sit around it.

IIThe two shapes of migration, and where schema conversion enters

Almost every DMS question comes down to one fork: same engine or a different one. The answer decides whether DMS alone is enough and drives most of the effort and risk.

A homogeneous migration keeps the engine: PostgreSQL to RDS for PostgreSQL, MySQL to Aurora MySQL, SQL Server to RDS for SQL Server, MongoDB to Amazon DocumentDB. Schema, types and stored procedures are already compatible. You move the schema with native tools and use DMS for the data. AWS also offers homogeneous data migrations, which use native database tools with no replication instance to size.

A heterogeneous migration changes the engine: Oracle or SQL Server to Aurora PostgreSQL, Db2 to Aurora. Oracle NUMBER, DATE, CLOB, sequences, PL/SQL packages and proprietary functions have no one-to-one PostgreSQL equivalent, so the schema must be converted first.

IIICommon source and target pairs

Most startup database migrations to AWS are one of these.

IVThe DMS workflow, step by step

A production migration follows the same arc either way. Every step before cutover is repeatable, so teams rehearse on a staging target first and measure the timings.

• Assess: Inventory size, table count, largest tables, LOB columns, keys, stored code and write volume. For engine changes, run the schema assessment. Choose and size the target. Output: a sizing and convertibility readout and a downtime budget.
• Convert the schema: Same engine: dump and reload with native tools. Engine change: convert with DMS Schema Conversion or SCT, resolve the flagged items, deploy to the empty target. Secondary indexes and foreign keys are often added after the full load.
• Full load: Create the replication instance or DMS Serverless configuration, the source and target endpoints, and a task with table mappings and rules. Enable CDC so the start log position is recorded before the first row moves.
• CDC replication: DMS streams changes from the source log to the target. The system stays in this state, source live and target caught up, for as long as you need to validate.
• Cutover: In a quiet window, stop writes to the source, wait for CDC lag to reach zero, re-enable deferred constraints, validate, repoint the application and resume writes. Keep the source intact for rollback.
• Validate: Use DMS data validation (row counts and checksums), application smoke tests and a monitoring soak. Then decommission the source, the task and the replication capacity.

VReplication instances, endpoints and DMS Serverless

DMS has a small set of moving parts, and replication capacity is the lever that decides how fast the migration runs.

A replication instance is the managed compute that reads, transforms and writes, inside your VPC. Larger instances run full load and CDC faster and hold more in-flight changes; under-sizing is a common reason for slow loads or CDC backlogs. An endpoint holds connection details for the source or target, and you can test connectivity before running anything. A task binds them with table mappings, transformation rules, the migration type and LOB settings.

DMS Serverless removes instance sizing: you set a capacity range in DMS capacity units (DCUs; AWS says one DCU equals 2 GB of RAM) and DMS provisions and scales the compute, billed by the hour. It suits uneven loads and teams that do not want to hand-tune instances. A provisioned instance can still win for very large, steady loads where cost predictability matters.

VIThe pitfalls that derail real DMS migrations

A handful of known issues cause most stalled migrations. An experienced team plans around them from day one.

• LOBs (large objects): BLOB, CLOB, TEXT and BYTEA columns are the most common cause of slow or failed tasks. Limited LOB mode is fast but truncates values past a size cap; full LOB mode is lossless but slow. Pick the mode per table from the real maximum object size.
• Very large tables: Split them into parallel segments, add secondary indexes after the load, and give the load phase more capacity.
• Schema edge cases: What conversion cannot handle (complex PL/SQL, sequences and identity semantics, proprietary functions) must be rewritten and tested by hand. Size it from the assessment report before you commit.
• Tables without a primary key: CDC needs to identify rows to apply updates and deletes. Add a key or plan special handling.
• Sequences and triggers: DMS copies rows, not sequence state. Advance sequences past the highest migrated value at cutover, and disable target triggers during the load.
• Source log retention: If the source purges log entries faster than DMS reads them, CDC breaks and you restart the full load. Extend retention to cover the migration window.

VIIWhat DMS costs, and when AWS funding applies

Per AWS's <a href="https://aws.amazon.com/dms/pricing/">DMS pricing page</a>, you pay by the hour for the replication capacity you use, whether a replication instance or DMS Serverless, plus storage and data transfer when the source is in another Region or outside AWS. DMS Schema Conversion is free to use apart from S3 storage.

The target RDS or Aurora database is an ongoing cost you would pay anyway. For Oracle to Aurora PostgreSQL, the business case is usually removing Oracle license and support costs, which is why those migrations are worth their engineering effort.

The real spend is people: schema conversion, the manual remainder, building and validating tasks, rehearsing and running the cutover.

That is the work MAP (Migration Acceleration Program) funding is meant to help with. For a qualifying migration to AWS, your matched AWS partner files MAP funding and AWS decides. For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves. AWS Activate credits are separate: you apply for them yourself, and they pay AWS usage, not partner fees.

VIIIHow CloudRoute fits

You do not have to run DMS yourself, and for an engine change you probably should not learn schema conversion on your production database.

Tell us the source (Oracle, SQL Server, MySQL, PostgreSQL, MongoDB), the target, your rough data size and your downtime tolerance. We match you with one vetted AWS partner that has done that pair before. We reply within 24 hours; your matched partner reaches out within 5 business days. The partner runs the workflow (assessment, schema conversion, DMS tasks, CDC validation, rehearsed cutover, soak) and files MAP funding when the migration qualifies.

CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding. For the foundation a database lands in, see the AWS landing zone guide, and the migration track for how engagements run.