Google Cloud, part of Alphabet (Nasdaq: GOOGL), says sportswear company On Holding (NYSE: ONON) used AI agents to migrate 24 core services to Google Cloud, cutting the time for each service from three months to two weeks. The companies said engineers retained responsibility for generated code, infrastructure changes and production cutovers while agents performed defined migration tasks.
The described workflow is more specific than a general developer copilot. Google Cloud said the multi-agent setup divided the work into codebase analysis, infrastructure-configuration generation, translation-pipeline creation and testing validation. On’s engineers reviewed the generated output, ran changes and authorized production cutovers.
According to the companies, a small internal team completed 15 of the migrations without outside implementation support and with less than five minutes of planned downtime per service. On said it was moving complex, interconnected microservices while trying to avoid disruption to retail operations and its engineering roadmap. Those results describe a single customer deployment and should not be treated as a general migration benchmark.
The report highlights an operational model that places agents inside bounded execution steps rather than giving them unrestricted authority over production. Agents mapped deployment patterns across more than 20 code repositories, while engineers remained accountable for decisions that could affect live services. That division is central to making agent-led infrastructure work fit normal change-control expectations.
The companies also said agents handled configuration scripting, data replication and environment validation. Those are tasks that can consume substantial time during a migration, especially where services have inconsistent configurations or long-lived dependencies. Automation can accelerate the analysis and preparation work, but it does not eliminate the need to test dependencies, monitor performance and maintain a rollback plan.
Migration leaders would also need to account for work that may not be visible in an agent workflow, such as updating runbooks, training support staff and establishing post-cutover observability. A fast technical move can create new operating risk if alerting, ownership and incident procedures do not move with the service. The companies did not address those lifecycle activities.
On selected Google Cloud as a common foundation for data, compute and AI, the companies said. It has also deployed Gemini Enterprise to employees and is using it to build internal agents for activities including reporting, research, scheduling and onboarding. The source does not detail the security controls, data boundaries or governance policies used for those other agents.
For cloud-operations teams, the notable element is the sequence of control: specialize agent tasks, have humans review generated code and changes, and preserve explicit approval before a cutover. That is a more cautious design than an agent that directly alters production environments, but it requires organizations to define where the boundaries sit and how they verify the system’s output.
Google Cloud’s account is a useful example of AI-assisted migration, not proof that agents will provide the same timeline or cost outcome across estates. The real test for enterprises will be whether the approach can work with their application dependencies, compliance requirements and release processes. Still, the case shows how AI agents can be applied to discrete infrastructure work while keeping final operational authority with engineers.