Google Cloud Migrate to Containers Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Migration

1. Introduction

What this service is

Migrate to Containers is a Google Cloud migration service that helps you convert virtual machine (VM)-based applications into containers and generate Kubernetes resources so you can run them on Google Kubernetes Engine (GKE).

One-paragraph simple explanation

If you have an app running on a VM (for example, in VMware or on a cloud VM) and you want to move it to Kubernetes without rebuilding everything from scratch, Migrate to Containers analyzes the VM, containerizes what’s needed, and produces deployable artifacts (container images and manifests) to run the app on GKE.

One-paragraph technical explanation

Technically, Migrate to Containers uses a set of migration components (deployed into a GKE cluster) to discover a source workload, perform an assessment, and execute a conversion pipeline that typically outputs container images (stored in a registry such as Artifact Registry) and Kubernetes YAML (Deployments/Services, and sometimes volumes and other resources). It’s designed for application modernization via re-platforming (VM → container on Kubernetes), not for lift-and-shift VM moves (that’s typically Migrate to Virtual Machines).

What problem it solves

Many organizations want Kubernetes benefits (standardized deployments, scaling, rolling updates, better portability) but have a large VM estate. Rewriting apps is costly and slow. Migrate to Containers helps teams start modernizing faster by providing a structured, tool-assisted path from VM workloads to containers, with assessments and repeatable migration execution.

Naming note (verify in official docs): Migrate to Containers is the current Google Cloud name for what was previously branded as Migrate for Anthos. The scope remains VM-to-container modernization targeting Kubernetes/GKE.

2. What is Migrate to Containers?

Official purpose

Migrate to Containers is intended to modernize VM-based applications by converting them to container-based workloads runnable on Kubernetes—most commonly on Google Kubernetes Engine (GKE).

Official landing page: https://cloud.google.com/migrate/containers

Core capabilities

At a high level, Migrate to Containers supports the lifecycle of VM-to-container modernization:

Discovery and assessment of source workloads (what is running on the VM, dependencies, feasibility signals).
Automated conversion of VM workloads into container images.
Generation of Kubernetes deployment artifacts for GKE (and Kubernetes generally).
Repeatable migration execution for multiple workloads (useful for migration waves).

Supported source environments and OS/app compatibility vary. Always confirm current support matrices in the official documentation: https://cloud.google.com/migrate/containers/docs

Major components (conceptual)

While exact component names and deployment patterns can evolve, typical building blocks include:

Migrate to Containers API / service control plane in Google Cloud (project-level configuration and orchestration).
Migration processing components running in a GKE cluster (controllers/operators that run assessments and perform conversions).
Connectors/adapters for source environments (for example, connectivity and credentials to VMware vSphere or cloud VMs).
Artifact output destinations:
Artifact Registry (recommended) to store container images.
A Git repo or local repository for Kubernetes manifests (pattern varies by workflow).

Service type

Migrate to Containers is best understood as a managed migration service that relies on in-cluster components (Kubernetes controllers/operators) to do the heavy lifting. It’s not “just a CLI” and not purely SaaS—it’s a hybrid model: Google Cloud-managed orchestration plus customer-project resources (GKE cluster, networking, IAM).

Scope (regional/global/zonal)

Project-scoped: configured per Google Cloud project (billing, IAM, API enablement).
Cluster-scoped execution: migration processing runs inside a specific GKE cluster (which is regional or zonal depending on how you create it).
Network-scoped connectivity: reaching sources (like on-prem VMware) depends on your VPC design, VPN/Interconnect, firewall rules, and DNS.

How it fits into the Google Cloud ecosystem

Migrate to Containers often sits in the middle of these Google Cloud capabilities:

Compute Engine / VMware Engine / on-prem VMware as sources (depending on supported connectors)
GKE as the runtime target
Artifact Registry for images
Cloud Logging & Cloud Monitoring for operational visibility
IAM for controlled access
VPC + Cloud VPN / Cloud Interconnect to securely reach on-prem environments
Migration Center (optional) to track and organize migrations across an estate
Migration Center: https://cloud.google.com/migration-center

3. Why use Migrate to Containers?

Business reasons

Accelerate modernization: move faster than rewriting applications from scratch.
Reduce operational overhead: standardize deployments and rollouts using Kubernetes patterns.
Improve portability: container workloads can be moved more easily across environments than VM images.
Enable platform standardization: align application delivery with Kubernetes-based platform teams.

Technical reasons

Containerization with structure: generate consistent artifacts (images + manifests) rather than ad-hoc Dockerfiles.
Repeatable workflows: migrate multiple VMs using a consistent process.
Bridge strategy: use VM-to-container as an intermediate step toward microservices or cloud-native refactoring.

Operational reasons

Kubernetes operations: leverage GKE upgrades, node pools, scaling, and integrated logging/monitoring.
Deployment consistency: Kubernetes manifests represent desired state; rollbacks and rollouts become standardized.
Better environment parity: closer alignment between dev/test/prod via container images.

Security/compliance reasons

IAM-based access control for who can run migrations and who can deploy to clusters.
Container security posture improvements are possible post-migration:
vulnerability scanning (Artifact Analysis)
policy enforcement (Policy Controller / organization policy)
standardized secrets handling
Improved auditability through Cloud Audit Logs and Kubernetes audit logging (when enabled).

Scalability/performance reasons

Horizontal scaling becomes more natural once running on GKE (if the app supports it).
Resilience patterns (readiness/liveness probes, pod disruption budgets) can be introduced.

When teams should choose it

Choose Migrate to Containers when: – You have VM-based Linux workloads that can run in containers without requiring full VM semantics. – You want to move toward GKE/Kubernetes as the standard runtime. – You need a faster modernization path than re-architecting immediately. – You have a portfolio of apps that are good candidates for re-platforming (stateless apps or apps with manageable state).

When they should not choose it

Avoid or reconsider Migrate to Containers when: – Workloads require kernel modules, privileged host access, or tight coupling to VM internals. – You’re migrating Windows-only workloads (verify support; VM-to-container for Windows is typically more constrained). – Apps are highly stateful with complex storage dependencies that won’t map cleanly to Kubernetes storage abstractions. – You primarily need VM lift-and-shift (use Migrate to Virtual Machines instead). – Your organization isn’t ready to run Kubernetes operationally (consider Cloud Run or managed services instead).

4. Where is Migrate to Containers used?

Industries

Common adoption patterns: – Financial services: modernization while keeping strict security controls. – Retail/e-commerce: move web and API tiers to scalable Kubernetes platforms. – Healthcare: modernization with audit and compliance requirements. – Manufacturing & logistics: modernize legacy middleware and internal tools. – SaaS providers: reduce VM sprawl and standardize delivery pipelines.

Team types

Cloud/platform engineering teams building a Kubernetes landing zone
DevOps and SRE teams migrating apps into GKE
Application teams modernizing services with platform support
Security teams defining guardrails for containerized workloads

Workloads

