EKS-to-GKE Migration Agent: A Safe Pilot Checklist

Google announced its Cloud Modernize portfolio on October 5, 2026. The announcement includes an EKS-to-GKE agentic migration capability in public preview. It says the pipeline can discover workloads, translate Kubernetes manifests, and map storage and networking between AWS EKS and Google Kubernetes Engine. Google also describes human approval gates and in-memory credential protections.

For a platform team, the immediate question is how to evaluate those capabilities on a real workload without putting a production cluster at risk. Start with one bounded pilot, keep every generated change reviewable, and agree on evidence that would stop the migration as well as evidence that would allow it to proceed.

What Google announced

Google places the EKS-to-GKE migration agent within its wider Cloud Modernize portfolio. The October 5 announcement calls the migration capability a public preview and says it automates discovery, Kubernetes manifest translation, and storage and network mappings. It also describes human approval gates and in-memory credential security.

Google's October 5 announcement does not specify support for every cluster feature, workload, or migration path. Confirm current preview access and supported scope with Google before building a delivery plan.

Google's EKS-to-GKE migration guidance recommends working through migrations in iterations. Its broader migration validation guidance recommends using a proof of concept, defining success criteria, testing the plan, and validating rollback scenarios. Those practices give teams a useful frame for assessing the new agent.

Choose a representative workload

Pick a service that matters enough to test real dependencies but can be isolated from a high-risk production cutover. Record its current Kubernetes version, manifests, controllers, storage needs, ingress and network rules, identity integrations, external services, and deployment pipeline.

Include the workload owner and the people who operate the destination platform. They can identify assumptions that are easy to miss in a repository, such as a manual DNS change, a provider-specific annotation, or an operational runbook that has no code equivalent.

If the service depends on persistent data or strict recovery objectives, include those requirements in scope from the start. The post describes storage and network mappings, while leaving application data transfer and consistency requirements unspecified. Give data movement and recovery their own plan and test evidence.

Set the gates before translation

Agree on acceptance criteria before the agent generates changes. A pilot should produce evidence that reviewers can reproduce:

| Review area | Evidence to collect | Gate before proceeding | |---|---|---| | Scope and inventory | Source manifests, dependencies, workload owner and excluded resources | Every in-scope component has an owner; exclusions are explicit | | Generated configuration | A version-controlled diff and a record of manual edits | Platform reviewers can explain each material change | | Security and identity | Access policy, secret handling, workload identity and network rules | No credential, permission or exposure change is accepted without review | | Workload behaviour | Automated tests, health checks and representative traffic results | The service meets the team's agreed functional and performance targets | | Data and recovery | Data movement plan, consistency checks, restore procedure and rollback rehearsal | Recovery works within the service's approved limits | | Operations | Monitoring, alerts, deployment steps and ownership after handover | The receiving team can operate and troubleshoot the service |

The table offers suggested internal controls for a migration pilot. Google's announcement does not present them as certification criteria. Set measurable thresholds that fit the service, then keep them the same when comparing the source and destination environments.

Route changes through the existing delivery path

Treat generated manifests as a proposal. Put them on a dedicated branch and send them through the repository's normal pull request checks, platform review and approval policy. Run the same static, security and policy checks used for manually authored infrastructure. Keep the agent's credentials limited to the repositories and test environments required for the pilot.

Check that the preview's human approval gates align with your team's access controls, protected branches and deployment approvals.

A reviewable diff is useful only when the team can tell what changed and why. Ask reviewers to compare resource limits, identity bindings, storage classes, ingress behaviour, network boundaries and provider-specific fields. Record corrections, then rerun tests against the revised output.

Test failure and rollback

Deploy the candidate to a non-production environment that resembles the target configuration. Check startup, health probes, service discovery, storage behaviour, permissions, observability and performance under representative load. Include at least one failure test that exercises the service's recovery path.

Before a production cutover, rehearse how the team will redirect traffic, restore or reconcile data, and identify the system of record during the transition. Set a maximum time for each step and name the person who can stop it. Google's migration validation guidance recommends testing rollback scenarios. Rehearsal shows whether the written recovery steps work.

Compare costs only after the destination workload passes the functional, security and recovery gates. Include the operating work needed to maintain the new platform alongside the initial infrastructure estimate.

Decide whether the pilot earned a second workload

The platform team should finish the pilot with a reviewed change set, repeatable tests, a documented exception list, an exercised recovery plan and a clear owner for the workload after migration.

If evidence is missing, keep the service on its current platform while the team closes the gap. If the pilot meets its criteria, use the lessons to choose the next workload. Update the criteria when the next service has different data, availability or compliance needs.

For supporting operational practices, see Bayseian's Kubernetes production guide and spec-driven agent workflow guide.

Sources

• Google Cloud, “Introducing Google Cloud Modernize, transforming for (and with) AI,” October 5, 2026.
• Google Cloud Architecture Center, “Migrate from Amazon EKS to GKE.”
• Google Cloud Architecture Center, “Best practices for validating a migration plan.”