Cloud Database Migration — DMS, Azure DMS & Database Migration Service Guide

In this tutorial, you'll learn about Cloud Database Migration. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud database Migration services move databases from on-premises or other clouds to managed cloud databases with minimal downtime, supporting homogeneous (MySQL to RDS MySQL) and heterogeneous (Oracle to Aurora) migrations.

What You'll Learn

You'll learn how to plan and execute database migrations using DMS, Azure DMS, and GCP DMS, including full-load, CDC, and validation strategies that keep your application running during the cutover.

Why It Matters

Migrating a database is risky. Downtime costs money, data loss is permanent, and schema incompatibilities can break applications. Managed Migration services handle schema conversion, continuous Replication, and validation. DodaZIP used DMS to migrate its user database from on-prem MySQL to Aurora with 5 minutes of downtime.

Real-World Use

A financial firm moves a 2TB Oracle database to Cloud SQL for PostgreSQL. DMS uses homogeneous Migration with change data capture. The source database stays online during the 3-day Migration, and the cutover takes under 60 seconds.

Migration Architecture

flowchart LR
  A[Source Database] --> B["DMS / Azure DMS / DMS"]
  B --> C[Full Load]
  C --> D[CDC Replication]
  D --> E[Target Database]
  E --> F[Validation]
  F --> G{Cutover Ready?}
  G -->|Yes| H[Stop Source, Route to Target]
  G -->|No| I["Fix Schema / Data Issues"]
  style B fill:#48f,color:#fff
  style G fill:#f90,color:#fff

AWS DMS

AWS DMS supports cross-database migrations using the Schema Conversion Tool.

# Create a replication instance
aws dms create-replication-instance \
  --replication-instance-identifier prod-migration \
  --replication-instance-class dms.c5.large \
  --allocated-storage 100 \
  --vpc-security-group-ids sg-12345

# Create source endpoint (on-prem MySQL)
aws dms create-endpoint \
  --endpoint-identifier source-mysql \
  --endpoint-type source \
  --engine-name mysql \
  --username dbadmin \
  --password mysecretpass \
  --server-name 10.0.1.50 \
  --port 3306

# Create target endpoint (Aurora PostgreSQL)
aws dms create-endpoint \
  --endpoint-identifier target-aurora \
  --endpoint-type target \
  --engine-name aurora-postgresql \
  --username dbadmin \
  --password mysecretpass \
  --server-name my-cluster.cluster-abc123.us-east-1.rds.amazonaws.com \
  --port 5432

# Start the migration task
aws dms create-replication-task \
  --replication-task-identifier migrate-orders \
  --source-endpoint-arn arn:aws:dms:us-east-1:...:endpoint/source-mysql \
  --target-endpoint-arn arn:aws:dms:us-east-1:...:endpoint/target-aurora \
  --replication-instance-arn arn:aws:dms:us-east-1:...:rep/prod-migration \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json

Azure Database Migration Service

Azure DMS provides offline and online migrations with the Azure Data Studio extension.

# Create a DMS service
az dms create \
  --name dodatech-dms \
  --resource-group my-rg \
  --location eastus \
  --sku-name Standard_1vCores

# Create a project for SQL Server to Azure SQL
az dms project create \
  --name migrate-orders \
  --resource-group my-rg \
  --service-name dodatech-dms \
  --location eastus \
  --source-platform SQL \
  --target-platform AzureSQLDb

# Start the migration
az dms project task create \
  --resource-group my-rg \
  --service-name dodatech-dms \
  --project-name migrate-orders \
  --task-name full-migration \
  --task-type OnlineMigration

GCP Database Migration Service

GCP DMS supports homogeneous migrations to Cloud SQL and heterogeneous through Striim.

# Create a connection profile for source
gcloud database-migration connection-profiles create \
  --region=us-central1 \
  --connection-profile=source-mysql \
  --display-name="On-prem MySQL" \
  --mysql='{"host":"10.0.1.50","port":3306,"username":"dbadmin","password":"mysecretpass"}'

# Create a migration job
gcloud database-migration migration-jobs create \
  --region=us-central1 \
  --migration-job=migrate-orders \
  --display-name="Orders migration" \
  --source-connection-profile=source-mysql \
  --destination-connection-profile=projects/my-project/locations/us-central1/connectionProfiles/target-cloudsql \
  --type=CONTINUOUS

# Promote the migration to complete cutover
gcloud database-migration migration-jobs promote \
  --region=us-central1 \
  --Migration-job=migrate-orders

Migration Validation

import boto3

dms = boto3.client("dms")

def check_migration_progress(task_arn):
    response = dms.describe_replication_tasks(
        Filters=[{"Name": "replication-task-arn", "Values": [task_arn]}]
    )
    task = response["replicationTasks"][0]
    return {
        "status": task["status"],
        "progress": task.get("replicationTaskStats", {}),
        "last_failure": task.get("lastFailureMessage", "None")
    }

task_arn = "arn:aws:dms:us-east-1:123456789012:task/abc123"
result = check_migration_progress(task_arn)
print(f"Status: {result['status']}")
print(f"Tables loaded: {result['progress'].get('tablesLoaded', 0)}")

Expected output:

Status: running
Tables loaded: 45

Common Errors

1. Underestimating schema conversion effort — Oracle to PostgreSQL requires manual schema changes (data types, sequences, packages). Use the AWS Schema Conversion Tool to identify incompatible objects early.
2. Insufficient Replication instance size — A small DMS instance cannot handle high-write workloads. Monitor target latency and scale the Replication instance if needed.
3. Not validating data after Migration — Row counts, checksums, and sample queries validate data integrity. DMS provides table-level statistics for validation.
4. Ignoring LOB handling — Large objects (BLOBs, CLOBs) require special configuration. Use limited LOB mode with a max size or full LOB mode for unlimited sizes.
5. Cutover not rehearsed — The first cutover should not be the real one. Practice the cutover procedure in a staging environment to find issues before the production Migration.

Practice Questions

1. What is the difference between full-load and CDC Migration? Full-load copies all existing data once. CDC continuously replicates changes from the source to keep the target in sync during Migration.
2. How does DMS handle schema differences between source and target? DMS maps compatible data types automatically. For incompatible types, use the Schema Conversion Tool to generate conversion scripts.
3. What is a homogeneous vs heterogeneous Migration? Homogeneous: same database engine (MySQL to RDS MySQL). Heterogeneous: different engine (Oracle to Aurora PostgreSQL). Heterogeneous requires schema conversion.
4. How do you minimize downtime during Migration? Use CDC to replicate changes up to the cutover moment. The final cutover takes seconds: stop writes to source, wait for CDC to catch up, redirect traffic to target.
5. Challenge: Design a Migration plan for a 5TB SQL Server database with 99.99% availability requirements. The Migration must complete within 2 weeks with less than 1 minute of downtime. Include rollback strategy.

Mini Project

Execute a database Migration:

• Set up a MySQL instance locally (Docker or on-prem simulator)
• Create a target Cloud SQL PostgreSQL instance
• Use DMS to migrate full-load + CDC
• Validate row counts and checksums on the target
• Perform the cutover and verify application connectivity

FAQ

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro.