How Google Cloud Modernize connects migration planning and AI assistance

Google is bringing modernization planning and preparation together

Google is bringing existing migration and modernization tools, new artificial intelligence (AI) agents, and a Modernization Hub together under Google Cloud Modernize. Google says the aim is to speed up changes to enterprise infrastructure and applications. The company has a commercial interest in making those changes easier because migrations to Google Cloud bring workloads onto its platform.

For chief information officers (CIOs) and engineering leaders, the overhaul addresses two connected tasks: coordinating a modernization program and preparing individual workloads to move. Combined assessments can help teams decide what to change, while agents can assist with cost exploration and migration engineering. Enterprise teams still decide whether the resulting systems are ready for production.

Consolidated planning connects assessments, migration choices, and costs

Coordination becomes harder when an enterprise runs several kinds of applications across clouds. Pareekh Jain, principal analyst at Pareekh Consulting, illustrates the problem with a hypothetical environment whose workload categories require separate assessments and teams. His consultancy advises enterprises on technology decisions, so it also has a commercial interest in modernization activity.

“An enterprise might have VMware workloads, Java applications, mainframes, Oracle databases and Kubernetes applications running across different clouds. Previously, these could require separate tools, assessments and migration teams. With the broader offering, CIOs require fewer handoffs, faster decisions and better visibility across a large modernization program,” Jain said. The burden in this example is bringing separate teams’ findings together before deciding how the program should proceed.

Separate findings can leave leaders with partial views of the same environment, forcing teams to explain dependencies and align recommendations at each handoff. Jain describes consolidation as bringing the work into “one end-to-end process”. Keeping assessment and planning connected can simplify decisions, while enterprise teams remain responsible for carrying them out.

Google Cloud Modernize provides the structure for that consolidation: Migration Center is being incorporated into it and will continue to support migration assessment and planning. Alongside it, Modernization Hub focuses on application modernization. Teams discussing the portfolio with Google therefore need to distinguish the Hub’s application focus from the broader migration functions.

Within that application focus, Google is combining the App Modernization CLI, a command-line interface through which users enter text commands, with Java and .NET modernization capabilities. The mainframe tools include Mainframe Assessment Tool, Dual Run, and Mainframe Connector. Google says teams will access the Hub through the Google Cloud Console, giving them a common interface for the application modernization tools gathered there.

A common interface can also connect assessment to the planning that follows. Viet-Anh Nguyen, machine learning lead at Scopic Software, describes that management benefit; Scopic Software has a commercial interest in enterprises investing in software modernization. “Instead of fragmented tools, the new Hub provides a consolidated assessment workflow. It gives CIOs one place to assess, plan and manage application modernization,” he said.

Planning from a combined assessment helps teams choose the engineering work an application needs. “Earlier, capabilities were spread across different Google tools. Teams can now understand applications and dependencies, get modernization recommendations and decide what to migrate, rehost or refactor from a more unified interface,” Jain said. Dependencies are the services and systems an application relies on; understanding them helps teams decide whether to move an application, rehost it with limited changes, or refactor its structure.

Those choices also shape the financial assessment, which Google is extending through Migration Center’s Quick Estimator Agent. Google says enterprise users can supply infrastructure data, including VMware inventory exports, to generate estimates of total cost of ownership, the overall costs of a migration scenario. Users can then explore scenarios and question cost assumptions in natural language, connecting infrastructure information to financial planning.

The assumptions matter because an estimate depends on the migration choices behind it. A planning team can use the estimator to see how different scenarios change projected costs, rather than treating the first estimate as fixed. This gives teams another way to assess a proposed move, while eventual operating costs still depend on how they carry it out.

Migration automation prepares changes for engineering review

Once a team chooses a migration route, the engineering work becomes more specific. Google’s EKS-to-GKE Migration Agent supports a defined route: moving Kubernetes workloads, or applications managed by Kubernetes, from Amazon EKS, the managed Kubernetes service from Amazon Web Services (AWS), to Google Kubernetes Engine (GKE). Teams should assess its capabilities against that route, since its stated scope does not imply equivalent support for every cloud-to-cloud migration.

For an EKS-to-GKE move, preparation starts with understanding the existing environment and the changes the destination requires. Google says the agent can analyze EKS environments, translate Kubernetes manifests, the files describing how workloads should run, and map storage and networking requirements. It can then help prepare workloads for deployment on GKE, with human approval checkpoints along the way.

Storage and networking need attention because a workload depends on infrastructure beyond its manifest. Mapping those requirements helps teams account for what the application will need at its destination. Google’s description therefore brings related preparation tasks into one assisted workflow, while engineers review the proposed changes.

Nguyen describes how that review can fit into engineering practice. “Since the Agent can automatically discover and translate AWS-specific infrastructure and Kubernetes configurations, validate the outputs, and create pull requests for human review, it reduces repetitive engineering,” he said. Pull requests are proposed changes submitted for review, allowing engineers to inspect the agent’s work before accepting it.

Pull requests give a concrete form to the human review Google includes in its approval checkpoints. The agent can discover configurations, prepare changes, and check outputs, while engineers decide whether to accept them. Developers and platform engineers could therefore spend less time repeating discovery, translation, and preparation work, with output they can inspect and judge.

Reducing that manual work could also change the effort involved in switching clouds. Jain sees the potential for faster, cheaper, and less risky moves. For a particular EKS-to-GKE migration, teams need to judge how much preparation the agent can assist with and how its proposed changes fit their existing review process.

Enterprise ownership continues through production cutover

Reviewing proposed changes is part of the wider responsibility that remains with the enterprise. According to Jain, teams still own testing, architectural decisions, data migration, and production cutover, the transition that puts the migrated system into live operation. Prepared configurations can support that work, but the team must still decide whether the application and its supporting systems are ready to run.

Making that decision requires CIOs and platform leaders to assign ownership beyond the agent’s approval checkpoints. People accepting configuration changes also need to know who is accountable for testing the system, deciding its architecture, moving its data, and authorizing the production transition. Accepting an agent’s proposed change is therefore one approval within the migration process; the authority to put the system into live operation must remain explicit.

Key takeaways for decision-makers

• Connect assessments to migration decisions: Google Cloud Modernize brings assessment, application modernization and cost exploration into a broader workflow. CIOs and platform leaders can use the combined findings to compare migration routes, examine dependencies and test cost assumptions before committing engineering resources.
• Evaluate automation against the migration route: Google’s EKS-to-GKE Migration Agent helps translate configurations and map storage and networking requirements for that specific move. Platform engineers need to review its proposed changes and assess how much preparation it saves within their existing workflow.
• Assign ownership through production cutover: Enterprises retain responsibility for architecture, testing, data migration and the transition to live operation. CIOs and engineering leaders need explicit owners for each decision, including who accepts agent-generated changes and who authorizes production deployment.