Migrating Databases with Database Migration Service

Overview and What You Will Learn

In this lab, you will set up a Database Migration Service job connecting a source database to a new Cloud SQL destination, understand the continuous replication phase that keeps both in sync, and see how the final cutover minimizes actual downtime during the switch.

Why This Matters in Production

A team plans a weekend-long maintenance window to manually export and import a production database into Cloud SQL, only to discover the export itself takes twelve hours and the application needs to stay fully offline that entire time. Database Migration Service exists specifically to avoid this - it continuously replicates changes from the source database during the migration, so the actual downtime is limited to a brief final cutover rather than the entire transfer duration.

Core Principles

Database Migration Service handles the full migration lifecycle - initial data transfer, then continuous replication of ongoing changes, then a final cutover - rather than a single one-time export-and-import operation that requires the source to be frozen for the entire duration.

The source database remains fully operational and serving live traffic throughout almost the entire migration - only the final cutover step involves a brief window where writes need to pause momentarily to guarantee no data is lost in the switch.

Detailed Step-by-Step Practical Lab

1. Create a project and enable the Database Migration API:

2. Create a connection profile representing the source database:

3. Create the migration job, specifying the source profile and the destination Cloud SQL configuration:

Note

--type=CONTINUOUS specifically enables the ongoing replication behavior - a one-time migration type exists too, but continuous is what makes minimal-downtime migration possible, since it keeps the destination in sync with the source right up until cutover.

4. Start the migration job:

5. Monitor the migration's progress until it reaches the "running" state, indicating continuous replication is actively keeping the destination in sync:

6. Once ready to cut over, promote the destination - this is the step that briefly pauses writes on the source, confirms full synchronization, then makes the Cloud SQL instance the new primary:

7. Verify the migration completed successfully and the destination is now standalone:

8. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Planning a migration around a single long maintenance window assuming the entire data transfer must happen during that window. Database Migration Service's continuous replication means the actual application downtime can be limited to just the final cutover, often a matter of minutes, not the hours or days a full manual export-import would otherwise require.

Tip

Test the promoted destination thoroughly against a copy of production traffic or a staging environment before actually promoting the real migration job. Promotion ends the connection to the source, making it a deliberate, one-way action rather than something easily reversed if an issue is discovered afterward.

• The source database must remain reachable throughout the entire continuous replication phase. If network connectivity between the source and Database Migration Service is interrupted for an extended period, replication can fall behind or fail, requiring investigation before the migration can safely proceed to cutover.
• Schema changes on the source during an active migration need care. A schema change on the source database mid-migration can require a corresponding update on the migration job's configuration - test this specific scenario if the source database is expected to have any schema changes during the migration window.

Quick Reference & Troubleshooting Commands