EKS-to-GKE Migration Agents: What They Automate (and What They Don't)

Google announced Google Cloud Modernize on October 5, 2026, "an end-to-end transformation portfolio to help enterprises collapse multi-year roadmaps with the power of AI," bringing Migration Center, Google Cloud VMware Engine, Google Cloud Mainframe Modernization and the new EKS-to-GKE Migration Agent under one roof (Google Cloud blog). Within a day, platform teams will hear a version of the same question in a planning meeting: can we cut the roadmap in half?

We've run these programs. Here's the honest read: an EKS to GKE migration follows the same pattern every time. Some months genuinely disappear. Others don't move at all, and those have always decided whether a migration lands on time. The useful work this week is mapping which phases the agent touches and which ones your team still owns.

What the portfolio actually automates

Start with what Google itself says, because the scoping is unusually candid.

The EKS-to-GKE Agentic Migration is in Public Preview. It automates "discovery, Kubernetes manifest translations, storage and network mappings across clouds," with human-in-the-loop approval gates and in-memory credential handling (Google Cloud blog). It was announced separately on September 24, 2026 as an open-source agent plugin, "a compilation of agent skills and a local Model Context Protocol (MCP) server," that translates AWS EKS infrastructure-as-code and Kubernetes manifests into GKE landing zones through automated pull requests (GKE agentic migration).

The translation list is specific, and it targets exactly the proprietary edges that make a cross-cloud move tedious: AWS IRSA (the EKS way of letting a pod assume an IAM role) to Workload Identity, ALB ingress (Amazon's load-balancer-backed entry point for cluster traffic) to the Gateway API, and Karpenter node claims (EKS's just-in-time node provisioner) to GKE Node Auto Provisioning or Custom Compute Classes. Outputs get validated offline through terraform validate and manifest structure checks (GKE agentic migration).

Alongside it, Modernization Hub is "a newly launched in-console experience where developers and architects can analyze source code, map dependencies, and accelerate modernization for Java, .NET, and mainframe applications" (Google Cloud blog). The Agentic Quick Estimator in Migration Center, which is GA, converts VMware inventory exports such as RVTools into Compute Engine TCO projections, with a chat interface for testing assumptions like multi-region footprints or BYOL versus pay-as-you-go. Google says that "condenses weeks of spreadsheet modeling into a defensible business case in minutes" (Google Cloud blog).

So: inventory, dependency mapping, IaC and manifest translation, offline validation, business-case modeling. That's a real compression of real grind, and still only part of the program.

The phases that don't compress

Google's own lifecycle description draws the line for you. Four things stay human-owned.

• Landing zone design. The plugin "scaffolds the foundational Google Cloud Terraform modules (VPC, subnets, GKE cluster, org policies) based on explicit platform decisions (such as GKE Autopilot vs. GKE Standard)" (GKE agentic migration). Explicit platform decisions means yours.
• Identity and network boundaries. Google's landing zone guidance frames the foundation as a set of human decisions across onboarding identities, resource hierarchy, network design, and security, and notes a landing zone "is often a prerequisite to deploying enterprise workloads in a cloud environment" (landing zones). The resource-hierarchy guidance presents three design options, environments, regions and subsidiaries, or an accountability framework, which Google notes most organizations combine into a hybrid at different levels of the hierarchy, chosen by answering questions about policy variance and team autonomy (resource hierarchy).
• Data gravity. The agent "automates the tedious logic of architectural translation, but it intentionally does not transport stateful data," generating runbooks that point teams to SLA-backed services such as Database Migration Service or Storage Transfer Service (GKE agentic migration).
• Blocker remediation. The agent produces a readiness report of architectural incompatibilities, and "before design can unlock, every blocker must have an assigned owner and target resolution date," with the platform engineer signing off on migration boundaries before translation begins (GKE agentic migration).

That last gate is the most instructive design choice in the whole release. The agent won't proceed until a human has named owners and dates. Google has essentially encoded the thing that kills migrations, unassigned architectural debt, as a hard stop.

Fast translation amplifies whatever design preceded it

Here's the risk nobody will raise in the planning meeting. If the landing zone is scaffolded from decisions your team supplies, an estate with an unresolved hierarchy, a fuzzy identity model, or a network design inherited by accident gets reproduced in the target cloud faster than before. Speed of translation multiplies design quality in both directions.

Google is blunt about the adjacent failure mode: "Raw models hallucinate non-existent resource properties, drop critical network or identity configurations, and lose context across interdependent files," with auditing and debugging time "cannibalizing any upfront speed gains" (GKE agentic migration). The plugin's guardrails, it "never applies changes directly to a live cluster," routing everything through pull requests and existing CI/CD review, "No 'ClickOps'," exist because that failure mode is well understood.

terraform validate passing is not the same as the generated estate meeting your policy. A generative step wants a deterministic reviewer, so deterministic checks belong on the other side of that pull request: CIS benchmark coverage across identity and access management, storage and encryption, and network security, run continuously rather than once at cutover.

Discount the roadmap-collapse language, carefully

Two pieces of outside evidence are worth holding in view, and both need honest handling.

Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027. The reasons cited: escalating costs, unclear business value, or inadequate risk controls. Gartner also warned specifically about "agent washing" (Gartner). METR ran a randomized trial of 16 experienced open-source developers across 246 real tasks. Developers took 19% longer with AI tools, while believing they were about 20% faster (METR). METR has since marked that result out of date and says its follow-up gives an unreliable signal. Treat it as a caution about perceived acceleration, not a current measurement.

The more practical gap: we found no independent technical evaluation of the EKS-to-GKE agent, no third-party measured time savings, success rate, or failure analysis. Everything public so far is first-party or partner testimonial. Google's post also cites NetEase Games cutting infrastructure scaling from hours to five minutes and server costs by 40% (Google Cloud blog). That's GKE containerization, not the migration agent, and the two shouldn't be merged in a business case.

The agent is Public Preview as of the October 5 post. Scope and capability may change. A Q4 plan built on it is a plan built on a preview artifact.

The commercial math is the hardest human phase

Ask the simplest question in the room: who signs the three-year commitment, and on what date? An agent can model TCO. It can't sign a commitment. Commitments set the real pace of a cross-cloud move, and that math shapes every migration regardless of how fast the translation step runs.

Google's documentation states that once purchased, a spend-based committed use discount "cannot cancel." The customer is "obligated to pay the agreed-upon amount for the full duration of the term." That term runs 1 or 3 years, regardless of changes in your business needs or usage patterns (CUD docs). Separately, GKE (Autopilot) service-specific CUDs are listed as "no longer available for purchase." Compute flexible CUDs cover eligible spend across Compute Engine, GKE and Cloud Run (CUD docs). Commitment sizing is therefore a pre-migration decision with a multi-year tail.

The exit side is equally unmoved by tooling. AWS waives data-transfer-out-to-internet charges only for customers moving all of their data off AWS, after contacting Support for pre-approval. The FAQ says approved customers "have 60 days to complete your move off of AWS." They must then delete remaining data and workloads or close the account (AWS FAQ). A 9/30/25 update on the AWS announcement blog says eligible customers "will have 90 days." They must notify Support if they need longer (AWS blog). AWS's own pages disagree on the window, so confirm the term that applies to you with Support before you build a cutover calendar on it.

This is why a technically finished replatform can still be financially stranded: overlapping non-cancellable commitments on both sides, plus a parallel-run period nobody budgeted. A 2021 McKinsey survey of 443 cloud migration respondents found 75% exceeded planned budgets, with 28% over their initial allocation by more than 20%. A secondary roundup cites that analysis (roundup). That figure is attributed as cited, not verified at source.

The pre-work to own before you point an agent at anything

Google's EKS-to-GKE architecture guide structures the work in four phases: assess and discover; plan and build a foundation; migrate workloads and data; optimize. Assessment covers workload inventories, team training, TCO, migration strategy, and validating the plan with a rollback strategy (migration guide). This pre-work applies to any EKS to GKE migration, not just one using Google's new agent. The agent helps most in phase one and in the translation slice of phase three. Before that:

1. Decide the resource hierarchy deliberately, environments, regions and subsidiaries, an accountability framework, or the hybrid most organizations end up with, and write down why.
2. Settle the identity model and network boundaries, including which workloads need isolation, before any Terraform is scaffolded.
3. Choose Autopilot versus Standard as a platform decision with cost and operational consequences, not as a prompt answer.
4. Inventory stateful data separately and plan its movement on its own timeline with purpose-built services.
5. Model the commitment and egress math for both clouds, including the parallel-run window.
6. Decide what watches spend after cutover. A front-loaded TCO estimate watches nothing.

That last point is the one teams skip. A TCO estimate built in minutes never gets reconciled against what the estate actually does, and drift surfaces at month-end close, weeks after it started. The fix is hourly spend recommendations across projects and SKUs, with BigQuery-level analytics underneath them, so an overrun surfaces faster than a month-end close will catch it. That's what Cloud Companion was built for, alongside 200+ automated security checks that give a generated landing zone a deterministic second opinion.

The honest answer for your planning meeting

Agentic migration tooling is real progress on real drudgery. Discovery, dependency mapping, manifest and IaC translation, business-case modeling: those compress. Landing zone design, identity and network boundaries, stateful data movement, blocker ownership, and the commit and licensing math do not, and Google's own documentation says so plainly.

So the roadmap doesn't collapse. It rebalances. The weeks you reclaim from typing translations go straight back into deciding where the workload should live and what it will cost to keep it there. Teams that use the reclaimed weeks on foundation design will finish early. Teams that use them to start sooner will arrive in a new cloud with the old estate's problems, faster.

If you're sizing that split for a Q4 plan, a fixed-scope Professional Services engagement is a clean way to divide it: let the agents compress discovery and translation, and put experienced hands on the foundation, the data, and the commercial model.