GitHub Enterprise Live Migrations Is Now GA: Zero Downtime

GitHub’s Enterprise Live Migrations (ELM) went generally available on September 1. If your organization has been running GitHub Enterprise Server on-prem and stalling on cloud migration because you couldn’t schedule the downtime — or because your monorepo breaks every migration tool you throw at it — that excuse is gone. ELM lets developers keep committing right through the migration. Cutover takes minutes.

How It Works

ELM runs a continuous sync from your GHES instance to GitHub Enterprise Cloud with Data Residency (GHEC DR). While the sync runs, developers keep working on the source repo — opening PRs, merging code, committing changes. When you’re ready to switch over, ELM drains only the remaining in-flight changes. The cutover window is minutes, not a maintenance weekend.

This is a meaningful departure from the existing GitHub Enterprise Importer (GEI), which takes repositories offline for the entire migration duration. For a large, globally active repo, that’s a scheduling nightmare. ELM removes it.

ELM runs as a service on your GHES appliance and is driven by the gh elm CLI extension. Site administrators manage migrations via SSH using the GHES REST API. According to the GitHub changelog announcement, the GA build has four months of preview hardening behind it:

# Enable ELM on your GHES appliance
ghe-config app.elm-exporter.enabled true
ghe-config-apply

# Install the CLI extension
gh extension install github/gh-elm

# Create and start migration
gh elm migration create --source-repo ORG/REPO --destination-enterprise ENTERPRISE
gh elm migration start MIGRATION_ID

GEI vs. ELM: Use Both

GitHub is clear that ELM doesn’t replace GEI — it complements it. The distinction matters:

• GitHub Enterprise Importer (GEI): Handles simpler repos, works at the org level, supports more concurrent migrations. Fine if brief downtime is acceptable.
• Enterprise Live Migrations (ELM): Purpose-built for massive monorepos with deep git history, large PR and issue volumes, and constant activity. Near-zero downtime. Single repository scope.

ELM is the tool GEI breaks on. If you have a 15GB monorepo touched by 200 engineers daily, GEI likely isn’t finishing that cleanly. ELM handles it. Per the official ELM documentation, ELM provides “granular repository-level visibility into migration progress, surfacing failures so you can be confident the migrated repository is an accurate replica.”

The tradeoffs: ELM migrates one repository at a time and caps at 10 concurrent migrations per GHES instance, 20 per destination enterprise. Organization-level data — settings, teams, projects — is not included and must be reconfigured manually on the destination.

Version Requirements

ELM requires a supported GHES patch version. Check yours before starting:

• 3.17.18+
• 3.18.12+
• 3.19.9+
• 3.20.3+
• 3.21.3+
• 3.22.0+

If you’re not on one of these minimums, GHES update comes before ELM planning.

The Data Residency Unlock

ELM specifically targets GHEC DR (ghe.com), not classic github.com GHEC. That distinction matters for regulated industries. GitHub has expanded data residency coverage significantly: the EU option now includes EFTA countries Norway and Switzerland (expanded March 2026), and supported regions cover the US, EU, Australia, and Japan.

GitHub Copilot also gained data residency support in the US and EU as of April 2026, with FedRAMP compliance. Taken together, the last three objections for regulated enterprises — downtime risk, data sovereignty, and AI tooling access — are now addressed. Expect migration volumes to accelerate in Q4.

What to Do Now

If you’re running GHES, three steps:

1. Check your GHES version. If you’re not on a supported patch, that’s your first task.
2. Identify priority repositories — specifically those too large, too active, or too critical to take offline.
3. Install the gh elm extension and review the migration guide before touching production.

ELM went GA with four months of public preview behind it (preview launched May 7, 2026). The rough edges have had time to smooth. It’s reasonable to start planning real migrations now rather than waiting for a future release cycle.