Migrate to Containers, formerly Migrate for Anthos (M4A), moves applications from virtual machines into containers without requiring a rewrite or access to source code. It captures the application, runtime dependencies and configuration, then produces artifacts for deployment on GKE, Anthos or a Kubernetes-conformant distribution. Containerization can be a first modernization step rather than an immediate move to microservices. section 15.0 section 15.3.2
Good candidates include stateless web frontends, multitier applications, middleware and bursty workloads—especially when a rewrite is too costly or dependencies are poorly understood. Assess data and external dependencies before choosing a workload: a complex application is not made independent merely by placing it in a container. section 15.2
A migration has three operational stages:
- Set up a processing cluster, define the VM source and prepare a landing zone for identity, networking, security and billing. Supported sources in the described workflow include VMware, major cloud VM platforms and bare metal; check current support before planning a migration. section 15.3.1
- Create and review a migration plan. Generate a container image, Dockerfile, deployment YAML and storage artifacts; test the result before deploying it. VM-specific components that Kubernetes replaces are left out, while storage is mapped to persistent volumes. section 15.3.1 section 15.3.2
- Optimize after deployment: connect generated artifacts to CI/CD, preserve useful service naming, restrict traffic between tiers with NetworkPolicy and configure dependencies that were not migrated automatically. NFS mounts, for example, require manual persistent-volume configuration. section 15.5 section 15.8
Compute Engine web server to GKE
For a CLI migration, create a processing cluster and grant it the required permissions. Configure the Compute Engine source, then run `migctl migration create my-migration --source http-source --vm-id http-server-demo --intent Image`. Review the plan, generate and retrieve artifacts, and apply the generated deployment YAML with `kubectl`. Check the resulting Service before directing traffic to it. The demonstration also opens HTTP access from `0.0.0.0/0`; do not copy that firewall rule into production without reviewing the exposure. section 15.4.2
migctl migration create my-migration --source http-source --vm-id http-server-demo --intent Image
Shows the CLI command that binds a named migration to its source VM and selects image-generation intent. section 15.4.2
The Google Cloud console provides a comparable plan-and-artifact workflow, but the described UI supports Google Cloud clusters rather than Anthos on AWS or VMware. Windows IIS migration is also described, using a Compute Engine VM as its source; unlike the Linux example, its retrieved artifacts are used to build and push an image. Verify platform support against the version being deployed. section 15.4.3 section 15.4.4
