3.3 Database Migration Service and Heterogeneous Database Migrations
Key Takeaways
- 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.
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 |
A logistics company runs a 4 TB Oracle database supporting 24/7 shipment tracking. It wants to replatform onto PostgreSQL on Google Cloud, continue running the same transactional workload against the new database, and cannot take a maintenance window longer than a few minutes. Which approach matches the requirements?
A retailer completes a Database Migration Service continuous migration from an on-premises MySQL database into Cloud SQL for MySQL. Validation queries against the Cloud SQL instance return correct data, but the application team reports that writes issued to the Cloud SQL endpoint are rejected and that the instance keeps changing as on-premises transactions occur. What is happening?
A finance team keeps its system of record in Cloud SQL for PostgreSQL and needs its BigQuery reporting layer to stay within a few minutes of the operational data. The PostgreSQL database will continue serving the application indefinitely, and the team wants the lowest-operations solution. Which service should they use?