A practitioner's guide to AWS Database Migration Service — covering migration phases, task configuration, LOB handling, PostgreSQL logical replication, and high-availability continuous replication — written from the perspective of an AWS Microsoft Workloads Competency partner.
Database migrations are one of the most complex and high-stakes challenges in cloud adoption. Whether you're modernizing a legacy SQL Server estate, moving off an expensive Oracle license, or re-platforming to a managed database service like Amazon Aurora, the decisions you make at the start of a migration determine whether you land cleanly — or spend months cleaning up.
This post draws directly on hands-on experience working with AWS Database Migration Service as part of Datapipe's AWS Relational Database Services practice — including the work that contributed to Datapipe earning AWS Microsoft Workloads Competency status. That recognition, which I helped drive as Director of Product Management, covered both Productivity Solutions (SharePoint, Exchange) and Database Solutions (SQL Server) — and is the context behind the guidance here.
Most database migration failures aren't technical — they're architectural. Teams underestimate the complexity of change tracking, choose the wrong migration type for their workload, or skip logging until something breaks. AWS DMS provides a solid foundation, but the tool is only as good as the decisions made around it.
The core value proposition of AWS DMS is that it enables organizations to migrate data to and from a wide range of databases — whether hosted in Amazon RDS, running on Amazon EC2, or on-premises — with minimal downtime. The service supports both homogeneous migrations (Oracle to Oracle, SQL Server to SQL Server) and heterogeneous migrations (Oracle to Amazon Aurora, SQL Server to PostgreSQL). In both cases, the service tracks changes being made to the source database so that they can be continuously applied to the target, keeping the two in sync throughout the cutover window.
When you provision an AWS DMS task, it runs through three distinct phases. Understanding what happens in each phase — and where things can go wrong — is essential for planning your migration window and cutover strategy.
Before you create a DMS task, you need to make several architectural choices. These aren't settings you can easily change mid-migration — get them right upfront.
You have three options: migrate existing data only, replicate data changes only, or a combination of both. For most production migrations, the combination approach is the right choice — it gives you a full baseline plus continuous sync, which is what makes near-zero-downtime cutovers possible. The "migrate existing data only" option is appropriate for one-time bulk loads where you can tolerate downtime.
By default, AWS DMS starts a task immediately upon creation. If you're coordinating a migration across multiple systems, you'll want to disable this and control the start time explicitly. A premature start in a multi-system migration can leave your target databases in an inconsistent state.
If tables already exist at the target, DMS needs to know what to do with them. Options include dropping and recreating the table, truncating existing data, or doing nothing. In most migrations you'll want to drop and recreate — but if you're running DMS against a target that already has schema applied (via SCT or a separate DDL script), truncating is the safer choice.
Large objects require special handling because they consume significantly more resources than standard column types. DMS gives you three modes:
A significant capability update — relevant to teams migrating PostgreSQL workloads — was the addition of Amazon RDS for PostgreSQL as a source for DMS, enabled through logical replication.
RDS for PostgreSQL supports logical replication starting from versions 9.4.9 and 9.5.4. This works through logical decoding, where replication slots stream changes from the database. A new rds_replication role (assigned to the master user by default) grants the permissions needed to manipulate and stream data through those logical slots. To enable it, set the parameter rds.logical_replication to 1.
What this unlocks is the ability to use RDS for PostgreSQL as a source — not just a target — in DMS tasks. This is particularly valuable for teams moving from PostgreSQL to a different database engine, or consolidating multiple PostgreSQL instances.
Continuous data replication with high availability was another meaningful addition to DMS that changed how teams approach cutover planning. By specifying Multi-AZ when you create your replication instances, DMS provisions a standby replication instance in a different Availability Zone. If the primary fails, DMS automatically fails over to the standby — keeping your ongoing replication running without manual intervention.
This matters most in long-running migrations where the replication phase runs for days or weeks. Without Multi-AZ, a replication instance failure forces a restart from the cached changes phase, which can mean hours of recovery time in a large migration.
The DMS migration story is inseparable from the broader SQL Server on AWS narrative that evolved significantly in 2017. The launch of SQL Server 2017 was notable because it was the first version of SQL Server to run natively on Linux — which meant that AWS customers could now run SQL Server 2017 on EC2 Linux instances, in addition to the existing EC2 Windows and Amazon RDS paths.
Docker container support added a third deployment pattern. For teams building modern applications that needed SQL Server but wanted container portability, this opened the door to running SQL Server workloads in containerized environments on AWS — a significant shift from the traditional Windows-only deployment model.
Microsoft SQL 2017 enables clients to build modern applications using the language of their choice, Windows, Linux, and Docker containers on the AWS Cloud. The AWS Competency Program is designed to provide customers with qualified APN members, like Datapipe, who have demonstrated technical proficiency and proven customer success in specialized solution and vertical areas. Our service helps clients harness the full potential of the AWS platform with a plan, build and run approach to using Microsoft SQL Server whether on EC2 or RDS and now with SQL Server 2017 on EC2 Windows or Linux instances or with Docker containers.
The technical guidance in this post reflects work done as part of Datapipe's journey to achieving AWS Microsoft Workloads Competency — a designation I managed the process for as Director of Product Management. Earning this competency required demonstrating deep technical proficiency across SQL Server, SharePoint, and Exchange workloads on AWS, validated through customer references, support reviews, and AWS training and certification requirements.
The core DMS architecture — replication instance, source and target endpoints, three-phase task execution — has remained stable and is the foundation of AWS's managed migration tooling today. The patterns that worked well in 2017 continue to be the right approach: choosing your migration type deliberately, handling LOBs explicitly, enabling logging unconditionally, and using Multi-AZ replication instances for anything running longer than a day.
What has changed is the ecosystem around DMS. The AWS Schema Conversion Tool has matured significantly. Aurora has expanded to support more engine types. And the rise of containerized workloads means that the SQL Server on Linux / Docker story that felt novel in 2017 is now a mainstream deployment pattern.
For teams planning a migration today, the strategic question isn't whether to use DMS — it's how to structure the migration program around it. That means getting the source database assessment right, defining the cutover window with stakeholders early, and treating the replication phase as an opportunity for parallel validation rather than a waiting period.
CloudScale Advisory helps cloud and SaaS companies define migration strategy, structure partner programs, and accelerate GTM execution across AWS, Azure, and GCP ecosystems.
Get in touch View services