Google's Arm Migration Required 38,156 Commits Across Billions of Lines

What a warehouse-scale ISA migration actually looks like

When Google migrated its server infrastructure from x86 to Arm processors, engineers expected the hardest work would involve rewriting low-level code and debugging toolchain issues. Instead, they discovered something surprising: the vast majority of effort went into updating build scripts, configuration files, and release manifests.

A team of Google engineers has published the first systematic analysis of what a modern instruction set architecture migration entails at scale. Using large language models to categorize 38,156 commits spanning a multibillion-line codebase, they found that contemporary ISA migrations look fundamentally different from historical examples—and that many tasks are ripe for automation.

Why it matters

As major cloud providers adopt Arm processors for efficiency gains, understanding the true cost and nature of ISA migration becomes critical for infrastructure planning. This research shows that while modern compilers and toolchains have eliminated many traditional porting headaches, they've been replaced by a high volume of simple, repetitive tasks. That shift creates both a challenge—sheer scale—and an opportunity for AI-assisted automation that could dramatically reduce migration timelines for future architecture transitions.

Two-phase approach to massive scale

Google's migration unfolded in two distinct phases, according to the research first reported by Communications of the ACM. Phase one targeted the largest workloads—systems like Spanner, BigQuery, and Bigtable. These required hands-on work with weekly meetings and careful performance testing as scheduling constraints were gradually removed.

During this phase, teams encountered issues they hadn't anticipated: x86-specific intrinsics, floating-point precision differences with long double types, memory ordering bugs masked by x86's stronger guarantees, and heap limits tuned for x86 that caused out-of-memory errors on Arm. Yet most fixes proved straightforward once identified.

Phase two addressed the long tail—more than 100,000 packages representing the remaining 40 percent of compute workload. At this scale, direct team engagement became impossible. The migration team instead relied on large-scale automated changes orchestrated through Google's internal tooling, which can shard massive commits across thousands of files and route them to appropriate code owners.

Configuration over code

The research team used Gemini 2.5 Flash to analyze the full commit corpus, ultimately categorizing changes into 16 distinct types. The analysis revealed that many commits involved modifying Bazel BUILD files, Blueprint release manifests, and continuous integration configurations rather than application source code itself.

Common tasks included updating architecture-specific build flags, fixing brittle tests that made exact floating-point comparisons, removing legacy x86-only scheduling constraints, and addressing multiarch release packages that exceeded infrastructure capacity limits. These changes were often simple individually but pervasive across the codebase.

Automation potential and AI limits

The researchers identified three key findings: many migration tasks are highly automatable with conventional tools; many tasks only need to be performed once when moving from single-architecture to multi-architecture support; and modern AI can handle additional categories, though some challenges remain.

The work highlights specific opportunities for the academic community to improve automated code transformation tools. It also challenges longstanding assumptions that ISA migrations primarily involve complex low-level programming work rather than configuration management at scale.

The detailed analysis and taxonomy were published by Eric Christopher, Kevin Crossan, Wolff Dobson, Chris Kennelly, Drew Lewis, Kun Lin, Martin Maas, Parthasarathy Ranganathan, Emma Rapati, and Brian Yang in Communications of the ACM.