{"id":713,"date":"2026-04-15T03:27:42","date_gmt":"2026-04-15T03:27:42","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-migrate-to-virtual-machines-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-migration\/"},"modified":"2026-04-15T03:27:42","modified_gmt":"2026-04-15T03:27:42","slug":"google-cloud-migrate-to-virtual-machines-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-migration","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/google-cloud-migrate-to-virtual-machines-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-migration\/","title":{"rendered":"Google Cloud Migrate to Virtual Machines Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Migration"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Migration<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p><strong>What this service is<\/strong><br\/>\n<strong>Migrate to Virtual Machines<\/strong> is a Google Cloud Migration service that helps you move existing virtual machines (VMs) from supported source environments (commonly VMware vSphere, and in some cases other clouds) into <strong>Compute Engine<\/strong> VMs.<\/p>\n\n\n\n<p><strong>Simple explanation (one paragraph)<\/strong><br\/>\nIf you have servers running as VMs in a data center (for example, on VMware) and you want those same servers running in Google Cloud, Migrate to Virtual Machines provides a guided workflow to discover VMs, replicate their disks, test booting in Google Cloud, and then cut over to Compute Engine with controlled downtime.<\/p>\n\n\n\n<p><strong>Technical explanation (one paragraph)<\/strong><br\/>\nMigrate to Virtual Machines uses a connector-based model: you register a <em>source<\/em> (such as a vCenter environment) and deploy a <strong>Migrate to Virtual Machines Connector<\/strong> in (or near) the source environment. The connector coordinates VM discovery and replication. During migration, the service continuously replicates blocks\/deltas from source disks to Google Cloud, prepares a target Compute Engine instance configuration, optionally performs OS adaptation steps needed for Google Cloud, and orchestrates <strong>test clones<\/strong> and <strong>cutover<\/strong>.<\/p>\n\n\n\n<p><strong>What problem it solves<\/strong><br\/>\nLift-and-shift migrations are hard because you must coordinate discovery, data replication, change tracking, test validations, downtime windows, and rollback planning\u2014often across different virtualization stacks and networks. Migrate to Virtual Machines provides a consistent, repeatable workflow to reduce migration risk and operational toil.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Migrate to Virtual Machines?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>Migrate to Virtual Machines is designed to migrate existing VMs into <strong>Google Cloud Compute Engine<\/strong>. It helps teams move workloads to Google Cloud with minimal re-architecture while still offering safe testing and controlled cutover.<\/p>\n\n\n\n<blockquote>\n<p>Naming note: Google has historically used names like <strong>Migrate for Compute Engine<\/strong> in older materials. In current Google Cloud documentation and console, the product is presented as <strong>Migrate to Virtual Machines<\/strong>. If you find older guides, treat them as legacy and verify against current docs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what it does)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Source registration and discovery<\/strong> of supported VM sources (commonly VMware).<\/li>\n<li><strong>Replication<\/strong> of VM disks to Google Cloud (typically incremental replication after an initial sync).<\/li>\n<li><strong>Test clone<\/strong> creation so you can boot the migrated VM in an isolated manner before cutover.<\/li>\n<li><strong>Cutover orchestration<\/strong> to create the final Compute Engine VM and complete the migration.<\/li>\n<li><strong>Basic automation<\/strong> around target VM settings, network attachment, and (where supported) OS adaptation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>While exact component names can evolve, the core building blocks are typically:\n&#8211; <strong>Migrate to Virtual Machines service (control plane)<\/strong>: Managed service in Google Cloud that stores migration configuration, state, and orchestrates actions.\n&#8211; <strong>Source<\/strong>: A logical representation of the environment you migrate from (for example, a vCenter).\n&#8211; <strong>Connector<\/strong>: A VM\/appliance deployed in the source environment that communicates with Google Cloud and coordinates discovery\/replication.\n&#8211; <strong>Migration object<\/strong>: Per-VM (or per selected VM) configuration describing how the VM is replicated and what the target Compute Engine VM should look like.\n&#8211; <strong>Replication resources \/ staging resources<\/strong>: Google Cloud resources created\/used during replication and testing (details vary; verify in official docs).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed migration orchestration service<\/strong> that creates and coordinates underlying Google Cloud resources and communicates with source environments through a connector.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global\/zonal<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The <strong>migration configuration<\/strong> is typically <strong>project-scoped<\/strong> and created in a chosen Google Cloud <strong>location<\/strong> (often a region).  <\/li>\n<li>The <strong>target Compute Engine VM<\/strong> is <strong>zonal<\/strong> (Compute Engine instances run in zones), with disks that may be zonal or regional depending on your configuration.<\/li>\n<li>Some control plane components may behave like global services, but you should treat migration configuration as tied to the chosen location and project. <strong>Verify in official docs<\/strong> for the latest \u201clocation\u201d behavior and constraints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Google Cloud ecosystem<\/h3>\n\n\n\n<p>Migrate to Virtual Machines is part of the broader Google Cloud <strong>Migration<\/strong> tooling set and commonly works alongside:\n&#8211; <strong>Compute Engine<\/strong> (the migration destination)\n&#8211; <strong>Cloud Storage<\/strong> (staging artifacts, temporary storage, or logs depending on workflow)\n&#8211; <strong>VPC<\/strong> networking (target subnet, firewall rules, routes; plus VPN\/Interconnect for hybrid connectivity)\n&#8211; <strong>Cloud Logging<\/strong> and <strong>Cloud Monitoring<\/strong> (operational visibility)\n&#8211; <strong>Cloud IAM<\/strong> (who can discover, replicate, test, and cut over)\n&#8211; <strong>Cloud KMS<\/strong> (customer-managed encryption keys, if you use CMEK for disks)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Migrate to Virtual Machines?<\/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>Faster time to cloud<\/strong>: Lift-and-shift workloads without waiting for full refactoring.<\/li>\n<li><strong>Lower migration risk<\/strong>: Built-in test steps and repeatable cutover workflow.<\/li>\n<li><strong>Reduced downtime<\/strong>: Continuous replication (where supported) helps shorten maintenance 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>Structured workflow<\/strong>: Discovery \u2192 replication \u2192 test clone \u2192 cutover.<\/li>\n<li><strong>Repeatability<\/strong>: Standard process per VM reduces \u201csnowflake migrations.\u201d<\/li>\n<li><strong>Compatibility focus<\/strong>: Migration tooling can handle common issues like drivers\/boot configuration (capability depends on OS\/source\u2014verify per OS).<\/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>Progress visibility<\/strong>: Central place to see migration state, replication health, and cutover readiness.<\/li>\n<li><strong>Separation of duties<\/strong>: IAM roles allow distinct responsibilities (migration admins vs operators vs viewers).<\/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 control<\/strong>: Controlled access to migration operations.<\/li>\n<li><strong>Auditable actions<\/strong>: Migration operations can be logged in Cloud Logging \/ audit logs.<\/li>\n<li><strong>Encryption options<\/strong>: Compute Engine disk encryption and optional CMEK via Cloud KMS.<\/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>Parallel migrations<\/strong>: Migrate multiple VMs using standardized patterns.<\/li>\n<li><strong>Incremental replication<\/strong>: Avoid repeated full copies after initial seeding (where supported).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Migrate to Virtual Machines when:\n&#8211; You want <strong>Compute Engine<\/strong> as the target platform.\n&#8211; You have many VMs and need a <strong>repeatable, operator-friendly<\/strong> migration workflow.\n&#8211; You need a <strong>test-before-cutover<\/strong> process.\n&#8211; You have (or can set up) <strong>hybrid connectivity<\/strong> (VPN\/Interconnect) and can deploy connectors.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:\n&#8211; You\u2019re migrating <strong>apps<\/strong> rather than VMs and can modernize directly (containers\/serverless).\n&#8211; You need <strong>application-level<\/strong> migration (databases, messaging, identity) rather than machine lift-and-shift.\n&#8211; Your source platform\/OS pattern is <strong>not supported<\/strong> or has constraints that make migration unreliable.<br\/>\n&#8211; Your organization requires a <strong>third-party DR-style replication<\/strong> product or more advanced orchestration than this service provides.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Migrate to Virtual Machines 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 (with strict change control and test requirements)<\/li>\n<li>Healthcare (regulated workloads migrating in phases)<\/li>\n<li>Retail and e-commerce (seasonal capacity planning, data center exit)<\/li>\n<li>Manufacturing (legacy workloads, plant systems)<\/li>\n<li>SaaS and tech (hybrid environments, consolidation)<\/li>\n<li>Government\/public sector (phased modernization)<\/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>Cloud platform teams standardizing landing zones<\/li>\n<li>Infrastructure\/virtualization teams moving from vSphere to cloud<\/li>\n<li>SRE\/operations teams owning cutover and rollback processes<\/li>\n<li>Security teams validating network segmentation and IAM controls<\/li>\n<li>App owners performing functional testing after test clone<\/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>Traditional 3-tier apps on Windows\/Linux VMs<\/li>\n<li>Line-of-business apps tied to VM images<\/li>\n<li>Legacy apps that can\u2019t easily be containerized<\/li>\n<li>Batch processing servers, schedulers, and internal tools<\/li>\n<li>Build agents and CI executors (when VM-based is required)<\/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: on-prem VMware with Cloud VPN\/Interconnect to Google Cloud<\/li>\n<li>Multi-region target designs: regional disks, multi-zone MIGs (after migration)<\/li>\n<li>Shared VPC enterprise landing zones<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Data center exit (bulk migration waves)<\/li>\n<li>Hardware refresh avoidance<\/li>\n<li>Merger\/acquisition consolidation<\/li>\n<li>Disaster recovery posture improvement (migrate then redesign)<\/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>: Validate the migration process, OS compatibility, and automation.<\/li>\n<li><strong>Production<\/strong>: Use change windows, runbooks, and test clones for sign-off; apply strict IAM and audit controls.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic ways teams use <strong>Migrate to Virtual Machines<\/strong> in Google Cloud Migration projects.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Data center exit for VMware workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A data center lease is ending; hundreds of VMware VMs must move quickly.<\/li>\n<li><strong>Why this service fits<\/strong>: Connector-based discovery and standardized replication\/cutover workflow.<\/li>\n<li><strong>Example<\/strong>: Migrate 200 internal Windows\/Linux servers to Compute Engine in waves aligned to business units.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) \u201cLift now, modernize later\u201d strategy<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: App teams can\u2019t refactor now but want to leave on-prem infrastructure.<\/li>\n<li><strong>Why this service fits<\/strong>: Moves VMs first; modernization can happen after.<\/li>\n<li><strong>Example<\/strong>: Lift an ERP app stack to Compute Engine, then gradually introduce managed databases and load balancing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Migration with strict testing gates<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Production change approval requires evidence of testing.<\/li>\n<li><strong>Why this service fits<\/strong>: Test clones allow validation before cutover.<\/li>\n<li><strong>Example<\/strong>: Run regression tests on a test clone in a quarantined subnet, then schedule cutover.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Bulk migration factory pattern<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Manual per-VM migrations don\u2019t scale.<\/li>\n<li><strong>Why this service fits<\/strong>: Consistent workflow, role separation, and repeatable steps.<\/li>\n<li><strong>Example<\/strong>: Platform team builds a runbook for connector deploy + migration creation + test + cutover.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Hybrid connectivity constrained migrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Bandwidth is limited; you need incremental replication and careful scheduling.<\/li>\n<li><strong>Why this service fits<\/strong>: Replication approach can reduce repeated full transfers (capabilities vary).<\/li>\n<li><strong>Example<\/strong>: Replicate continuously for a week over VPN, then cut over during a weekend.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Migration to a standardized Google Cloud landing zone<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security requires all workloads be attached to Shared VPC subnets with specific firewall policies.<\/li>\n<li><strong>Why this service fits<\/strong>: Target VM settings can align with landing zone standards.<\/li>\n<li><strong>Example<\/strong>: Migrate workloads into a \u201cprod\u201d VPC with centralized firewall rules and logging enabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Moving legacy Windows servers that must remain VM-based<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: App requires Windows Server with specific drivers or installers.<\/li>\n<li><strong>Why this service fits<\/strong>: VM migration keeps OS\/app intact; OS adaptation may help with cloud boot requirements.<\/li>\n<li><strong>Example<\/strong>: Migrate a licensing server and a legacy .NET app server to Compute Engine.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Migration wave with rollback safety<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Business demands the ability to roll back if validation fails.<\/li>\n<li><strong>Why this service fits<\/strong>: Test clones and staged cutover reduce risk; rollback plan can keep source VM intact until finalization.<\/li>\n<li><strong>Example<\/strong>: Cut over 10 VMs; keep source powered off but not deleted until a 48-hour validation window passes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Consolidating environments after M&amp;A<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Two VMware estates must be consolidated into one cloud platform.<\/li>\n<li><strong>Why this service fits<\/strong>: Repeatable migrations into a shared Google Cloud organization structure.<\/li>\n<li><strong>Example<\/strong>: Create separate projects per business unit; migrate VMs and apply org policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Migrating workloads to prepare for managed services adoption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: App runs on VMs but you plan to move database to Cloud SQL later.<\/li>\n<li><strong>Why this service fits<\/strong>: Keep compute stable while changing dependencies gradually.<\/li>\n<li><strong>Example<\/strong>: Lift app VMs first, then migrate database with Database Migration Service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Refreshing OS\/agent baselines post-migration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: On-prem VMs have inconsistent agent versions and patching.<\/li>\n<li><strong>Why this service fits<\/strong>: Migration is a forcing function to standardize monitoring\/OS configuration after cutover.<\/li>\n<li><strong>Example<\/strong>: After migration, install Ops Agent, apply CIS hardening, and enroll in OS patch management.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) \u201cOne subnet per environment\u201d segmentation migrations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Must isolate migrated test clones from production systems.<\/li>\n<li><strong>Why this service fits<\/strong>: You can place test clones into a restricted subnet with no outbound internet.<\/li>\n<li><strong>Example<\/strong>: Test clone boots in <code>test-migrations-subnet<\/code> with firewall rules denying all except bastion access.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Feature availability can depend on the source platform (for example, VMware vs other sources), OS type, and connector version. Always verify specifics in the official docs for your scenario.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Source registration and VM discovery<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Registers a source environment and discovers VMs and metadata.<\/li>\n<li><strong>Why it matters<\/strong>: Accurate inventory reduces missed dependencies.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster planning and less manual inventory work.<\/li>\n<li><strong>Caveats<\/strong>: Discovery requires network reachability and source-side permissions; firewall\/proxy constraints can block it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Connector-based architecture<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses a deployed connector\/appliance to securely communicate between source and Google Cloud.<\/li>\n<li><strong>Why it matters<\/strong>: Keeps source credentials and connectivity controlled.<\/li>\n<li><strong>Practical benefit<\/strong>: Works in hybrid networks where direct inbound access is restricted.<\/li>\n<li><strong>Caveats<\/strong>: Connector availability becomes operationally important; plan redundancy\/monitoring per docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Replication (initial + incremental)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Copies VM disk data to Google Cloud and then replicates changes.<\/li>\n<li><strong>Why it matters<\/strong>: Reduces downtime by avoiding a single \u201cbig bang\u201d copy at cutover time.<\/li>\n<li><strong>Practical benefit<\/strong>: Cutovers become mostly \u201cfinal sync + boot in cloud.\u201d<\/li>\n<li><strong>Caveats<\/strong>: Network throughput, latency, and packet loss strongly affect replication time.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Test clone \/ test cutover<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Creates a test VM in Compute Engine based on replicated data.<\/li>\n<li><strong>Why it matters<\/strong>: Validates bootability, performance, and app function before production cutover.<\/li>\n<li><strong>Practical benefit<\/strong>: Catch driver, DNS, licensing, and firewall issues early.<\/li>\n<li><strong>Caveats<\/strong>: Testing in isolation may not reflect all production dependencies unless networks are staged accordingly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Cutover orchestration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Coordinates final replication and creates the final target VM.<\/li>\n<li><strong>Why it matters<\/strong>: Standardizes a risky step.<\/li>\n<li><strong>Practical benefit<\/strong>: Repeatable runbook: stop source (if required), final sync, start target.<\/li>\n<li><strong>Caveats<\/strong>: Downtime still exists; application consistency depends on app-level quiescing strategy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Target VM configuration mapping<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you define Compute Engine properties (zone, machine type, network\/subnet, disk type, labels).<\/li>\n<li><strong>Why it matters<\/strong>: Ensures migrated VMs align with landing zone standards.<\/li>\n<li><strong>Practical benefit<\/strong>: Fewer post-migration changes and compliance drift.<\/li>\n<li><strong>Caveats<\/strong>: Some source hardware profiles won\u2019t map 1:1; you must choose equivalent machine types.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) OS adaptation (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Helps adjust boot drivers\/agents\/settings for Compute Engine.<\/li>\n<li><strong>Why it matters<\/strong>: Boot failures are a common migration blocker.<\/li>\n<li><strong>Practical benefit<\/strong>: More reliable first boot in Google Cloud.<\/li>\n<li><strong>Caveats<\/strong>: OS adaptation support varies by OS version and source details; verify for your OS. Some corner cases still require manual remediation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) IAM roles and audit visibility<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Cloud IAM for access control; operations can be logged via Cloud Audit Logs.<\/li>\n<li><strong>Why it matters<\/strong>: Migration actions are sensitive (they create VMs and copy data).<\/li>\n<li><strong>Practical benefit<\/strong>: Enforce least privilege, separation of duties, and compliance reporting.<\/li>\n<li><strong>Caveats<\/strong>: Misconfigured IAM can block migrations or unintentionally allow broad access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Integration with core Google Cloud ops tooling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works alongside Cloud Logging\/Monitoring and Compute Engine operations.<\/li>\n<li><strong>Why it matters<\/strong>: Operations teams need visibility and alerts.<\/li>\n<li><strong>Practical benefit<\/strong>: Standardize logs, metrics, and incident response.<\/li>\n<li><strong>Caveats<\/strong>: Monitoring coverage depends on how you instrument connector and target VMs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\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<ol class=\"wp-block-list\">\n<li>You configure a <strong>Source<\/strong> in Google Cloud and deploy a <strong>Connector<\/strong> in the source environment.<\/li>\n<li>The connector authenticates to Google Cloud and connects to the source system (for example, vCenter).<\/li>\n<li>The service discovers VMs and lets you define a <strong>Migration<\/strong> per VM.<\/li>\n<li>Replication copies disks to Google Cloud (initial sync) and then continuously replicates changes (incremental).<\/li>\n<li>You create <strong>Test clones<\/strong> for validation.<\/li>\n<li>You schedule <strong>Cutover<\/strong>, perform final sync, and boot the final Compute Engine VM.<\/li>\n<\/ol>\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>: Migration definitions, operations (start replication, test, cutover), IAM authorization.<\/li>\n<li><strong>Data plane<\/strong>: VM disk data replicated from source to Google Cloud over your hybrid connectivity.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine<\/strong>: Destination VM instances, persistent disks, images\/snapshots (implementation-dependent).<\/li>\n<li><strong>VPC<\/strong>: Target subnet and firewall rules; routing from on-prem to cloud for testing\/cutover.<\/li>\n<li><strong>Cloud VPN \/ Cloud Interconnect<\/strong>: Commonly used for replication traffic.<\/li>\n<li><strong>Cloud Logging \/ Cloud Monitoring<\/strong>: Operational visibility and auditability.<\/li>\n<li><strong>Cloud KMS<\/strong>: CMEK for disk encryption, if required by policy.<\/li>\n<li><strong>Cloud DNS<\/strong> (optional): Cutover DNS changes for applications.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A migration project typically relies on:<\/li>\n<li>Compute Engine API<\/li>\n<li>The Migrate to Virtual Machines API\/service (service name can appear as a dedicated API in Google Cloud)<\/li>\n<li>IAM, Cloud Logging, and networking services<\/li>\n<li>Source platform APIs (for VMware, vCenter\/ESXi endpoints)<\/li>\n<\/ul>\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 access<\/strong>: Controlled with IAM roles on the project (and possibly on the migration resource).<\/li>\n<li><strong>Connector authentication<\/strong>: Connector registers with Google Cloud and uses an identity to call the migration service. The exact registration mechanism can change\u2014follow the current connector registration steps in official docs.<\/li>\n<li><strong>Source credentials<\/strong>: Stored\/used by connector to talk to the source platform; manage these carefully (least privilege, rotation).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Connector needs:<\/li>\n<li>Reachability to the source management endpoints (e.g., vCenter).<\/li>\n<li>Outbound connectivity to Google Cloud endpoints for the migration service and for data transfer.<\/li>\n<li>Data replication uses:<\/li>\n<li>Your hybrid network link (VPN\/Interconnect) or other supported connectivity.<\/li>\n<li>Firewall and routing must permit required ports. <strong>Verify required ports in official docs<\/strong> because they differ by source type and connector version.<\/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>Enable <strong>Cloud Audit Logs<\/strong> and review:<\/li>\n<li>Who created migrations<\/li>\n<li>Who executed test and cutover<\/li>\n<li>Who created\/destroyed target resources<\/li>\n<li>Use Cloud Monitoring for:<\/li>\n<li>Connector VM health (CPU, memory, disk, network)<\/li>\n<li>VPN\/Interconnect throughput and error rates<\/li>\n<li>Target Compute Engine VM health post-cutover<\/li>\n<li>Use governance:<\/li>\n<li>Resource hierarchy (Org\/Folder\/Project)<\/li>\n<li>Labels\/tags for chargeback and inventory (<code>env<\/code>, <code>app<\/code>, <code>cost-center<\/code>, <code>migration-wave<\/code>)<\/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  subgraph OnPrem[On-prem \/ Source Environment]\n    VC[vCenter \/ Source API]\n    SRCVM[Source VM(s)]\n    CONN[Migrate to Virtual Machines Connector]\n    VC --- CONN\n    SRCVM --- CONN\n  end\n\n  subgraph GCP[Google Cloud Project]\n    M2VM[Migrate to Virtual Machines Service]\n    CE[Compute Engine (Target VM)]\n    VPC[VPC Subnet + Firewall]\n    LOG[Cloud Logging \/ Audit Logs]\n  end\n\n  CONN --&gt;|Control| M2VM\n  CONN --&gt;|Replication data| GCP\n  M2VM --&gt; CE\n  CE --&gt; VPC\n  M2VM --&gt; LOG\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 SourceDC[Source Data Center]\n    subgraph VMware[VMware Cluster]\n      vCenter[vCenter]\n      esxi[ESXi Hosts]\n      vmA[VM: app-01]\n      vmB[VM: db-01]\n    end\n    conn1[Connector VM]\n    conn2[Connector VM (optional\/HA pattern per docs)]\n    vCenter --- conn1\n    vCenter --- conn2\n    vmA --- esxi\n    vmB --- esxi\n  end\n\n  subgraph Network[Hybrid Connectivity]\n    vpn[Cloud VPN or Interconnect]\n    fw[Firewall \/ Routes]\n  end\n\n  subgraph GCPProject[Google Cloud Project]\n    m2vm[Migrate to Virtual Machines]\n    subgraph LandingZone[Landing Zone VPC]\n      subnetTest[Test Subnet]\n      subnetProd[Prod Subnet]\n      bastion[Bastion \/ IAP access (optional)]\n    end\n    ceTest[Test Clone VM]\n    ceProd[Cutover VM]\n    kms[Cloud KMS (CMEK optional)]\n    logs[Cloud Logging + Audit Logs]\n    mon[Cloud Monitoring]\n  end\n\n  conn1 --&gt; vpn\n  conn2 --&gt; vpn\n  vpn --&gt; fw\n  fw --&gt; m2vm\n\n  m2vm --&gt; ceTest\n  m2vm --&gt; ceProd\n  ceTest --&gt; subnetTest\n  ceProd --&gt; subnetProd\n  ceProd --&gt; kms\n  m2vm --&gt; logs\n  ceProd --&gt; mon\n  conn1 --&gt; mon\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Google Cloud account\/project requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>Google Cloud project<\/strong> with <strong>billing enabled<\/strong><\/li>\n<li>Organization policies reviewed (some org policies can block external IPs, service account key creation, etc.)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You typically need permissions to:\n&#8211; Enable APIs\n&#8211; Create and manage migration resources\n&#8211; Create and manage Compute Engine instances, disks, networks as required by the migration workflow<\/p>\n\n\n\n<p>Look for predefined roles related to the migration service (for example, roles in the <code>vmmigration<\/code> family) and Compute Engine roles. Exact role names can change\u2014<strong>verify in official IAM docs<\/strong>:\n&#8211; A migration admin\/operator role (for managing sources, connectors, migrations)\n&#8211; Compute Engine admin permissions (or a least-privilege custom role)\n&#8211; Service Account User where needed for attaching service accounts to VMs<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Billing must be enabled.<\/li>\n<li>Even if the migration service itself has no separate fee (often the case), you will incur costs for:<\/li>\n<li>Replication staging resources<\/li>\n<li>Target VM compute<\/li>\n<li>Persistent disks<\/li>\n<li>Network egress\/ingress where applicable<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">CLI\/SDK\/tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud Console<\/strong> (most migration workflows are console-driven)<\/li>\n<li><strong>gcloud CLI<\/strong> (recommended for project setup, IAM, and cleanup)<\/li>\n<li>Install: https:\/\/cloud.google.com\/sdk\/docs\/install<\/li>\n<li>Access to your source environment tooling:<\/li>\n<li>VMware vSphere client \/ vCenter access, if migrating from VMware<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Availability depends on Google Cloud location support for this service. Choose a region close to your source to reduce latency and replication time.<\/li>\n<li><strong>Verify supported locations in the official docs<\/strong>.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Expect quotas around:\n&#8211; Compute Engine instances, CPUs, persistent disk total GB\n&#8211; API request quotas\n&#8211; Possibly migration-specific quotas (sources\/connectors\/migrations)\nAlways review quotas before large waves:\n&#8211; https:\/\/cloud.google.com\/compute\/quotas<br\/>\n&#8211; Migration service quotas: <strong>verify in official Migrate to Virtual Machines docs<\/strong><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine API enabled<\/li>\n<li>The Migrate to Virtual Machines API\/service enabled (exact API name: verify in the console API Library)<\/li>\n<li>Cloud Logging (enabled by default)<\/li>\n<li>Cloud Monitoring (recommended)<\/li>\n<li>Cloud VPN or Cloud Interconnect if migrating from on-prem over private connectivity<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (how costs are charged)<\/h3>\n\n\n\n<p>Pricing for Migrate to Virtual Machines can change over time and may have special terms. In many cloud migration services, the orchestration layer is not billed directly and you pay for underlying resources. <strong>Verify current pricing on the official pricing page<\/strong>:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing entry point: https:\/\/cloud.google.com\/migrate\/virtual-machines\/pricing (verify URL in case it changes)<\/li>\n<li>Google Cloud Pricing Calculator: https:\/\/cloud.google.com\/products\/calculator<\/li>\n<\/ul>\n\n\n\n<p>When estimating, break costs into two buckets:<\/p>\n\n\n\n<p>1) <strong>Migration-time costs (temporary)<\/strong>\n&#8211; Replication\/staging resources created in Google Cloud (compute, disks, snapshots, storage)\n&#8211; Network costs for moving data (especially if traffic crosses the public internet or leaves a region)<\/p>\n\n\n\n<p>2) <strong>Run-time costs (after cutover)<\/strong>\n&#8211; Compute Engine VM (vCPU\/RAM)\n&#8211; Persistent disk (SSD\/HDD, provisioned size)\n&#8211; Backups\/snapshots\n&#8211; Load balancers, NAT, logging\/monitoring volume<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions to consider<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Compute Engine machine type<\/strong> for test clones and final cutover VMs<\/li>\n<li><strong>Persistent disk type and size<\/strong> (pd-balanced, pd-ssd, pd-standard, hyperdisk variants depending on region)<\/li>\n<li><strong>Snapshot and image storage<\/strong><\/li>\n<li><strong>Network data transfer<\/strong><\/li>\n<li>Ingress to Google Cloud is often priced differently than egress\u2014verify for your path.<\/li>\n<li>Cross-region replication\/test can add inter-region egress<\/li>\n<li><strong>VPN\/Interconnect costs<\/strong><\/li>\n<li>Cloud VPN tunnel charges and egress, or Interconnect port and VLAN attachment charges<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine has limited free tier offerings in specific regions and machine types, but migrations rarely fit cleanly into free tier due to disk sizes and replication traffic. Treat free tier as a bonus, not a plan.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Key cost drivers (what makes bills jump)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Large disks<\/strong> (10+ TB per VM) and long replication windows<\/li>\n<li><strong>Keeping staging resources running<\/strong> after cutover<\/li>\n<li><strong>Repeated test clones<\/strong> without cleaning up test VMs\/disks<\/li>\n<li><strong>Overprovisioning machine types<\/strong> vs right-sizing post-migration<\/li>\n<li><strong>Network egress<\/strong> if your migration path exits Google Cloud or uses cross-region design unnecessarily<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden\/indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Logging volume<\/strong> (verbose logs from agents\/connectors)<\/li>\n<li><strong>Snapshots<\/strong> retained longer than intended<\/li>\n<li><strong>Reserved IPs<\/strong>, load balancers, and NAT gateways created during cutover<\/li>\n<li><strong>Operational overhead<\/strong> (people time) if migrations are not standardized<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If migrating from on-prem:<\/li>\n<li>Cloud VPN\/Interconnect traffic to Google Cloud typically incurs network charges depending on the product and path.<\/li>\n<li>If you use the public internet, consider egress charges from your ISP and potential performance issues.<\/li>\n<li>If migrating across regions:<\/li>\n<li>Inter-region egress inside Google Cloud can be a major cost driver.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Run <strong>test clones<\/strong> with small machine types when functional testing permits.<\/li>\n<li>Use a <strong>dedicated test subnet<\/strong> and restrict connectivity to avoid accidental production usage.<\/li>\n<li><strong>Delete test VMs and disks<\/strong> promptly after validation.<\/li>\n<li><strong>Finalize migrations<\/strong> and clean staging resources immediately after successful cutover.<\/li>\n<li>Right-size the target VM after performance baseline.<\/li>\n<li>Prefer private connectivity (Interconnect) for large migrations\u2014often better performance and predictable cost model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>A low-cost proof-of-concept often includes:\n&#8211; 1 small source VM (e.g., 40\u2013100 GB disk)\n&#8211; A small test clone VM running for a few hours\n&#8211; Minimal snapshots retained\n&#8211; VPN connectivity you already have<\/p>\n\n\n\n<p>You\u2019d estimate:\n&#8211; Persistent disk GB-month prorated for the test period\n&#8211; Compute Engine VM hours for test and cutover VMs\n&#8211; VPN\/egress as applicable<\/p>\n\n\n\n<p>Because exact numbers vary by region and machine type, use the calculator and plug in your:\n&#8211; VM size (vCPU\/RAM)\n&#8211; Disk size and type\n&#8211; Expected test duration and replication duration\n&#8211; Network throughput and hours<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production waves (50\u2013500 VMs):\n&#8211; Budget for <strong>parallel replication<\/strong> resource usage (temporary) plus a ramp-up of permanent compute costs.\n&#8211; Expect peak costs during migration windows because you temporarily pay for both:\n  &#8211; On-prem (existing contracts)\n  &#8211; Cloud staging + target run-rate<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\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>realistic<\/strong> small migration flow: migrate a single VMware VM to Compute Engine using <strong>Migrate to Virtual Machines<\/strong> with a test clone and a cutover. The steps focus on correctness and operational safety.<\/p>\n\n\n\n<blockquote>\n<p>If you don\u2019t have VMware available, you can still follow the Google Cloud project setup, IAM, networking, and service enabling portions. For the connector deployment and discovery steps, you need a supported source environment.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Set up Migrate to Virtual Machines in a Google Cloud project<\/li>\n<li>Register a VMware source using a connector<\/li>\n<li>Discover a VM<\/li>\n<li>Start replication<\/li>\n<li>Create a test clone and validate boot<\/li>\n<li>Execute cutover<\/li>\n<li>Clean up resources to avoid ongoing charges<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Prepare a Google Cloud project (APIs, IAM, networking).\n2. Ensure hybrid connectivity (VPN\/Interconnect) and firewall paths.\n3. Create a migration source and deploy the connector in VMware.\n4. Create and run a migration (replicate \u2192 test clone \u2192 cutover).\n5. Validate and troubleshoot.\n6. Clean up.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create\/select a Google Cloud project and enable billing<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>In the Google Cloud Console, select or create a project:\n   &#8211; https:\/\/console.cloud.google.com\/projectselector2\/home\/dashboard<\/p>\n<\/li>\n<li>\n<p>Ensure billing is linked:\n   &#8211; https:\/\/console.cloud.google.com\/billing<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have a project with billing enabled.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the Console, open <strong>Billing<\/strong> and confirm the project shows an active billing account.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Install and initialize the Google Cloud CLI (recommended)<\/h3>\n\n\n\n<p>On your workstation:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud init\ngcloud auth login\ngcloud config set project YOUR_PROJECT_ID\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: <code>gcloud<\/code> is authenticated and points to your project.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud config list project\ngcloud projects describe YOUR_PROJECT_ID --format=\"value(projectNumber)\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Enable required APIs<\/h3>\n\n\n\n<p>Enable Compute Engine and the migration API (the exact API name may appear as <strong>VM Migration<\/strong> \/ <strong>vmmigration<\/strong> in the API Library\u2014confirm in your project).<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable compute.googleapis.com\ngcloud services enable logging.googleapis.com\ngcloud services enable monitoring.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>Now enable the Migrate to Virtual Machines API (name can vary). Try:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services enable vmmigration.googleapis.com\n<\/code><\/pre>\n\n\n\n<p>If that fails, open the API Library in the Console and search for:\n&#8211; \u201cMigrate to Virtual Machines\u201d\n&#8211; \u201cVM Migration\u201d\n&#8211; \u201cvmmigration\u201d<\/p>\n\n\n\n<p>API Library:\n&#8211; https:\/\/console.cloud.google.com\/apis\/library<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: APIs are enabled.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud services list --enabled | egrep 'compute|logging|monitoring|vmmigration'\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Prepare IAM (minimum roles for the lab)<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Configure migration sources\/connectors\/migrations\n&#8211; Create Compute Engine instances and disks<\/p>\n\n\n\n<p>For a lab, you can assign broader roles to a dedicated admin user. For production, prefer least privilege and\/or custom roles.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Identify your principal:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">gcloud auth list\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"2\">\n<li>Assign roles (role names may vary; verify official IAM role list for the service). If you have an admin-only lab project, you can temporarily grant <code>Editor<\/code>, but it\u2019s not recommended for production.<\/li>\n<\/ol>\n\n\n\n<p>Example (broad for lab only):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \\\n  --member=\"user:YOUR_EMAIL\" \\\n  --role=\"roles\/editor\"\n<\/code><\/pre>\n\n\n\n<p>If you want to be more precise, look for roles like:\n&#8211; <code>roles\/compute.admin<\/code>\n&#8211; <code>roles\/iam.serviceAccountUser<\/code>\n&#8211; Migration roles such as <code>roles\/vmmigration.admin<\/code> (verify exact name)<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: You can open Migrate to Virtual Machines and create resources.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the Console, open the migration UI and confirm you can create a Source.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Prepare target networking in Google Cloud (VPC, subnet, firewall)<\/h3>\n\n\n\n<p>You need:\n&#8211; A VPC\/subnet where test clones and cutover VMs will land\n&#8211; Firewall rules allowing admin access (SSH\/RDP) from a safe source (bastion, IAP, or your corporate IP range)<\/p>\n\n\n\n<p>For a lab, create a dedicated VPC and subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks create mig-lab-vpc --subnet-mode=custom\n\ngcloud compute networks subnets create mig-lab-subnet \\\n  --network=mig-lab-vpc \\\n  --region=us-central1 \\\n  --range=10.10.0.0\/24\n<\/code><\/pre>\n\n\n\n<p>Create a restricted SSH rule (replace <code>YOUR_PUBLIC_IP\/32<\/code>):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create mig-lab-allow-ssh \\\n  --network=mig-lab-vpc \\\n  --allow=tcp:22 \\\n  --source-ranges=YOUR_PUBLIC_IP\/32 \\\n  --target-tags=mig-lab\n<\/code><\/pre>\n\n\n\n<p>If you need RDP for Windows:<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute firewall-rules create mig-lab-allow-rdp \\\n  --network=mig-lab-vpc \\\n  --allow=tcp:3389 \\\n  --source-ranges=YOUR_PUBLIC_IP\/32 \\\n  --target-tags=mig-lab\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: A subnet exists for migrated instances; firewall rules are ready.<\/p>\n\n\n\n<p><strong>Verification<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute networks subnets list --filter=\"name:mig-lab-subnet\"\ngcloud compute firewall-rules list --filter=\"name~mig-lab\"\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Ensure hybrid connectivity from source to Google Cloud<\/h3>\n\n\n\n<p>If your source is on-prem VMware, you typically need <strong>Cloud VPN<\/strong> or <strong>Cloud Interconnect<\/strong> so the connector and replication traffic can reach Google Cloud reliably.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud VPN overview: https:\/\/cloud.google.com\/network-connectivity\/docs\/vpn\/concepts\/overview<\/li>\n<li>Cloud Interconnect overview: https:\/\/cloud.google.com\/network-connectivity\/docs\/interconnect\/concepts\/overview<\/li>\n<\/ul>\n\n\n\n<p><strong>Expected outcome<\/strong>: The source environment can reach Google Cloud endpoints required by the connector and replication flow.<\/p>\n\n\n\n<p><strong>Verification ideas<\/strong>\n&#8211; From the connector VM (once deployed), confirm it can resolve DNS and reach required Google endpoints (exact endpoints\/ports: verify in official docs).\n&#8211; Monitor VPN tunnel status if using Cloud VPN.<\/p>\n\n\n\n<blockquote>\n<p>If your organization requires private-only egress, review Private Google Access \/ Private Service Connect options and validate compatibility with the connector. <strong>Verify in official docs<\/strong> for connector networking requirements.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Open Migrate to Virtual Machines in the Console and select a location<\/h3>\n\n\n\n<p>In the Console:\n1. Navigate to <strong>Migrate to Virtual Machines<\/strong>:\n   &#8211; https:\/\/console.cloud.google.com\/migrate\/virtual-machines\n2. Choose the project.\n3. Select the <strong>location\/region<\/strong> where you will manage migrations (the UI usually prompts you).<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Migration service UI is accessible and ready.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; You can see options to create a <strong>Source<\/strong> and manage connectors\/migrations.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a VMware source<\/h3>\n\n\n\n<p>In the Migrate to Virtual Machines UI:\n1. Click <strong>Sources<\/strong> \u2192 <strong>Create source<\/strong>\n2. Choose <strong>VMware<\/strong> (or the source type you use)\n3. Provide:\n   &#8211; Source name (e.g., <code>vmware-dc1<\/code>)\n   &#8211; vCenter endpoint details (per UI)\n   &#8211; Credentials with least privilege (per Google\u2019s requirements)\n4. Save the source.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: A source definition exists.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; The source appears in the sources list (it may show \u201cwaiting for connector\u201d until you deploy\/register it).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Deploy and register the Migrate to Virtual Machines Connector in VMware<\/h3>\n\n\n\n<p>This step is often the most sensitive because it involves:\n&#8211; OVA\/OVF deployment into VMware\n&#8211; Network settings (IP, DNS, gateway)\n&#8211; Registration with your Google Cloud project\/source<\/p>\n\n\n\n<p>In the Migrate to Virtual Machines UI:\n1. Go to the source and choose <strong>Add connector<\/strong> \/ <strong>Download connector<\/strong>.\n2. Download the connector OVA\/OVF and note any registration code\/token instructions.\n3. In VMware vSphere:\n   &#8211; Deploy OVF Template\n   &#8211; Place it on a network that can reach:\n     &#8211; vCenter (management)\n     &#8211; Google Cloud (outbound to required endpoints)\n4. Power on the connector VM and complete registration using the connector UI\/console instructions.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: The connector shows as <strong>Connected\/Active<\/strong> in Google Cloud.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; In the migration UI, the connector status is healthy and the source moves toward a \u201cready\u201d state.\n&#8211; Discovery begins or can be triggered.<\/p>\n\n\n\n<p><strong>Common issues<\/strong>\n&#8211; Wrong DNS\/gateway \u2192 connector can\u2019t reach Google\n&#8211; Firewall blocks outbound TLS \u2192 connector can\u2019t register\n&#8211; vCenter credentials lack permissions \u2192 discovery fails<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Discover VMs and select a candidate VM for migration<\/h3>\n\n\n\n<p>In the UI:\n1. Open the source.\n2. Confirm discovered VMs appear.\n3. Choose a small non-critical VM for the first run:\n   &#8211; Prefer a VM with a single disk and simple networking\n   &#8211; Avoid domain controllers and latency-sensitive databases for the first test<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: You can see the VM details and choose it for migration.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; VM metadata (name, OS, disk sizes) is visible.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Create a migration for the selected VM<\/h3>\n\n\n\n<p>In the UI:\n1. Click <strong>Create migration<\/strong>\n2. Select the source VM\n3. Configure target settings:\n   &#8211; Target region\/zone (close to your users and data)\n   &#8211; VPC\/subnet: <code>mig-lab-vpc<\/code> \/ <code>mig-lab-subnet<\/code>\n   &#8211; Machine type: choose something small for testing\n   &#8211; Disk type: choose balanced or standard for cost (performance needs vary)\n   &#8211; Labels: <code>env=test<\/code>, <code>migration=lab<\/code>\n   &#8211; Network tags: <code>mig-lab<\/code> (to match your firewall rules)\n4. Save the migration.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: A migration object is created.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; The migration shows in the migrations list with status like \u201cNot started\u201d or similar.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 12: Start replication<\/h3>\n\n\n\n<p>In the migration details:\n1. Click <strong>Start replication<\/strong> (or equivalent)\n2. Monitor progress<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Replication begins and eventually reaches a ready state for testing.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Replication status shows progress\n&#8211; You may see staging resources created in the project (names vary)<\/p>\n\n\n\n<blockquote>\n<p>Replication time depends on disk size and available bandwidth. A 100 GB VM can still take significant time if bandwidth is limited.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 13: Create a test clone and validate boot<\/h3>\n\n\n\n<p>Once replication is sufficiently complete (UI often indicates readiness):\n1. Click <strong>Test clone<\/strong> (or <strong>Test<\/strong>)<br\/>\n2. Choose test settings:\n   &#8211; Place it in <code>mig-lab-subnet<\/code>\n   &#8211; Optionally use a dedicated test subnet with restricted routes\n3. Create the test clone<\/p>\n\n\n\n<p>After the test VM is created:\n&#8211; For Linux: SSH into the instance\n&#8211; For Windows: RDP (if enabled and allowed)<\/p>\n\n\n\n<p>Example SSH (if external IP exists and SSH is allowed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">gcloud compute ssh TEST_VM_NAME \\\n  --zone=us-central1-a\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: The test clone boots successfully in Compute Engine.<\/p>\n\n\n\n<p><strong>Verification checklist<\/strong>\n&#8211; VM status is <strong>RUNNING<\/strong>\n&#8211; You can log in\n&#8211; Check OS logs:\n  &#8211; Linux: <code>dmesg<\/code>, <code>\/var\/log\/syslog<\/code> or <code>\/var\/log\/messages<\/code>\n  &#8211; Windows: Event Viewer system log\n&#8211; Validate basic app function (service starts, local ports listening)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 14: Plan and execute cutover<\/h3>\n\n\n\n<p>Cutover is a change event. Before proceeding:\n&#8211; Confirm maintenance window\n&#8211; Confirm DNS and IP plan\n&#8211; Confirm rollback plan<\/p>\n\n\n\n<p>In the UI:\n1. Click <strong>Cutover<\/strong>\n2. Follow prompts (may include final sync and source VM state changes)\n3. Wait for cutover completion\n4. Confirm the final Compute Engine VM is created and running in the intended subnet\/zone<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: The production target VM is running in Compute Engine.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; VM exists in Compute Engine instances list:\n  &#8211; https:\/\/console.cloud.google.com\/compute\/instances\n&#8211; Validate app function\n&#8211; Confirm monitoring\/agent installation as required<\/p>\n\n\n\n<blockquote>\n<p>Do not immediately delete or decommission the source VM until your validation period ends and stakeholders sign off.<\/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 after cutover:<\/p>\n\n\n\n<p><strong>Compute \/ boot<\/strong>\n&#8211; VM is running\n&#8211; Serial console shows no boot errors (use Compute Engine serial port logs if needed)<\/p>\n\n\n\n<p><strong>Network<\/strong>\n&#8211; Correct subnet and firewall tags applied\n&#8211; Internal IP is as expected\n&#8211; Outbound internet access behaves as intended (NAT vs no NAT)<\/p>\n\n\n\n<p><strong>OS and agents<\/strong>\n&#8211; Linux: confirm Google guest environment\/agents as required by your org (varies by distro and image)\n&#8211; Windows: confirm drivers and network adapters are correct<\/p>\n\n\n\n<p><strong>Application<\/strong>\n&#8211; Services are running\n&#8211; App endpoints are reachable\n&#8211; Background jobs and scheduled tasks work<\/p>\n\n\n\n<p><strong>Security<\/strong>\n&#8211; No unexpected external IPs\n&#8211; IAM access is least privilege\n&#8211; OS firewall rules are correct<\/p>\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 problems and realistic fixes:<\/p>\n\n\n\n<p>1) <strong>Connector can\u2019t register \/ shows offline<\/strong>\n&#8211; <strong>Cause<\/strong>: DNS, proxy, or firewall blocks outbound TLS to Google.\n&#8211; <strong>Fix<\/strong>: Validate outbound connectivity; verify required domains\/ports in official docs; confirm NTP time sync.<\/p>\n\n\n\n<p>2) <strong>VM discovery shows zero VMs<\/strong>\n&#8211; <strong>Cause<\/strong>: vCenter permissions insufficient; wrong vCenter endpoint; connector can\u2019t reach vCenter.\n&#8211; <strong>Fix<\/strong>: Verify connector-to-vCenter connectivity; use least-privilege role recommended by Google; confirm credentials.<\/p>\n\n\n\n<p>3) <strong>Replication is very slow<\/strong>\n&#8211; <strong>Cause<\/strong>: Bandwidth limits, packet loss, VPN throughput caps, busy source storage.\n&#8211; <strong>Fix<\/strong>: Increase bandwidth, prefer Interconnect for large waves, schedule replication off-peak, verify MTU settings on VPN.<\/p>\n\n\n\n<p>4) <strong>Test clone boots but has no network<\/strong>\n&#8211; <strong>Cause<\/strong>: NIC\/driver mismatch, OS adaptation incomplete, incorrect subnet\/firewall, missing routes.\n&#8211; <strong>Fix<\/strong>: Verify OS driver support; confirm firewall tags and rules; check VPC routes; confirm guest OS network config (DHCP\/static).<\/p>\n\n\n\n<p>5) <strong>Cutover VM fails to boot<\/strong>\n&#8211; <strong>Cause<\/strong>: Boot mode mismatch (UEFI vs BIOS), unsupported disk\/controller configuration, OS-specific issues.\n&#8211; <strong>Fix<\/strong>: Check serial console logs; validate boot settings in migration options; consult OS compatibility notes in official docs.<\/p>\n\n\n\n<p>6) <strong>Unexpected costs after migration<\/strong>\n&#8211; <strong>Cause<\/strong>: Test VMs left running; staging disks not deleted; snapshots retained.\n&#8211; <strong>Fix<\/strong>: Delete test clones and finalize\/cleanup migration resources; review disks and snapshots in the project.<\/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 charges, clean up in this order after you\u2019re done:<\/p>\n\n\n\n<p>1) <strong>Delete test clone VMs<\/strong> (if still present)\n2) <strong>Delete cutover VM<\/strong> (only if this was a lab and not a real migration)\n3) In Migrate to Virtual Machines:\n   &#8211; Stop replication\n   &#8211; Delete migration objects\n   &#8211; Delete sources\/connectors (only if not needed)\n4) Delete lab firewall rules, subnet, and VPC if unused<\/p>\n\n\n\n<p>Example commands (be careful\u2014these are destructive):<\/p>\n\n\n\n<pre><code class=\"language-bash\"># Delete firewall rules\ngcloud compute firewall-rules delete mig-lab-allow-ssh --quiet\ngcloud compute firewall-rules delete mig-lab-allow-rdp --quiet\n\n# Delete subnet and VPC\ngcloud compute networks subnets delete mig-lab-subnet --region=us-central1 --quiet\ngcloud compute networks delete mig-lab-vpc --quiet\n<\/code><\/pre>\n\n\n\n<p>Also review and delete:\n&#8211; Unused persistent disks\n&#8211; Snapshots created during testing\n&#8211; Reserved IP addresses\n&#8211; VPN resources created only for the lab<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\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>Migrate in waves<\/strong>: group by dependency and business owner (Wave 0 pilot \u2192 Wave 1 non-critical \u2192 Wave N critical).<\/li>\n<li><strong>Separate test and prod networks<\/strong>: use dedicated subnets and firewall policies for test clones.<\/li>\n<li><strong>Right-size after cutover<\/strong>: lift-and-shift first, then tune machine type and disks once you have performance data.<\/li>\n<li><strong>Document dependencies<\/strong>: DNS, AD, license servers, NTP, SMTP, file shares\u2014test clones should validate these.<\/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; avoid <code>Editor<\/code> in production.<\/li>\n<li>Separate duties:<\/li>\n<li>Migration admins (configure sources\/connectors)<\/li>\n<li>Operators (execute test\/cutover)<\/li>\n<li>Viewers\/auditors (read-only)<\/li>\n<li>Avoid long-lived service account keys when possible; follow connector guidance for secure auth.<\/li>\n<li>Use <strong>labels<\/strong> and <strong>resource hierarchy<\/strong> to control access via IAM conditions (where applicable).<\/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>Delete test clones quickly.<\/li>\n<li>Clean up staging resources immediately after finalization.<\/li>\n<li>Prefer <strong>balanced<\/strong> disks unless you have evidence you need SSD\/high-performance disks.<\/li>\n<li>Use committed use discounts or reservations for steady-state workloads after migration (Compute Engine pricing strategy).<\/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>Place target VMs in a region\/zone that meets latency requirements.<\/li>\n<li>Use adequate disk performance (IOPS\/throughput) for databases and write-heavy systems.<\/li>\n<li>Validate network throughput from users to the new region.<\/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>After migration, consider:<\/li>\n<li>Regional persistent disks (where appropriate)<\/li>\n<li>Multi-zone instance groups for stateless workloads<\/li>\n<li>Backups and snapshots with defined retention policies<\/li>\n<li>Keep a rollback plan until post-cutover validation is complete.<\/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>Implement standard observability:<\/li>\n<li>Ops Agent (or your organization\u2019s standard)<\/li>\n<li>Uptime checks for key endpoints<\/li>\n<li>Log-based alerts for app errors<\/li>\n<li>Create a cutover runbook:<\/li>\n<li>Freeze window<\/li>\n<li>Final replication checkpoint<\/li>\n<li>DNS changes<\/li>\n<li>Verification steps<\/li>\n<li>Rollback steps<\/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>Labels:<\/li>\n<li><code>env<\/code>, <code>app<\/code>, <code>owner<\/code>, <code>cost-center<\/code>, <code>migration-wave<\/code>, <code>data-class<\/code><\/li>\n<li>Naming:<\/li>\n<li>Preserve hostname patterns if possible (but don\u2019t break cloud naming rules)<\/li>\n<li>Use Organization Policies to enforce:<\/li>\n<li>No public IPs unless approved<\/li>\n<li>Approved regions only<\/li>\n<li>CMEK for disks if required<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\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>Access to Migrate to Virtual Machines is governed by <strong>Cloud IAM<\/strong>.<\/li>\n<li>Use predefined roles where possible; otherwise use custom roles with:<\/li>\n<li>Ability to create\/read\/update migration resources<\/li>\n<li>Ability to create required Compute Engine resources during migration<\/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>Data at rest<\/strong>: Compute Engine persistent disks are encrypted by default.<\/li>\n<li><strong>CMEK<\/strong>: If you need customer-managed keys, use <strong>Cloud KMS<\/strong> for disk encryption (validate that your migration workflow supports CMEK for the target disks).<\/li>\n<li><strong>Data in transit<\/strong>: Replication traffic is protected in transit; still, you should prefer private connectivity and follow official connector network guidance.<\/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>Avoid external IPs for migrated workloads unless required.<\/li>\n<li>Prefer:<\/li>\n<li>Private subnets + Cloud NAT (for controlled outbound)<\/li>\n<li>IAP TCP forwarding or bastion for admin access<\/li>\n<li>Ensure firewall rules are <strong>least privilege<\/strong>, especially for RDP\/SSH.<\/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>Don\u2019t bake secrets into VM images.<\/li>\n<li>Move secrets to <strong>Secret Manager<\/strong> where feasible after migration.<\/li>\n<li>Rotate credentials after cutover, especially if source credentials were reused.<\/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>Ensure <strong>Admin Activity<\/strong> audit logs are enabled (default).<\/li>\n<li>Consider enabling <strong>Data Access<\/strong> audit logs where appropriate (can be high-volume\/cost).<\/li>\n<li>Record change tickets and link them to migration operations.<\/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>Validate data residency and approved regions before replication begins.<\/li>\n<li>Ensure security controls carry over:<\/li>\n<li>Endpoint protection<\/li>\n<li>Vulnerability scanning<\/li>\n<li>Patch management<\/li>\n<li>OS hardening baselines<\/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>Allowing 0.0.0.0\/0 SSH\/RDP to migrated VMs<\/li>\n<li>Leaving test clones running with permissive firewall rules<\/li>\n<li>Reusing privileged vCenter credentials broadly<\/li>\n<li>Not restricting who can execute <strong>cutover<\/strong><\/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 separate projects for dev\/test\/prod migrations if needed.<\/li>\n<li>Use Shared VPC and centralized firewall policies.<\/li>\n<li>Require approvals for cutover via process and IAM.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Treat this section as a checklist to review during planning. Exact limitations change\u2014verify in the official docs for your connector version and source type.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility limitations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not all OS versions and configurations migrate cleanly; verify support matrix for:<\/li>\n<li>Linux distros\/kernels<\/li>\n<li>Windows Server versions<\/li>\n<li>UEFI vs BIOS boot mode<\/li>\n<li>Special disk\/controller configurations<\/li>\n<li>Some workloads require app-level consistency steps (database flush\/quiescing) beyond VM-level replication.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and scaling constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine quotas (CPU, disk GB) can block cutover unexpectedly.<\/li>\n<li>API quotas can affect automation.<\/li>\n<li>Migration service resource limits (sources\/connectors\/migrations per location) may apply\u2014verify.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Service availability and supported locations vary.<\/li>\n<li>Choosing a far region increases replication time and potentially cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Staging disks and snapshots can accumulate.<\/li>\n<li>Inter-region egress can be expensive if you test in one region and cut over in another.<\/li>\n<li>Logging volume can grow during troubleshooting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Connector VM needs maintenance: patching, monitoring, backups (per your org\u2019s standards).<\/li>\n<li>Test clones might accidentally interact with production dependencies if not isolated (risk: duplicate IPs, duplicate hostnames, unintended job execution).<\/li>\n<li>DNS cutover can cause partial traffic split if TTLs aren\u2019t managed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Applications that bind to MAC address, hardware ID, or local USB dongles may break.<\/li>\n<li>Licensing models may change in cloud.<\/li>\n<li>Performance tuning is often needed after migration (disk and network differ from on-prem).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VMware snapshots, thin\/thick provisioning, and storage performance can affect replication.<\/li>\n<li>vCenter permissions must match Google\u2019s requirements; least privilege must still allow required actions.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">In Google Cloud (same cloud)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Google Cloud VMware Engine (GCVE)<\/strong>: Keep VMware stack and migrate with VMware-native tooling (often HCX). Best when you want minimal change and keep vSphere operations.<\/li>\n<li><strong>Migrate to Containers<\/strong>: For modernization into GKE rather than lift-and-shift into Compute Engine.<\/li>\n<li><strong>Database Migration Service<\/strong>: For database-level migration rather than VM lift-and-shift.<\/li>\n<li><strong>Storage Transfer Service \/ Transfer Appliance<\/strong>: For bulk data transfer, not full VM migration orchestration.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">In other clouds<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>AWS Application Migration Service (MGN)<\/strong>: Lift-and-shift into AWS using agent-based replication.<\/li>\n<li><strong>Azure Migrate (Server Migration)<\/strong>: Azure\u2019s hub for discovery and migration to Azure VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Open-source \/ self-managed alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Veeam \/ Zerto \/ other DR replication tools<\/strong>: Often used for replication and migration with strong RPO\/RTO features (cost and complexity vary).<\/li>\n<li>DIY approach:<\/li>\n<li>Export\/import images, rsync, or backup\/restore\u2014usually higher risk and more manual.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\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>Migrate to Virtual Machines (Google Cloud)<\/strong><\/td>\n<td>Moving VMs into Compute Engine with a guided workflow<\/td>\n<td>Test clone + cutover workflow; integrates with IAM\/VPC; repeatable process<\/td>\n<td>Requires connector and supported sources; still needs careful networking and OS validation<\/td>\n<td>You want Compute Engine as destination and a standardized migration workflow<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud VMware Engine (GCVE)<\/strong><\/td>\n<td>Keeping VMware platform while moving to Google Cloud<\/td>\n<td>Minimal change; VMware-native operations\/tooling<\/td>\n<td>Higher platform cost; still VMware management overhead<\/td>\n<td>You need VMware compatibility, low refactor, and want to keep vSphere stack<\/td>\n<\/tr>\n<tr>\n<td><strong>Migrate to Containers<\/strong><\/td>\n<td>Modernizing VM-based apps into containers<\/td>\n<td>Potential cost and ops improvements; cloud-native deployment<\/td>\n<td>Not lift-and-shift; requires app changes<\/td>\n<td>You can invest in modernization now<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Application Migration Service<\/strong><\/td>\n<td>Migrating to AWS<\/td>\n<td>Mature lift-and-shift pattern; agent-based replication<\/td>\n<td>Different cloud; requires AWS landing zone<\/td>\n<td>Your destination is AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Migrate (Server Migration)<\/strong><\/td>\n<td>Migrating to Azure<\/td>\n<td>Integrated Azure discovery\/migration hub<\/td>\n<td>Different cloud; Azure-specific<\/td>\n<td>Your destination is Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>Veeam\/Zerto (third-party)<\/strong><\/td>\n<td>DR-like replication, strict RPO\/RTO<\/td>\n<td>Strong replication\/DR features; flexible<\/td>\n<td>Licensing cost; operational complexity<\/td>\n<td>You need DR-grade replication and already use these tools<\/td>\n<\/tr>\n<tr>\n<td><strong>DIY export\/import<\/strong><\/td>\n<td>Small, simple VMs; one-offs<\/td>\n<td>Full control; sometimes cheapest for tiny workloads<\/td>\n<td>High manual effort; error-prone; limited testing orchestration<\/td>\n<td>Only for very small migrations with strong in-house expertise<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\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 company migrating a VMware estate<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A financial services company must migrate 600 VMware VMs to Google Cloud while meeting audit requirements, change approvals, and strict network segmentation.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>On-prem VMware with redundant connectors (pattern per official docs)<\/li>\n<li>Cloud Interconnect to a Shared VPC landing zone<\/li>\n<li>Dedicated subnets:<ul>\n<li><code>mig-test<\/code> isolated for test clones<\/li>\n<li><code>prod-app<\/code>, <code>prod-db<\/code> for cutover<\/li>\n<\/ul>\n<\/li>\n<li>IAM separation:<ul>\n<li>Migration engineering team configures sources\/connectors<\/li>\n<li>Operations team executes cutovers<\/li>\n<\/ul>\n<\/li>\n<li>Central logging and audit export to SIEM<\/li>\n<li><strong>Why this service was chosen<\/strong><\/li>\n<li>Provides a repeatable workflow with test clones and controlled cutover<\/li>\n<li>Integrates with Google Cloud IAM and landing zone constraints<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Reduced downtime by using replication<\/li>\n<li>Improved auditability of migration actions<\/li>\n<li>Standardized post-migration operations using Cloud Monitoring and organization policies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Small VMware cluster moving to Compute Engine<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup runs 15 VMs on a small vSphere cluster. Hardware is aging; they want to move quickly with minimal redesign.<\/li>\n<li><strong>Proposed architecture<\/strong><\/li>\n<li>Cloud VPN to Google Cloud<\/li>\n<li>One connector deployed on-prem<\/li>\n<li>Migrate critical services first (Git, CI runner, internal wiki)<\/li>\n<li>Use a single VPC and minimal firewall rules initially, then harden<\/li>\n<li><strong>Why this service was chosen<\/strong><\/li>\n<li>Faster than rebuilding from scratch<\/li>\n<li>Enables testing before committing to cutover<\/li>\n<li><strong>Expected outcomes<\/strong><\/li>\n<li>Reduced reliance on on-prem hardware<\/li>\n<li>Ability to scale compute on demand<\/li>\n<li>A path to later adopt managed services<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Migrate to Virtual Machines the same as \u201cMigrate for Compute Engine\u201d?<\/strong><br\/>\nMigrate for Compute Engine is a name used in older Google Cloud materials. Today the product is presented as <strong>Migrate to Virtual Machines<\/strong> in Google Cloud. Always follow the current documentation for your workflow.<\/p>\n\n\n\n<p>2) <strong>What is the destination for Migrate to Virtual Machines?<\/strong><br\/>\nThe primary destination is <strong>Compute Engine<\/strong> (Google Cloud VMs).<\/p>\n\n\n\n<p>3) <strong>Do I need a connector?<\/strong><br\/>\nCommonly yes\u2014especially for VMware sources. The connector handles discovery and replication coordination. Follow official docs for connector deployment requirements.<\/p>\n\n\n\n<p>4) <strong>Can I test before I cut over?<\/strong><br\/>\nYes. The service supports <strong>test clones<\/strong> (test instances) so you can validate boot and application behavior before final cutover.<\/p>\n\n\n\n<p>5) <strong>How much downtime should I expect?<\/strong><br\/>\nDowntime depends on data change rate, final sync time, and application shutdown\/startup time. Replication reduces downtime, but it does not remove the need for a controlled cutover window.<\/p>\n\n\n\n<p>6) <strong>Does it migrate networking exactly (same IP\/MAC)?<\/strong><br\/>\nTypically, cloud VMs get new virtual NICs and IPs based on VPC configuration. You may be able to plan static internal IPs in Google Cloud, but preserving on-prem L2 identity is generally not the model. Plan for DNS\/IP changes.<\/p>\n\n\n\n<p>7) <strong>Can I keep the VM hostname the same?<\/strong><br\/>\nOften yes at the OS level, but ensure it doesn\u2019t create conflicts (especially if source and test clone run simultaneously on the same network). Isolate test clones to avoid duplicate hostnames and AD\/DNS issues.<\/p>\n\n\n\n<p>8) <strong>What about Active Directory domain controllers?<\/strong><br\/>\nBe careful. Migrating DCs requires strict planning to avoid replication and identity issues. Consider building new DCs in Google Cloud and migrating services instead. If you must lift-and-shift, follow Microsoft and Google best practices.<\/p>\n\n\n\n<p>9) <strong>Is Migrate to Virtual Machines agent-based?<\/strong><br\/>\nMany workflows are connector-based. Some OS adaptation steps may require in-guest operations depending on OS and method. Verify per source\/OS in the official docs.<\/p>\n\n\n\n<p>10) <strong>Can I migrate databases this way?<\/strong><br\/>\nYou can lift-and-shift a database VM, but that doesn\u2019t modernize it. For many databases, consider <strong>Database Migration Service<\/strong> or managed databases for better reliability and operations.<\/p>\n\n\n\n<p>11) <strong>How do I secure connector credentials?<\/strong><br\/>\nUse least privilege on the source (vCenter) and follow official guidance for how the connector stores and uses credentials. Rotate credentials after the migration wave when appropriate.<\/p>\n\n\n\n<p>12) <strong>Where do I see logs and audit events?<\/strong><br\/>\nUse <strong>Cloud Logging<\/strong> for service logs and <strong>Cloud Audit Logs<\/strong> to track who performed migration actions. Also monitor connector VM logs according to your operational practices.<\/p>\n\n\n\n<p>13) <strong>What are common reasons a migrated VM won\u2019t boot?<\/strong><br\/>\nBoot mode mismatch (UEFI\/BIOS), driver issues, unsupported kernel\/storage controller patterns, or OS adaptation failures. Use serial console logs and official troubleshooting guides.<\/p>\n\n\n\n<p>14) <strong>Can I automate migrations with an API?<\/strong><br\/>\nGoogle Cloud services typically provide APIs. Migrate to Virtual Machines often maps to a migration API (commonly referred to as VM Migration). If you need automation, confirm the API surface and supported operations in the official docs and client libraries.<\/p>\n\n\n\n<p>15) <strong>How do I estimate time to migrate?<\/strong><br\/>\nEstimate based on:\n&#8211; Total data size (GB\/TB)\n&#8211; Effective throughput (Mbps\/Gbps) after overhead\n&#8211; Data change rate (GB\/day)\n&#8211; Replication and validation time<br\/>\nThen validate with a pilot VM and measure real throughput.<\/p>\n\n\n\n<p>16) <strong>What\u2019s the best first VM to migrate as a pilot?<\/strong><br\/>\nChoose a small, low-risk VM with:\n&#8211; Single disk\n&#8211; No complex dependencies\n&#8211; Easy validation steps<br\/>\nAvoid core identity, large databases, or latency-sensitive services as your first pilot.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Migrate to Virtual Machines<\/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>Migrate to Virtual Machines documentation \u2014 https:\/\/cloud.google.com\/migrate\/virtual-machines\/docs<\/td>\n<td>Primary source for supported sources, connector setup, workflows, and troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Migrate to Virtual Machines pricing \u2014 https:\/\/cloud.google.com\/migrate\/virtual-machines\/pricing<\/td>\n<td>Confirms whether the service has direct charges and what underlying resources drive cost<\/td>\n<\/tr>\n<tr>\n<td>Pricing calculator<\/td>\n<td>Google Cloud Pricing Calculator \u2014 https:\/\/cloud.google.com\/products\/calculator<\/td>\n<td>Build region-specific estimates for compute, disks, snapshots, and networking<\/td>\n<\/tr>\n<tr>\n<td>Official Compute Engine docs<\/td>\n<td>Compute Engine documentation \u2014 https:\/\/cloud.google.com\/compute\/docs<\/td>\n<td>Needed for machine types, disks, networking, IAM, and operations after cutover<\/td>\n<\/tr>\n<tr>\n<td>Official networking docs<\/td>\n<td>Cloud VPN overview \u2014 https:\/\/cloud.google.com\/network-connectivity\/docs\/vpn\/concepts\/overview<\/td>\n<td>Common hybrid connectivity option for replication traffic<\/td>\n<\/tr>\n<tr>\n<td>Official networking docs<\/td>\n<td>Cloud Interconnect overview \u2014 https:\/\/cloud.google.com\/network-connectivity\/docs\/interconnect\/concepts\/overview<\/td>\n<td>Preferred for large migrations requiring stable throughput<\/td>\n<\/tr>\n<tr>\n<td>Official IAM docs<\/td>\n<td>IAM overview \u2014 https:\/\/cloud.google.com\/iam\/docs\/overview<\/td>\n<td>Designing least privilege for migration operators and service accounts<\/td>\n<\/tr>\n<tr>\n<td>Official logging\/audit<\/td>\n<td>Cloud Audit Logs overview \u2014 https:\/\/cloud.google.com\/logging\/docs\/audit<\/td>\n<td>How to audit migration actions and resource changes<\/td>\n<\/tr>\n<tr>\n<td>Official monitoring<\/td>\n<td>Cloud Monitoring overview \u2014 https:\/\/cloud.google.com\/monitoring\/docs<\/td>\n<td>Monitor connector health, VM health, and build alerts<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Google Cloud Architecture Center \u2014 https:\/\/cloud.google.com\/architecture<\/td>\n<td>Reference architectures for landing zones, networking, and governance<\/td>\n<\/tr>\n<tr>\n<td>Best practices<\/td>\n<td>Google Cloud Well-Architected Framework \u2014 https:\/\/cloud.google.com\/architecture\/framework<\/td>\n<td>Reliability, security, cost, and operational excellence principles applied post-migration<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Google Cloud Tech (YouTube) \u2014 https:\/\/www.youtube.com\/googlecloudtech<\/td>\n<td>Often includes migration sessions and operational guidance (search within channel for VM migration topics)<\/td>\n<\/tr>\n<tr>\n<td>Release updates<\/td>\n<td>Google Cloud Release Notes \u2014 https:\/\/cloud.google.com\/release-notes<\/td>\n<td>Track service changes that affect migration workflows and connector versions<\/td>\n<\/tr>\n<tr>\n<td>Community (cautious)<\/td>\n<td>Google Cloud Community \u2014 https:\/\/www.googlecloudcommunity.com\/<\/td>\n<td>Practical troubleshooting patterns; validate answers against official docs<\/td>\n<\/tr>\n<tr>\n<td>Hands-on labs<\/td>\n<td>Google Cloud Skills Boost \u2014 https:\/\/www.cloudskillsboost.google\/<\/td>\n<td>Look for migration and Compute Engine labs; verify there is a current lab for this service<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, SREs, cloud engineers<\/td>\n<td>Google Cloud foundations, DevOps practices, migration and operations topics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate IT professionals<\/td>\n<td>DevOps\/SCM fundamentals, CI\/CD, cloud basics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud ops and platform teams<\/td>\n<td>Cloud operations, monitoring, reliability practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, operations engineers<\/td>\n<td>SRE practices, observability, incident management<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops teams exploring AIOps<\/td>\n<td>AIOps concepts, automation, monitoring analytics<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content (verify current offerings)<\/td>\n<td>Beginners to intermediate engineers<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training resources (verify course catalog)<\/td>\n<td>DevOps engineers, students<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps\/community platform (verify services)<\/td>\n<td>Teams seeking short-term coaching\/support<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support\/training resources (verify offerings)<\/td>\n<td>Ops teams needing practical support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact portfolio)<\/td>\n<td>Migration planning, cloud operations, automation<\/td>\n<td>Landing zone readiness, migration factory runbooks, cost governance<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Training + consulting (verify service catalog)<\/td>\n<td>Skills enablement plus implementation support<\/td>\n<td>Migration readiness workshops, platform enablement, CI\/CD and ops practices<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps\/cloud consulting (verify offerings)<\/td>\n<td>DevOps transformation and cloud operations<\/td>\n<td>Build observability, IAM baselines, operational runbooks for migrated workloads<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\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 Migrate to Virtual Machines<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Compute Engine basics:<\/li>\n<li>Instances, machine types, images, disks, snapshots<\/li>\n<li>Google Cloud networking:<\/li>\n<li>VPC, subnets, firewall rules, routes, Cloud NAT<\/li>\n<li>Hybrid connectivity (Cloud VPN \/ Interconnect)<\/li>\n<li>IAM fundamentals:<\/li>\n<li>Roles, service accounts, least privilege<\/li>\n<li>Linux\/Windows administration:<\/li>\n<li>Boot troubleshooting, networking, OS logs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Operational excellence on Google Cloud:<\/li>\n<li>Cloud Monitoring, Logging, alerting<\/li>\n<li>Patch management and vulnerability scanning approaches<\/li>\n<li>Reliability patterns:<\/li>\n<li>Instance groups, load balancing, multi-zone designs<\/li>\n<li>Backup and DR on Google Cloud<\/li>\n<li>Modernization options:<\/li>\n<li>Migrate to Containers, GKE, serverless<\/li>\n<li>Managed databases (Cloud SQL, AlloyDB\u2014choose per workload)<\/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 migration engineer<\/li>\n<li>Cloud solutions architect<\/li>\n<li>Platform engineer<\/li>\n<li>SRE \/ operations engineer<\/li>\n<li>Infrastructure engineer (VMware-to-cloud)<\/li>\n<li>Security engineer (migration governance and audit)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Google Cloud)<\/h3>\n\n\n\n<p>While there isn\u2019t typically a certification dedicated solely to this service, the skills align with:\n&#8211; <strong>Associate Cloud Engineer<\/strong>\n&#8211; <strong>Professional Cloud Architect<\/strong>\n&#8211; <strong>Professional Cloud DevOps Engineer<\/strong><\/p>\n\n\n\n<p>Always confirm current certification offerings:\n&#8211; 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>Build a migration landing zone:<\/li>\n<li>Shared VPC, restricted admin access, logging, labels<\/li>\n<li>Migrate a non-critical VM and create a post-migration hardening checklist<\/li>\n<li>Create a cost report showing:<\/li>\n<li>migration-time spend vs steady-state spend<\/li>\n<li>Write a cutover runbook template:<\/li>\n<li>test plan, DNS plan, rollback, sign-offs<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cutover<\/strong>: The point where production use moves from the source VM to the migrated VM in Google Cloud.<\/li>\n<li><strong>Compute Engine<\/strong>: Google Cloud\u2019s Infrastructure-as-a-Service VM offering.<\/li>\n<li><strong>Connector<\/strong>: A deployed appliance\/VM that communicates with the source environment and the Google Cloud migration service.<\/li>\n<li><strong>Discovery<\/strong>: Process of listing and identifying VMs and metadata from a source environment.<\/li>\n<li><strong>Incremental replication<\/strong>: Replicating only changed blocks after an initial full copy.<\/li>\n<li><strong>Landing zone<\/strong>: A standardized Google Cloud environment (projects, VPCs, IAM, policies) designed for secure, governed workloads.<\/li>\n<li><strong>Migrate to Virtual Machines<\/strong>: Google Cloud service for migrating VMs into Compute Engine.<\/li>\n<li><strong>Persistent Disk<\/strong>: Block storage used by Compute Engine VMs.<\/li>\n<li><strong>Project<\/strong>: A Google Cloud resource container for billing, APIs, IAM, and resources.<\/li>\n<li><strong>Replication<\/strong>: Copying VM disk data from the source to Google Cloud.<\/li>\n<li><strong>Service account<\/strong>: A Google Cloud identity used by workloads and services to call APIs.<\/li>\n<li><strong>Shared VPC<\/strong>: A Google Cloud model where a host project owns the VPC network shared by service projects.<\/li>\n<li><strong>Test clone<\/strong>: A test VM created from replicated data to validate boot and function before cutover.<\/li>\n<li><strong>VPC<\/strong>: Virtual Private Cloud network in Google Cloud.<\/li>\n<li><strong>VPN\/Interconnect<\/strong>: Hybrid connectivity options to connect on-prem networks to Google Cloud.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p><strong>Migrate to Virtual Machines<\/strong> is Google Cloud\u2019s guided service for <strong>Migration<\/strong> of existing VMs\u2014most commonly from VMware\u2014into <strong>Compute Engine<\/strong>. It matters because it provides a repeatable workflow (discovery \u2192 replication \u2192 test clone \u2192 cutover) that reduces risk and operational complexity compared to ad-hoc migrations.<\/p>\n\n\n\n<p>It fits best when you want to lift-and-shift into Compute Engine, validate with test clones, and control cutover with clear operational steps. Cost planning should focus on underlying resources (Compute Engine, disks, snapshots, and network transfer) and on avoiding surprises like leftover test\/staging resources. Security success depends on least-privilege IAM, isolated test networks, careful firewall rules, and strong audit logging.<\/p>\n\n\n\n<p>Use it when you need a practical path from existing VM estates to Google Cloud with controlled downtime; consider alternatives like Google Cloud VMware Engine if you need to keep the VMware stack, or modernization paths if you can refactor.<\/p>\n\n\n\n<p><strong>Next step<\/strong>: Read the official Migrate to Virtual Machines documentation and run a pilot migration on one non-critical VM, measuring replication throughput and validating your cutover runbook end-to-end.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Migration<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,46],"tags":[],"class_list":["post-713","post","type-post","status-publish","format-standard","hentry","category-google-cloud","category-migration"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/713","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=713"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/713\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=713"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=713"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=713"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}