GitHub has moved Enterprise Live Migration (ELM) to general availability, adding a continuously‑syncing service that copies repositories from GHES to GHEC DR and finishes the cutover in minutes. For teams that run AI pipelines, manage cloud platforms, operate CI/CD, or enforce security policies, the ability to shift massive, active monorepos without a planned outage removes a major coordination bottleneck.
What Changed
ELM now runs as a built‑in service on the GHES appliance and is controlled through the gh elm CLI extension. The service keeps source and target in lock‑step, letting developers continue to push commits, open issues, and file pull requests while the migration progresses. When the operator triggers cutover, only the remaining in‑flight changes are drained, reducing the final downtime to a few minutes. The feature supports GHES versions 3.17.18+ through 3.22.0+ and ships with the latest GHES patch releases.
Why Engineers Should Care
- Zero‑disruption releases: AI model training jobs or data‑processing pipelines that pull code from a repository can keep running while the backend moves to the cloud.
- Monorepo readiness: ELM is explicitly designed for repositories with deep history, large issue and PR counts, and constant activity, which are common in platform and security tooling.
- Automation friendly: The CLI provides both human‑readable and JSON output, enabling scripted monitoring and integration with existing DevOps tooling.
- Compliance alignment: Moving to
GHEC DRsatisfies data‑residency requirements without needing a separate migration window.
Architectural and Operational Implications
- ELM runs alongside the existing GitHub Enterprise Importer (GEI); teams should evaluate each repository’s size and tolerance for brief downtime to decide which tool to apply.
- Credential configuration is performed through the
gh elmextension, which talks to the GHES REST API. Proper secret handling and least‑privilege API tokens remain essential. - Resource‑level progress tracking surfaces failures before cutover, so operators can pause or rollback without affecting production workloads.
- Because the service lives on the GHES appliance, capacity planning must account for the additional CPU and I/O load during the sync phase.
- Automation scripts can consume the JSON output; a typical start command looks like:
gh elm create --source ghes.example.com --target ghec.example.com
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Adopt ELM for any repository that cannot afford a maintenance window, especially large monorepos that feed CI pipelines or security scanners. Pair it with GEI for smaller, low‑risk repos to keep overall migration time short. Verify that your GHES instance meets the supported version matrix, provision API credentials with minimal scopes, and instrument monitoring around the ELM progress API to catch pre‑cutover issues early. Finally, update your migration playbooks to include the gh elm CLI steps and JSON‑based health checks, ensuring a repeatable, near‑zero‑downtime path to the cloud.