Managed Databases
Advanced 13 min read Managed Databases

Database Migration

Move databases with momentum, not re-keying

Migrating databases across engines, regions or to the cloud uses tools like AWS DMS, Azure Database Migration Service and GCP Database Migration Service to move data with minimal downtime and automated schema conversion.

migrationDMSDatabase Migration Servicereplicationschema conversiononline migration
Prerequisites: Relational Managed Databases
Before we start

What you will learn

  • Choose online vs offline database migration
  • Use AWS DMS / Azure DMS / GCP DMS
  • Handle schema conversion and cutover safely
In 60 seconds

Database migration services replicate from a source (on-prem, EC2, other clouds, same cloud different region) into a target, converting schema where engines differ, until a cutover flips the app. Online = near-zero downtime; offline = dump/load with a maintenance window.

Introduction

What is this?

AWS DMS (Database Migration Service) + Schema Conversion Tool (SCT); Azure Database Migration Service + Data Migration Assistant; GCP Database Migration Service (Postgres/MySQL) + SQL translate. Steps: assess (schema/objects/constraints), convert (SCT/SQL translate), migrate data (full load), replicate change (CDC via binlog/WAL) and cutover (stop writes, final sync, flip DNS). Offline vs online trade: downtime vs schema translation complexity.

Motivation

Why do you need it?

  • Move off aging on-prem DBs without rewriting every stored proc.
  • Same-engine region relocation with near-zero downtime.
  • Schema conversion automates the fiddly object-by-object translation.
  • Migrating correctly beats a weekend of 'restore and pray'.
Think about it

Mental model

Imagine

Moving offices with a moving crew that packs, ships and sets up

Think of

Managed database migration

The crew (DMS) inventories what's packed (assessment), re-books furniture for a new layout (schema convert), ships boxes (full load), keeps faxing along new documents (change replication), and finally switches the signboard (cutover).

Mechanics

How it works

  • Assessment tool catalogs objects, warnings and incompatible types.
  • Schema conversion translates DDLs (Oracle→Postgres, MySQL→SQL) with human review of edge cases.
  • Full load bulk-imports existing data into the target.
  • Continuous replication (CDC) streams new changes from the source's binlog/WAL to the target.
  • Cutover: pause writes, drain final lag, verify, flip the app endpoint to the target.

Online migration stages.

Source
Assess + convert
Full load
CDC replicate
Cutover
Hands-on

Examples

AWS DMS essentials

AWS DMS essentials
# endpoints
aws dms create-endpoint ... --source-engine oracle
aws dms create-endpoint ... --target-engine aurora-postgresql
# replication instance (size for the dataset)
aws dms create-replication-instance --replication-instance-class dms.c5.large
# task: full-load + CDC
aws dms create-replication-task --replication-task-identifier app-move \
  --source-endpoint-arn ... --target-endpoint-arn ... \
  --replication-instance-arn ... --migration-type full-load-and-cdc

Endpoints + replication instance + task = the full pipeline; CDC keeps the target warm to cutover.

Real world

In production

  • A credit union migrated Oracle→Aurora Postgres online with DMS + SCT over a weekend.
  • Azure DMS moved an on-prem SQL Server to Azure SQL with continuous replication during business hours.
  • GCP DMS subs a Postgres shard into a Cloud SQL target with < 5 min of app stop at cutover.
Guidelines

Best practices

  • Run an assessment first; fix high-severity warnings before committing to the schedule.
  • Test the full migration (load+CDC+cutover) in staging twice before the real one.
  • Instrument lag; cutover only after a clean lag-drain window.
  • Roll back plan: keep the source live and pointed-to until the target proves itself.
Watch out

Common mistakes

  • Skipping the assessment → undocumented triggers/sequences break the target at 2am.
  • Cutting over while CDC still has billable lag → data loss for writes after stop.
  • Ignoring collation/encoding differences that silently corrupt VARCHARs.
  • Restoring a dump mid-schema-convert instead of using the managed migration path.
Root cause analysis

Common issues

Error
CDC lag never drains to zero
Root cause

Source busy or replication instance underpowered

Fix

Scale the replication instance, pause non-critical writes during the drain, or extend the migration window.

Error
Foreign keys fail during full load
Root cause

Tables loaded in dependency order

Fix

Disable constraints during load (task-level) and enable post-load with validation.

When things break

Debugging tips

  • Migration stalls: check errors in the replication task; resolve source table-level errors not 'task paused'.
  • Lag grows: enlarge the replication instance and parallelize the load/CDC tasks.
  • Schema mismatches: review SCT/translate warnings; re-run conversion after fixes.
  • Test-average: cutover should match your staging rehearsal closely; record both.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

An online migration requires writers to stop before the full load.

Go deeper

Official documentation

AWS — Database Migration Service
docs
Azure — Database Migration Service
docs
GCP — Database Migration Service
docs