AWS Database Migration Service (DMS) - How to Migrate Databases to AWS

This article is aimed at organisations planning a production database migration to AWS – whether that’s escaping expensive licences (Oracle, SQL Server) or moving from on-premise to the cloud. If you’re looking for the specific Oracle → PostgreSQL scenario, see our complete Oracle to PostgreSQL migration guide. For the general AWS migration process (not just databases), see the AWS cloud migration guide.

What AWS DMS is and when to use it

AWS Database Migration Service moves data between databases – from a one-off copy to continuous, real-time replication. The key advantage: the source database stays fully operational for the entire migration. Applications keep running, users keep working, and DMS copies data and tracks changes in the background.

DMS supports two migration types:

• Homogeneous – same engine on both sides (Oracle → Oracle on RDS, PostgreSQL → Aurora PostgreSQL, MySQL → RDS MySQL). The schema transfers essentially unchanged and DMS handles the data.
• Heterogeneous – different engines (Oracle → PostgreSQL, SQL Server → Aurora MySQL). This needs schema conversion via SCT first, and only then does DMS migrate the data.

When DMS is the right tool

• You’re migrating a production database and can’t afford a multi-hour outage
• You’re moving from on-premise (or another cloud) to RDS / Aurora
• You’re leaving commercial licences (Oracle, SQL Server) for open source (PostgreSQL, MySQL)
• You need ongoing replication between databases (e.g. to feed a separate reporting instance)

When you don’t need DMS

• The database is small (< 10 GB) and you can afford downtime – native pg_dump/mysqldump is often simpler
• The migration is homogeneous and you can use native snapshots (e.g. RDS snapshot → restore)
• You only need schema conversion without moving data – that’s SCT’s job, not DMS

DMS and SCT – who does what

This is the most common source of confusion, so let’s be clear. DMS and SCT are two separate tools that solve two different problems:

In a homogeneous migration (Oracle → Oracle) the schema is compatible, so SCT is often unnecessary – DMS alone is enough. In a heterogeneous migration (Oracle → PostgreSQL) the order is always the same: SCT converts and deploys the schema on the target first, then DMS fills it with data. Running DMS against an empty, incompatible database without prior schema conversion will simply fail.

Full Load vs CDC – two migration modes

DMS offers three replication task modes. The choice determines how much downtime you take.

Full Load

A one-off copy of all data from source to target. Simple, but it requires that nothing changes in the source during the load (or that you accept losing changes made in that window). Suitable for:

• Databases < 100 GB
• Dev/staging environments
• Migrations with a planned maintenance window (weekend, overnight)

Full Load + CDC

Full load first, then DMS switches to continuous change replication (Change Data Capture). Everything that changed in the source during and after the full load is replicated on an ongoing basis. This is the mode that delivers minimal downtime at cutover. It requires change logging enabled on the source side (see below).

CDC only

Replication of changes alone, without an initial load – used when historical data was moved by another method (e.g. a snapshot) and DMS only needs to catch up on changes from a defined point.

What CDC requires on the source side

DMS migration step by step

AWS DMS costs

DMS is cheap relative to the value it delivers – the main cost is the replication instance’s running time, not the service itself.

For a typical migration lasting 3-4 weeks (including the parallel CDC period), the DMS service itself usually costs a few hundred to ~$500. It’s a negligible line item against the total cost of the migration project – detailed ranges are in our AWS migration cost guide.

DMS and Database Savings Plans

Worth knowing: DMS replication instance costs are covered by Database Savings Plans – the same commitment model that lowers your RDS and Aurora instance bill. In exchange for committing to a steady spend (measured in $/h) for 1 or 3 years, you get a discount against the on-demand rate.

For a one-off migration lasting 1-3 months this usually doesn’t make sense – a one-year commitment doesn’t pay off for a few weeks of work. But for continuous CDC maintained long term, the DMS instance runs non-stop, and that’s when a Database Savings Plan can take a substantial part of the cost off the budget.

The most common such scenario is feeding a data warehouse. DMS is used not only for a one-off migration but as a permanent mechanism to replicate changes from a transactional (OLTP) database into a warehouse – Amazon Redshift, S3, or another analytics platform. Here the replication instance runs indefinitely, because the CDC stream never ends. That’s the textbook case for a Database Savings Plan: steady, predictable spend held for years, ideal to cover with a commitment.

We’ll cover Database Savings Plans in more depth in a dedicated article. For migration purposes, remember the rule: one-off project → on-demand; long-running CDC (e.g. feeding a data warehouse) → consider a Savings Plan.

Common DMS migration pitfalls

1. LOBs (Large Objects) and how they’re handled

Problem: BLOB/CLOB/BYTEA columns need special configuration. The default DMS mode (Limited LOB) truncates data above a set size, leading to silent data loss.

Solution: For tables with large LOBs we use Full LOB or Inline LOB mode with an appropriately chosen LobMaxSize. We always verify checksums on LOB tables after migration.

2. Tables without a primary key

Problem: CDC relies on row identification. Tables without a primary key or unique index cause problems replicating changes (UPDATE/DELETE have no way to target a specific row).

Solution: Identify such tables during assessment. Add a primary key before migration, or make a deliberate decision to migrate those tables in Full Load mode only.

3. CDC lag grows over time

Problem: With a high transaction volume on the source, CDC lag can build up, which prevents a clean cutover.

Solution: Increase the replication instance size, split the task into several parallel ones (per table group), tune ParallelLoadThreads. We monitor CDCLatencyTarget from day one, not on cutover day.

4. Foreign keys and load order

Problem: Foreign-key constraints block loading data in the wrong order (child before parent).

Solution: Disable constraints for the full load (session_replication_role = replica on PostgreSQL), re-enable them afterwards, and validate integrity.

5. Data types without an equivalent

Problem: In a heterogeneous migration, some source types have no direct equivalent in the target (this is SCT’s job, but DMS surfaces the problem at load time).

Solution: Resolved at the schema conversion stage (SCT). DMS with transformations can additionally cast types on the fly, but it’s better to fix this in the schema than in the replication task.

How AWS MAP funds a DMS migration

A database migration delivered with DMS almost always fits the AWS Migration Acceleration Program (MAP) – especially when the goal is escaping commercial licences (Oracle, SQL Server) for Aurora or RDS.

For Oracle and SQL Server database migrations, AWS runs dedicated tracks with an increased budget – we cover the details in our Oracle to PostgreSQL migration guide. Qualification requires an active source environment, a target that’s a native AWS service, and a certified MAP partner to submit the application. We handle that end to end.

Frequently asked questions

Next steps – free database migration assessment

Every DMS migration starts with an assessment of the source environment. We analyse your databases (engine, size, transaction volume, tables without primary keys, LOB presence, integration points) and come back with:

1. Mode recommendation – Full Load vs CDC, depending on your downtime requirements
2. Replication instance and architecture sizing – size, networking, Multi-AZ
3. Realistic timeline and cost estimate – including MAP funding projections
4. Cutover plan – how to switch with minimal business impact

We’ve delivered database migrations for firms in finance, insurance, and the public sector – including regulated environments with data-residency constraints and production systems that can’t take an outage. Whether you’re leaving expensive licences behind or moving from on-premise to the cloud, the first step is understanding what you’re working with.

Planning a database migration to AWS?

Book a free 30-minute call. We'll assess your migration complexity, recommend a DMS mode, and check whether your project qualifies for AWS MAP funding (typically 70-80% of costs covered).

Book a call Send us a message