Google Cloud has opened a new front in the fight for enterprise Kubernetes workloads. On September 25, 2026, the company’s containers and Kubernetes team published a post titled “Introducing GKE agentic migration for AI-assisted EKS-to-GKE migrations with built-in governance,” putting a public preview of an AI agent built to move clusters off Amazon’s Elastic Kubernetes Service and onto Google Kubernetes Engine. The tool, called GKE Agentic Migration, ships as an open-source plugin rather than a hosted service, and it lands at a moment when Synergy Research Group pegs the global cloud infrastructure market at roughly $143 billion for the second quarter of 2026, with Amazon Web Services still holding the largest single slice.
The pitch is straightforward. Migrating a production Kubernetes estate between clouds is slow, expensive, and full of ways to break something quietly. Google says its agent reads existing infrastructure-as-code and live cluster configuration, maps AWS-specific primitives to their closest GKE equivalents, and generates a reviewable pull request instead of touching a live cluster directly. Whether that pitch survives contact with real production traffic is the question worth asking, and it’s one the company hasn’t fully answered yet.
What GKE Agentic Migration Actually Does
GKE Agentic Migration runs locally, inside a developer’s own toolchain, rather than as a managed cloud service that Google operates on a customer’s behalf. According to Google’s product description, the agent indexes a source EKS environment, including its infrastructure-as-code definitions, and looks for AWS-native constructs that have no direct GKE analog. The most commonly cited example is Karpenter, the AWS autoscaler that provisions EC2 nodes on demand, which the agent maps to GKE’s Custom Compute Classes. That single mapping matters because autoscaling behavior is one of the easiest things to get subtly wrong during a cross-cloud move, and a wrong mapping tends to show up weeks later as a cost spike or a capacity shortfall rather than an immediate failure.
Once the agent has a picture of the source cluster, it produces two outputs: a set of proposed configuration changes packaged as a pull request, and a data-migration runbook covering the stateful pieces (persistent volumes, databases, anything that isn’t a stateless deployment). Google’s own framing leans hard on the word “reviewable.” Nothing is applied automatically. An engineer still has to read the diff, approve it, and run the migration steps, which puts this tool closer to a very well-informed pairing partner than to an autonomous ops system.
Validation happens before anything touches production
Google says the agent validates generated configuration offline, meaning the checks run against a static model of the target environment rather than against a live cluster. That’s a meaningful design choice. Ad hoc use of a general-purpose coding assistant to “write me a migration script” carries an obvious risk: the model has no deterministic guardrail stopping it from generating a syntactically valid but operationally dangerous change, like an overly broad IAM binding or a load balancer rule that silently drops traffic. Google is positioning GKE Agentic Migration as a structured alternative to that ad hoc pattern, built around fixed validation rules the generative layer can’t override.
Engineers doing this kind of move by hand today typically juggle multiple kubectl contexts side by side while diffing manifests, something like this:
kubectl config get-contexts
kubectl config use-context aws-eks-prod
kubectl get nodes -o wide
kubectl config use-context gcp-gke-prod
kubectl get nodes -o wide
kubectl diff -f ./manifests/That manual context-switching is exactly the friction Google says it built GKE Agentic Migration to remove, by automating the comparison and the primitive-mapping step rather than leaving an engineer to spot every AWS-specific quirk by eye.
Why Google Is Shipping This Now
Timing tells its own story. Google Cloud Next ’26, held in April 2026, focused its GKE announcements on AI-inference performance: faster cold starts, scale-out for agent workloads, and an isolated execution environment called GKE Agent Sandbox. The EKS-to-GKE migration tool didn’t appear there. It arrived five months later, as a standalone September announcement, which suggests Google treated it less as a headline product and more as a targeted move once the underlying agent-tooling groundwork from Next was in place.
The competitive backdrop gives that timing some weight. Synergy Research’s Q2 2026 numbers show AWS holding 28% of the global cloud infrastructure market, Microsoft Azure at 20%, and Google Cloud at 15%, up from roughly 13% a year earlier. Google Cloud’s growth rate is outpacing both larger rivals, and a tool that lowers the switching cost for AWS customers specifically, rather than for cloud customers generally, is a direct play against the market leader rather than a generic land-grab.
Comparing Control-Plane Costs Across EKS, AKS, and GKE
Migration tooling aside, the underlying economics of running Kubernetes still differ by provider, and that’s part of what makes a switch worth considering in the first place. Here’s how the three major managed Kubernetes control planes compare on list pricing as of late September 2026.
| Service | Control-plane fee | Free tier | Native migration tooling |
|---|---|---|---|
| Amazon EKS | ~$0.10 per cluster-hour (about $73/month) | None on standard support | AWS Migration Hub (general-purpose, not Kubernetes-specific) |
| Azure AKS | $0 on the free tier | Free tier standard, paid uptime-SLA tier available | Azure Migrate (general-purpose, not Kubernetes-specific) |
| Google GKE | ~$0.10 per cluster-hour (about $73/month) | One zonal or Autopilot cluster free per billing account | Migration Center plus the new GKE Agentic Migration for EKS sources |
Those figures cover the control plane only. Worker-node compute, storage, networking, load balancers, observability, and support contracts are billed separately in all three cases, and they typically dwarf the control-plane fee itself. See the official GKE pricing page, EKS pricing page, and AKS pricing page for the current rate cards, since cloud pricing changes without much notice.
A Short History of Cloud-to-Cloud Migration Tooling
Cloud providers have offered migration assistance for as long as multi-cloud has been a real option, but almost all of it has pointed one direction: into the provider offering the tool. AWS Migration Hub, launched years ago, centralizes discovery and tracking for workloads moving onto AWS. Azure Migrate does the same for Azure. Google’s own Migration Center follows the identical pattern for GKE and Compute Engine. None of these were built to make leaving easy.
The open source world filled some of the gap differently. Velero handles Kubernetes backup and restore, and it can move workloads between clusters on different providers, though it wasn’t designed to translate cloud-specific resources like autoscalers or load balancer annotations. GitOps tools such as Argo CD and Flux redeploy portable Kubernetes manifests across clusters cleanly, but manifests are only ever part of a real production setup. Infrastructure-as-code tools like Terraform and OpenTofu can recreate infrastructure on a new provider, but a Terraform module written for AWS still needs a human to redesign the AWS-specific resources for GCP. GKE Agentic Migration is Google’s attempt to automate that redesign step specifically, rather than leaving it as manual work layered on top of existing IaC tooling.
How GKE Agentic Migration Stacks Up Against the Alternatives
Several categories of tools touch cloud-to-cloud Kubernetes migration today, and they solve different slices of the problem. The table below lines up the main options by scope.
| Tool | Primary scope | Cloud-specific primitive mapping | Direction |
|---|---|---|---|
| GKE Agentic Migration | EKS-to-GKE Kubernetes migration | Yes (e.g. Karpenter to Custom Compute Classes) | Into GKE only |
| AWS Migration Hub | General workload discovery and tracking | No | Into AWS only |
| Azure Migrate | Servers, databases, general app migration | No | Into Azure only |
| Velero | Kubernetes backup, restore, cluster move | No | Cloud-agnostic |
| Terraform / OpenTofu | Infrastructure-as-code provisioning | No (requires manual redesign) | Cloud-agnostic |
The distinguishing feature Google is selling isn’t backup-and-restore or generic IaC provisioning, both of which already exist. It’s the combination of reading a live AWS-flavored setup, mapping the AWS-specific pieces to Google’s equivalents, and handing back a pull request a human can actually review line by line. Nothing else in the table above does that particular job today, largely because it requires deep knowledge of both providers’ primitives baked into one tool, which is a narrower and more opinionated build than a general migration platform.
The Multi-Cloud Kubernetes Reality Behind the Announcement
Kubernetes adoption itself is no longer in question. The Cloud Native Computing Foundation’s 2025 annual survey, released January 20, 2026, found that 82% of container users now run Kubernetes in production, up from 66% in 2023. That climb reflects a technology that has moved from early-adopter territory to default infrastructure across most sizeable engineering organizations in less than a decade.
What’s less settled is how many of those organizations run Kubernetes across more than one cloud at once, and by extension how large the addressable market for a migration agent actually is. Flexera’s 2026 State of the Cloud Report, published March 18, 2026, reports that 83% of respondents use AWS in some capacity, and that cost savings, workload migration, and delivery speed rank as the top three priorities cloud leaders track. Those numbers describe general cloud usage and priorities rather than a clean multi-cloud percentage, and no public survey yet isolates how many companies specifically run EKS and GKE side by side. That’s a real gap in the data, and it means the size of the audience for a tool like this one is still a matter of Google’s internal estimate rather than an externally verified figure.
Security and Vendor Lock-In Concerns
Handing an AI agent read access to production infrastructure-as-code, Kubernetes manifests, and cloud identity configuration raises the obvious question of what that agent can see and where that data goes. A migration tool by definition needs to inspect secrets metadata, registry references, and networking rules to do its job, which means redaction and scoped permissions matter more here than in most developer tooling.
There’s a second, subtler risk in the generated output itself. A large language model can produce a Kubernetes network policy or IAM binding that parses correctly and still grants far more access than intended, or a storage mapping that looks equivalent but behaves differently under load. Google’s answer is the deterministic guardrail layer sitting between the generative model and anything that reaches a live cluster, plus the requirement that changes land as a reviewable pull request rather than an automatic apply. That’s a real mitigation, though it still depends on a human reviewer catching what the guardrails miss, and reviewers get tired of reading AI-generated diffs just like they get tired of reading anyone else’s.
The lock-in angle cuts in an interesting direction. A tool that makes it easier to move into GKE doesn’t automatically make it easier to leave GKE later, especially once a workload adopts Google-specific replacements like Custom Compute Classes in place of Karpenter. Google is lowering the switching cost in one direction only, which is a rational business decision for Google and a fact worth knowing for anyone evaluating the move. Hidden AWS dependencies compound the problem too: IAM roles for service accounts, ALB and NLB integrations, EBS and EFS storage semantics, Route 53 routing, and PrivateLink connections don’t have exact GKE equivalents, and no automated mapping tool eliminates the need to test those integration points by hand.
What This Means for AWS and Azure
AWS has faced provider-switching friction as a structural advantage for years. If Google’s agent genuinely cuts the engineering hours needed to move a Kubernetes estate off EKS, that advantage erodes a little, even if the tool only handles one leg of a much larger enterprise migration (data gravity, compliance obligations, and existing AWS enterprise agreements all still weigh in AWS’s favor). Amazon hasn’t publicly responded to the GKE Agentic Migration launch as of this writing, and the company has no announced equivalent that maps GKE-specific primitives into EKS terms.
Azure sits in a similar spot to AWS here, watching from the sidelines rather than participating. Neither Microsoft nor Amazon has a comparably specific tool for pulling Kubernetes workloads off a rival’s managed service, which leaves Google, for now, as the only major cloud provider actively building migration tooling aimed at competitors’ clusters rather than its own new customers exclusively. Whether that stays a Google-only move or triggers a response from AWS or Azure within the next few product cycles is one of the more interesting open questions this announcement raises.
Market Impact: Google Cloud’s Revenue Momentum
The migration tool lands against a backdrop of strong financial results for Google Cloud. Alphabet’s Q2 2026 earnings release put Google Cloud segment revenue at approximately $24.8 billion for the quarter ended June 30, 2026, up from $13.6 billion a year earlier, a growth rate the company attributes largely to AI infrastructure demand rather than to any single product launch. GKE Agentic Migration is too new to have moved that number, and Google hasn’t published adoption figures, cost savings, or migration-time data from early users of the public preview. Any claim about the tool’s financial impact right now would be speculation dressed up as analysis, so the honest read is that this is a strategic bet on future share, not a documented revenue driver yet.
Risks That Could Slow Adoption
A few practical obstacles stand between this preview and broad enterprise use. First, stateful workloads remain the hardest part of any Kubernetes migration, and an agent that maps compute and networking primitives well can still stumble on persistent volumes, database consistency, and encryption-in-transit requirements during a cutover window. Second, large enterprises tend to run heavily customized admission controllers, custom resource definitions, and internal platform layers on top of vanilla Kubernetes, and an agent trained on common patterns may not recognize a bespoke internal abstraction correctly. Third, regulated industries with strict change-management processes will likely want independent verification of every generated pull request before it touches anything, which limits how much time the tool actually saves in the environments where migration costs are highest.
There’s also a trust problem that’s specific to this moment in AI tooling generally. Plenty of engineering teams have been burned by AI-generated code that looked plausible and wasn’t, and a migration tool touching production infrastructure carries a much higher cost of failure than a coding assistant suggesting a function. Google’s guardrail design directly addresses that concern on paper, but public preview software hasn’t had time to build the kind of track record that makes platform teams comfortable running it against revenue-critical clusters.
Predictions: Where This Goes Next
- Expect AWS to respond within two to three quarters, either with its own AI-assisted migration tooling or with pricing and support incentives designed to make EKS customers less price-sensitive to a switch.
- Google will likely extend the agent to cover AKS-to-GKE migrations next, since the underlying primitive-mapping approach generalizes to any source Kubernetes provider, not just EKS.
- Enterprise adoption in regulated sectors (finance, healthcare, government) will lag general adoption by at least a year, as compliance teams build review processes for AI-generated infrastructure changes.
- Watch for Google to publish adoption and cost-savings numbers at Google Cloud Next ’27 if the preview performs well, since the company has a pattern of quantifying successful launches roughly a year after quiet previews.
- Third-party platform vendors such as Rafay, Platform9, and CAST AI will likely add comparable migration-assist features rather than cede the category entirely to a single cloud provider’s tool.
Frequently Asked Questions
What is GKE Agentic Migration?
It’s an open-source AI agent plugin from Google Cloud, released in public preview on September 25, 2026, that helps migrate Kubernetes workloads from Amazon EKS to Google GKE. It reads existing infrastructure-as-code, maps AWS-specific primitives to GKE equivalents, and produces a reviewable pull request plus a data-migration runbook.
Does GKE Agentic Migration automatically change my production cluster?
No. Google says the tool validates changes offline and generates a pull request for human review rather than applying anything to a live cluster automatically.
How much does it cost to run GKE compared to EKS and AKS?
Both EKS and GKE charge roughly $0.10 per cluster-hour for the standard control plane, about $73 per month per cluster, while Azure AKS offers a free control-plane tier with paid options for extended SLA support. Worker-node compute, storage, and networking costs are billed separately in all three cases and typically make up the bulk of total spend.
Is GKE Agentic Migration only for AWS EKS customers?
The current public preview is scoped specifically to EKS-to-GKE migrations. Google hasn’t announced support for migrating from Azure AKS or self-managed Kubernetes clusters, though the underlying approach could plausibly extend there.
What percentage of companies run Kubernetes in production today?
According to the CNCF’s 2025 Annual Survey, 82% of container users run Kubernetes in production, up from 66% in 2023.
What are the alternatives to GKE Agentic Migration?
Options include Velero for Kubernetes backup and restore across clusters, GitOps tools like Argo CD and Flux for redeploying portable manifests, and infrastructure-as-code tools like Terraform or OpenTofu, which can recreate infrastructure on a new provider but require manual redesign of cloud-specific resources.
Does using GKE Agentic Migration create vendor lock-in to Google Cloud?
It can. The tool maps AWS primitives to Google-specific replacements, such as Karpenter to Custom Compute Classes, which lowers the cost of moving into GKE without necessarily making it easier to move away from GKE later.
Has AWS or Microsoft responded to the GKE Agentic Migration launch?
Neither company has announced a comparable tool as of late September 2026. AWS Migration Hub and Azure Migrate remain general-purpose migration services oriented toward their own platforms rather than tools for mapping a rival’s Kubernetes primitives.
