Database Migration Service is the managed Google Cloud tool for moving a database into a target such as AlloyDB. A common scenario on the Professional Cloud Database Engineer exam involves moving an existing workload onto AlloyDB while keeping data consistent and limiting how long the application is unavailable. The pieces that make this work are a conversion workspace for the schema, a migration job that loads and then continuously replicates the data, and a final cutover when you are ready to switch production over. Knowing how those pieces fit together is usually enough to answer the question.
The scenario starts with a source environment. In the case we are working through, that source is an Oracle database, which represents the existing system that holds the data and schema you need to move. The destination is an AlloyDB cluster, which is the PostgreSQL-compatible target that will eventually take over the production workload. The work between those two ends is what Database Migration Service handles.
Because the source is Oracle and the target is PostgreSQL-compatible, the schema cannot move across unchanged. Database Migration Service uses a conversion workspace to handle that translation. The conversion workspace is where Oracle-specific objects and data types are mapped to their PostgreSQL equivalents in AlloyDB, so that the structure of the database lands correctly on the new side. You prepare the schema in the conversion workspace first, and the migration job then uses that workspace when it runs.
Once the schema is ready, you create a migration job that references the conversion workspace. Running this as a continuous job is what keeps downtime low. A continuous job performs the initial load of the existing data and then keeps replicating ongoing changes from the source to the target, so AlloyDB stays in sync with the source while the application is still running against the original database. This is the detail the Professional Cloud Database Engineer exam tends to lean on, since a continuous job is what lets you minimize downtime rather than taking the source offline for the full duration of the copy.
The migration is not finished when the data first lands. After the initial load completes and the job is replicating ongoing changes, the AlloyDB cluster is kept current with the source until you are ready to switch over. At that point you perform the final cutover and the AlloyDB cluster takes over the production workload. Because the target was already in sync, the cutover itself is the short window where service moves, rather than the whole copy.
Our Professional Cloud Database Engineer course covers migrating to AlloyDB with Database Migration Service alongside conversion workspaces and continuous migration jobs, with practice questions that drill these distinctions.