Web apps (Apache/Nginx + app runtime)
API services
Batch workers and schedulers (where Kubernetes Jobs/CronJobs apply)
Legacy monoliths that can run “as-is” in a container initially
Middleware components (with careful networking/storage design)

Architectures

VM-to-GKE re-platforming for the application layer
Hybrid migration: on-prem VMware → GKE in Google Cloud
Strangler patterns: migrate part of a system while dependencies remain elsewhere
Platform standardization: consolidate many apps into fewer GKE clusters

Real-world deployment contexts

On-prem data center to Google Cloud (VPN/Interconnect)
Multi-cloud to Google Cloud (where supported by connectors)
Internal enterprise private clusters (GKE private cluster) for compliance

Production vs dev/test usage

Dev/test: validate feasibility, build playbooks, and refine artifact generation.
Production: run structured migration waves with governance, observability, rollback plans, and change management.

5. Top Use Cases and Scenarios

Below are realistic use cases for Migrate to Containers. Exact feasibility depends on workload characteristics and current support matrices (verify in official docs).

1) VM-based web app to GKE (stateless)

Problem: Web app runs on a VM with manual deploys and inconsistent environments.
Why this service fits: Converts runtime and filesystem into a container image and generates Kubernetes manifests.
Example: A Debian VM running Nginx + a Node.js app is migrated to GKE and exposed via a LoadBalancer Service or Ingress.

2) Standardizing deployments across teams

Problem: Different teams deploy apps differently (SSH + scripts, custom init scripts, etc.).
Why this service fits: Produces Kubernetes artifacts that can be integrated into GitOps pipelines.
Example: 30 internal tools are migrated and deployed via a standardized Helm/Kustomize + CI/CD workflow (post-migration refinement).

3) Data center exit for VMware estates

Problem: Large VMware footprint; need to migrate apps before hardware renewal.
Why this service fits: Designed for VM → container conversion, often used with on-prem connectivity.
Example: A set of Linux VMs in vSphere are containerized and deployed to GKE with Cloud VPN connectivity for dependencies during transition.

4) Moving legacy monoliths into a Kubernetes platform (first step)

Problem: Monolith is hard to refactor immediately, but platform team mandates Kubernetes.
Why this service fits: Enables re-platforming first, then iterative refactoring.
Example: A Java monolith runs in a container on GKE with minimal changes; later, teams introduce config externalization and split services.

5) Enabling Kubernetes-native operations (rolling updates, probes)

Problem: VM deployments cause downtime; no standard health checks.
Why this service fits: Generated manifests provide a baseline to add readiness/liveness probes and rollout strategies.
Example: After migration, the team adds /healthz probes and uses Deployment rolling updates.

6) Consolidating multiple VMs into shared GKE clusters

Problem: VM sprawl increases cost and operational overhead.
Why this service fits: Containers share nodes and can be right-sized via requests/limits.
Example: 20 lightly used VMs become 20 Deployments across two regional GKE clusters with node pools sized for steady vs burst workloads.

7) Building a migration factory (waves and playbooks)

Problem: One-off migrations are inconsistent and hard to repeat.
Why this service fits: Creates a repeatable process: assess → convert → validate → deploy → cutover.
Example: A platform team defines a standard validation checklist and rollout plan for each migrated workload.

8) Pre-refactor step before moving to Cloud Run or microservices

Problem: App must be containerized first; direct refactor is too risky.
Why this service fits: Gets the app into a container image quickly; then you can decide the best runtime (GKE vs Cloud Run).
Example: App is migrated to GKE; later the team splits stateless parts and moves them to Cloud Run.

9) Improve security posture through container scanning and policy

Problem: VM patching is inconsistent; little visibility into vulnerabilities.
Why this service fits: Container images can be scanned, and deployments can be policy-controlled.
Example: After migration, Artifact Registry scanning and admission policies prevent deployment of high-severity vulnerable images.

10) Hybrid operation during transition (dependencies remain on VMs)

Problem: App needs a database still on-prem; full migration takes time.
Why this service fits: You can run the app on GKE while keeping connectivity to existing dependencies.
Example: App moves to GKE; continues connecting to an on-prem database via VPN until database migration is complete.

6. Core Features

Feature availability can change; confirm in official docs: https://cloud.google.com/migrate/containers/docs

1) VM workload assessment

What it does: Evaluates a VM/application to determine containerization feasibility and highlights potential issues.
Why it matters: Prevents wasted effort on workloads that won’t run well in containers.
Practical benefit: Helps you prioritize “easy wins” and plan remediation for harder apps.
Caveats: Assessments are signals, not guarantees—testing is still required.

2) Automated container image generation

What it does: Produces container images representing the VM workload’s runtime/filesystem needs.
Why it matters: Avoids hand-crafting Dockerfiles for complex legacy apps.
Practical benefit: Faster time-to-first-container.
Caveats: Generated images may be larger than optimized hand-built images; you often optimize later.

3) Kubernetes manifest generation

What it does: Creates baseline YAML for deploying the containerized workload on Kubernetes/GKE.
Why it matters: Bridges the gap between a container image and a runnable Kubernetes workload.
Practical benefit: Provides a starting point for adding probes, resources, autoscaling, and ingress.
Caveats: Manifests usually require review—especially networking, service exposure, and storage.

4) Migration orchestration via a GKE-based processing environment

What it does: Runs migration jobs/controllers in a Kubernetes cluster to perform conversions.
Why it matters: Scales migration operations and isolates migration tooling.
Practical benefit: You can run multiple migrations and standardize operations.
Caveats: You must operate the processing cluster (upgrades, permissions, cost).

5) Integration with Artifact Registry (typical pattern)

What it does: Stores generated container images in Google Cloud’s registry.
Why it matters: Centralized image lifecycle, IAM access control, and integration with scanning.
Practical benefit: Cleaner CI/CD integration and promotion across environments.
Caveats: Storage and egress costs apply depending on usage.

6) Repeatable migration runs (migration waves)

What it does: Supports executing similar processes across a fleet of workloads.
Why it matters: Migration is usually a program, not a project.
Practical benefit: Consistency, auditability, and predictable execution.
Caveats: Requires governance, naming conventions, and good operational discipline.

7) Support for hybrid connectivity patterns

What it does: Works in environments where source is on-prem and target is in Google Cloud.
Why it matters: Many enterprises migrate from on-prem VMware.
Practical benefit: Enables phased migration and hybrid cutovers.
Caveats: Network design (VPN/Interconnect, DNS, firewall rules) is often the hardest part.

8) Kubernetes-native operational alignment

What it does: Produces artifacts that fit Kubernetes deployment workflows.
Why it matters: Lets you use GKE features like rolling updates and health checks.
Practical benefit: Improves reliability and standardization over VM scripts.
Caveats: Some apps require refactoring to truly benefit (statelessness, externalized config).

9) Separation of “migration tooling” from “runtime clusters” (common best practice)

