Database Migration Service is the primary tool for moving database workloads into Google Cloud, and it shows up frequently in exam scenarios. It is a serverless product that transfers data and metadata from a source database to a destination database, maintaining the integrity of your schemas and records throughout the process. It currently supports migrations to Cloud SQL and to AlloyDB for PostgreSQL, so it serves as the main bridge to Google Cloud's managed relational databases. On the Professional Cloud Database Engineer exam, the questions tend to come down to picking the right migration approach for a given set of constraints, so it helps to be precise about how the service works and how migrations are classified.
At a high level, the service automates the two parts of a migration that are tedious to do by hand. It performs the initial data snapshot to get the migration started, and it manages continuous replication to keep new changes in sync until you are ready to cut over. Because it handles both, you can move the bulk of the data first and then switch to the destination with minimal downtime.
For more complex moves, Database Migration Service uses conversion workspaces. A conversion workspace is a dedicated environment for refactoring your database components, with tools to convert schema and code objects so they work correctly in the new environment. The service also integrates Gemini for heterogeneous schema conversions, using AI assistance to help map and rewrite code from one database dialect to another. Conversion workspaces and Gemini matter specifically when the source and destination are not the same database technology, which we come back to below.
The first way a migration is classified is by how it handles ongoing changes, and this is the dimension tied to downtime. The two options are continuous and one-time.
A continuous migration is also called an online or ongoing migration because it keeps the source and destination in sync. It performs an initial full dump and load to move the bulk of the data, and then it continuously synchronizes changes from the source to the cloud instance in real time. This minimizes application downtime, because your application can keep running against the source right up until the moment you switch the connection string over to Google Cloud. When replication is finished, the service promotes the destination to a standalone primary instance, which completes the transition.
A one-time migration works differently. It executes a single point-in-time snapshot of the source, which means any data written after that moment is not captured. The service then loads that fixed data dump into the destination. Because nothing changes after the snapshot, you have to stop writes on the source before the snapshot begins to prevent data inconsistency during the transfer. The database stays frozen until the full load completes, so a one-time migration results in extended downtime compared to a continuous one.
When the exam frames a question around uptime or downtime requirements, this is the distinction it is testing. If the scenario cannot tolerate much downtime, the answer leans toward a continuous migration. If a maintenance window is acceptable and simplicity is the priority, a one-time migration is reasonable.
The second way a migration is classified is by technical compatibility between the source and destination, and this is the dimension tied to complexity. The two options here are homogeneous and heterogeneous.
A homogeneous migration involves identical database engines on both sides, such as moving an on-premises MySQL instance to Cloud SQL for MySQL. Because the engines match, schema mapping is simpler, and the system can keep data types and features consistent without translating them.
A heterogeneous migration connects environments built on different database technologies, such as moving from Oracle to PostgreSQL. Here the destination cannot run the source logic as-is, so the schema and code have to be converted to make the destination compatible. This is where conversion workspaces and Gemini do their work, automating the translation of complex database objects. A heterogeneous migration carries much greater complexity than a homogeneous one because of the structural translation required.
The point that is easy to miss is that these are not competing categories. Continuous versus one-time and homogeneous versus heterogeneous describe different aspects of the same migration, so every migration is categorized along both dimensions at once. A given migration follows either a continuous or a one-time approach, and it is also either homogeneous or heterogeneous depending on whether the source and destination engines match. A move from on-premises MySQL to Cloud SQL for MySQL with no downtime is a continuous homogeneous migration. A move from Oracle to PostgreSQL during a maintenance window is a one-time heterogeneous migration. On the Professional Cloud Database Engineer exam, a scenario will usually give you clues for both dimensions, and reading the downtime constraint and the engine compatibility separately is what lets you land on the correct configuration.
Our Professional Cloud Database Engineer course covers Database Migration Service alongside Cloud SQL and AlloyDB migration targets, with practice questions that drill these distinctions.
