Study guide
3.3 Database Migration Service and Heterogeneous Database Migrations
Google Cloud Professional Data Engineer Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 About the Google Cloud Professional Data Engineer Exam 0.2 Study Strategy & Cloud Data Engineering Methodology
2 Chapter 1: Designing for Security and Compliance
1.1 IAM Roles, Service Accounts, and Least Privilege for Data 1.2 Data Encryption, Key Management, and Privacy with Cloud DLP 1.3 Compliance, Data Sovereignty, and Geographic Placement 1.4 Multi-Environment Architecture: Development, Staging, and Production
3 Chapter 2: Designing for Reliability and Resilience
2.1 High Availability, Disaster Recovery, and Failover Patterns 2.2 Fault Tolerance and ACID Guarantees in Distributed Systems 2.3 Data Validation, Cleansing, and Quality Assurance with Dataform 2.4 AI-Assisted Data Preparation and LLM Query Generation
4 Chapter 3: Architecture Patterns and Flexibility
3.1 Modern Data Architectures: Data Lake, Warehouse, Lakehouse, and Mesh 3.2 Data Migration Strategies and Hybrid/Multi-Cloud Integration 3.3 Database Migration Service and Heterogeneous Database Migrations
5 Chapter 4: Ingestion Architectures: Pub/Sub and Streaming Sources
4.1 Cloud Pub/Sub Core Architecture and Ingestion 4.2 Pub/Sub Advanced Patterns: Dead-Lettering, Ordering, and Schemas 4.3 Change Data Capture (CDC) with Datastream and Batch Ingestion
6 Chapter 5: Stream and Batch Processing with Apache Beam and Cloud Dataflow
5.1 Apache Beam Core Concepts and Pipeline Design 5.2 Advanced Windowing, Watermarks, and Triggers 5.3 Dataflow Pipeline Optimization, Scaling, and Templates
7 Chapter 6: Data Transformation with Dataproc, Data Fusion, and Workflow Orchestration
6.1 Apache Spark and Hadoop with Cloud Dataproc 6.2 Visual Data Pipelines with Cloud Data Fusion 6.3 Workflow Orchestration with Cloud Composer 6.4 AI Data Enrichment inside Data Pipelines
8 Chapter 7: Storage Service Selection and Cloud Storage Architecture
7.1 Google Cloud Storage Service Selection Decision Matrix 7.2 Cloud Storage Architecture, Classes, and Lifecycle Management
9 Chapter 8: Deep Dive into Google BigQuery Storage
8.1 BigQuery Storage Architecture and Data Organization 8.2 Partitioning and Clustering for Performance and Cost 8.3 BigLake and Hybrid Querying across Clouds 8.4 Data Warehouse Modeling: Star Schemas, Denormalization, and Slowly Changing Dimensions
10 Chapter 9: Operational and NoSQL Databases: Bigtable and Cloud Spanner
9.1 Cloud Bigtable Architecture and Row Key Design 9.2 Cloud Bigtable Schema Management and Performance Tuning 9.3 Cloud Spanner: Globally Scalable Relational Database
11 Chapter 10: BigQuery Query Performance and Optimization
10.1 BigQuery SQL Tuning and Performance Best Practices 10.2 BigQuery BI Engine and Materialized Views 10.3 Data Sharing and Analytics Hub 10.4 Preparing Data for Visualization and BI Tool Connectivity
12 Chapter 11: Machine Learning Readiness and Data Governance
11.1 Machine Learning with BigQuery ML 11.2 Feature Engineering and Data Preparation for AI/ML 11.3 Data Governance, Cataloging, and Discovery with Dataplex 11.4 Unstructured Data, Embeddings, and Retrieval-Augmented Generation
13 Chapter 12: Site Reliability Engineering and Monitoring for Data Systems
12.1 SRE Principles for Data: SLIs, SLOs, and SLAs 12.2 Observability: Cloud Monitoring, Cloud Logging, and Alerting 12.3 Troubleshooting Data Pipelines and Workload Failures
14 Chapter 13: Workload Automation, CI/CD, and Cost Optimization
13.1 CI/CD and Version Control for Data Pipelines 13.2 BigQuery Cost Management and Capacity Planning 13.3 Holistic Cost Optimization across GCP Data Services 13.4 Query Workload Management: Interactive vs. Batch Jobs, Queues, and Quotas
3.3 Database Migration Service and Heterogeneous Database Migrations
Key Takeaways Explain This Topic AI
Database Migration Service migrates running databases onto Cloud SQL for MySQL, PostgreSQL, or SQL Server and AlloyDB for PostgreSQL, while Datastream replicates change data into BigQuery or Cloud Storage for analytics.
Homogeneous native migrations and replication into Cloud SQL or AlloyDB carry no additional Database Migration Service charge; heterogeneous migrations are billed on GiB processed with separate CDC and backfill rates.
Heterogeneous migrations run through a conversion workspace that performs automatic schema conversion, exposes an interactive editor, supports customization directives, and offers Gemini-assisted schema and code translation.
Connectivity options are IP allowlist, reverse SSH tunnel, VPN, and private connectivity through VPC peering; connections use SSL/TLS and continuous migrations support customer-managed encryption keys.
Continuous migration takes a snapshot and then applies change data capture for a minimal-downtime cutover, while promotion is the step that ends replication and makes the destination a writable primary.
Last updated: September 2026
3.3 Database Migration Service and Heterogeneous Database Migrations
Section 1.4 of the official exam guide names the tools you are expected to recognize: "BigQuery Data Transfer Service, Database Migration Service, Transfer Appliance, Google Cloud networking, Datastream." Four of those move files or analytics data . Exactly one of them moves a running database into another running database , and that is Database Migration Service (DMS) .
Confusing DMS with Datastream is the most common error in this part of the blueprint, and the exam exploits it repeatedly. The distinction is not about which one performs change data capture — both do — but about where the data lands and what the destination is for .
What Database Migration Service Actually Does
DMS migrates operational databases onto Google Cloud managed database targets with minimal downtime. The destination is always a database you will continue to run transactions against:
- Destination Supported For
- Cloud SQL for MySQL MySQL-native migration and replication
- Cloud SQL for PostgreSQL PostgreSQL-native migration and replication, plus heterogeneous sources
- Cloud SQL for SQL Server SQL Server migrations
- AlloyDB for PostgreSQL PostgreSQL-native migration and replication, plus heterogeneous sources
Two migration shapes exist, and the vocabulary is tested directly:
A homogeneous migration moves between the same database technology — MySQL to Cloud SQL for MySQL, PostgreSQL to AlloyDB for PostgreSQL. The schema transfers essentially as-is.
A heterogeneous migration moves between different engines — Oracle to PostgreSQL, SQL Server to PostgreSQL. Schema, data types, and procedural code all have to be converted before any rows move.
Conversion Workspaces and Gemini-Assisted Conversion
Heterogeneous migrations run through a conversion workspace . DMS performs initial schema conversion automatically, exposes the draft in an interactive SQL editor so you can inspect and edit converted objects, and supports customization directives that override automated conversion rules where your organization needs a different mapping. Gemini-powered conversion assistance helps translate schema and procedural code — stored procedures, triggers, and functions are where a heterogeneous migration usually stalls, because there is no mechanical equivalence between Oracle PL/SQL and PostgreSQL PL/pgSQL.
The exam-relevant sequencing is: convert the schema in the conversion workspace, apply it to the destination, then run the migration job. A scenario that describes starting a heterogeneous migration job without a conversion workspace is describing a failure.
Connection Profiles, Migration Jobs, and Cutover
Three objects make up every DMS migration:
Connection profile — a stored record describing how to reach a database: engine type, hostname or IP, port, and credentials. You create one for the source and, in most flows, one for the destination.
Migration job — the migration process itself. It references the connection profiles, selects whether to move all databases or a specific subset, and defines the destination instance configuration.
Promotion — the cutover step that ends replication and turns the destination into a standalone, writable primary. Until you promote, the destination is a replica still receiving changes.
DMS supports several connectivity methods between the source and Google Cloud, and the right one depends on where the source lives:
- Connectivity Method When It Fits
- IP allowlist Source has a stable public IP and the network team can permit Google Cloud ranges
Reverse SSH tunnel Source sits behind a firewall with no inbound path; a bastion establishes the tunnel outward
VPN Existing site-to-site connectivity between on-premises and the VPC
Private connectivity (VPC peering) Source already runs inside Google Cloud or a peered network, keeping traffic off the public internet
Connections are encrypted with SSL/TLS certificates, and continuous migrations support customer-managed encryption keys (CMEK) — the detail to remember when a scenario adds a key-custody requirement.
Continuous Migration vs. One-Time Migration
This choice maps directly onto the downtime requirement in the scenario:
A continuous migration takes an initial snapshot and then uses change data capture to track and apply source changes in real time. The application keeps writing to the source throughout, so downtime is limited to the short promotion window at cutover. This is the answer whenever the scenario says "minimal downtime," "24/7 order entry," or "cannot take a maintenance window."
A one-time migration is a single point-in-time snapshot using a dump-and-load approach, and it can cause application downtime. It is simpler and appropriate when the source can be quiesced — a monthly reporting database, a decommissioned system, a development instance.
Pricing Shape
Pricing is one of the few places where the two migration shapes diverge sharply, and it is a clean exam fact:
Homogeneous native migrations and replication into Cloud SQL or AlloyDB for PostgreSQL carry no additional charge for the DMS service. You pay for the destination instance you provision, not for the migration.
Heterogeneous migrations are billed on GiB processed , metered per migration job on raw uncompressed bytes, with change data capture and backfill charged at different rates and a monthly free backfill allowance.
The practical consequence: a scenario that frames DMS cost as a reason to hand-script a MySQL-to-Cloud SQL move is presenting a false constraint.
Choosing Among the Five Named Migration Tools
This matrix is the highest-value artifact in the section. Most Section 1.4 questions reduce to reading one row of it.
Tool Moves Destination Use When
Database Migration Service A running database Cloud SQL / AlloyDB You are replatforming an operational database and will keep transacting against it
Datastream Row-level changes (CDC) BigQuery or Cloud Storage You want an analytics copy kept fresh; the source remains the system of record
BigQuery Data Transfer Service Scheduled dataset loads BigQuery Recurring ingestion from SaaS sources, other warehouses, or Cloud Storage on a schedule
Storage Transfer Service Objects and files Cloud Storage Online bulk file transfer from another cloud, an on-premises filesystem, or a URL list
Transfer Appliance Objects and files, offline Cloud Storage Volume divided by available bandwidth exceeds the acceptable window — ship the data physically
The disambiguating question to ask on exam day is simply: after the move, what runs against the destination? If the answer is an application issuing transactions, it is DMS. If the answer is analysts and dashboards, it is Datastream or BigQuery DTS. If the answer is "nothing — these are just files," it is Storage Transfer Service or Transfer Appliance.
Exam Traps and Antipatterns Summary
Scenario Cue Wrong Answer Correct Choice
"Replatform an on-premises Oracle OLTP database onto PostgreSQL" Datastream into BigQuery DMS heterogeneous migration with a conversion workspace into Cloud SQL for PostgreSQL or AlloyDB
"Keep our BigQuery reporting copy of the MySQL orders table current" DMS continuous migration Datastream CDC into BigQuery; the source stays the system of record
"Source is behind a firewall with no inbound access" Expose the database publicly and allowlist Google ranges Reverse SSH tunnel, VPN, or private connectivity
"24/7 order entry; we cannot take a maintenance window" One-time migration over the weekend Continuous migration with CDC, then promote at cutover
"DMS cost is a concern for a MySQL to Cloud SQL move" Hand-script a dump and load Homogeneous native migration carries no additional DMS charge
"Stored procedures did not come across" Re-run the migration job Convert procedural code in the conversion workspace with Gemini assistance and customization directives
"The application still writes to the old database after cutover" File a support case The destination was never promoted; promotion ends replication and makes it writable