What it does: Encourages running migration tooling in a dedicated processing cluster.
Why it matters: Reduces risk to production clusters and avoids cluttering them with migration components.
Practical benefit: Cleaner operations and blast-radius control.
Caveats: Additional cluster cost.

10) IAM and audit integration (Google Cloud controls)

What it does: Uses Google Cloud IAM and Audit Logs to govern who can run migrations and access artifacts.
Why it matters: Migration touches sensitive data and credentials.
Practical benefit: Better compliance posture and traceability.
Caveats: You must design least-privilege roles and manage secrets carefully.

7. Architecture and How It Works

High-level service architecture

A typical Migrate to Containers setup has:

Source environment: where the VM runs (for example, on-prem VMware or cloud VMs).
Connectivity: network path from Google Cloud/GKE to the source (VPN/Interconnect, firewall, routing, DNS).
Migration processing cluster: a GKE cluster that runs the migration controllers/jobs.
Artifact destinations: Artifact Registry for images, plus a repository/location for Kubernetes manifests.
Target runtime: GKE cluster(s) where you deploy the migrated workloads (can be the same as the processing cluster, but often separate in production).

Request/data/control flow (typical)

Control plane operations:
Admin configures sources, credentials, and migration settings in a Google Cloud project.
Assessment:
Migration components inspect the VM/app metadata and produce a report.
Conversion:
Migration components create container images and manifests.
Publishing:
Images are pushed to Artifact Registry (or another supported registry).
Manifests are produced for deployment.
Deployment:
Platform/app teams deploy to a target GKE cluster, then validate and cut over traffic.

Integrations with related services

Common integrations include: – GKE: where migration tooling runs and where workloads land. – Artifact Registry: image storage and scanning integration. – Cloud Logging / Cloud Monitoring: logs/metrics from GKE and migration components. – Cloud Audit Logs: administrative actions and API calls. – Secret Manager (recommended): store credentials used for source access (pattern varies). – Cloud VPN / Cloud Interconnect: secure connectivity to on-prem. – VPC firewall rules: allow required ports to vCenter/VMs (for VMware scenarios).

Dependency services

A GKE cluster (Standard is commonly used for migration tooling; verify requirements in docs).
Google Cloud APIs (Compute, Container, Artifact Registry, and the Migrate to Containers API).
Network services for hybrid connectivity as required.

Security/authentication model

Google Cloud IAM controls access to configure and operate migrations.
Kubernetes RBAC controls access inside the migration processing cluster.
Service accounts are used by controllers to call Google Cloud APIs.
Source credentials (e.g., vCenter credentials or VM access credentials) must be stored securely and rotated.

Networking model

The processing cluster needs:
Egress to reach the source environment (direct VPC routing, VPN, or Interconnect).
Access to Artifact Registry endpoints.
DNS resolution for source endpoints (vCenter, VMs).
For private clusters, ensure private access is configured (for Google APIs and required endpoints).

Monitoring/logging/governance considerations

Enable and use:
Cloud Logging for GKE workloads and system components.
Cloud Monitoring dashboards and alerting for cluster health.
Audit Logs for migration actions.
Governance:
Use labels/tags for migration waves, owners, environments.
Store generated artifacts in version control where possible (post-generation).

Simple architecture diagram (Mermaid)

flowchart LR
  A[Source VM(s)] -->|Network access (VPN/Interconnect/VPC)| B[GKE Processing Cluster<br/>(Migrate to Containers components)]
  B --> C[Artifact Registry<br/>Container Images]
  B --> D[Kubernetes Manifests<br/>YAML output]
  D --> E[GKE Target Cluster<br/>Run migrated app]
  C --> E

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph OnPrem[On-prem / Source Environment]
    VC[vCenter / Source Control (if VMware)]
    VM1[VM: app-01]
    VM2[VM: app-02]
  end

  subgraph Net[Connectivity]
    VPN[Cloud VPN or Interconnect]
    DNS[Hybrid DNS (Cloud DNS + on-prem)]
  end

  subgraph GCP[Google Cloud Project]
    subgraph Proc[GKE Processing Cluster (dedicated)]
      MTC[Migrate to Containers controllers/jobs]
      NS[v2k / migration namespace]
    end

    AR[Artifact Registry]
    LOG[Cloud Logging]
    MON[Cloud Monitoring]
    AUD[Cloud Audit Logs]

    subgraph Runtime[GKE Runtime Cluster(s)]
      IN[Ingress / Gateway]
      APP[App Deployments/Services]
      HPA[Autoscaling policies]
    end
  end

  VC --> VM1
  VC --> VM2

  VM1 -->|App + file system capture| MTC
  VM2 -->|App + file system capture| MTC

  VPN --- Proc
  VPN --- OnPrem
  DNS --- Proc
  DNS --- OnPrem

  MTC --> AR
  MTC --> LOG
  MTC --> MON
  MTC --> AUD

  AR --> APP
  IN --> APP

8. Prerequisites

Account/project requirements

A Google Cloud project with billing enabled.
Ability to create and manage:
GKE clusters
Artifact Registry repositories
(Optional) VPN/Interconnect connectivity for on-prem sources

Permissions / IAM roles

For a hands-on lab, the simplest approach is Project Owner on a dedicated sandbox project.

For production, follow least privilege. Common permission areas include: – GKE administration (cluster creation, RBAC) – Artifact Registry write access – Compute/network administration (VPC, firewall, VPN) – Migrate to Containers-specific permissions (verify exact role names in official docs)

Verify required IAM roles and predefined roles here: https://cloud.google.com/migrate/containers/docs

Billing requirements

Billing must be enabled because you will use:
GKE compute resources
Artifact Registry storage
Load balancers (if you expose services)
Potential network egress

CLI/SDK/tools needed

Google Cloud CLI (gcloud): https://cloud.google.com/sdk/docs/install
kubectl (usually installed via the Cloud SDK): https://kubernetes.io/docs/tasks/tools/
Optional but helpful:
Docker (for inspecting images locally; not strictly required)
Access to Cloud Console

Region availability

GKE and Artifact Registry are regional services. Choose a region supported by your organization.
Migrate to Containers availability can vary. Verify in official docs for supported regions and any product constraints.

Quotas/limits

Typical quotas that may matter: – GKE cluster/node limits – Compute Engine CPU quotas (for nodes and VMs) – Load balancer quotas – Artifact Registry storage/requests quotas

Check quotas: Cloud Console → IAM & Admin → Quotas.

Prerequisite services

Enable APIs (names can change; verify in your project’s API Library): – Kubernetes Engine API – Compute Engine API – Artifact Registry API – Cloud Resource Manager API (often used by tooling) – Migrate to Containers API (verify the exact API name in the API Library)

9. Pricing / Cost

Current pricing model (how to think about it)

Migrate to Containers commonly follows a model where the tool itself is not billed as a separate “license” line item, but you pay for the Google Cloud resources it uses (clusters, compute, storage, network). However, pricing models can change, and some features can have billable dependencies.

Verify the latest billing/pricing guidance in official documentation: – Product page: https://cloud.google.com/migrate/containers – Docs: https://cloud.google.com/migrate/containers/docs – Google Cloud Pricing: https://cloud.google.com/pricing – Pricing Calculator: https://cloud.google.com/products/calculator – GKE pricing: https://cloud.google.com/kubernetes-engine/pricing – Artifact Registry pricing: https://cloud.google.com/artifact-registry/pricing

Pricing dimensions (most common cost components)

GKE cluster costs – Control plane fees (for Standard clusters; Autopilot differs) – Node VM costs (vCPU/RAM hours) – Persistent disks for nodes or workloads (if used)
Artifact Registry – Storage for container images – Network egress (if pulling images across regions or to on-prem)
Networking – Load balancers (Services of type LoadBalancer, Ingress/Gateway) – Cloud VPN hourly + egress (if used) – Interconnect costs (if used)
Logging and monitoring – Cloud Logging ingestion and retention (beyond free allotments) – Monitoring metrics (generally generous, but can grow at scale)
Temporary migration data – Snapshot or staging storage (depends on workflow) – Additional disks used during conversion

Free tier (if applicable)

Google Cloud often has free tiers for some services and trial credits for new accounts, but this is not guaranteed for every account type. Check: – https://cloud.google.com/free – Always validate in your Billing account.

Cost drivers (what makes it expensive)

Running a dedicated processing cluster 24/7 instead of scaling it down after migrations.
Large numbers of migration jobs running concurrently.
Large images due to “lifted” VM filesystems.
Cross-region image storage/pulls.
Hybrid networking costs (VPN/Interconnect) and data transfer.

Hidden or indirect costs to plan for

Time spent by engineers to validate and optimize generated artifacts.
CI/CD changes to adopt container + Kubernetes pipelines.
Security posture improvements (policy tooling, scanning) may add cost.

Network/data transfer implications

Moving data from on-prem to Google Cloud can incur:
on-prem outbound bandwidth costs
VPN/Interconnect data transfer charges (depending on product and path)
Pulling images from Artifact Registry:
cross-region pulls can cost more than same-region pulls

How to optimize cost

Use a temporary processing cluster and delete it when the migration wave completes.
Keep Artifact Registry in the same region as GKE runtime clusters.
Reduce image size after migration by:
removing unused packages/files
adopting minimal base images (where feasible)
Avoid external LoadBalancers for internal test services; use:
ClusterIP + port-forward
Internal LoadBalancer (where appropriate)
Set Logging retention deliberately.

Example low-cost starter estimate (non-numeric)

A minimal lab typically includes: – 1 small GKE Standard cluster (1–2 nodes) – 1 small Compute Engine VM as a source (if your source is in-cloud) – 1 Artifact Registry repository – No VPN/Interconnect, no external load balancer (use port-forward)

Use the calculator to estimate: – Node machine type hourly cost × hours – VM machine type hourly cost × hours – Artifact storage GB × duration

Example production cost considerations (non-numeric)

In production, plan for: – Separate processing and runtime clusters (or at least isolated namespaces and RBAC) – HA clusters (regional GKE) for runtime – Multiple node pools, autoscaling – Higher Artifact storage and higher network traffic – Logging/Monitoring volumes and retention policies – Hybrid connectivity (VPN/Interconnect) and DNS management

10. Step-by-Step Hands-On Tutorial

This lab is designed to be safe and low-cost while still demonstrating a realistic Migrate to Containers workflow.

Because Migrate to Containers supports multiple source types and UI flows can evolve, some steps are console-driven and require you to follow the official UI prompts for your chosen source environment. The infrastructure steps (project, VM, GKE, Artifact Registry) and deployment validation are fully executable via CLI.

Objective

Containerize a simple VM-hosted web workload and deploy it to GKE using artifacts produced by Migrate to Containers.

Lab Overview

You will: 1. Create a Google Cloud project environment (or use an existing sandbox project). 2. Create an Artifact Registry repository. 3. Create a small source VM with a web server. 4. Create a GKE cluster to host Migrate to Containers components (processing cluster). 5. Use Migrate to Containers (Cloud Console) to assess and migrate the VM into: – a container image stored in Artifact Registry – Kubernetes manifests 6. Deploy the migrated app to GKE. 7. Validate the deployment. 8. Clean up all resources to avoid ongoing cost.

Step 1: Set variables and confirm project/billing

Open Cloud Shell or your terminal with gcloud configured.

export PROJECT_ID="YOUR_PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

gcloud config set project "$PROJECT_ID"
gcloud config set compute/region "$REGION"
gcloud config set compute/zone "$ZONE"

Expected outcome – gcloud config list shows the correct project/region/zone.

Verification:

gcloud config list
gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)"

Step 2: Enable required APIs

Enable core APIs used by the lab.

gcloud services enable \
  compute.googleapis.com \
  container.googleapis.com \
  artifactregistry.googleapis.com \
  cloudresourcemanager.googleapis.com

Now enable the Migrate to Containers API.

The API name can differ from what you expect. In Cloud Console → APIs & Services → Library, search for Migrate to Containers and enable it. If you know the service name, you can enable it with gcloud services enable ....

Expected outcome – APIs enabled without errors.

Verification:

gcloud services list --enabled --format="value(config.name)" | sort | grep -E "compute|container|artifactregistry"

Step 3: Create an Artifact Registry repository for migration output

Create a Docker repository in Artifact Registry:

export AR_REPO="m2c-repo"

gcloud artifacts repositories create "$AR_REPO" \
  --repository-format=docker \
  --location="$REGION" \
  --description="Repo for Migrate to Containers lab"

Configure Docker authentication (for later pulls/pushes if needed):

gcloud auth configure-docker "${REGION}-docker.pkg.dev"

Expected outcome – Artifact Registry repo exists.

Verification:

gcloud artifacts repositories describe "$AR_REPO" --location="$REGION"

Step 4: Create a source VM (simple web workload)

Create a small Linux VM and install Nginx:

export VM_NAME="m2c-source-vm"

gcloud compute instances create "$VM_NAME" \
  --zone="$ZONE" \
  --machine-type="e2-medium" \
  --image-family="debian-12" \
  --image-project="debian-cloud" \
  --tags="m2c-source"

Allow SSH from your IP if needed (Cloud Shell usually works without extra rules). For HTTP testing, open port 80 (optional for the lab, but useful):

gcloud compute firewall-rules create allow-http-m2c-lab \
  --allow=tcp:80 \
  --target-tags="m2c-source" \
  --description="Allow HTTP to the source VM for testing" \
  --direction=INGRESS

SSH and install Nginx:

gcloud compute ssh "$VM_NAME" --zone="$ZONE" --command="sudo apt-get update && sudo apt-get install -y nginx && echo 'Hello from the SOURCE VM' | sudo tee /var/www/html/index.html"

