Google Cloud Modernize: governing agent-led modernization
Google Cloud is bringing inventory, infrastructure migration, and application transformation into an agent-assisted offering. The potential gain is real, but moving faster does not reduce architectural accountability, evidence requirements, or the need for an exit plan.
1. What Google announced
On 5 October, Google Cloud introduced Google Cloud Modernize, a portfolio bringing together Migration Center, Google Cloud VMware Engine, Google Cloud Mainframe Modernization, and new agentic capabilities. Modernization Hub is intended to provide a common environment for analysing source code, mapping dependencies, and managing modernization work.
The announcement includes an Amazon EKS-to-Google Kubernetes Engine migration agent. Google describes three complementary areas: infrastructure assessment, platform modernization, and application modernization. This is a technical acceleration offering; the announcement does not demonstrate that any particular migration will automatically be correct, compliant, or economically sound.
2. What this changes for a Belgian or French company
For a structured SME, mid-market company, large enterprise, or public administration, inventory and transformation preparation can become more continuous. IT teams can identify dependencies earlier, generate migration proposals, and focus human reviews on high-risk deviations. This can shorten a programme, especially where applications, clusters, and document stores have accumulated.
The practical change is also organizational: the agent handles sensitive information—code, topology, configurations, and sometimes production data. Before a pilot, teams should specify processing regions, collected data, retention, service permissions, telemetry, subprocessors, and export conditions. For organizations subject to GDPR, NIS2, or sector rules, accountability does not transfer to the tool.
3. Separate discovery, proposal, and execution
A controlled chain has at least three levels. Discovery can remain read-only and produce a verifiable dependency map. Proposal can generate code, manifests, or a plan, but must remain subject to tests and review. Execution should use a separate identity, minimal permissions, a change window, backups, and a tested rollback.
The same separation applies to business systems. A modernization effort should not connect an agent directly to Odoo, a financial ERP, or a RAG database with broad write privileges. Interfaces, data contracts, and logs must remain stable and auditable throughout the transition.
4. Underside analysis: sovereignty is measured through reversibility
An integrated platform reduces fragmentation, but it can also concentrate inventory, recommendations, and execution with one provider. For a sovereign or hybrid AI strategy, the right metric is therefore not migration speed alone: it is the ability to export the map, decisions, tests, logs, and deployable artefacts.
Agents can help modernize an application or RAG pipeline, but acceptance criteria must remain independent of the model: functional behaviour, cybersecurity, performance, cost, data residency, and continuity. Local, cloud, and hybrid architectures should be comparable using the same evidence, including when the provider or model changes.
5. Implementation plan
Start with a non-critical but representative application. Establish a reference inventory, grant read-only access, and compare the generated map with the teams’ knowledge. Then allow only plan and artefact generation in an isolated environment. Measure errors, review time, total cost, added dependencies, and rollback quality before expanding the scope.
Priority: enforce four control gates—validated inventory, reviewed plan, independent testing, and demonstrated rollback—before a modernization agent can act on a production workload.
Govern an AI modernization