Database Migration Service Study Notes

Database Migration Service, or DMS, is a serverless, fully managed service for migrating databases to Google Cloud with minimal downtime. It supports homogeneous migrations such as PostgreSQL to Cloud SQL for PostgreSQL and heterogeneous migrations such as Oracle to PostgreSQL. DMS handles initial load and continuous change replication until you promote the destination at cutover.

Key facts

• DMS uses connection profiles that store source and destination connection details, credentials, and encryption settings, allowing migration jobs to be created consistently and reused securely.
• A migration job performs a one-time snapshot or dump of the source, then continuously replicates ongoing changes using log-based change data capture, keeping the destination nearly synchronized.
• Supported sources include on-premises databases, databases on Compute Engine, Amazon RDS, and other clouds, with destinations primarily Cloud SQL and AlloyDB depending on engine and migration type.
• Because DMS is serverless, you do not provision or manage replication VMs; Google manages the infrastructure, scaling, and health monitoring of the migration job for you.
• Connectivity from the source can be established through VPC peering, VPN, Cloud Interconnect, or reverse SSH tunnel patterns, and choosing the correct method is a key setup step for private databases.
• Cutover is a controlled promotion step where you stop writes to the source, let replication catch up to zero lag, promote the Cloud SQL destination to a standalone instance, and redirect applications.
• DMS provides validation and monitoring during migration, showing replication lag and errors so you can plan the maintenance window and verify data consistency before switching traffic.
• For heterogeneous migrations, DMS works alongside schema conversion tooling to translate schemas, data types, and code objects, because replication alone does not convert an Oracle schema to PostgreSQL automatically.
• Testing a migration job with a test run or a cloned job is recommended before production, allowing you to verify connectivity, permissions, and data integrity without affecting the live source workload.

What the exam expects you to know

• Choose DMS whenever the scenario requires migrating a production database to Cloud SQL or AlloyDB with minimal downtime using continuous replication, rather than offline dump and restore.
• Know the workflow order: create connection profiles, create and test the migration job, start replication, monitor lag, then promote the destination during the cutover window.
• Identify VPC peering or private connectivity as the requirement for migrating from a private on-premises or VPC-hosted source that has no public IP address.
• Distinguish homogeneous migrations where the engine stays the same from heterogeneous migrations where the engine changes and schema conversion becomes an additional required step.
• Remember DMS is serverless and managed, so exam options requiring you to build and manage your own replication server are inferior solutions.
• Understand that Storage Transfer Service moves files and objects, not live databases with change replication, so database migration scenarios should never answer Storage Transfer Service.

Database Migration Service vs Cloud SQL import/export: when to use which

Use Database Migration Service when migrating a live production database with minimal downtime, because it continuously replicates changes after the initial load so the destination stays current until cutover. Use Cloud SQL import and export with dump files in Cloud Storage when the database is small, downtime is acceptable, or you are seeding a development environment. The exam signal is downtime tolerance: near-zero downtime and ongoing changes mean DMS, while a simple offline move during a maintenance window can use import and export. See also the Cloud SQL import/export notes.

Useful gcloud commands

gcloud database-migration connection-profiles create my-source --region=us-central1 --type=POSTGRESQL --display-name=SourceProfile
gcloud database-migration migration-jobs create my-job --region=us-central1 --source=my-source --destination=my-dest --connectivity-type=STATIC_IP
gcloud database-migration migration-jobs list --region=us-central1

Common exam traps

• DMS does not eliminate the need for application cutover planning; you must still stop or redirect writes and update connection strings when promoting the destination instance.
• Heterogeneous migration is not just replication; schema and code conversion must happen separately, so assuming an Oracle database replicates directly into PostgreSQL without conversion is wrong.
• A migration job cannot start successfully without correct connectivity and source permissions for log-based replication, including enabling the required logging on the source database.
• Promoting the destination ends the migration job and replication; after promotion the destination is standalone and changes no longer flow from the old source automatically.

Frequently asked questions

How does DMS minimize downtime during migration?

DMS first loads an initial snapshot of the source database and then continuously applies new changes captured from the source transaction logs to the destination. Because the destination stays synchronized while the source remains live, the final cutover only needs a brief window to drain remaining changes and redirect applications. This is far shorter than an offline dump and restore.

What is a connection profile in DMS?

A connection profile stores all the details DMS needs to reach a source or destination database, including host, port, username, password, and SSL configuration. Profiles are reusable across migration jobs and keep credentials managed in one place. Creating and testing profiles for both source and destination is the first step in any DMS migration workflow tested on the exam.

What happens when you promote a DMS destination?

Promotion finalizes the migration by stopping replication and converting the destination replica into a standalone Cloud SQL or AlloyDB instance ready for production traffic. Applications then connect directly to the promoted instance using its connection details. After promotion, the migration job is complete and the source is no longer synchronized, so rollback requires a separate plan.

Study aid disclaimer: Cloud Cert Notes is an independent educational study aid. It is not affiliated with, endorsed by, or sponsored by Google, Microsoft, Amazon, Oracle, or Alibaba. Google Cloud, Associate Cloud Engineer, and Cloud Digital Leader are trademarks of Google LLC; all other certification names and product names are trademarks of their respective owners. Always confirm service details against the official provider documentation before sitting an exam.