Google Cloud has open-sourced GKE agentic migration, an agent plugin built around a local Model Context Protocol (MCP) server that translates AWS EKS infrastructure and Kubernetes manifests into GKE landing zones through automated pull requests. The tool targets enterprises standardizing on Google Kubernetes Engine (GKE) for critical and AI-driven workloads, whose platform teams currently face slow manual refactoring of infrastructure-as-code, cloud-specific architectural differences, and custom translation scripts when moving from EKS.

The announcement frames the problem around four governance failures. Generic LLM assistants hallucinate infrastructure code, use deprecated API fields, or omit security rules, shifting the bottleneck from writing code to debugging it. Legacy migration tools connect directly to live clusters and deploy via API calls, bypassing Git as the true source of truth, breaking CI/CD pipelines, and making rollbacks difficult. Long-running, multi-week migrations lose context when platform engineers hand off to application developers. Existing tooling such as Velero captures AWS-specific configurations like ALBs without translating them for Google Cloud, while reverse-engineering tools generate flat configurations that strip away the developer’s original logical intent.

The plugin addresses these challenges with four design principles. Hybrid verification means LLM workers author Terraform and Kubernetes YAML, while deterministic transforms handle exact mappings such as Workload Identity annotations and image registries; every AI-generated translation is submitted to strict deterministic validations, including terraform validate and manifest contracts, before being presented to a human. GitOps-native workflows never apply changes directly to a live cluster; the plugin reads the source of truth, generates the target state, and opens a pull request so all changes route through standard human-in-the-loop CI/CD review. Translation is separated from transport: the plugin intentionally does not move stateful data and instead generates contextual runbooks for SLA-backed tools like Database Migration Service and Storage Transfer Service. Finally, multi-persona state management persists long-running migration state, enabling protected asynchronous handoffs: platform engineers establish the baseline landing zone, and application developers independently join from their own machines within permission-isolated folders.

Under the hood, the migration lifecycle is a state graph of executable functions that systematically passes context down the chain. It starts with deep EKS repository discovery: the plugin clones the source Git repository or performs a live cluster scan, programmatically indexes source manifests, maps dependencies, and builds an inventory. Assessment and blocker governance produces a readiness report of architectural incompatibilities; every blocker must have an assigned owner and target resolution date, and the platform engineer signs off on migration boundaries before translation begins. Landing zone design scaffolds foundational Google Cloud Terraform modules covering VPC, subnets, GKE cluster, and org policies based on explicit platform decisions such as GKE Autopilot versus GKE Standard. AI-assisted cloud translation handles proprietary shifts, including AWS IRSA to Workload Identity, ALB ingress to the Gateway API, and Karpenter node claims to GKE Node Auto Provisioning or Custom Compute Classes. Generated modules are then compiled and verified offline with terraform validate, manifest structure checks, and output contracts, and the finalized configuration is opened as a pull request for review.

The tool is packaged as an open-source agent plugin with no custom CLI binaries and no central control plane, so teams collaborate through their existing development harness. The article positions it as a way to turn migrations from disjointed refactoring exercises into predictable, AI-assisted, reviewable GitOps workflows, and directs readers to star or clone the GitHub repository, run the onboarding guide against a sample EKS repository, and share feedback through the Google Cloud Community. A customer quote from Persistent EVP Rahul Shrivastava emphasizes that deterministic guardrails, structured state persistence, multi-persona boundaries, and human approval gates are what make the migration factory acceptable to large enterprise clients.