Google’s October 5 Cloud Modernize announcement lists an EKS-to-GKE Migration Agent in public preview. The linked repository sets a concrete limit: the agent never runs Terraform apply. That leaves a consequential gap between preparing a migration proposal and authorizing its deployment.
In our assessment, that boundary should shape the evaluation. The central question is whether the generated changes give a team enough evidence to approve the move—and who takes responsibility when configuration review becomes a production decision.
A preview label with an earlier technical history
The October 5 announcement combines existing modernization tools and new capabilities into a portfolio. Google highlights discovery, configuration mappings, human approval gates and in-memory credential security for the agent.
Google’s September 24 technical description had already presented the linked open-source plugin. The reviewed official pages do not reconcile that description with October’s public-preview label. Whether the later announcement reflects packaging, access changes or the same plugin remains unresolved; it should not be treated as a first technical launch or general availability.
For evaluators, this creates a straightforward question: which artifact is under review? A portfolio announcement and a repository description should not become interchangeable evidence without clarity about the build being tested.
What the agent prepares—and where it stops
Google’s technical post describes agent skills and a local MCP server for repository inspection or EKS scanning, dependency inventory, blocker discovery and Terraform scaffolding. Examples include IRSA-to-Workload Identity, ALB-to-Gateway API and Karpenter-to-GKE provisioning translations. Google describes local validation and pull-request review, while excluding direct live-cluster changes and stateful data transport.
The repository README adds explicit boundaries: no source EKS modification, an optional read-only live scan and a GCS state ledger. Translation covers specified Kubernetes objects and infrastructure formats. Application refactoring and managed services including RDS, S3 and EFS are excluded; the README describes manual runbooks and gates workload migration until data has moved.
Those are genuine controls over the agent’s authority. They do not prove that a proposed target configuration is correct. A reviewer still needs to distinguish an intentional platform choice from an assumption made during translation, and a documented exclusion from a requirement that has actually been satisfied.
Two mappings that need specific evidence
Identity requires a permission decision
Google’s Workload Identity Federation documentation describes fine-grained Google Cloud API access without service-account key files. Enabling federation does not itself grant IAM permissions. The documentation also addresses matching identities in clusters sharing a project workload identity pool, and service-account impersonation where direct federation has API limitations.
In our assessment, an identity proposal deserves review as an access-design decision. Which principal receives which role? Is the intended separation between workloads preserved? A generated mapping should explain the proposed answer, while acceptance should depend on evidence for the required access boundary. Target-platform documentation does not verify the agent’s IRSA conversion or establish one-to-one AWS permission equivalence.
Ingress guidance offers narrow context
Google’s Ingress-to-Gateway guide, updated October 6 UTC, covers Ingress NGINX migration, not AWS ALB parity. It describes creating Gateway and HTTPRoutes, testing the new address, shifting DNS and retaining the old Ingress until traffic ceases. It lists partial parity for prefix-replacement URL rewrites and external authentication, which may require a custom approach.
That context helps frame an evaluation; it cannot certify an ALB translation. Review should ask for evidence tied to the workload’s actual routing, rewrite and authentication requirements. The acceptance question is whether those requirements have been demonstrated, rather than whether the output resembles an appropriate target resource.
Our assessment: the cutover remains a team decision
A useful pilot would start with a narrow workload and an acceptance plan written before reviewing the generated proposal. That order matters: it prevents the proposal from defining its own success criteria. Reviewers should know what the workload must do before deciding whether the changes satisfy it.
The proposal should make unresolved decisions visible. For each important change, a team could record the intended behavior, the person accepting it and the evidence required. An unanswered question would then remain an open decision, rather than disappear inside an approved pull request.
Keep responsibility explicit:
- Name reviewers for identity, traffic, storage and provisioning choices.
- Assign data readiness separately from configuration approval.
- Define workload evidence required before deployment and traffic switching.
- Identify who authorizes the cutover and who can stop it.
This is editorial guidance, not a claim about additional agent features. Its purpose is to separate three judgments: whether the proposal is coherent, whether the target workload meets its requirements and whether the team is ready to move. Approval of one should not silently stand in for the others.
A runbook also needs an owner and completion evidence. Instructions for excluded work are useful, but their existence cannot establish data readiness. The final decision-maker should be able to see which prerequisites are complete, which remain uncertain and what would justify withholding approval.
What remains unverified
The documents reviewed for this article establish no independent benchmark, verified end-to-end customer result or complete workload compatibility matrix. Detailed preview eligibility, supported versions, pricing and service levels also remain unspecified.
The agent therefore warrants evaluation as a preparation workflow. Its controls create space for human judgment; workload evidence must support that judgment. The cutover remains a decision someone must own.
Related reading: Google Cloud U4: What Low-Latency Teams Can Actually Deploy.
Sources
Cloud Modernize announcement; agentic migration description; repository README; GKE identity documentation; Ingress NGINX migration context. Agent capabilities are vendor-reported, without independent testing.
Image disclosure: Featured and inline images are AI-generated editorial concepts, not Google Cloud product images or interfaces.