Google built an agent to move your Kubernetes off AWS. Migration agents make the exit plan real

Every cloud contract has an exit clause, and almost no enterprise believes it. Leaving a cloud means months of reverse engineering, translation and testing, so the exit plan stays a document in a risk register. Google’s modernization launch on October 5 includes an agent whose whole job is to make one specific exit cheaper: moving Kubernetes workloads from Amazon EKS to Google Kubernetes Engine.

What Google announced

As part of Google Cloud Modernize, described in a post by Souvik Choudhury and Tom Nikl, Google introduced EKS-to-GKE Agentic Migration, in Public Preview. Google says it:

• manages discovery, Kubernetes manifest translation, and storage and network mapping across clouds in an automated pipeline;
• includes human-in-the-loop approval gates and in-memory credential handling intended to keep strict GitOps compliance.

Alongside it, the Agentic Quick Estimator, now GA, turns VMware inventory exports such as RVTools into total cost of ownership projections on Compute Engine. Google says it condenses weeks of spreadsheet modeling into “a defensible business case in minutes.” That is Google’s description of its own sales-cycle tool; treat the output as a starting point, not as the business case.

Exit costs are dropping, on both sides of the table

1. Read-only discovery in the source account
2. Translate manifests, map storage and network
3. Changes proposed as pull requests
4. Platform team approves and merges
5. GitOps applies to GKE
6. Traffic cutover and rollback decision

• Agent autonomy: Read-only discovery in the source account · Translate manifests, map storage and network · Changes proposed as pull requests
• Human authority: Platform team approves and merges · GitOps applies to GKE · Traffic cutover and rollback decision

Agent workPipeline you already control

Migration is labor, and labor is what agents compress. The AWS architecture we covered in our analysis of migration playbooks moves workloads into AWS; Google’s agent moves them out of AWS. Expect every hyperscaler to ship one aimed at its competitors. The side effect matters more than any single tool: the cost of switching clouds is falling, and that changes three things.

The exit plan becomes testable. An exit plan that has never been rehearsed is a hope. If an agent can translate a representative cluster in days, you can run the rehearsal once a year on a non-critical workload and record how long it took. That evidence is worth more in a risk committee than any clause. For banks, the 2023 interagency guidance on third-party relationships from the Federal Reserve, FDIC and OCC already expects exit strategies for critical services; a rehearsal is the strongest proof that one exists.

Negotiations change. A credible, measured exit is leverage at renewal. It also cuts the other way: the vendor building the agent wants your workloads, and its TCO estimator is part of its sales motion. Rebuild the numbers with your own finance team before they reach a board deck.

Commitments still create gravity. Committed spend, marketplace credits and discounts tie you to a provider long after the technology would let you leave, as we noted in our piece on procurement shaping the AI stack. Cheaper switching does not help if the contract makes leaving expensive.

Where autonomy should stop

Google’s design choices are the right ones, and worth copying for any infrastructure agent:

• Credentials. The agent needs access to your AWS account to discover what runs there. Give it a dedicated, read-only role scoped to the clusters in question, time-boxed for the migration. “In-memory” handling means credentials are not stored; it does not limit what they can do while held.
• GitOps as the boundary. The agent proposes; the repository and the pipeline apply. Its output should arrive as reviewable changes, never as direct writes to the target cluster.
• What translation cannot see. Manifests are the easy part. IAM roles bound to service accounts, load balancer controllers, storage classes, pod security settings and the managed services workloads call (queues, databases, secrets) all differ between clouds. Ask which of these the preview handles, and test the rest by hand.

What to do now

1. Rehearse one exit per year on a non-critical workload and record time and effort.
2. Scope migration agent credentials as read-only, per cluster and time-boxed.
3. Keep GitOps as the only write path to the target cluster.
4. List the cloud-specific dependencies manifests do not cover before trusting a timeline.
5. Rebuild vendor TCO estimates with your own finance assumptions.
6. Read your commitments alongside the technical exit plan; both decide whether you can leave.

The bottom line

Migration agents are being built to win workloads, but their real gift to enterprises is a credible exit. Use Google’s preview, or its equivalents from other clouds, to turn your exit plan into a measured rehearsal, and keep the agent’s authority ending at the pull request.