在过去的一年中，虽然Git流量呈指数级增长，但GitHub上99.99999%的Git存储库开始同时存在于两个地方：我们自己的数据中心和Azure。其余的都是平台上最繁忙的，只有一件事阻碍了他们： 25毫秒的往返行程。
在之前的博客文章中，我们阐述了下一代存储架构背后的两个原则：最小化协调将存储与计算分离在这篇文章中，我们将介绍旧设计和新设计之间的直接桥梁。
我们将讨论仲裁序列化写入方式的更改如何将最繁忙的存储库转移到Azure中，以及同一步骤如何为没有持久状态的副本打开大门。
我们如何到达这里移动的时机和形状是由代理转变驱动的：快速增长的流量，我们数据中心和周边地理区域的电力容量的硬性上限，以及物理供应链限制。在迁移开始时，剩余的容量与所有可能的扩展让我们有足够的时间安全迁移，但不足以缓慢迁移。
虽然我们已经原型化了新的架构方法，用于在云基础设施上扩展Git，但在这种增长下，同时改变存储架构和托管平台带来了太大的风险。鉴于我们的规模以及服务对社区的重要性，我们需要仔细排列工作顺序：首先移动数据，然后在架构到达后对其进行演进。