Moving a Kubernetes application from Amazon EKS to Google GKE is not a search-and-replace job. Infrastructure code, identity, ingress, storage, and deployment habits must all line up. Google’s new open-source agentic migration project proposes a reviewable path through that work—but deliberately stops short of moving the live data or applying infrastructure for you.
What Google released
On September 24, 2026, Google Cloud introduced GKE agentic migration, an open-source plugin built from agent skills and a local Model Context Protocol (MCP) server. It reads an EKS estate from checked-in infrastructure-as-code and Kubernetes manifests, then helps translate that source into a GKE landing zone and GKE-native workload definitions. The project repository describes support for Antigravity and Claude Code as agent harnesses.
The central design choice is to let a language model author candidate Terraform and YAML while deterministic tools handle validation and exact mappings. Google lists checks such as terraform validate manifest contracts and output contracts before generated changes are presented. The agent delivers the resulting configuration as a pull request for human review. The agent does not run terraform apply or modify the source EKS estate; an optional live EKS discovery scan is read-only.
The translation that actually needs engineering judgment
Some AWS constructs have a recognizable GKE destination, but not a one-to-one replacement. Google’s examples include IAM Roles for Service Accounts, Workload Identity Federation for GKE, ALB ingress to Gateway API resources, and Karpenter node claims to GKE node-provisioning options. A generated mapping still has to be evaluated against the application’s permissions, traffic, latency, and cost requirements.
The project separates migration-admin, platform-engineer, and application-developer roles. It keeps a state ledger so a multi-week migration can resume and hand off across people. The platform team can establish the landing zone and review blockers; application owners can translate their components within narrower permissions. This approach is more specific than asking a general chatbot to rewrite manifests without a shared record of decisions.
The work it intentionally leaves to you
The plugin does not transport stateful data. For managed databases, object storage, secrets, and similar services, it produces contextual runbooks and gates dependent workloads until you handle the migration through appropriate tools. It is also not an application-source-code refactoring service or a replacement for network design. “Agentic migration” here means assisted configuration translation and coordinated review, not an autonomous cutover.
Before piloting, inventory source repositories and live dependencies, choose a low-risk workload, and decide who approves each generated pull request. Run the offline validations, compare the target design with a manually reviewed migration plan, and test rollback and data cutover separately. The project’s onboarding guide is the right place to check current prerequisites rather than copy a one-line prompt into a production account.
A useful pattern beyond Kubernetes
The release illustrates a more disciplined way to use agents around infrastructure: model-generated proposals, deterministic validation, permission-separated roles, and human approval at the merge boundary. Our guide to private MCP access covers a different part of the tool-access boundary, while the Copilot sandboxing guide explains why local agent execution controls matter. Neither is a migration plan on its own, but both are relevant when choosing the environment in which an agent will inspect infrastructure code.
Google has published the code and workflow; it has not published a universal migration success rate. Treat the project as an engineering accelerator to evaluate against a representative workload, not a guarantee that a complex EKS estate will transfer safely without platform and data-migration work.