Expected outcome – VM is running and serves a simple page.

Verification (get external IP and curl it):

export VM_IP="$(gcloud compute instances describe "$VM_NAME" --zone="$ZONE" --format='value(networkInterfaces[0].accessConfigs[0].natIP)')"
curl -s "http://${VM_IP}" | head

You should see Hello from the SOURCE VM.

Step 5: Create a GKE cluster (processing cluster)

Create a small GKE Standard cluster for running Migrate to Containers components.

Requirements can vary (privileged pods, specific node OS, etc.). If you hit issues, verify prerequisites in official docs and adjust.

export GKE_CLUSTER="m2c-processing-cluster"

gcloud container clusters create "$GKE_CLUSTER" \
  --zone="$ZONE" \
  --num-nodes=1 \
  --machine-type="e2-standard-4" \
  --release-channel="regular"

Get credentials:

gcloud container clusters get-credentials "$GKE_CLUSTER" --zone="$ZONE"
kubectl get nodes

Expected outcome – Cluster reachable and has nodes in Ready state.

Step 6: Install/enable Migrate to Containers on the cluster (Console-driven)

In Google Cloud Console:

Go to Migrate to Containers: https://cloud.google.com/migrate/containers (click Console entry points if shown in your UI)
Follow prompts to: – select your project – select the processing cluster (m2c-processing-cluster) – install required components into the cluster

During installation, the service typically creates namespaces and controllers.

Expected outcome – Installation completes successfully.

Verification (namespaces/pods): – The exact namespace name can differ by version. Look for migration-related namespaces.

kubectl get namespaces
kubectl get pods -A | grep -i -E "migrate|v2k|container" || true

If you see migration controllers and pods running, installation is likely correct.

Step 7: Register the source environment (Console-driven)

In the Migrate to Containers UI, add a source.

For VMware: you typically provide vCenter endpoint + credentials and ensure network reachability.
For cloud VMs: you typically select a supported source type and provide project/account context.

For this lab, attempt to register the Compute Engine VM you created if that source type is supported in your current Migrate to Containers release.

If Compute Engine is not available as a source type in your environment, use a supported source type available to you (for example, a VMware lab environment). Verify supported sources in official docs: https://cloud.google.com/migrate/containers/docs

Expected outcome – Source registers successfully and the VM becomes discoverable/eligible.

Verification: – In the UI, confirm the source status is healthy/connected and the VM appears in inventory.

Step 8: Run an assessment (Console-driven)

Select the VM workload and run an assessment (or equivalent “analyze” step).

Expected outcome – Assessment report completes. – You receive signals about containerization feasibility and any remediation items.

Verification: – Ensure assessment status is “Completed” (or similar). – Read the findings for ports, services, storage, and startup behaviors.

Step 9: Create and execute a migration plan (Console-driven)

Create a migration plan that outputs: – A container image to Artifact Registry (choose your m2c-repo) – Kubernetes manifests for deployment to GKE

Then run the migration.

Expected outcome – A container image is created and pushed to Artifact Registry. – Kubernetes manifests are generated and available for download/export.

Verification: List images in Artifact Registry:

gcloud artifacts docker images list "${REGION}-docker.pkg.dev/${PROJECT_ID}/${AR_REPO}" --include-tags

You should see at least one image created by the migration.

Step 10: Deploy the migrated workload to GKE

You have two common paths:

Path A (recommended for this lab): Use the manifests generated by Migrate to Containers and apply them.
Path B: If the UI provides a one-click deploy to the cluster, use it and then validate with kubectl.

Assuming you downloaded manifests to a local folder ./m2c-output/:

kubectl apply -f ./m2c-output/

If you need a namespace:

kubectl create namespace m2c-app || true
kubectl -n m2c-app apply -f ./m2c-output/

Expected outcome – Pods start in the target namespace. – A Service exposes the app (ClusterIP or LoadBalancer depending on manifest).

Verification:

kubectl get pods -A
kubectl get svc -A

If a LoadBalancer Service exists, wait for an external IP:

kubectl -n m2c-app get svc

If it’s ClusterIP only, use port-forward to test quickly:

kubectl -n m2c-app port-forward svc/YOUR_SERVICE_NAME 8080:80

Then:

curl -s http://127.0.0.1:8080 | head

You should see your app’s page (for this lab, something similar to the Nginx page or your custom content).

Step 11: Add basic Kubernetes health checks (optional but recommended)

Migrations often produce a baseline manifest. Add readiness/liveness probes once you know the app behavior.

Example (edit your Deployment):

kubectl -n m2c-app edit deployment YOUR_DEPLOYMENT_NAME

Add:

readinessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20

Expected outcome – Kubernetes can detect unhealthy pods and gate traffic until ready.

Verification:

kubectl -n m2c-app describe pod -l app=YOUR_LABEL

Validation

Use this checklist:

Artifact Registry contains migrated image bash gcloud artifacts docker images list "${REGION}-docker.pkg.dev/${PROJECT_ID}/${AR_REPO}"
Workload runs in GKE bash kubectl -n m2c-app get deploy,rs,pods,svc
Application responds – If LoadBalancer: curl http://EXTERNAL_IP – If port-forward: curl http://127.0.0.1:8080
Logs show normal operation bash kubectl -n m2c-app logs deploy/YOUR_DEPLOYMENT_NAME --tail=100

Troubleshooting

Issue: Migrate to Containers components not running in the cluster

Check cluster connectivity: bash kubectl get nodes
Check system pods: bash kubectl get pods -A
In the Console, verify installation status. Re-run installation if needed.

Issue: Source cannot be reached (common with on-prem)

Validate connectivity:
VPN/Interconnect status
VPC routes
Firewall rules (to vCenter/VM IPs/required ports)
DNS resolution
For on-prem VMware, confirm vCenter credentials and permissions.

Issue: Migration completes but app fails on GKE

Check pod logs: bash kubectl -n m2c-app logs POD_NAME --tail=200
Common causes:
Hard-coded IPs/hostnames that differ in Kubernetes
File paths or permissions
Missing environment variables/config files
App expects systemd/init behavior (containers don’t use systemd by default)

Issue: Service exposed but not reachable

If using LoadBalancer:
Wait for IP assignment.
Confirm firewall and Service type.
Prefer port-forward to isolate network issues: bash kubectl -n m2c-app port-forward svc/YOUR_SERVICE_NAME 8080:80

Cleanup

To avoid ongoing charges, delete resources.

Delete the GKE cluster:

gcloud container clusters delete "$GKE_CLUSTER" --zone="$ZONE" --quiet

Delete the VM:

gcloud compute instances delete "$VM_NAME" --zone="$ZONE" --quiet

Delete firewall rule:

gcloud compute firewall-rules delete allow-http-m2c-lab --quiet

Delete Artifact Registry repository (removes stored images):

gcloud artifacts repositories delete "$AR_REPO" --location="$REGION" --quiet

Expected outcome – All billable resources created in the lab are removed.

