Share with your CTO
GitHub is shipping Enterprise Live Migrations (ELM) into general availability, giving engineering organizations a near-zero-downtime path to move repositories from GitHub Enterprise Server to GitHub Enterprise Cloud with Data Residency. The tool continuously syncs data during migration so developers never stop committing, with cutover measured in minutes rather than days. It’s built specifically for monorepos with deep git history, high pull request volume, and round-the-clock activity, and it runs alongside the existing GitHub Enterprise Importer to let teams match the right tool to each repository’s risk profile.
What this means for your business
The historical cost of a major repository migration has been a forced maintenance window, which for globally distributed teams means someone is always losing productive hours. ELM eliminates that negotiation entirely. A 500-engineer org spanning London, Austin, and Singapore no longer needs to find a three-hour window where nobody is pushing to a critical monorepo, because the cutover happens while the work continues.
GitHub’s decision to build this as a continuous-sync service rather than a snapshot-and-freeze tool reflects where enterprise engineering is actually heading. The implicit assumption in older migration tooling was that repositories could tolerate downtime. That assumption broke down as monorepos became the architectural choice for large codebases, and as CI/CD pipelines made any repository pause immediately visible as a pipeline stall. ELM is GitHub’s acknowledgment that “migration window” is an organizational concept that engineering reality has outpaced.
The two-tool strategy, ELM for high-stakes repositories paired with GitHub Enterprise Importer for straightforward ones, is the right call operationally, but it introduces a governance question worth tracking: who inside your engineering org decides which repositories qualify for which path, and does that decision get documented before a migration goes sideways? The signal worth watching is whether GitHub eventually collapses these into a single adaptive tool or keeps them deliberately separate as complexity tiers.
Concept deep-dive: Continuous sync migration
Traditional repository migrations copy a snapshot of data, lock the source, and replay any changes made during the copy, requiring a hard freeze at some point. Continuous sync migration instead keeps source and target in ongoing replication throughout the process, like a live database replica, so the gap between them is always small. Cutover becomes a brief drain of in-flight writes rather than a full transfer. For a monorepo receiving hundreds of commits per day, this difference translates directly into zero forced downtime versus a multi-hour freeze that blocks every pipeline depending on that repository.
Based on reporting from Enterprise Live Migrations from GHES to ghe.com generally available, originally published 2026-09-01 18:24:00.
