What happens to the source database during a CONTINUOUS migration?

Nothing changes on the source until you explicitly promote the destination. DMS reads the source's binlog (MySQL) or replication slot (PostgreSQL) without taking it offline or locking tables for anything beyond the brief initial snapshot. The source keeps serving production traffic for the entire replication window, sometimes days, until cutover.

Why did the migration job fail during the initial dump but replication metadata still shows data flowing?

A full dump failure on one table doesn't necessarily kill the whole job; DMS reports per-table dump status separately from the overall CDC stream health. Check the job's error details for the specific object, a common cause is a table using a storage engine other than InnoDB, which DMS's MySQL migrations don't support for CDC.

Does the destination need to be publicly accessible?

No, and for anything beyond a demo it shouldn't be. vpcPeeringConnectivity lets DMS route to a Cloud SQL instance's private IP over a VPC peering connection to the DMS-managed tenant project, which is the documented path for production migrations instead of authorizing the source's IP on the destination's public interface.

GCP Database Migration Service Builder

StorageGCP

Build DMS migration job configurations with source/destination profiles and VPC connectivity.

Database Migration Service Configuration

Build DMS migration job configurations with source/destination profiles, VPC connectivity, and database filters.

Required Fields

namedisplayNametypesource.connectionProfiledestination.connectionProfile

{
  "name": "projects/my-project/locations/us-central1/migrationJobs/mysql-to-cloudsql-prod",
  "displayName": "Production MySQL to Cloud SQL Migration",
  "type": "CONTINUOUS",
  "source": {
    "connectionProfile": "projects/my-project/locations/us-central1/connectionProfiles/source-mysql",
    "engine": "MYSQL",
    "host": "10.0.1.50",
    "port": 3306,
    "username": "replication_user",
    "ssl": {
      "type": "SERVER_CLIENT",
      "clientKey": "<REDACTED>",
      "clientCertificate": "<REDACTED>",
      "caCertificate": "<REDACTED>"
    }
  },
  "destination": {
    "connectionProfile": "projects/my-project/locations/us-central1/connectionProfiles/dest-cloudsql",
    "cloudSqlId": "my-project:us-central1:prod-db"
  },
  "vpcPeeringConnectivity": {
    "vpc": "projects/my-project/global/networks/prod-vpc"
  },
  "dumpFlags": {
    "dumpFlags": [
      { "name": "max-allowed-packet", "value": "1073741824" },
      { "name": "hex-blob", "value": "" }
    ]
  },
  "databasesFilter": {
    "databases": ["app_production", "analytics"]
  },
  "labels": {
    "migration": "phase-1",
    "source": "on-prem"
  }
}

Generated Output

Output will appear here...

See It in Action

A team migrating a 400GB on-prem MySQL instance to Cloud SQL sets type to CONTINUOUS expecting a quiet weekend cutover, but the job sits in RUNNING state for six days instead of the expected six hours because a 90-million-row audit_log table has no primary key, so CDC replication for it never starts even though every other table catches up within hours. They use the builder to add that table to databasesFilter's exclusion list, re-run the dump for just that table with a defined key added, and the CONTINUOUS stream catches up to near-zero lag within the hour, letting them promote on schedule.

What This Tool Does

Build a Database Migration Service job that moves a MySQL, PostgreSQL, or SQL Server database into Cloud SQL or AlloyDB, either as a ONE_TIME dump or a CONTINUOUS change-data-capture stream off the source's binlog/WAL. CONTINUOUS jobs stay in a running replica state until you call promote, at which point DMS stops replication and the destination becomes writable, so the cutover is a single explicit action rather than a passive cron trigger. Dump flags like max_allowed_packet matter more than people expect: the default 4MB packet size silently truncates large BLOB rows during the initial full dump on MySQL sources.

Technical Details

The builder validates that name, displayName, type, source.connectionProfile, and destination.connectionProfile are present before treating the JSON as a ready-to-apply DMS job body, mirroring the required fields on the CreateMigrationJob API — a job missing a connection profile reference has nothing to actually connect to source or destination.

Common Use Cases

1Migrating an on-prem MySQL primary to Cloud SQL with vpcPeeringConnectivity so replication traffic to the private IP destination never crosses the public internet.
2Debugging a stalled CONTINUOUS job that's stuck in the CDC phase because a source table lacks a primary key, which DMS requires for row-level replication.
3Scoping a databasesFilter to migrate only two of a dozen schemas on a shared MySQL instance, leaving the rest on-prem until later phases.
4Setting dumpFlags.hex-blob before a full dump of a table with binary columns, after the initial migration failed on non-UTF8 byte sequences.

Common Questions

What happens to the source database during a CONTINUOUS migration?: Nothing changes on the source until you explicitly promote the destination. DMS reads the source's binlog (MySQL) or replication slot (PostgreSQL) without taking it offline or locking tables for anything beyond the brief initial snapshot. The source keeps serving production traffic for the entire replication window, sometimes days, until cutover.
Why did the migration job fail during the initial dump but replication metadata still shows data flowing?: A full dump failure on one table doesn't necessarily kill the whole job; DMS reports per-table dump status separately from the overall CDC stream health. Check the job's error details for the specific object, a common cause is a table using a storage engine other than InnoDB, which DMS's MySQL migrations don't support for CDC.
Does the destination need to be publicly accessible?: No, and for anything beyond a demo it shouldn't be. vpcPeeringConnectivity lets DMS route to a Cloud SQL instance's private IP over a VPC peering connection to the DMS-managed tenant project, which is the documented path for production migrations instead of authorizing the source's IP on the destination's public interface.

Expert Tips

TIP

Requires a primary key or unique, not-null index on every table you want replicated via CDC; tables without one get skipped silently in the CONTINUOUS phase even though the initial dump copies their existing rows fine.

TIP

Set connectivity method before creating the connection profile, not after; the VPC peering range you reserve for DMS can't overlap with any existing peered range in the destination's network, and changing it later means recreating the profile.

TIP

A promote is irreversible from the tool's perspective: once called, DMS tears down the replication stream and there's no built-in path back to CONTINUOUS mode, so validate replica lag and row counts before promoting, not after.

Related Learning Guides

GCS Storage Classes & Lifecycle22 min read
Memorystore for Redis Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.