11. Best Practices

Architecture best practices

Use a dedicated processing cluster for migration tooling in production to isolate risk.
Keep processing and runtime clusters in the same region as Artifact Registry for performance and cost.
Plan a cutover strategy:
DNS-based cutover (TTL planning)
load balancer switch
blue/green or canary
For stateful apps, decide early:
use managed databases (Cloud SQL, AlloyDB) rather than containerizing DBs
use appropriate Kubernetes storage (PersistentVolumes) only when necessary

IAM/security best practices

Use least privilege:
separate roles for “migration operators” vs “cluster deployers”
Use dedicated service accounts for migration components.
Store source credentials in Secret Manager or a controlled secret store; rotate regularly.
Restrict who can push to Artifact Registry and who can deploy to production clusters.

Cost best practices

Treat migration tooling as ephemeral:
scale down node pools or delete processing clusters when not in use
Optimize image storage:
lifecycle policies (where supported)
delete old generated images after validation
Avoid external load balancers for every test deployment.

Performance best practices

After migration, tune:
CPU/memory requests and limits
JVM/app runtime settings
file I/O patterns (container storage differs from VM disks)
Use node pools for workload classes (general, compute-optimized, memory-optimized).

Reliability best practices

Add:
readiness and liveness probes
PodDisruptionBudgets
multiple replicas for stateless services
Use regional GKE clusters for production where appropriate.
Use gradual rollout techniques and rollback plans.

Operations best practices

Standardize:
logging formats and structured logs
metrics and SLOs
alerting for pod restarts, error rates, latency
Use GitOps or CI/CD to manage generated manifests and subsequent edits.

Governance/tagging/naming best practices

Label everything:
env=dev|test|prod
app=...
migration-wave=...
owner=team-...
Adopt a consistent naming convention:
m2c-proc-<region>-<wave>
app-<name>-<env>

12. Security Considerations

Identity and access model

Google Cloud IAM governs:
who can configure Migrate to Containers
who can access Artifact Registry images
who can create/modify GKE clusters
Kubernetes RBAC governs:
who can install controllers
who can apply manifests into namespaces
who can read secrets/configmaps/logs

Recommendation: – Separate duties between: – migration operators – platform operators – app deployers

Encryption

Data at rest:
Artifact Registry is encrypted at rest by default (Google-managed keys); consider CMEK where required.
Persistent disks and other storage are encrypted at rest.
Data in transit:
Use TLS for API calls.
Use VPN/Interconnect encryption for hybrid paths (VPN is encrypted; Interconnect requires MACsec in some options—verify).

Network exposure

Prefer private GKE clusters for production.
Use internal load balancers for internal apps.
Restrict inbound access using:
firewall rules
Cloud Armor (if applicable)
identity-aware access patterns (beyond the scope of this tutorial)

Secrets handling

Do not store source credentials in plain text in scripts or Git.
Use Secret Manager and/or Kubernetes Secrets with encryption and RBAC controls.
Rotate credentials after migration waves.

Audit/logging

Enable and review:
Cloud Audit Logs for admin actions
GKE audit logs (if enabled) for cluster-level actions
Keep an audit trail of:
who ran which migration
what artifacts were produced
who deployed to production

Compliance considerations

Data residency: keep clusters and Artifact Registry in approved regions.
Least privilege and separation of duties are often audit requirements.
Retention: set log and artifact retention policies aligned with compliance rules.

Common security mistakes

Over-permissioned service accounts (project-wide Editor on production).
Leaving migration processing clusters running with broad access after the program ends.
Exposing migrated services publicly by default via external LoadBalancers.
Migrating applications with embedded credentials in config files inside the VM filesystem.

Secure deployment recommendations

After migration, immediately improve posture:
externalize config and secrets
enforce image scanning and admission policies
run as non-root where possible (may require refactoring)
apply network policies (Kubernetes NetworkPolicy) if supported by your cluster setup

13. Limitations and Gotchas

This section is intentionally candid. Validate specifics in the official docs and test with representative workloads.

Known limitations (typical)

Not all VM workloads are good container candidates (systemd-heavy services, kernel dependencies, privileged operations).
Containerized apps may behave differently due to:
filesystem layering
different init process
different networking model

Quotas

You may hit:
GKE node quota limits
IP address exhaustion in subnets
Load balancer quotas
Artifact Registry rate/storage quotas

Regional constraints

GKE and Artifact Registry are regional.
Cross-region image pulls increase latency and can increase costs.

Pricing surprises

Leaving GKE clusters running (especially processing clusters) becomes the biggest cost driver.
LoadBalancer Services can add recurring costs.
Logging ingestion can grow quickly in busy clusters.

Compatibility issues

Some apps assume:
fixed IP addresses
local disk persistence across restarts
OS services or cron behavior that differs in containers
State: mapping VM disks to Kubernetes PersistentVolumes needs careful design.

Operational gotchas

“Lifted” container images can be large and include unnecessary packages.
Generated manifests are a baseline; you must add:
resource requests/limits
probes
security context
proper service exposure and ingress configuration

Migration challenges

Network dependencies are often the hardest part (DNS, firewall, service discovery).
Cutover planning (traffic switching and rollback) is frequently underestimated.
Teams may treat this as a “one-click conversion”; in reality, it’s a modernization project.

Vendor-specific nuances

GKE private clusters require deliberate configuration for Google API access (Private Google Access, NAT).
Artifact Registry region selection matters for both cost and compliance.

14. Comparison with Alternatives

The “right” modernization path depends on workload fit, operational maturity, and desired end state.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Migrate to Containers (Google Cloud)	VM-to-Kubernetes re-platforming	Structured conversion workflow; artifacts for GKE; good stepping stone to modernization	Not a magic rewrite; may require remediation and tuning; requires Kubernetes operational capability	You want VM → container on GKE with a repeatable migration process
Migrate to Virtual Machines (Google Cloud)	Lift-and-shift VM migration	Fast VM moves with minimal app changes	Doesn’t modernize the runtime; you still manage VMs	You need fast migration first, modernization later
Manual containerization (Dockerfile + K8s)	Teams with app expertise and time	Maximum control; smaller images; best-practice containers	Time-consuming; inconsistent across teams; higher skill requirement	You can invest engineering effort for optimized, maintainable containers
Google Cloud Run	Stateless HTTP services; event-driven workloads	Fully managed; simple ops; scales to zero	Not ideal for complex stateful apps; some platform constraints	Your app can run as a stateless container and you want minimal ops
Anthos / platform modernization programs	Large enterprises needing hybrid governance	Policy, fleet management, consistency across clusters	Higher complexity and organizational change	You need multi-cluster governance and standardized platform operations
AWS App2Container (AWS)	VM-to-container on AWS ecosystems	Integrated with AWS tooling	AWS-centric; different target runtime	Your primary target is AWS and you want AWS-native tooling
Azure Migrate + container approaches (Azure)	Migration within Azure	Strong ecosystem integrations	Tooling and workflows differ; may require more manual steps	Your primary target is Azure
Open-source VM-to-K8s tools (varies)	Experimentation and custom pipelines	Flexible, customizable	Less integrated; you own support and maintenance	You need maximum customization and accept operational ownership

