In a significant milestone for the world’s most popular software development platform, GitHub has announced that 99.99999% of its Git repositories have now been successfully migrated to Microsoft Azure. This massive infrastructure shift, which has unfolded over the past year, marks a pivotal moment in how the company manages the exponential growth of Git traffic. As the platform transitions, the focus now turns to the final, most complex fraction of its repositories—those that are among the busiest on the service—and the engineering innovations required to bring them into the cloud without compromising performance.
The migration was born out of necessity rather than mere convenience. As GitHub witnessed an unprecedented surge in activity, driven largely by the “agentic shift”—a wave of autonomous AI agents and automated workflows performing massive numbers of operations—the company faced a hard ceiling regarding the power capacity of its own data centers. Physical supply chain constraints and the geographical limits of existing infrastructure meant that GitHub needed a scalable, reliable path forward that could handle the influx of data without interrupting the daily workflows of millions of developers.
Navigating the Migration Strategy
The architectural overhaul was designed with two primary principles in mind: minimizing coordination and decoupling storage from compute. However, executing such a transition while traffic was at an all-time high presented a unique challenge. GitHub opted for a careful, sequenced approach. The goal was to migrate the data first, ensuring that every service, dependency, and repository was safely hosted in Azure, and then evolve the underlying architecture once the data had settled in its new environment.
The first repository replica landed in Azure’s Central US region in August 2025. Since then, the platform has systematically moved the majority of its data. Today, most repositories maintain two of their five replicas within Azure, with the cloud infrastructure now handling approximately half of all global Git traffic. This transition has allowed GitHub to absorb growth seamlessly, keeping its own data centers stable while the platform scales horizontally across Azure’s vast footprint.
The routing mechanism, known as "Spokes," plays a critical role in this transition. By employing preferential routing, Spokes ensures that traffic is directed to the replica located in the same region and availability zone as the user request, thereby minimizing read latency. As more replicas move to Azure, the share of traffic served from the cloud naturally grows, until the final replica is migrated and the original data center region can be gracefully decommissioned.
Solving the Throughput Bottleneck
While the vast majority of the platform’s data has migrated smoothly, the final 0.00001% of repositories—the “busiest” on the platform—present a complex engineering hurdle. In the current architecture, a repository hosted across multiple regions faces a significant throughput ceiling. Because the Spokes quorum requires a majority to commit a write but waits for every healthy replica to respond, the slowest replica in the network inevitably dictates the speed of every transaction.
When a repository is split between an on-premises data center and an Azure region 1,000 miles away, the 25ms round-trip latency becomes a constant, unavoidable tax on every write operation. Because each write holds a repository-wide lock until it commits, this latency creates a queue, effectively capping the throughput. For the busiest repositories, which are already operating near their capacity limits, this added latency would cause them to fall behind with every push.
To address this, GitHub is moving away from repository-wide serialization in favor of per-reference serialization. The logic is rooted in the principle of minimizing coordination: only writes that contend on the same reference (such as the same branch) need to wait for each other. Since the majority of Git updates—such as developers pushing to their own unique feature branches—do not depend on one another, they can be applied independently. By changing the scope of the quorum to individual references, GitHub can ensure that writes to different branches no longer block each other. Internal testing suggests this shift will result in 3 to 4 times higher throughput at lower latency, providing the necessary headroom to bring the final, most active repositories into the Azure ecosystem.
Decoupling for Future Scale
Beyond solving the immediate migration challenges, the architectural shift enables a more modular approach to scaling. Traditionally, read and write operations have competed for the same resources on the same replicas, making it impossible to scale them independently. By decoupling storage from compute, GitHub is introducing "virtual replicas" that interact with Azure Blob Storage.
These virtual replicas act as a bridge to object storage. They stream incoming writes and serve no read traffic, effectively becoming the first fully ephemeral nodes in the GitHub architecture. A write is not acknowledged until it is confirmed as durable in object storage. While this introduces a slight latency, the per-reference serialization mechanism prevents it from becoming a throughput bottleneck. Furthermore, these virtual replicas coalesce transactions on different references into a single set of network operations, meaning a busy repository pays for the cost of a single round trip to object storage rather than one per individual write.
Once this infrastructure is in place, GitHub can scale out an unlimited number of virtual read replicas on demand. Each of these read replicas warms its cache directly from Azure Blob Storage and reconciles its state in the background. This architecture eliminates the traditional resource contention between reads and writes, allowing the platform to support massive read volume without impacting the performance of developers pushing code.
The Road Ahead
The Spokes service has served as the backbone of GitHub’s growth, evolving from a simple quorum coordinator into a sophisticated, intelligent routing and load-balancing layer. It currently manages well over 100 billion operations per day. While the core of this system remains highly effective, the engineering team recognizes that the existing commit protocol will eventually reach its limit as the platform approaches its next billion repositories.
The current transition is merely one step in a much longer journey. The next major challenge is further optimizing write throughput. Currently, every write still waits on replicas that maintain full copies of the repository, yet only a small fraction of the data in a write requires strict ordering. Since Git objects are immutable and identified by their contents, they can technically be stored without needing global consensus. The hard part, as GitHub engineers have noted, is building a system that can order the necessary metadata as fast as possible without creating new, secondary bottlenecks.
As the platform continues to accommodate the relentless growth of automated agent traffic, each of these architectural refinements provides more breathing room. The transition to Azure is not just about moving data; it is about rewriting the underlying rules of how the platform functions to ensure it remains responsive and resilient for the next generation of software development. As GitHub approaches its major industry events, the company has signaled that it will soon unveil the final end state of this architecture—a system designed to handle the scale and complexity of the future, while maintaining the reliability that the developer community has come to expect.
