{"id":677,"date":"2026-04-14T23:53:34","date_gmt":"2026-04-14T23:53:34","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-database-migration-service-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-databases\/"},"modified":"2026-04-14T23:53:34","modified_gmt":"2026-04-14T23:53:34","slug":"google-cloud-database-migration-service-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-databases","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-database-migration-service-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-databases\/","title":{"rendered":"Google Cloud Database Migration Service Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Databases"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Databases<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Google Cloud <strong>Database Migration Service<\/strong> is a managed service for migrating relational databases into Google Cloud with minimal downtime. It\u2019s designed for teams that want a repeatable, auditable, and operationally safer alternative to building custom migration scripts and replication pipelines.<\/p>\n\n\n\n<p>In simple terms: Database Migration Service helps you move a database (for example, MySQL or PostgreSQL) from on\u2011premises or another cloud into <strong>Cloud SQL<\/strong> or <strong>AlloyDB<\/strong>, and\u2014when supported\u2014keeps the target continuously updated until you\u2019re ready to cut over.<\/p>\n\n\n\n<p>Technically, Database Migration Service orchestrates the migration workflow end-to-end: source and destination connectivity, initial load, and (for \u201ccontinuous\u201d migrations) change replication so the destination stays in sync. You configure migrations using resources like <strong>connection profiles<\/strong> and <strong>migration jobs<\/strong>, and you monitor progress using Google Cloud\u2019s operations tooling (logging\/monitoring\/audit trails).<\/p>\n\n\n\n<p>The problem it solves: database migrations are risky and time-consuming because they combine data movement, networking, security, schema and user preparation, downtime coordination, and verification. Database Migration Service reduces that complexity by providing a structured, supported path for common migration patterns in Google Cloud Databases.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Database Migration Service?<\/h2>\n\n\n\n<p><strong>Official purpose (high level):<\/strong> Database Migration Service (DMS) helps you migrate databases to Google Cloud managed databases\u2014primarily <strong>Cloud SQL<\/strong> and, for supported PostgreSQL scenarios, <strong>AlloyDB<\/strong>. It provides guided workflows for one-time migrations and (where supported) continuous replication for low-downtime cutovers.<br\/>\nVerify supported sources\/targets and versions in the official docs because support evolves over time: https:\/\/cloud.google.com\/database-migration\/docs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>Common capabilities you should expect from Database Migration Service include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Homogeneous migrations<\/strong> (same engine family), such as MySQL\u2192Cloud SQL for MySQL or PostgreSQL\u2192Cloud SQL for PostgreSQL (verify exact engine\/version support).<\/li>\n<li><strong>One-time migrations<\/strong> for moving a snapshot of data.<\/li>\n<li><strong>Continuous migrations<\/strong> (where supported) to replicate changes after an initial load to minimize downtime during cutover.<\/li>\n<li><strong>Connectivity options<\/strong> for reaching sources across VPCs and hybrid networks (for example, over VPN\/Interconnect) with private networking patterns.<\/li>\n<li><strong>Operational visibility<\/strong> into migration status and errors through Google Cloud console and logging\/monitoring integrations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>Database Migration Service is configured and operated with a few key resource types (names as used in Google Cloud):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Migration job<\/strong>: the main resource that represents a migration workflow (one-time or continuous), including state and progress.<\/li>\n<li><strong>Connection profiles<\/strong>: reusable connection definitions for <strong>source<\/strong> and <strong>destination<\/strong> endpoints (host, port, engine type, credentials, TLS settings, etc.).<\/li>\n<li><strong>Private connectivity resources<\/strong> (when used): a way to enable private network paths between DMS and your source environment (exact resource names and steps depend on the chosen connectivity model\u2014verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type:<\/strong> fully managed Google Cloud service (control plane in Google Cloud; you do not manage replication servers in the same way you would with self-managed tools).<\/li>\n<li><strong>Scope:<\/strong> configured per <strong>Google Cloud project<\/strong> and typically per <strong>region<\/strong> for migration resources (jobs\/connectivity are region-bound in many Google Cloud services; confirm region behavior for your specific migration type in official docs).<\/li>\n<li><strong>Ecosystem fit:<\/strong> Database Migration Service sits in the <strong>Databases<\/strong> portfolio as the migration\/orchestration layer that helps you adopt <strong>Cloud SQL<\/strong> and <strong>AlloyDB<\/strong> while integrating with IAM, VPC networking, Cloud Logging, Cloud Monitoring, and Cloud Audit Logs.<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Important: Google Cloud Database Migration Service is not the same product as \u201cAWS Database Migration Service\u201d or \u201cAzure Database Migration Service.\u201d They are separate services with different architectures and pricing.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Database Migration Service?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Lower migration risk:<\/strong> a managed workflow reduces bespoke scripting and \u201ctribal knowledge\u201d migrations.<\/li>\n<li><strong>Faster cloud adoption:<\/strong> simplifies moving to managed databases (Cloud SQL\/AlloyDB) so teams can focus on application modernization.<\/li>\n<li><strong>Predictable cutovers:<\/strong> continuous replication (when supported) enables planned cutovers with shorter downtime windows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardized migration flow:<\/strong> consistent job lifecycle, progress tracking, and error reporting.<\/li>\n<li><strong>Supports common migration patterns:<\/strong> especially homogeneous migrations where schema conversion is not the primary hurdle.<\/li>\n<li><strong>Better repeatability:<\/strong> migration job definitions and connection profiles make it easier to reproduce dev\/test rehearsals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Centralized visibility:<\/strong> status and events through Google Cloud console plus logging\/monitoring.<\/li>\n<li><strong>Separation of concerns:<\/strong> the platform team can standardize connectivity and IAM patterns; application teams can execute migrations with guardrails.<\/li>\n<li><strong>Auditable operations:<\/strong> integrates with Cloud Audit Logs for administrative actions.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM-based access control:<\/strong> restrict who can create connection profiles\/jobs and who can view details.<\/li>\n<li><strong>Private networking options:<\/strong> align with least exposure principles; avoid public database endpoints when possible.<\/li>\n<li><strong>Encryption in transit:<\/strong> use TLS where supported; manage secrets carefully (ideally with Secret Manager).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Designed for production cutovers:<\/strong> continuous replication helps avoid long downtime for large datasets (subject to source engine and workload).<\/li>\n<li><strong>Compatible with managed targets:<\/strong> moving to Cloud SQL\/AlloyDB can improve operational scalability (HA, backups, patching) compared to self-managed instances.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Database Migration Service if:\n&#8211; You\u2019re migrating <strong>supported relational engines<\/strong> into <strong>Cloud SQL<\/strong> or <strong>AlloyDB<\/strong>.\n&#8211; You want <strong>low downtime<\/strong> with continuous replication (if supported for your engine\/method).\n&#8211; You prefer a <strong>managed<\/strong> migration workflow with Google Cloud integrations (IAM, logging, monitoring).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Database Migration Service may not be the right tool if:\n&#8211; You need <strong>heterogeneous migration with schema conversion<\/strong> as the primary capability (e.g., Oracle\u2192PostgreSQL with complex conversion). Google Cloud may provide other tools or partner solutions for assessment and conversion\u2014verify current recommendations in official docs.\n&#8211; Your source environment cannot meet the <strong>connectivity requirements<\/strong> (routing, firewall, TLS, user privileges).\n&#8211; You need advanced transformations, filtering, or event streaming semantics\u2014consider <strong>Datastream<\/strong> (CDC streaming) or data pipelines (Dataflow) depending on the goal.\n&#8211; Your migration is extremely small\/simple and a <strong>native backup\/restore<\/strong> is sufficient and safer for your use case.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Database Migration Service used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services (regulated migrations with strict audit controls)<\/li>\n<li>Healthcare (PHI-aware migrations with private networking)<\/li>\n<li>Retail\/e-commerce (downtime-sensitive transactional systems)<\/li>\n<li>SaaS and technology companies (frequent environment cloning and upgrades)<\/li>\n<li>Manufacturing\/logistics (hybrid\/on\u2011prem to cloud transitions)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform\/Cloud Center of Excellence (standardizing migration patterns)<\/li>\n<li>SRE\/Operations teams (cutover and reliability ownership)<\/li>\n<li>DevOps teams (automation, IaC, CI\/CD of infrastructure)<\/li>\n<li>Database administrators (source readiness, replication, performance)<\/li>\n<li>Security teams (network and access controls)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OLTP systems (orders, payments, inventory)<\/li>\n<li>SaaS tenant databases<\/li>\n<li>Back-office systems (ERP\/CRM integrations)<\/li>\n<li>Reporting read replicas (when migrating to a managed target)<\/li>\n<li>Dev\/test refresh pipelines (if using one-time migrations to seed environments)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hybrid connectivity (on\u2011prem source over Cloud VPN\/Interconnect)<\/li>\n<li>Multi-cloud migrations (source in another cloud into Google Cloud)<\/li>\n<li>VPC-based private database access patterns<\/li>\n<li>Cloud SQL HA deployments with private IP<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Dev\/test:<\/strong> run rehearsal migrations repeatedly to validate sizing, networking, privileges, and cutover steps.<\/li>\n<li><strong>Production:<\/strong> rely on continuous replication (if supported) plus a carefully planned cutover with validation, rollback plan, and monitoring.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Database Migration Service is commonly used in Google Cloud Databases programs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) On\u2011prem MySQL to Cloud SQL with low downtime<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A business-critical MySQL database must move off aging hardware with minimal downtime.<\/li>\n<li><strong>Why DMS fits:<\/strong> Provides an initial load plus continuous replication (when supported) to reduce the downtime window.<\/li>\n<li><strong>Example:<\/strong> A retail POS backend migrates from an on\u2011prem VM to Cloud SQL for MySQL, cutting over during a short maintenance window.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) PostgreSQL from another cloud to AlloyDB for performance modernization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A PostgreSQL workload needs better performance and managed scaling, but downtime must be minimal.<\/li>\n<li><strong>Why DMS fits:<\/strong> Supports migrations into AlloyDB for PostgreSQL in supported scenarios (verify engine\/version and migration mode).<\/li>\n<li><strong>Example:<\/strong> A SaaS vendor migrates from self-managed PostgreSQL to AlloyDB to improve query throughput.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) SQL Server to Cloud SQL for SQL Server (lift-and-shift)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A Windows-based app depends on SQL Server and needs to move to managed infrastructure.<\/li>\n<li><strong>Why DMS fits:<\/strong> Provides a structured migration workflow for supported SQL Server sources\/targets (verify support and limitations).<\/li>\n<li><strong>Example:<\/strong> A manufacturing MES app moves from on-prem SQL Server to Cloud SQL for SQL Server.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Data center exit with staged cutovers per application<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Dozens of databases must be migrated with consistent controls and reporting.<\/li>\n<li><strong>Why DMS fits:<\/strong> Standardizes migrations via connection profiles\/jobs; integrates with IAM and audit logs.<\/li>\n<li><strong>Example:<\/strong> A healthcare org migrates departmental databases in waves, each with rehearsals and approval gates.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Migration rehearsal automation (pre-production validation)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Teams need repeated practice runs to validate time-to-migrate, errors, and operational steps.<\/li>\n<li><strong>Why DMS fits:<\/strong> Repeatable job setup and consistent observability streamline rehearsals.<\/li>\n<li><strong>Example:<\/strong> A platform team runs monthly rehearsal migrations to validate ongoing readiness for production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Hybrid connectivity migrations over VPN\/Interconnect<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> The source database cannot be exposed publicly due to policy.<\/li>\n<li><strong>Why DMS fits:<\/strong> Supports private networking patterns when properly configured.<\/li>\n<li><strong>Example:<\/strong> A bank migrates PostgreSQL over Cloud Interconnect without public IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Consolidation of fragmented MySQL instances into managed Cloud SQL<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many small MySQL servers are costly to operate and patch.<\/li>\n<li><strong>Why DMS fits:<\/strong> Provides a consistent method to migrate each instance into Cloud SQL (note: consolidation into fewer instances requires planning; DMS migrates a source to a destination\u2014merging may need extra work).<\/li>\n<li><strong>Example:<\/strong> A media company migrates 20 departmental MySQL servers into managed Cloud SQL instances per environment.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Application modernization prerequisite: move database first<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> The app will be refactored later, but the database needs managed ops now.<\/li>\n<li><strong>Why DMS fits:<\/strong> Enables \u201cdatabase-first\u201d migration patterns for quicker operational wins.<\/li>\n<li><strong>Example:<\/strong> An enterprise moves PostgreSQL to Cloud SQL first, then modernizes app services to GKE later.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Disaster recovery strategy change (new primary in Google Cloud)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> The organization wants to relocate primaries into Google Cloud and keep the old site as fallback during transition.<\/li>\n<li><strong>Why DMS fits:<\/strong> Continuous replication (if supported) can help maintain synchronization until cutover.<\/li>\n<li><strong>Example:<\/strong> A logistics company migrates primary MySQL to Cloud SQL and uses the old environment temporarily as contingency.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Managed database adoption to improve compliance posture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Compliance audits require consistent patching, backups, and access controls.<\/li>\n<li><strong>Why DMS fits:<\/strong> Supports moving to Cloud SQL\/AlloyDB, where operational controls are standardized.<\/li>\n<li><strong>Example:<\/strong> A fintech moves to Cloud SQL with CMEK (where applicable) and centralized IAM policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Cross-region migration preparation (regional redesign)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A database must be moved to a different region as part of latency\/sovereignty requirements.<\/li>\n<li><strong>Why DMS fits:<\/strong> Helps run controlled migrations into a new regional Cloud SQL\/AlloyDB deployment (ensure connectivity and region support).<\/li>\n<li><strong>Example:<\/strong> An EU business migrates workloads into an EU region and updates app routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Test environment seeding with one-time migration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Developers need a realistic dataset in a new Cloud SQL instance.<\/li>\n<li><strong>Why DMS fits:<\/strong> One-time migrations can seed data with less manual dump\/restore.<\/li>\n<li><strong>Example:<\/strong> A QA team seeds a staging Cloud SQL instance from a sanitized on-prem MySQL source.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability varies by database engine, version, and migration mode. Always confirm current support in the official docs: https:\/\/cloud.google.com\/database-migration\/docs<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Migration jobs (one-time and continuous)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Represents the migration workflow; you choose one-time or continuous (CDC-like) replication when supported.<\/li>\n<li><strong>Why it matters:<\/strong> Provides a structured lifecycle: configure \u2192 start \u2192 monitor \u2192 validate \u2192 cut over.<\/li>\n<li><strong>Practical benefit:<\/strong> Less custom scripting; consistent operational steps.<\/li>\n<li><strong>Caveat:<\/strong> Continuous replication requires specific source configuration (e.g., binary logs\/WAL, privileges). Verify prerequisites per engine.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Connection profiles (source and destination)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Stores connection info and settings for endpoints.<\/li>\n<li><strong>Why it matters:<\/strong> Separates connectivity configuration from migration job logic.<\/li>\n<li><strong>Practical benefit:<\/strong> Reuse profiles across rehearsals; simplify standardization.<\/li>\n<li><strong>Caveat:<\/strong> Treat credentials and TLS materials as sensitive. Prefer least privilege and secret management patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Private connectivity options (for non-public sources)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Enables DMS to reach private IP databases over VPC\/hybrid networking, reducing exposure.<\/li>\n<li><strong>Why it matters:<\/strong> Many enterprises disallow public database endpoints.<\/li>\n<li><strong>Practical benefit:<\/strong> Aligns with private-by-default security.<\/li>\n<li><strong>Caveat:<\/strong> Requires correct routing, firewall rules, and non-overlapping CIDRs. Misconfigurations are a common cause of connection failures.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Guided setup and validation checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> The console workflow typically validates reachability and basic configuration.<\/li>\n<li><strong>Why it matters:<\/strong> Catches issues early (auth, network, permissions).<\/li>\n<li><strong>Practical benefit:<\/strong> Faster troubleshooting than ad-hoc replication setup.<\/li>\n<li><strong>Caveat:<\/strong> Validation is not a substitute for application-level testing and performance testing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Observability: status, logs, metrics (via Google Cloud Ops)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Surfaces job state, errors, and operational signals.<\/li>\n<li><strong>Why it matters:<\/strong> Migrations are time-bound and risk-sensitive; you need visibility.<\/li>\n<li><strong>Practical benefit:<\/strong> Integrate with alerting on failures or lag (where available).<\/li>\n<li><strong>Caveat:<\/strong> Metric\/log availability depends on engine\/mode. Verify what signals are exposed for your migration type.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) IAM and auditability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Uses Google Cloud IAM roles to control who can create\/modify jobs and view details; admin actions appear in Cloud Audit Logs.<\/li>\n<li><strong>Why it matters:<\/strong> Migration credentials and operations are sensitive.<\/li>\n<li><strong>Practical benefit:<\/strong> Enforce least privilege and change control.<\/li>\n<li><strong>Caveat:<\/strong> Over-broad roles are a common risk. Use custom roles when needed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Integration with Cloud SQL \/ AlloyDB target provisioning<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Works with managed targets; you typically pre-create the target instance and then migrate into it.<\/li>\n<li><strong>Why it matters:<\/strong> Successful migration depends on target sizing, flags, users, extensions, and network design.<\/li>\n<li><strong>Practical benefit:<\/strong> Standard target patterns (private IP, HA, backups) can be applied consistently.<\/li>\n<li><strong>Caveat:<\/strong> Schema\/user objects and permissions may need careful planning. DMS focuses on migration, not ongoing database tuning.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Cutover support (promotion\/finalization flow)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides a defined process to stop writes on source, let replication catch up (continuous), and finalize.<\/li>\n<li><strong>Why it matters:<\/strong> Cutover is where most outages occur.<\/li>\n<li><strong>Practical benefit:<\/strong> Clear step sequence reduces human error.<\/li>\n<li><strong>Caveat:<\/strong> You still need an application cutover plan: connection strings, DNS, secrets, and rollback.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level architecture<\/h3>\n\n\n\n<p>At a high level, Database Migration Service sits between:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>source database<\/strong> (on\u2011prem, VM, or another cloud)<\/li>\n<li>A <strong>target managed database<\/strong> in Google Cloud (Cloud SQL or AlloyDB)<\/li>\n<li>Supporting components: <strong>VPC networking<\/strong>, <strong>IAM<\/strong>, and <strong>Operations<\/strong> tooling<\/li>\n<\/ul>\n\n\n\n<p>The service coordinates:\n1. Connectivity to source and target\n2. Initial data load\n3. Optional continuous replication to keep the target updated\n4. Final cutover steps<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow vs data flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> You create and manage connection profiles and migration jobs in a Google Cloud project (console\/API). IAM controls access.<\/li>\n<li><strong>Data plane:<\/strong> The actual data movement occurs over the configured network path from source to Google Cloud target.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common Google Cloud integrations in real deployments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cloud SQL \/ AlloyDB<\/strong>: destination platforms<\/li>\n<li><strong>VPC<\/strong>: routing, firewall rules, private IP design<\/li>\n<li><strong>Cloud VPN \/ Cloud Interconnect<\/strong>: hybrid connectivity to on\u2011prem sources<\/li>\n<li><strong>Secret Manager<\/strong> (recommended): store and rotate database passwords\/keys (DMS may require direct credential entry depending on workflow; if so, enforce internal processes)<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: migration observability<\/li>\n<li><strong>Cloud Audit Logs<\/strong>: admin and configuration audit trail<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services (typical)<\/h3>\n\n\n\n<p>Depending on your configuration, you may need:\n&#8211; Database Migration Service API (Database Migration API)\n&#8211; Cloud SQL Admin API\n&#8211; Compute Engine API (if using VMs or VPC constructs)\n&#8211; Service Networking API (commonly required for private service networking scenarios, especially for Cloud SQL private IP)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>User\/admin authentication:<\/strong> Google Cloud IAM identities (users\/groups\/service accounts) interact with the DMS control plane.<\/li>\n<li><strong>Data authentication:<\/strong> Database username\/password and potentially TLS client\/server certificates depending on your engine and security configuration.<\/li>\n<li><strong>Authorization:<\/strong> IAM decides who can operate DMS; database grants decide what the migration user can read\/replicate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<p>Common patterns include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Public IP connectivity:<\/strong> simplest but often least preferred. Requires opening firewall rules on the source and\/or allowing connections from DMS, plus TLS for protection.<\/li>\n<li><strong>Private connectivity:<\/strong> preferred for production. Source is reachable via VPC (and optionally VPN\/Interconnect). Requires careful CIDR planning, routing, and firewall rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Monitoring:<\/strong> define alerts for job failures, replication lag (if exposed), and Cloud SQL instance health.<\/li>\n<li><strong>Logging:<\/strong> enable and retain relevant logs; ensure sensitive values are not leaked in logs.<\/li>\n<li><strong>Governance:<\/strong> define naming conventions for jobs and connection profiles; use labels\/tags where supported for cost allocation and inventory.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  A[Source DB\\n(MySQL\/PostgreSQL\/SQL Server)] --&gt;|Initial load + optional continuous replication| B[Database Migration Service]\n  B --&gt; C[Target DB\\n(Cloud SQL or AlloyDB)]\n  D[IAM] --&gt; B\n  E[VPC \/ VPN \/ Interconnect] --- A\n  E --- B\n  E --- C\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph OnPrem[On-prem \/ Other cloud]\n    SDB[(Source Database)]\n    FW[Firewall \/ Security Groups]\n  end\n\n  subgraph Hybrid[Hybrid Connectivity]\n    VPN[Cloud VPN or Interconnect]\n    RT[Routing]\n  end\n\n  subgraph GCP[Google Cloud Project]\n    VPC[VPC Network\\nSubnets + Firewall rules]\n    DMS[Database Migration Service\\n(Migration job + Connection profiles)]\n    LOG[Cloud Logging]\n    MON[Cloud Monitoring]\n    AUD[Cloud Audit Logs]\n    SM[Secret Manager\\n(recommended)]\n    TDB[(Cloud SQL \/ AlloyDB Target)]\n  end\n\n  SDB --- FW\n  FW --&gt; VPN --&gt; RT --&gt; VPC\n  VPC --- DMS\n  DMS --&gt; TDB\n\n  DMS --&gt; LOG\n  DMS --&gt; MON\n  DMS --&gt; AUD\n  SM -.store secrets.-&gt; DMS\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A Google Cloud <strong>project<\/strong> with <strong>billing enabled<\/strong><\/li>\n<li>APIs enabled (commonly):<\/li>\n<li>Database Migration API<\/li>\n<li>Cloud SQL Admin API (and\/or AlloyDB Admin API if applicable)<\/li>\n<li>Compute Engine API (for VPC, firewall, VMs)<\/li>\n<li>Service Networking API (often needed for private IP targets like Cloud SQL)<\/li>\n<li>Verify exact API list in official docs for your migration path.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM permissions (typical)<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Create\/manage DMS resources (migration jobs, connection profiles, connectivity)\n&#8211; Create\/manage Cloud SQL or AlloyDB target resources\n&#8211; Configure VPC firewall rules\/routes (if using private connectivity)<\/p>\n\n\n\n<p>Common predefined roles you may see in guides include:\n&#8211; <code>roles\/datamigration.admin<\/code> (Database Migration Service Admin)\n&#8211; <code>roles\/cloudsql.admin<\/code> (for Cloud SQL targets) and\/or AlloyDB admin roles as applicable\n&#8211; <code>roles\/compute.networkAdmin<\/code> (VPC\/firewall)\n&#8211; <code>roles\/iam.serviceAccountUser<\/code> (if operating via service accounts)<\/p>\n\n\n\n<p>Exact minimum roles vary; prefer least privilege and consider custom roles for production.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud Console<\/strong> (web UI)<\/li>\n<li><strong>gcloud CLI<\/strong> (recommended for repeatability): https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>A SQL client (mysql\/psql\/sqlcmd) for validation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<p>Database Migration Service is region-based. Choose a region that:\n&#8211; Supports your target (Cloud SQL\/AlloyDB) features\n&#8211; Minimizes latency to the source (especially for continuous replication)\n&#8211; Meets data residency requirements<\/p>\n\n\n\n<p>Verify current region support in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Quotas can apply to:\n&#8211; Number of migration jobs \/ connection profiles\n&#8211; API request quotas\n&#8211; Cloud SQL instance quotas\n&#8211; Network resources (IP ranges, peering limits)<\/p>\n\n\n\n<p>Check quotas in the Cloud console and in product docs before large-scale migrations.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services and source readiness<\/h3>\n\n\n\n<p>Your source must meet engine-specific prerequisites. Examples (verify per engine\/version):\n&#8211; MySQL: binary logging configuration, appropriate privileges, stable network connectivity\n&#8211; PostgreSQL: WAL settings, replication permissions, extensions compatibility (if applicable)\n&#8211; SQL Server: required permissions and features<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (what you pay for)<\/h3>\n\n\n\n<p>Database Migration Service pricing can change over time. <strong>Do not assume it is always free or always billed<\/strong>\u2014confirm on the official pricing page for your date\/region.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page (verify current model): https:\/\/cloud.google.com\/database-migration\/pricing  <\/li>\n<li>Pricing calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<p>In many real deployments, the largest costs are often <strong>not<\/strong> the DMS control plane itself but the <strong>target database<\/strong> and <strong>networking\/data transfer<\/strong> involved.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common pricing dimensions and cost drivers<\/h3>\n\n\n\n<p>Even when the migration service has minimal direct charges, migrations typically incur costs in these areas:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Target database costs<\/strong>\n   &#8211; Cloud SQL: instance size (vCPU\/RAM), storage type\/size, HA configuration, backups, read replicas\n   &#8211; AlloyDB: compute and storage costs\n   &#8211; These costs run during rehearsals and the full migration window.<\/p>\n<\/li>\n<li>\n<p><strong>Network and data transfer<\/strong>\n   &#8211; Data egress from the source environment (especially if source is outside Google Cloud)\n   &#8211; Cross-region network charges if source and target are in different regions\n   &#8211; VPN\/Interconnect costs (tunnel charges, bandwidth\/attachments)<\/p>\n<\/li>\n<li>\n<p><strong>Compute used for source hosting or staging<\/strong>\n   &#8211; If you stand up temporary VMs for source simulation or intermediate steps\n   &#8211; Bastion hosts \/ proxies for private connectivity patterns<\/p>\n<\/li>\n<li>\n<p><strong>Storage and backups<\/strong>\n   &#8211; Cloud SQL automated backups and PITR (if enabled)\n   &#8211; Logs and monitoring retention (Cloud Logging costs can rise with verbose logs)<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Long migration windows:<\/strong> continuous replication may run for days while you validate\u2014meaning you pay for target instances longer than expected.<\/li>\n<li><strong>Overprovisioned targets:<\/strong> teams often oversize early \u201cjust in case\u201d and forget to resize later.<\/li>\n<li><strong>Rehearsal environments:<\/strong> multiple non-prod targets can multiply costs.<\/li>\n<li><strong>Data transfer surprises:<\/strong> egress from another cloud provider can be significant.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use the <strong>smallest target size<\/strong> that still meets migration performance needs for rehearsals, then resize for production.<\/li>\n<li>Keep <strong>source and target in the same region<\/strong> where feasible.<\/li>\n<li>Prefer <strong>private connectivity<\/strong> that avoids unnecessary hops and reduces exposure (cost impact depends on your topology).<\/li>\n<li>Limit log verbosity and set Cloud Logging retention policies appropriately.<\/li>\n<li>Clean up old migration jobs, connection profiles, and temporary infrastructure after cutover.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A low-cost lab typically includes:\n&#8211; 1 small Compute Engine VM (source)\n&#8211; 1 small Cloud SQL instance (target)\n&#8211; Minimal storage\n&#8211; A short migration window (hours, not days)<\/p>\n\n\n\n<p>Use the pricing calculator to estimate based on:\n&#8211; VM type + hours\n&#8211; Cloud SQL instance size + storage + hours\n&#8211; Network egress (ideally $0 if all in one region inside Google Cloud)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations (conceptual)<\/h3>\n\n\n\n<p>Production migration planning should include:\n&#8211; Cloud SQL HA (regional) if required\n&#8211; Sufficient IOPS\/storage for sustained replication catch-up\n&#8211; VPN\/Interconnect costs if hybrid\n&#8211; Monitoring and on-call time (people cost)\n&#8211; A rollback environment (potentially parallel run)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab walks through a <strong>small, realistic<\/strong> migration: <strong>MySQL on a Compute Engine VM (source)<\/strong> \u2192 <strong>Cloud SQL for MySQL (target)<\/strong> using <strong>Database Migration Service<\/strong>.<\/p>\n\n\n\n<blockquote>\n<p>Notes before you begin:\n&#8211; Exact screens and required flags can change. Use this lab as a practical workflow and <strong>verify each engine prerequisite<\/strong> in the official documentation for your chosen MySQL version.\n&#8211; The tutorial uses <strong>private IP connectivity inside a VPC<\/strong> to avoid exposing MySQL publicly. If you can\u2019t use private connectivity in your environment, you can adapt to public IP connectivity (but do so only with strong firewall restrictions and TLS).<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Migrate a MySQL database into Cloud SQL for MySQL using Database Migration Service, validate replicated data, and clean up resources safely.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a VPC firewall rule and a MySQL source VM\n2. Configure MySQL prerequisites for replication\/migration\n3. Create a Cloud SQL target instance\n4. Create Database Migration Service resources:\n   &#8211; Private connectivity (if required by your chosen connectivity model)\n   &#8211; Source and destination connection profiles\n   &#8211; A migration job (continuous preferred for low downtime, if available)\n5. Run the migration and validate data replication\n6. Clean up all resources<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a project and set gcloud defaults<\/h3>\n\n\n\n<p>1) Set variables (edit to your needs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">export PROJECT_ID=\"YOUR_PROJECT_ID\"\nexport REGION=\"us-central1\"\nexport ZONE=\"us-central1-a\"\nexport NETWORK=\"default\"\n<\/code><\/pre>\n\n\n\n<p>2) Set your project and region:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config set project \"$PROJECT_ID\"\ngcloud config set compute\/region \"$REGION\"\ngcloud config set compute\/zone \"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>gcloud config list<\/code> shows your project\/region\/zone.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Enable required APIs<\/h3>\n\n\n\n<p>Enable common APIs used in this lab:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable \\\n  datamigration.googleapis.com \\\n  sqladmin.googleapis.com \\\n  compute.googleapis.com \\\n  servicenetworking.googleapis.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> APIs enable successfully (may take 1\u20133 minutes).<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled --filter=\"name:datamigration OR name:sqladmin\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create the MySQL source VM (Compute Engine)<\/h3>\n\n\n\n<p>Create a small Linux VM (choose a machine type appropriate for your quotas). This example uses a Debian image:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances create mysql-source-vm \\\n  --zone \"$ZONE\" \\\n  --machine-type \"e2-medium\" \\\n  --image-family \"debian-12\" \\\n  --image-project \"debian-cloud\" \\\n  --network \"$NETWORK\" \\\n  --tags \"mysql-source\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> VM is created.<\/p>\n\n\n\n<p>SSH into it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh mysql-source-vm --zone \"$ZONE\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Install and configure MySQL on the source VM<\/h3>\n\n\n\n<p>On the VM, install MySQL server (package name can vary by distro\/version):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo apt-get update\nsudo apt-get install -y default-mysql-server\n<\/code><\/pre>\n\n\n\n<p>Check MySQL is running:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo systemctl status mysql --no-pager\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> MySQL service is active\/running.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Configure MySQL for migration\/replication prerequisites<\/h4>\n\n\n\n<p>Database Migration Service continuous migrations typically require binary logging and specific settings. The exact required settings depend on your MySQL version and DMS method. <strong>Verify the current requirements in the official docs<\/strong> for \u201cMySQL source requirements\u201d.<\/p>\n\n\n\n<p>A common baseline includes:\n&#8211; <code>server-id<\/code>\n&#8211; <code>log_bin<\/code>\n&#8211; <code>binlog_format=ROW<\/code><\/p>\n\n\n\n<p>Edit the MySQL config (location may vary). On Debian, commonly:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo nano \/etc\/mysql\/mysql.conf.d\/mysqld.cnf\n<\/code><\/pre>\n\n\n\n<p>Add\/update under <code>[mysqld]<\/code> (example only\u2014verify required values):<\/p>\n\n\n\n<pre><code class=\"language-ini\">[mysqld]\nserver-id=1\nlog_bin=mysql-bin\nbinlog_format=ROW\nbinlog_row_image=FULL\n<\/code><\/pre>\n\n\n\n<p>Restart MySQL:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo systemctl restart mysql\n<\/code><\/pre>\n\n\n\n<p>Verify binary log is enabled:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mysql -e \"SHOW VARIABLES LIKE 'log_bin';\"\nsudo mysql -e \"SHOW VARIABLES LIKE 'binlog_format';\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>log_bin<\/code> = ON and <code>binlog_format<\/code> = ROW.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Create a sample database and table<\/h4>\n\n\n\n<p>Create a database and some rows to migrate:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mysql &lt;&lt;'SQL'\nCREATE DATABASE dms_lab;\nUSE dms_lab;\n\nCREATE TABLE customers (\n  id INT PRIMARY KEY AUTO_INCREMENT,\n  email VARCHAR(255) NOT NULL,\n  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP\n);\n\nINSERT INTO customers (email) VALUES\n ('alice@example.com'),\n ('bob@example.com');\nSQL\n<\/code><\/pre>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mysql -e \"SELECT * FROM dms_lab.customers;\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Two rows appear.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Create a dedicated migration user<\/h4>\n\n\n\n<p>Create a user for DMS. Privileges required vary by migration method. <strong>Follow the official docs<\/strong> for the minimal grants. For a lab, you can start with broader grants and then tighten later.<\/p>\n\n\n\n<p>Example (adjust host and password):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mysql &lt;&lt;'SQL'\nCREATE USER 'dms_user'@'%' IDENTIFIED BY 'CHANGEME_STRONG_PASSWORD';\nGRANT SELECT, RELOAD, SHOW VIEW, EVENT, TRIGGER, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT\n  ON *.* TO 'dms_user'@'%';\nFLUSH PRIVILEGES;\nSQL\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> user created.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Allow private connectivity from DMS to the source VM (firewall)<\/h3>\n\n\n\n<p>If you use a private connectivity model, you typically allocate an IP range for DMS connectivity and then allow that range to access the source database port (3306). The exact IP range depends on how you set up DMS private connectivity.<\/p>\n\n\n\n<p>For now, create a firewall rule that you will later scope to the DMS connectivity range. In a real environment, keep this rule as narrow as possible.<\/p>\n\n\n\n<p>Example firewall rule (you will replace the source range with the actual DMS range you allocate):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Example only. Replace SOURCE_RANGE with the DMS private connectivity CIDR you allocate (e.g., 10.10.0.0\/24).\nexport SOURCE_RANGE=\"10.10.0.0\/24\"\n\ngcloud compute firewall-rules create allow-mysql-from-dms \\\n  --network \"$NETWORK\" \\\n  --allow tcp:3306 \\\n  --source-ranges \"$SOURCE_RANGE\" \\\n  --target-tags \"mysql-source\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Firewall rule created.<\/p>\n\n\n\n<blockquote>\n<p>If you are not using DMS private connectivity and instead use public connectivity, you must control exposure tightly (source authorized networks, restricted firewall rules) and enable TLS.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create the Cloud SQL for MySQL target instance<\/h3>\n\n\n\n<p>Create a Cloud SQL instance. Choose the smallest suitable configuration for a lab, but ensure it supports your required features.<\/p>\n\n\n\n<p>You can create it via Console (recommended for beginners) or CLI.<\/p>\n\n\n\n<p><strong>Console approach:<\/strong>\n1. Go to Cloud SQL: https:\/\/console.cloud.google.com\/sql\n2. Create instance \u2192 <strong>MySQL<\/strong>\n3. Choose region, set root password, configure networking (private IP recommended for production)\n4. Create the instance<\/p>\n\n\n\n<p><strong>CLI approach (example; flags vary\u2014verify current gcloud SQL syntax):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">export SQL_INSTANCE=\"mysql-target-cloudsql\"\nexport SQL_ROOT_PASSWORD=\"CHANGEME_STRONG_PASSWORD\"\n\ngcloud sql instances create \"$SQL_INSTANCE\" \\\n  --database-version=MYSQL_8_0 \\\n  --region=\"$REGION\" \\\n  --root-password=\"$SQL_ROOT_PASSWORD\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Cloud SQL instance is created and running.<\/p>\n\n\n\n<p>Verification:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud sql instances describe \"$SQL_INSTANCE\" --format=\"value(state)\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create Database Migration Service connection profiles<\/h3>\n\n\n\n<p>Database Migration Service setup is often easiest in the <strong>Google Cloud Console<\/strong>, because it guides you through connectivity options and validations.<\/p>\n\n\n\n<p>Go to Database Migration Service:\nhttps:\/\/console.cloud.google.com\/database-migration<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">7A) (If needed) Create private connectivity for DMS<\/h4>\n\n\n\n<p>In the DMS console, look for <strong>Connectivity<\/strong> \/ <strong>Private connectivity<\/strong> setup (terminology can vary). You typically:\n&#8211; Choose a region\n&#8211; Select a VPC network\n&#8211; Provide a dedicated, non-overlapping IP range (CIDR) for peering<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Private connectivity resource is created and in a ready state.<\/p>\n\n\n\n<blockquote>\n<p>If you created a firewall rule in Step 5, ensure the allowed source CIDR matches the DMS connectivity CIDR you actually allocated.<\/p>\n<\/blockquote>\n\n\n\n<h4 class=\"wp-block-heading\">7B) Create a source connection profile (MySQL on VM)<\/h4>\n\n\n\n<p>You will need:\n&#8211; Host: the private IP of <code>mysql-source-vm<\/code> (find it in Compute Engine \u2192 VM details)\n&#8211; Port: 3306\n&#8211; Username: <code>dms_user<\/code>\n&#8211; Password: the password you set\n&#8211; TLS settings: configure if required by your security policy<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> DMS validates connectivity and saves the profile.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">7C) Create a destination connection profile (Cloud SQL)<\/h4>\n\n\n\n<p>Select the Cloud SQL instance as the destination endpoint.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> Destination profile created.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create and run a migration job<\/h3>\n\n\n\n<p>In Database Migration Service:\n1. Create <strong>Migration job<\/strong>\n2. Select:\n   &#8211; Source connection profile\n   &#8211; Destination connection profile\n3. Choose migration type:\n   &#8211; <strong>Continuous<\/strong> (preferred for low downtime) if available for your MySQL source\/target\n   &#8211; Otherwise choose <strong>One-time<\/strong>\n4. Configure additional options (dump settings, objects to include\/exclude, etc.) as prompted.\n5. Start the job.<\/p>\n\n\n\n<p><strong>Expected outcome:<\/strong> The job enters a running state and begins initial load, then (for continuous) starts replicating ongoing changes.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Validate data in Cloud SQL<\/h3>\n\n\n\n<p>Connect to Cloud SQL and check that the <code>dms_lab<\/code> database and <code>customers<\/code> table exist and contain rows.<\/p>\n\n\n\n<p>One convenient approach is:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud sql connect \"$SQL_INSTANCE\" --user=root\n<\/code><\/pre>\n\n\n\n<p>Then in the SQL prompt:<\/p>\n\n\n\n<pre><code class=\"language-sql\">SHOW DATABASES;\nSELECT * FROM dms_lab.customers;\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You see the two seeded rows.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Test ongoing replication (for continuous migrations)<\/h4>\n\n\n\n<p>On the source VM, insert another row:<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo mysql -e \"INSERT INTO dms_lab.customers (email) VALUES ('carol@example.com');\"\n<\/code><\/pre>\n\n\n\n<p>Then query Cloud SQL again:<\/p>\n\n\n\n<pre><code class=\"language-sql\">SELECT * FROM dms_lab.customers;\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The new row appears on the target after a short delay (replication lag depends on workload and network).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Cutover (conceptual)<\/h3>\n\n\n\n<p>For a continuous migration, a typical cutover sequence is:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Put the application into maintenance\/read-only mode (stop writes to source)<\/li>\n<li>Wait until replication catches up (lag approaches zero)<\/li>\n<li>Finalize\/promote the migration (DMS workflow)<\/li>\n<li>Point applications to the Cloud SQL instance (update connection strings, secrets, DNS)<\/li>\n<li>Monitor closely and keep a rollback plan for a limited window<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome:<\/strong> Application writes to Cloud SQL, and the source is no longer the system of record.<\/p>\n\n\n\n<blockquote>\n<p>Cutover steps can vary by engine and DMS workflow updates\u2014follow the current official cutover guide for your migration type.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DMS migration job status shows <strong>running\/healthy<\/strong> (or completed for one-time)<\/li>\n<li>Cloud SQL contains:<\/li>\n<li><code>dms_lab<\/code> database<\/li>\n<li><code>customers<\/code> table<\/li>\n<li>expected row counts<\/li>\n<li>Insert on source appears on target (continuous migration)<\/li>\n<li>Cloud SQL instance CPU\/memory are within acceptable bounds during migration<\/li>\n<li>Cloud Logging shows no repeated connectivity\/authentication errors<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common errors and practical fixes:<\/p>\n\n\n\n<p>1) <strong>\u201cCannot connect to source\u201d<\/strong>\n&#8211; Check source VM firewall rule allows port 3306 from the correct DMS connectivity range.\n&#8211; Verify routing (if hybrid): VPC routes, VPN status, non-overlapping CIDRs.\n&#8211; Confirm MySQL binds to the right interface (e.g., not only <code>127.0.0.1<\/code>).<\/p>\n\n\n\n<p>2) <strong>Authentication failures<\/strong>\n&#8211; Confirm username\/password in the source connection profile.\n&#8211; Verify MySQL user host pattern (<code>'dms_user'@'%'<\/code> vs restricted).\n&#8211; If TLS is required, ensure certificates are correct and CA trust is configured as required.<\/p>\n\n\n\n<p>3) <strong>Replication prerequisites not met<\/strong>\n&#8211; Verify MySQL binary logging is enabled and binlog format matches requirements.\n&#8211; Ensure required privileges are granted (replication-related privileges often required for continuous).\n&#8211; Check MySQL version compatibility with the target.<\/p>\n\n\n\n<p>4) <strong>Migration is slow<\/strong>\n&#8211; Check source\/target sizing (CPU, disk, IOPS).\n&#8211; Verify network throughput\/latency.\n&#8211; Reduce load on the source during initial load if possible.\n&#8211; Consider running migration during off-peak hours.<\/p>\n\n\n\n<p>5) <strong>Schema\/object mismatches<\/strong>\n&#8211; DMS focuses on migrating data and supported objects for the chosen engine\/method. Stored procedures, triggers, definers, or special plugins may require manual steps. Verify in docs and test rehearsals.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing costs, delete lab resources when finished.<\/p>\n\n\n\n<p>1) Delete the DMS migration job and connection profiles (Console is easiest):\n&#8211; Database Migration Service \u2192 Migration jobs \u2192 Delete\n&#8211; Connection profiles \u2192 Delete\n&#8211; Private connectivity resource \u2192 Delete (if created)<\/p>\n\n\n\n<p>2) Delete Cloud SQL instance:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud sql instances delete \"$SQL_INSTANCE\"\n<\/code><\/pre>\n\n\n\n<p>3) Delete Compute Engine VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute instances delete mysql-source-vm --zone \"$ZONE\"\n<\/code><\/pre>\n\n\n\n<p>4) Delete firewall rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules delete allow-mysql-from-dms\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> No billable lab resources remain.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rehearse migrations<\/strong> in dev\/staging with production-like data volumes and network paths.<\/li>\n<li>Choose <strong>private connectivity<\/strong> for production migrations whenever possible.<\/li>\n<li>Keep <strong>source and target close<\/strong> (regionally) to reduce latency and replication lag.<\/li>\n<li>Plan the <strong>cutover<\/strong> as an application change, not just a database event (config, secrets, DNS, pooling).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong> roles for DMS operators.<\/li>\n<li>Separate duties:<\/li>\n<li>Network admins manage private connectivity and firewall rules<\/li>\n<li>DBAs manage source grants<\/li>\n<li>App teams validate functionality<\/li>\n<li>Restrict who can <strong>view connection profile details<\/strong>, because they may contain sensitive info.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Timebox rehearsal environments; delete idle targets.<\/li>\n<li>Right-size Cloud SQL\/AlloyDB after migration; don\u2019t keep \u201cmigration sizing\u201d forever.<\/li>\n<li>Monitor Cloud Logging ingestion volume; reduce noisy logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure source DB has enough headroom for initial load (CPU, disk, IOPS).<\/li>\n<li>Avoid running heavy maintenance jobs during initial load (index rebuilds, batch jobs).<\/li>\n<li>Validate target parameter settings (buffer pool, max connections) appropriate to your workload (within Cloud SQL constraints).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a rollback plan:<\/li>\n<li>Clear criteria for success\/failure<\/li>\n<li>Data divergence strategy<\/li>\n<li>Duration you can keep the old system online<\/li>\n<li>Use Cloud SQL HA where required and test failover behavior separately from migration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Define an <strong>on-call runbook<\/strong> for migration day:<\/li>\n<li>Where to look for logs<\/li>\n<li>How to pause\/stop\/retry (if supported)<\/li>\n<li>Who to contact for network\/DB\/app<\/li>\n<li>Use labels and naming conventions:<\/li>\n<li><code>env=staging<\/code>, <code>app=orders<\/code>, <code>migration=2026q2<\/code><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize naming:<\/li>\n<li><code>cp-src-&lt;app&gt;-&lt;env&gt;<\/code><\/li>\n<li><code>cp-dst-&lt;app&gt;-&lt;env&gt;<\/code><\/li>\n<li><code>mj-&lt;app&gt;-&lt;env&gt;-&lt;date&gt;<\/code><\/li>\n<li>Use consistent labels for cost allocation and inventory tracking.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Control plane access is governed by <strong>IAM<\/strong>.<\/li>\n<li>Use separate Google Cloud groups for:<\/li>\n<li>Migration operators<\/li>\n<li>Network operators<\/li>\n<li>Read-only auditors<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit:<\/strong> Prefer TLS between DMS and source\/target where supported; follow official engine-specific guidance.<\/li>\n<li><strong>At rest:<\/strong> Cloud SQL and AlloyDB encrypt data at rest by default; consider CMEK requirements for your org (verify feature availability per product\/edition).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer <strong>private IP<\/strong> for Cloud SQL and private connectivity to sources.<\/li>\n<li>If public IP must be used:<\/li>\n<li>Restrict source firewall to known ranges<\/li>\n<li>Use TLS<\/li>\n<li>Avoid broad <code>0.0.0.0\/0<\/code> access at all costs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Store DB passwords in <strong>Secret Manager<\/strong> and enforce rotation policies.<\/li>\n<li>Limit who can retrieve secrets; avoid embedding credentials in scripts and tickets.<\/li>\n<li>If connection profiles require direct password entry, use internal secure processes (screen sharing restrictions, redaction, access logs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Cloud Audit Logs<\/strong> to track:<\/li>\n<li>Who created\/modified migration jobs<\/li>\n<li>Who changed networking or IAM<\/li>\n<li>Ensure log retention matches compliance requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data residency: choose regions appropriately.<\/li>\n<li>Access controls: enforce MFA and conditional access where applicable.<\/li>\n<li>Change management: migrations should be change-ticketed with approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overly broad firewall rules<\/li>\n<li>Using root\/admin DB credentials for migrations<\/li>\n<li>Publicly accessible source DB during migration<\/li>\n<li>No audit trail for migration operators<\/li>\n<li>Not testing TLS\/certificates until cutover day<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use private connectivity and private IP targets.<\/li>\n<li>Create a dedicated migration user with minimal required grants.<\/li>\n<li>Use dedicated projects or folders for migration operations if your org requires environment separation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>These are common constraints and pitfalls; confirm engine-specific and version-specific details in official docs.<\/p>\n<\/blockquote>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Engine\/version compatibility:<\/strong> Not every source version is supported; verify supported versions and editions.<\/li>\n<li><strong>Homogeneous focus:<\/strong> DMS is primarily for same-engine migrations. Heterogeneous conversion may require additional tools\/workflows.<\/li>\n<li><strong>Extensions and custom features:<\/strong> PostgreSQL extensions, MySQL plugins, and SQL Server features may not migrate cleanly.<\/li>\n<li><strong>Definers\/security context:<\/strong> Views\/triggers\/procedures with definers can fail or behave differently on the target.<\/li>\n<li><strong>Networking is the #1 failure domain:<\/strong> routing, firewall, DNS, TLS, and IP overlap issues are common.<\/li>\n<li><strong>Replication lag surprises:<\/strong> high write volume can cause lag; plan for catch-up time.<\/li>\n<li><strong>Large objects\/large tables:<\/strong> initial load can take longer than expected; test with realistic volumes.<\/li>\n<li><strong>Cutover is an application event:<\/strong> forgetting connection pools, caches, or DNS TTLs can extend downtime.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Database Migration Service is one option in Google Cloud\u2019s Databases and data movement toolbox. Here\u2019s how it compares.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Database Migration Service (Google Cloud)<\/strong><\/td>\n<td>Homogeneous migrations into Cloud SQL\/AlloyDB with guided workflows<\/td>\n<td>Managed orchestration, integrates with IAM\/logging, supports continuous migration in supported cases<\/td>\n<td>Not a full transformation platform; support depends on engine\/version; network setup can be non-trivial<\/td>\n<td>You want a Google-managed migration workflow into Cloud SQL\/AlloyDB<\/td>\n<\/tr>\n<tr>\n<td><strong>Cloud SQL native tools (backup\/restore, import\/export, replicas)<\/strong><\/td>\n<td>Simple moves, small DBs, or replication patterns within Cloud SQL<\/td>\n<td>Familiar DB-native methods; sometimes simplest<\/td>\n<td>More manual steps; less \u201cmigration workflow\u201d visibility<\/td>\n<td>When your use case is straightforward and downtime is acceptable<\/td>\n<\/tr>\n<tr>\n<td><strong>Datastream (Google Cloud)<\/strong><\/td>\n<td>Streaming change data capture (CDC) into analytics\/pipelines<\/td>\n<td>CDC to targets like BigQuery\/GCS and downstream processing<\/td>\n<td>Not primarily a \u201cmove my OLTP DB into Cloud SQL\u201d tool<\/td>\n<td>When you need streaming CDC for analytics or event-driven pipelines<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed tools (mysqldump\/pg_dump, logical replication, rsync, custom scripts)<\/strong><\/td>\n<td>Full control or niche requirements<\/td>\n<td>Maximum flexibility<\/td>\n<td>High operational burden; error-prone; harder to audit<\/td>\n<td>When you need custom behavior not supported by managed services<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Database Migration Service<\/strong><\/td>\n<td>Migrations into AWS<\/td>\n<td>Mature service for AWS ecosystems<\/td>\n<td>Different cloud; not integrated into Google Cloud targets<\/td>\n<td>Choose when migrating into AWS, not Google Cloud<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Database Migration Service<\/strong><\/td>\n<td>Migrations into Azure<\/td>\n<td>Azure ecosystem integration<\/td>\n<td>Different cloud; not integrated into Google Cloud targets<\/td>\n<td>Choose when migrating into Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>3rd-party replication\/migration (Qlik Replicate, Striim, etc.)<\/strong><\/td>\n<td>Complex migrations, transformations, enterprise replication<\/td>\n<td>Broad source\/target matrix; advanced features<\/td>\n<td>Licensing cost; operational overhead<\/td>\n<td>When you need cross-engine, advanced transforms, or multi-target replication<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: regulated hybrid migration to Cloud SQL<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services firm must migrate on\u2011prem MySQL databases into Google Cloud while meeting strict security and audit requirements.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>On\u2011prem MySQL sources connected via <strong>Cloud Interconnect<\/strong><\/li>\n<li>DMS configured with <strong>private connectivity<\/strong><\/li>\n<li>Targets are <strong>Cloud SQL for MySQL<\/strong> with private IP, HA (where required), automated backups, and centralized monitoring<\/li>\n<li>IAM groups for migration operators with audit logging enabled<\/li>\n<li><strong>Why Database Migration Service was chosen:<\/strong><\/li>\n<li>Standardized workflow across many databases<\/li>\n<li>Better auditability than ad-hoc scripts<\/li>\n<li>Continuous migration to reduce downtime windows<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced operational burden (patching\/backups handled by Cloud SQL)<\/li>\n<li>Repeatable migration runbooks<\/li>\n<li>Improved security posture through private networking and IAM controls<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: quick move from VM MySQL to Cloud SQL<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A startup runs MySQL on a single VM with manual backups and wants managed reliability without extended downtime.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Source: MySQL on VM<\/li>\n<li>Target: Cloud SQL for MySQL (single-zone or HA based on budget)<\/li>\n<li>DMS continuous migration (if supported) to minimize downtime<\/li>\n<li><strong>Why Database Migration Service was chosen:<\/strong><\/li>\n<li>Minimal team time to set up compared to building replication scripts<\/li>\n<li>Clear status reporting during migration<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Faster recovery posture (managed backups)<\/li>\n<li>Less ops toil<\/li>\n<li>Easier scaling later with Cloud SQL features<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Database Migration Service the same as AWS DMS?<\/strong><br\/>\nNo. Google Cloud Database Migration Service is a Google Cloud product for migrating into Google Cloud managed databases. AWS DMS is an AWS product.<\/p>\n\n\n\n<p>2) <strong>What databases can I migrate with Database Migration Service?<\/strong><br\/>\nSupported sources\/targets depend on the current product support matrix (engine and version). Common supported engines include MySQL and PostgreSQL into Cloud SQL, and some PostgreSQL paths into AlloyDB. Verify current support: https:\/\/cloud.google.com\/database-migration\/docs<\/p>\n\n\n\n<p>3) <strong>Does Database Migration Service do schema conversion (heterogeneous migration)?<\/strong><br\/>\nDatabase Migration Service is primarily focused on homogeneous migrations. For cross-engine conversions, you typically need additional tools and planning. Verify current Google Cloud guidance for your source\/target pair.<\/p>\n\n\n\n<p>4) <strong>Can I do near-zero downtime migrations?<\/strong><br\/>\nContinuous migration (where supported) can reduce downtime significantly, but \u201cnear-zero\u201d depends on application cutover steps, replication lag, and workload characteristics.<\/p>\n\n\n\n<p>5) <strong>Do I need public IP access on my source database?<\/strong><br\/>\nNot necessarily. Many migrations can be done using private connectivity over VPC and hybrid networking. Public IP should be avoided for production unless strongly controlled.<\/p>\n\n\n\n<p>6) <strong>How do I secure credentials used in connection profiles?<\/strong><br\/>\nUse least-privilege database users, protect access to DMS resources with IAM, and use Secret Manager for password governance. Follow your organization\u2019s secret-handling policies.<\/p>\n\n\n\n<p>7) <strong>Does DMS migrate users and permissions?<\/strong><br\/>\nThis can vary by engine and method. Even when users are migrated, you should plan to validate grants\/roles and application connectivity. Verify behavior for your engine.<\/p>\n\n\n\n<p>8) <strong>How do I validate that the target matches the source?<\/strong><br\/>\nAt minimum: row counts, checksums for key tables, application tests, and performance tests. Also validate indexes, constraints, triggers, and routines where applicable.<\/p>\n\n\n\n<p>9) <strong>Can I pause and resume a migration job?<\/strong><br\/>\nJob lifecycle actions depend on migration mode and current product capabilities. Check the DMS documentation for your migration type.<\/p>\n\n\n\n<p>10) <strong>What if the migration fails halfway through?<\/strong><br\/>\nYou typically troubleshoot connectivity\/auth\/config issues, then retry or recreate the migration depending on failure mode. Plan rehearsals to reduce surprises in production.<\/p>\n\n\n\n<p>11) <strong>Will migration impact source performance?<\/strong><br\/>\nYes, initial load and ongoing replication read the source database and can increase I\/O and CPU. Provision headroom and schedule heavy steps off-peak.<\/p>\n\n\n\n<p>12) <strong>Can I migrate across regions?<\/strong><br\/>\nOften yes, but cross-region latency and data transfer costs can be significant. Prefer same-region migrations when possible.<\/p>\n\n\n\n<p>13) <strong>How does DMS interact with Cloud SQL private IP?<\/strong><br\/>\nCloud SQL private IP requires VPC configuration (often Private Service Access). DMS connectivity must be designed to reach both source and target networks.<\/p>\n\n\n\n<p>14) <strong>Is Database Migration Service suitable for very large databases (TB scale)?<\/strong><br\/>\nIt can be, but throughput, migration time, and operational risk increase with size. Test early with representative data and confirm performance constraints and recommended patterns.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the best first step before using DMS in production?<\/strong><br\/>\nRun an end-to-end rehearsal with production-like connectivity, validate prerequisites, measure timing, and write a cutover\/rollback runbook.<\/p>\n\n\n\n<p>16) <strong>Do I need a DBA to use DMS?<\/strong><br\/>\nYou can start without one for small labs, but production migrations benefit greatly from DBA involvement\u2014especially for source configuration, replication prerequisites, performance tuning, and validation.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Database Migration Service<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Database Migration Service docs<\/td>\n<td>Canonical setup guides, concepts, connectivity, troubleshooting: https:\/\/cloud.google.com\/database-migration\/docs<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Database Migration Service pricing<\/td>\n<td>Current pricing model and billing notes (verify): https:\/\/cloud.google.com\/database-migration\/pricing<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Google Cloud Pricing Calculator<\/td>\n<td>Estimate total costs (target DB + network + logging): https:\/\/cloud.google.com\/products\/calculator<\/td>\n<\/tr>\n<tr>\n<td>Official product page<\/td>\n<td>Database Migration Service overview<\/td>\n<td>High-level capabilities and supported paths: https:\/\/cloud.google.com\/database-migration<\/td>\n<\/tr>\n<tr>\n<td>Cloud SQL docs<\/td>\n<td>Cloud SQL documentation<\/td>\n<td>Target sizing, HA, networking, backups: https:\/\/cloud.google.com\/sql\/docs<\/td>\n<\/tr>\n<tr>\n<td>AlloyDB docs<\/td>\n<td>AlloyDB documentation<\/td>\n<td>If migrating to AlloyDB for PostgreSQL: https:\/\/cloud.google.com\/alloydb\/docs<\/td>\n<\/tr>\n<tr>\n<td>Observability docs<\/td>\n<td>Cloud Logging<\/td>\n<td>Understand log ingestion\/retention and costs: https:\/\/cloud.google.com\/logging\/docs<\/td>\n<\/tr>\n<tr>\n<td>Observability docs<\/td>\n<td>Cloud Monitoring<\/td>\n<td>Metrics and alerting for migration and target health: https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Google Cloud Tech (YouTube)<\/td>\n<td>Product explainers and demos (search for Database Migration Service): https:\/\/www.youtube.com\/@GoogleCloudTech<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>Presented neutrally as training resources to explore (verify current offerings on each site).<\/p>\n\n\n\n<p>1) <strong>DevOpsSchool.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> DevOps engineers, SREs, cloud engineers<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> Google Cloud operations, migration workflows, DevOps tooling<br\/>\n&#8211; <strong>Mode:<\/strong> check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n\n\n\n<p>2) <strong>ScmGalaxy.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> beginners to intermediate engineers<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> software configuration management, DevOps fundamentals, tooling<br\/>\n&#8211; <strong>Mode:<\/strong> check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.scmgalaxy.com\/<\/p>\n\n\n\n<p>3) <strong>CLoudOpsNow.in<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> cloud operations and platform teams<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> cloud ops practices, reliability, automation<br\/>\n&#8211; <strong>Mode:<\/strong> check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.cloudopsnow.in\/<\/p>\n\n\n\n<p>4) <strong>SreSchool.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> SREs, operations engineers, reliability-focused teams<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> SRE principles, monitoring, incident response<br\/>\n&#8211; <strong>Mode:<\/strong> check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.sreschool.com\/<\/p>\n\n\n\n<p>5) <strong>AiOpsSchool.com<\/strong><br\/>\n&#8211; <strong>Suitable audience:<\/strong> operations teams exploring AIOps approaches<br\/>\n&#8211; <strong>Likely learning focus:<\/strong> observability, automation, operational analytics<br\/>\n&#8211; <strong>Mode:<\/strong> check website<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.aiopsschool.com\/<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>Listed as trainer platforms\/sites to explore (verify current offerings and credentials directly).<\/p>\n\n\n\n<p>1) <strong>RajeshKumar.xyz<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps\/cloud training content (verify)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> engineers looking for practical guidance<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/rajeshkumar.xyz\/<\/p>\n\n\n\n<p>2) <strong>devopstrainer.in<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps training programs (verify)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> DevOps engineers and students<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopstrainer.in\/<\/p>\n\n\n\n<p>3) <strong>devopsfreelancer.com<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> freelance DevOps services\/training resources (verify)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> teams seeking hands-on help or mentoring<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsfreelancer.com\/<\/p>\n\n\n\n<p>4) <strong>devopssupport.in<\/strong><br\/>\n&#8211; <strong>Likely specialization:<\/strong> DevOps support and enablement (verify)<br\/>\n&#8211; <strong>Suitable audience:<\/strong> ops teams needing implementation support<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopssupport.in\/<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>Presented neutrally as consulting providers to evaluate (verify services, references, and contracts directly).<\/p>\n\n\n\n<p>1) <strong>cotocus.com<\/strong><br\/>\n&#8211; <strong>Likely service area:<\/strong> cloud\/DevOps consulting (verify)<br\/>\n&#8211; <strong>Where they may help:<\/strong> migration planning, architecture reviews, implementation assistance<br\/>\n&#8211; <strong>Consulting use case examples:<\/strong> migration readiness assessment; VPC\/hybrid connectivity design; operational runbooks<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/cotocus.com\/<\/p>\n\n\n\n<p>2) <strong>DevOpsSchool.com<\/strong><br\/>\n&#8211; <strong>Likely service area:<\/strong> DevOps consulting and training (verify)<br\/>\n&#8211; <strong>Where they may help:<\/strong> platform enablement, automation, cloud adoption support<br\/>\n&#8211; <strong>Consulting use case examples:<\/strong> CI\/CD enablement; cloud landing zone guidance; migration execution support<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n\n\n\n<p>3) <strong>DEVOPSCONSULTING.IN<\/strong><br\/>\n&#8211; <strong>Likely service area:<\/strong> DevOps consulting services (verify)<br\/>\n&#8211; <strong>Where they may help:<\/strong> deployment automation, operations, cloud migrations<br\/>\n&#8211; <strong>Consulting use case examples:<\/strong> migration factory setup; monitoring\/alerting integration; security baseline reviews<br\/>\n&#8211; <strong>Website:<\/strong> https:\/\/www.devopsconsulting.in\/<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before this service<\/h3>\n\n\n\n<p>To use Database Migration Service effectively, build basics in:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Relational database fundamentals:<\/strong> backups, replication concepts, transactions, indexing<\/li>\n<li><strong>MySQL\/PostgreSQL\/SQL Server administration basics:<\/strong> users\/privileges, logs, performance signals<\/li>\n<li><strong>Google Cloud fundamentals:<\/strong> projects, IAM, VPC networks, firewall rules<\/li>\n<li><strong>Cloud SQL basics:<\/strong> instance types, storage, HA, private IP networking<\/li>\n<li><strong>Hybrid networking basics:<\/strong> VPN\/Interconnect concepts, routing, CIDR planning (for enterprise migrations)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after this service<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Advanced Cloud SQL \/ AlloyDB operations:<\/strong> performance tuning, HA\/DR design, backups\/PITR, maintenance windows<\/li>\n<li><strong>Observability:<\/strong> Cloud Monitoring alerting and SLOs for database services<\/li>\n<li><strong>Security hardening:<\/strong> least privilege IAM, secret management, private service networking<\/li>\n<li><strong>Data modernization:<\/strong> Datastream, Dataflow, BigQuery analytics patterns (if your goal goes beyond lift-and-shift)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Solutions Architect<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Database Administrator (DBA)<\/li>\n<li>Cloud Security Engineer (for reviews\/approvals)<\/li>\n<li>Technical Program Manager (migration programs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Google Cloud certifications don\u2019t always map 1:1 to a single service, but relevant tracks typically include:\n&#8211; Associate Cloud Engineer (foundational operations)\n&#8211; Professional Cloud Architect (architecture and migration planning)\n&#8211; Professional Data Engineer (if migrations feed analytics)\nVerify current Google Cloud certification offerings: https:\/\/cloud.google.com\/learn\/certification<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrate a MySQL ecommerce schema from VM \u2192 Cloud SQL with continuous replication and cutover runbook<\/li>\n<li>Run three rehearsals and measure migration time under different VM\/Cloud SQL sizes<\/li>\n<li>Build an internal \u201cmigration checklist\u201d covering networking, IAM, source prerequisites, and validation queries<\/li>\n<li>Add alerting for migration job failures and Cloud SQL health during migration windows<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AlloyDB:<\/strong> Google Cloud\u2019s managed PostgreSQL-compatible database service optimized for performance (verify capabilities and migration support for your scenario).<\/li>\n<li><strong>Cloud SQL:<\/strong> Google Cloud managed relational database service for engines like MySQL, PostgreSQL, and SQL Server.<\/li>\n<li><strong>Connection profile:<\/strong> Database Migration Service resource defining how to connect to a source or destination database.<\/li>\n<li><strong>Continuous migration:<\/strong> A migration mode where changes on the source continue replicating to the target after initial load, enabling lower downtime cutover (when supported).<\/li>\n<li><strong>Cutover:<\/strong> The moment you switch application traffic\/writes from the source database to the target database.<\/li>\n<li><strong>CIDR:<\/strong> IP address range notation (e.g., <code>10.10.0.0\/24<\/code>) used in VPC subnetting and firewall rules.<\/li>\n<li><strong>Cloud Audit Logs:<\/strong> Google Cloud logs that record administrative actions and access patterns for supported services.<\/li>\n<li><strong>Cloud Monitoring:<\/strong> Metrics, dashboards, and alerting service for Google Cloud.<\/li>\n<li><strong>Cloud Logging:<\/strong> Centralized log storage, search, and retention controls for Google Cloud.<\/li>\n<li><strong>Firewall rule (VPC):<\/strong> Rule controlling allowed inbound\/outbound traffic at the network level in Google Cloud VPC.<\/li>\n<li><strong>GTID (MySQL):<\/strong> Global Transaction ID, used to uniquely identify transactions for replication (requirements vary).<\/li>\n<li><strong>Migration job:<\/strong> The Database Migration Service resource representing a specific migration execution.<\/li>\n<li><strong>Private connectivity:<\/strong> Network configuration that allows DMS to reach a source database without exposing it publicly (exact implementation varies; verify in docs).<\/li>\n<li><strong>Private IP (Cloud SQL):<\/strong> Cloud SQL networking mode where the instance is only reachable via internal IP in a VPC.<\/li>\n<li><strong>Replication lag:<\/strong> Delay between source writes and when those changes appear on the target during continuous replication.<\/li>\n<li><strong>WAL (PostgreSQL):<\/strong> Write-Ahead Log used for durability and replication.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Google Cloud <strong>Database Migration Service<\/strong> is a managed service in the <strong>Databases<\/strong> category that helps you migrate supported relational databases into <strong>Cloud SQL<\/strong> and (in supported cases) <strong>AlloyDB<\/strong>. It matters because database migrations combine networking, security, data movement, and cutover coordination\u2014and DMS provides a structured, observable workflow to reduce risk.<\/p>\n\n\n\n<p>From a cost perspective, the biggest drivers are usually the <strong>target database runtime<\/strong>, <strong>storage<\/strong>, and <strong>network egress<\/strong>, not just the migration tool itself\u2014so rehearsals, right-sizing, and cleanup are essential. From a security perspective, prioritize <strong>private connectivity<\/strong>, strict firewall rules, least-privilege IAM, and careful secrets handling.<\/p>\n\n\n\n<p>Use Database Migration Service when you want a Google-managed migration workflow for supported sources and targets, especially when you need <strong>low downtime<\/strong> via continuous replication (where supported). Next step: read the official DMS documentation for your specific engine\/version support matrix and run at least one rehearsal migration end-to-end before planning production cutover.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Databases<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,51],"tags":[],"class_list":["post-677","post","type-post","status-publish","format-standard","hentry","category-databases","category-google-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/677","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=677"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/677\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=677"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=677"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=677"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}