GitHub Live Migrations Cut Cutover to Minutes—Version Support Is the Gate

In its September 1, 2026 release notice, GitHub made Enterprise Live Migrations generally available for repository moves from GitHub Enterprise Server to GitHub Enterprise Cloud with Data Residency on GHE.com, described continuous synchronization that can reduce final cutover from days to minutes, and listed minimum source patches of GHES 3.17.18, 3.18.12, 3.19.9, 3.20.3, 3.21.3 and 3.22.0. The direct eligibility answer is therefore narrow: the destination must be GHE.com, the source must run a supported GHES patch, and the repository must satisfy ELM’s operational and content constraints.

An independent digest published September 2 also recorded the general-availability status, GHES-to-GHE.com scope, continuous synchronization and complementary roles of ELM and GitHub Enterprise Importer. Platform teams do not need to choose one tool for an entire enterprise: they can reserve ELM for repositories where avoiding a long write freeze matters and keep GEI for conventional moves that can tolerate brief downtime.

Start the decision tree with destination and downtime

The first branch is data residency and destination architecture. A repository qualifies for this ELM release only when it is moving from GHES to GitHub Enterprise Cloud with Data Residency on GHE.com; a move to another GitHub destination is outside the announced path, regardless of repository size.

For repositories on the supported route, downtime tolerance separates the strongest ELM candidates from GEI candidates. An active repository belongs in the ELM pool when a long freeze could block deployments, interrupt distributed contributors or stall time-sensitive work. A stable repository with a manageable maintenance window can remain on GEI, avoiding the additional coordination required by continuous synchronization.

• Use ELM: the destination is GHE.com, the GHES patch is supported, the repository passes preflight checks, and prolonged downtime presents material operational risk.
• Use GEI: its migration path supports the repository and a controlled period without normal repository access is acceptable.
• Remediate first: the route is otherwise eligible, but the source patch, connectivity, visibility, release assets or permissions fail an ELM prerequisite.
• Select another supported path: the planned cloud destination is not GHE.com.

The GHES patch and preflight conditions are hard gates

The version numbers are minimum patches within named GHES release lines, not permission to migrate from every installation labeled 3.17 or later. A platform team should record the appliance version and patch as evidence for each wave, then compare it with the current supported list before scheduling; documentation can change as GitHub adds patches or migration paths.

GitHub’s ELM preparation checklist requires an HTTPS source URL, outbound traffic to the destination, migrations enabled in the Management Console, GHES site-administrator access and GHE.com enterprise-owner access; it also sets concurrency ceilings of 10 repository migrations per source GHES instance and 20 per destination enterprise, rejects public repositories, limits release assets to 2 GB, and warns that force pushes during migration can rewrite history in a way ELM cannot reconcile. None of these gates can be offset by accepting more downtime.

The published materials have not remained perfectly synchronized: the preparation page has displayed preview labeling and version assumptions that differ from the later general-availability notice. For the launch described here, the dated release notice is the clearest published baseline, but production approval should use the current documentation or written confirmation from GitHub when the installed patch is not unambiguously covered.

Repository shape determines who should receive ELM capacity

Passing the eligibility checks does not automatically make ELM the best allocation. Continuous live updates consume more migration capacity than a conventional import, so the limited slots should go first to repositories whose activity, scale or business role makes a lengthy freeze unusually costly.

Large monorepositories with deep Git history, substantial issue and pull-request volume, or continuous contributions are the clearest candidates. Repository size alone is insufficient: a very large but mostly inactive archive may tolerate GEI, while a smaller repository tied to frequent production deployments may justify ELM because interruption carries greater operational impact.

Repository contents and organizational dependencies also affect the choice. ELM handles one repository per migration; organization settings, teams and projects are not part of that repository transfer. Teams should therefore inventory destination organization configuration separately instead of treating a successful repository copy as proof that the entire operating environment is ready.

The safest sequence keeps a go-or-stop point before cutover

The operational advantage comes from separating the long backfill from the final interruption. Developers can continue using the source during most of the migration while subsequent changes are synchronized. Cutover then archives the source, drains remaining changes and shifts the repository into its short read-only period.

1. Confirm GHE.com as the destination, record the exact GHES patch and resolve any ambiguity in the supported-version list.
2. Classify repositories by downtime tolerance, activity, size, visibility, release-asset limits and organization-level dependencies.
3. Verify HTTPS, outbound connectivity, migration settings, administrator privileges, destination ownership and credentials before starting a production wave.
4. Run a representative pilot and preserve its status output, failure details and acceptance results. Tell developers that force pushes must stop while the migration is active.
5. At the ready-for-cutover checkpoint, confirm that expected recent changes are present, review resource-level failures and give one named operator authority to proceed or stop.
6. Begin cutover, keep the source read-only, validate repository data and required destination configuration, and permit new destination writes only after acceptance checks pass.

The most useful rollback checkpoint is immediately before destination writes are allowed. If the source has to be restored, keeping the destination read-only prevents two copies from accepting divergent work. Once both repositories receive new commits or configuration changes, recovery becomes reconciliation rather than a clean reversal.

General availability changes the freeze, not the evidence burden

The confirmed launch gives eligible GHES repositories a generally available live route to GHE.com and can compress the final interruption to minutes. It does not remove destination restrictions, patch requirements, concurrency limits, repository exclusions or post-migration configuration work.

The resulting migration portfolio should usually be mixed: ELM for supported repositories where sustained activity or operational criticality makes downtime expensive, and GEI where a brief planned outage is acceptable. The remaining uncertainty is version alignment across GitHub’s published pages, so the safest production record is a repository-level eligibility decision, a captured preflight result and an explicit acceptance checkpoint before either copy receives new work.

Also read:

• Google Translate Starts Global Live Speech Rollout, but Lessons Stay Uneven
• Runway Characters Is Live—but Web Sessions Stop at Two Minutes
• Instagram Live’s 1,000-Follower Gate Still Locks Out Small Creators