15. Real-World Example

Enterprise example: VMware data center exit with phased modernization

Problem
A financial services company runs 400 Linux VMs on VMware.
Hardware refresh is due in 12 months.
Teams want Kubernetes for standardized ops, but rewriting is too slow.
Proposed architecture
Hybrid connectivity: on-prem → Google Cloud using Interconnect (or VPN initially)
Dedicated GKE processing cluster for Migrate to Containers
Separate GKE runtime clusters per environment (dev/test/prod)
Artifact Registry in the same region as runtime clusters
Central logging/monitoring and strict IAM + audit controls
Why Migrate to Containers was chosen
Enables VM → container re-platforming for a subset of apps quickly.
Provides repeatable workflows across migration waves.
Fits a controlled, audited enterprise approach.
Expected outcomes
30–40% of workloads moved to GKE within 6–9 months (the container-friendly portion).
Reduced VM sprawl and standardized release management.
Clear backlog for apps requiring refactoring or that remain as VMs temporarily.

Startup/small-team example: Consolidating VM-hosted internal tools onto GKE

Problem
A startup runs multiple small tools (admin UI, webhook receiver, metrics tool) on separate VMs.
VM patching and deployments are manual.
Proposed architecture
One regional GKE cluster for runtime
Migrate to Containers used to containerize a few existing VM apps as a quick win
Artifact Registry for images
GitHub Actions for deployments (post-migration)
Why this service was chosen
Gets apps onto Kubernetes quickly without requiring every team member to become a container expert immediately.
Expected outcomes
Fewer VMs and simplified deployment operations.
A stepping stone to later adopt Cloud Run for some services once they are stateless and simplified.

16. FAQ

1) Is Migrate to Containers the same as “Migrate for Anthos”?

Migrate to Containers is the current Google Cloud product name commonly associated with what was previously branded as Migrate for Anthos. Confirm the latest naming and scope in official docs: https://cloud.google.com/migrate/containers/docs

2) Does Migrate to Containers migrate my database too?

Typically, it focuses on VM-to-container conversion for application workloads. Databases are usually better migrated to managed services (e.g., Cloud SQL) or handled with dedicated database migration tooling. Verify supported scenarios in the docs.

3) Does it work for Windows VMs?

Windows containerization has constraints and support varies by product version. Verify current support matrices in official documentation.

4) Can I deploy to Kubernetes other than GKE?

The artifacts are Kubernetes-based, but the service is designed around Google Cloud workflows and GKE. Portability depends on generated manifests and your target Kubernetes environment.

5) Do I need a dedicated GKE cluster for migration processing?

For production, it’s a common best practice to isolate migration tooling. For labs or small migrations, some teams use a shared cluster—but isolation is safer.

6) How “automatic” is VM-to-container conversion?

It can automate a significant portion, but most real apps need follow-up work: – configs and secrets externalization – probes and resource tuning – networking/service discovery adjustments – storage redesign for stateful components

7) Will the migrated container be optimized?

Often the first output is functional but not minimal. Plan time to reduce image size, remove unused packages, and adopt best practices.

8) What’s the difference between Migrate to Containers and Migrate to Virtual Machines?

Migrate to Virtual Machines: move VMs with minimal change (lift-and-shift).
Migrate to Containers: convert VM workloads into containers and Kubernetes artifacts (re-platform to Kubernetes).

9) Can I use this for a “strangler” migration?

Yes. You can migrate one component/service while leaving others on VMs, as long as networking and dependencies are handled carefully.

10) How do I handle secrets after migration?

Move secrets out of the VM filesystem into: – Secret Manager + CSI driver (common pattern), or – Kubernetes Secrets with tight RBAC and encryption options. Avoid embedding secrets in container images.

11) What networking is required for on-prem VMware sources?

You generally need: – routable connectivity (VPN/Interconnect) – firewall openings to required endpoints/ports – DNS resolution Exact requirements depend on connector design; verify in official docs.

12) Does it support private GKE clusters?

Often yes, but private clusters require careful setup for API access and egress (NAT, Private Google Access). Validate the official guidance.

13) How do I estimate migration effort?

Do an assessment on representative apps and categorize: – easy (stateless) – moderate (some config/storage changes) – hard (system dependencies, stateful, complex networking) Use that to forecast waves and staffing.

14) How do I roll back if the containerized app fails?

Keep the VM running during initial cutover and switch traffic back via DNS/load balancer if needed. Plan rollback as part of your runbook.

15) What’s the biggest reason migrations fail?

Underestimating: – dependency mapping (DNS, service discovery) – state/storage redesign – operational readiness for Kubernetes (monitoring, alerts, on-call procedures)

17. Top Online Resources to Learn Migrate to Containers

Resource Type	Name	Why It Is Useful
Official product page	Google Cloud – Migrate to Containers	High-level overview and entry points to docs: https://cloud.google.com/migrate/containers
Official documentation	Migrate to Containers documentation	Authoritative setup, workflows, supported sources, and requirements: https://cloud.google.com/migrate/containers/docs
Migration portfolio	Google Cloud Migration	Broader context and related services: https://cloud.google.com/solutions/migration
Migration program tracking	Migration Center	Helps organize and track migrations at scale: https://cloud.google.com/migration-center
Pricing (core dependencies)	GKE pricing	Cluster and control plane cost model: https://cloud.google.com/kubernetes-engine/pricing
Pricing (artifacts)	Artifact Registry pricing	Image storage and request costs: https://cloud.google.com/artifact-registry/pricing
Pricing tool	Google Cloud Pricing Calculator	Build region-specific estimates: https://cloud.google.com/products/calculator
Observability	Cloud Operations suite	Logging/monitoring patterns for GKE: https://cloud.google.com/products/operations
Kubernetes learning	GKE documentation	Deploy, secure, and operate workloads: https://cloud.google.com/kubernetes-engine/docs
Community learning	Google Cloud Tech (YouTube)	Talks and demos; verify relevance to current releases: https://www.youtube.com/@googlecloudtech

18. Training and Certification Providers

The following training providers are listed neutrally as requested. Offerings, quality, and certification alignment should be verified on each website.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	DevOps, Kubernetes, cloud operations, migration-adjacent skills	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps fundamentals, SCM, CI/CD, cloud basics	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud engineers, operations teams	Cloud operations, reliability, tooling	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs, operations engineers	SRE practices, monitoring, incident management	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams, automation engineers	AIOps concepts, automation, observability	Check website	https://www.aiopsschool.com/

19. Top Trainers

