Google Cloud Modernize Unifies Tools; EKS Agent in Preview

On October 5, 2026, Google Cloud introduced Google Cloud Modernize, grouping Migration Center, Google Cloud VMware Engine and Google Cloud Mainframe Modernization with a new in-console Modernization Hub and an EKS-to-GKE migration agent in public preview. The launch gives enterprises a common portfolio for assessment, infrastructure moves and application modernization, but the agent has a narrower job: preparing a Kubernetes workload to move from Amazon Elastic Kubernetes Service to Google Kubernetes Engine.

For an EKS-to-GKE project, the agent can discover the source environment, translate Kubernetes manifests and map storage and networking requirements. Its workflow includes human approval gates. That makes its output a proposed target configuration for engineers to judge, rather than an automatic decision that a production application is ready to switch clouds.

One portfolio, different products and release stages

Modernize is an umbrella for several existing services and newer capabilities. Migration Center supports infrastructure assessment and planning; Google Cloud VMware Engine serves VMware estates; and Google Cloud Mainframe Modernization covers a separate class of legacy applications. Their inclusion under one name does not turn them into a single migration engine. The newly launched Modernization Hub is the console experience for examining source code and dependencies across Java, .NET and mainframe modernization work.

The distinction matters when a team is budgeting an EKS move. Migration Center's Agentic Quick Estimator is labeled generally available and uses inputs such as VMware inventory exports to build total-cost-of-ownership projections for a proposed Compute Engine environment. That is an assessment capability for infrastructure economics, not the container migration workflow. Modernization Hub organizes application analysis and related tools, while the EKS-to-GKE agent addresses the translation and mapping needed for a particular managed Kubernetes transition. The public-preview label attaches to that agent, not to every service now listed in Modernize.

The EKS agent prepares configuration for review

The agent's useful unit of work is the migration proposal. Discovery gathers details of the EKS environment; manifest translation adapts Kubernetes resources for GKE; and storage and network mapping identifies cross-cloud equivalents that need a design decision. Those steps can remove repetitive inventory and conversion work, yet a mapped resource is still a proposal about how an application should run on the target platform. Workload behavior and operational requirements decide whether that proposal is acceptable.

Google Cloud's earlier public-preview description calls GKE Agentic Migration an open-source plugin that runs locally, indexes source infrastructure-as-code, maps cloud-specific components such as Karpenter to GKE Custom Compute Classes, and validates configurations offline. It describes reviewable pull requests and data-migration runbooks without live cluster mutations. That earlier preview listing is also a useful date boundary: the October 5 announcement assembled the broader Modernize portfolio; it did not mark the agent's first appearance or its promotion to general availability.

This workflow helps explain the human approval gates. A pull request lets engineers inspect generated infrastructure and manifest changes within their normal change process. A data-migration runbook can organize work that must happen around deployment, but producing one is different from moving stateful application data. In-memory credential handling, which Google lists alongside the gates, addresses how the agent handles credentials during its work; it is not a substitute for reviewing the target access model.

Engineering decisions still separate preparation from cutover

In CIO's interview with analyst Pareekh Jain, he said consolidation could bring “fewer handoffs, faster decisions and better visibility,” while identifying testing, architectural decisions, data migration and production cutover as work teams still own. That is the practical boundary for the agent: it can prepare and present changes, but engineers decide whether the target design meets the application's requirements and when a live service can move.

Storage illustrates why translation alone cannot settle the decision. Mapping an EKS workload's storage requirements to GKE resources can show what target configuration to create, while the team still has to determine how existing data arrives, how the application reads and writes it, and whether recovery expectations hold after the move. Network mapping raises a similar question about reachable services and traffic paths. Those are application-specific judgments, not a property that follows automatically from a valid Kubernetes manifest.

Testing is the other boundary. A configuration may pass offline validation and still need deployment-level checks of application behavior, permissions and dependencies in the intended GKE environment. The team must then authorize the production change, plan how traffic switches to the target and decide how to respond if the workload does not behave as expected. The agent's approval points are useful precisely because they leave a deliberate pause between generated work and that operational commitment.

Preview status changes the readiness calculation

The portfolio launch offers a simpler route into Google's migration tools, but it does not make the EKS-to-GKE agent a generally available service. For a real project, public preview means the agent's generated inventory, mappings and pull requests should be judged as inputs to an engineering migration plan. The established products and generally available estimator may help with other parts of that plan, yet their release status does not transfer to the preview plugin.

A platform team can therefore gain value before a production cutover: the agent can expose source dependencies, draft target resources and make cross-cloud assumptions visible in a reviewable change. The decisive step remains a tested, approved target design with a data-movement and traffic-cutover plan. Until the team can establish those conditions for its own workload, a prepared GKE configuration is an intermediate artifact, not a completed migration.