AWS DMS (Database Migration Service)
Migrate databases to AWS with minimal downtime and continuous data replication
DMS is like a moving company for databases; it helps you migrate data from one database to another with minimal downtime. You could be moving from Oracle on-premises to Aurora in AWS, or from MySQL to PostgreSQL, or even from a database to S3 for analytics. DMS handles the heavy lifting: it copies your existing data (full load), then continuously replicates ongoing changes (CDC - change data capture) so your source and target stay in sync. When you're ready to cut over, you switch your application to the new database with minimal downtime. It's like moving houses while still living in the old one; you gradually move stuff over, and when everything's ready, you make the final switch.
DMS uses a replication instance (EC2 instance running DMS software) to read from a source database, transform data (optional), and write to a target database. It supports homogeneous migrations (Oracle to Oracle) and heterogeneous migrations (Oracle to PostgreSQL, requiring AWS Schema Conversion Tool for schema translation). DMS operates in three modes: full load (one-time copy), CDC (continuous replication), and full load + CDC (copy then replicate).
Key Capabilities
Key features: multi-AZ replication instances for high availability, task monitoring via CloudWatch, and data validation.
Gotchas & Constraints
Gotcha #1: DMS replicates data, not schema; use SCT to convert schema for heterogeneous migrations. Gotcha #2: CDC requires database-specific setup (e.g., enabling binary logging for MySQL, archive logging for Oracle). Constraints: Replication lag can occur with high-volume changes, some data types aren't supported (e.g., Oracle BFILE), and large LOBs can slow replication.
A financial services company migrates 50 Oracle databases (20TB total) from on-premises to Aurora PostgreSQL. Manual migration would require weeks of downtime, which is unacceptable for 24/7 operations. They use DMS with AWS SCT: SCT converts Oracle schemas to PostgreSQL-compatible schemas, and DMS handles data migration. They create DMS tasks for each database, starting with full load (copy existing data), then enabling CDC (replicate ongoing changes). Source databases remain in production while DMS continuously syncs changes to Aurora. After 2 weeks of replication (ensuring data consistency), they schedule a cutover window: stop application writes, let DMS catch up (final sync takes 5 minutes), switch application connection strings to Aurora, and resume operations. Total downtime: 10 minutes per database. They use DMS data validation to verify 100% data accuracy.
The Result
successful migration with minimal downtime, 60% cost savings (Aurora vs. Oracle licenses), and improved performance.