These are provided as trainer-related sites/platforms as requested. Validate current services and offerings directly.

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training and guidance (verify current focus)	Beginners to intermediate	https://rajeshkumar.xyz/
devopstrainer.in	DevOps and Kubernetes training (verify course catalog)	DevOps engineers, students	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps support/training resources (verify offerings)	Teams needing short-term help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and enablement (verify services)	Ops/DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

Listed neutrally as requested. Validate service portfolios, references, and scope directly with each company.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact offerings)	Migration planning, DevOps enablement, platform delivery	Migration factory design, GKE platform setup, CI/CD and GitOps enablement	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and training services	Skills uplift + implementation support	Kubernetes adoption roadmap, migration runbooks, SRE practices rollout	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify portfolio)	Automation, cloud ops, deployment pipelines	CI/CD modernization, IaC implementation, operational readiness for migrations	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To use Migrate to Containers effectively, you should understand:

Linux fundamentals
processes, services, filesystem permissions
networking basics (ports, DNS, routing)
VM operations
how apps start on boot, service managers, logs
Containers
images vs containers, registries, basic Docker concepts
Kubernetes basics
Pods, Deployments, Services, Ingress
ConfigMaps and Secrets
Google Cloud foundations
projects, IAM, VPC
GKE fundamentals
Artifact Registry

What to learn after this service

Once you can migrate workloads, focus on making them production-grade:

Kubernetes operations
autoscaling (HPA/VPA where applicable)
workload identity patterns
network policies (where applicable)
Observability
SLOs, alerting, tracing
Security
image scanning and policy enforcement
hardened pod security (non-root, minimal privileges)
Modernization beyond re-platforming
refactor to managed services (Cloud SQL, Memorystore)
service mesh or gateway patterns (where appropriate)
CI/CD + GitOps standardization

Job roles that use it

Cloud migration engineer
Platform engineer (GKE)
DevOps engineer
SRE
Cloud solutions architect
Security engineer (container and platform security)

Certification path (if available)

Google Cloud certifications that commonly align with this work (verify latest tracks on Google Cloud certification site): – Associate Cloud Engineer – Professional Cloud Architect – Professional Cloud DevOps Engineer

Certification hub: https://cloud.google.com/learn/certification

Project ideas for practice

Migrate a simple VM-hosted web app and add:
readiness/liveness probes
resource requests/limits
a CI pipeline to redeploy images
Migrate a VM app that depends on a database and:
move DB to Cloud SQL
implement private connectivity and secrets rotation
Build a “migration wave” dashboard:
track apps, owners, cutover dates, rollback plans
store manifests in Git and enforce reviews

22. Glossary

Artifact Registry: Google Cloud service for storing container images and artifacts with IAM control and integrations.
Cutover: The moment you switch production traffic from the old environment (VM) to the new environment (GKE).
GKE (Google Kubernetes Engine): Managed Kubernetes service on Google Cloud.
Hybrid connectivity: Network connectivity between on-prem environments and cloud (VPN/Interconnect).
Ingress: Kubernetes resource that manages external access to services, typically HTTP(S).
Kubernetes manifest: YAML definitions of Kubernetes resources (Deployments, Services, etc.).
Lift-and-shift: Moving a workload with minimal changes (VM to VM), typically not changing architecture.
Migration wave: A batch of workloads migrated together under a coordinated plan.
Namespace: Kubernetes mechanism to isolate resources within a cluster.
Re-platforming: Moving to a new runtime/platform with limited code changes (VM → container on Kubernetes).
Rollback: Reverting to the previous stable state after a failed deployment or cutover.
Service account: An identity used by applications or controllers to call Google Cloud APIs.
Source environment: Where the current VM workload runs (on-prem VMware, cloud VMs, etc.).
Target runtime: Where the migrated workload runs (typically GKE).

23. Summary

Migrate to Containers on Google Cloud is a practical Migration service for modernizing VM-based applications by converting them into containers and Kubernetes deployment artifacts, usually targeting GKE. It matters because it helps teams move faster than full rewrites while still making meaningful progress toward standardized, scalable operations.

From an architecture perspective, plan for a processing cluster, solid network connectivity to sources, and a secure artifact supply chain (Artifact Registry + IAM). From a cost perspective, the biggest drivers are usually GKE cluster runtime, artifact storage, load balancers, and networking—so treat migration infrastructure as ephemeral when possible. From a security perspective, prioritize least privilege IAM, secure credential handling, and auditability.

Use Migrate to Containers when you want a repeatable VM-to-Kubernetes path and you’re ready to operate Kubernetes. If you only need VM lift-and-shift, consider Migrate to Virtual Machines instead. Next, deepen your skills in GKE operations, observability, and post-migration hardening so migrated apps become truly production-ready on Kubernetes.

Category

1. Introduction

What this service is

One-paragraph simple explanation

One-paragraph technical explanation

What problem it solves

2. What is Migrate to Containers?

Official purpose

Core capabilities

Major components (conceptual)

Service type

Scope (regional/global/zonal)

How it fits into the Google Cloud ecosystem

3. Why use Migrate to Containers?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose it

When they should not choose it

4. Where is Migrate to Containers used?

Industries

Team types

Workloads

Architectures

Real-world deployment contexts

Production vs dev/test usage

5. Top Use Cases and Scenarios

1) VM-based web app to GKE (stateless)

2) Standardizing deployments across teams

3) Data center exit for VMware estates

4) Moving legacy monoliths into a Kubernetes platform (first step)

5) Enabling Kubernetes-native operations (rolling updates, probes)

6) Consolidating multiple VMs into shared GKE clusters

7) Building a migration factory (waves and playbooks)

8) Pre-refactor step before moving to Cloud Run or microservices

9) Improve security posture through container scanning and policy

10) Hybrid operation during transition (dependencies remain on VMs)

6. Core Features

1) VM workload assessment

2) Automated container image generation

3) Kubernetes manifest generation

4) Migration orchestration via a GKE-based processing environment

5) Integration with Artifact Registry (typical pattern)

6) Repeatable migration runs (migration waves)

7) Support for hybrid connectivity patterns

8) Kubernetes-native operational alignment

9) Separation of “migration tooling” from “runtime clusters” (common best practice)

10) IAM and audit integration (Google Cloud controls)

7. Architecture and How It Works

High-level service architecture

Request/data/control flow (typical)

Integrations with related services

Dependency services

Security/authentication model

Networking model

Monitoring/logging/governance considerations

Simple architecture diagram (Mermaid)

Production-style architecture diagram (Mermaid)

8. Prerequisites

Account/project requirements

Permissions / IAM roles

Billing requirements

CLI/SDK/tools needed

Region availability

Quotas/limits

Prerequisite services

9. Pricing / Cost

Current pricing model (how to think about it)

Pricing dimensions (most common cost components)

Free tier (if applicable)

Cost drivers (what makes it expensive)

Hidden or indirect costs to plan for

Network/data transfer implications

How to optimize cost

Example low-cost starter estimate (non-numeric)

Example production cost considerations (non-numeric)

10. Step-by-Step Hands-On Tutorial

Objective