Enterprise Live Migrations が GA、GHES から ghe.com へほぼ止めずに移せる
GHES から GHEC Data Residency へ、同期を続けながら移して分単位でカットオーバーする Enterprise Live Migrations が GA。対応 GHES 版と GEI との使い分けを整理する。
Enterprise Live Migrations が
GitHub Enterprise Server（GHES）から GitHub Enterprise Cloud with Data Residency（GHEC DR）へ、リポジトリを稼働させたまま移す Enterprise Live Migrations（ELM） が一般提供になった。2026年9月1日付の GitHub Changelog に載っている。changelog のタイトルは移行先を ghe.com と呼び、本文では GHEC DR と書かれている。github.com 上の GHEC が移行先に含まれるかは、この changelog には書かれていない。
関係するのは、GHES から GHEC DR への移行を計画していて、停止時間を確保できないリポジトリを抱えるチームに限られる。GHES に残るつもりなら今日やることはない。移行を考えているチームには、対応バージョンの下限と、GitHub Enterprise Importer（GEI）との使い分けが判断材料になる。
同期を続けて、最後に残った差分だけを流し込む
ELM は移行元から移行先へデータを継続的に同期する。移行中も開発者は元のリポジトリで作業を続け、カットオーバーで止まるのは、その時点で処理中だった変更を流し切る時間だけだ。changelog はこれを「数日ではなく数分」（訳）と表現し、地理的に分散したチームが触る業務上重要なリポジトリで、移行を差し込める停止窓がない場合を想定していると書く。
対象として名指しされているのは、既存ツールの限界を押し上げる種類のリポジトリだ。深い git 履歴を持つ巨大なモノレポ、大量の issue とプルリクエスト、昼夜を問わない活動が挙げられている。リソース単位の進捗追跡があり、失敗はカットオーバー前に表面化する。進めるか止めるかを、その情報を見てから決められる。
ELM は GHES アプライアンス上でサービスとして動き、後述の gh elm CLI から操作する。
GEI を置き換えるものではない
changelog は ELM を GEI の補完と位置づけている。短い停止が許容できる素直な移行は GEI、無停止が要るリポジトリは ELM と、リポジトリの大きさ、形、活動量ごとに選ぶ。両方を同じ移行戦略の中で同時に走らせてよい、と明記されている。
この使い分けは、移行対象の棚卸しを先に済ませる必要があるということでもある。全リポジトリを ELM に載せる理由は changelog からは読み取れない。停止窓が取れないリポジトリを先に決め、残りは GEI に回す。
gh elm 拡張が GHES の REST API 経由で進める
操作は GitHub CLI の拡張 gh elm で行う。認証情報の設定から、移行の作成、監視、カットオーバーの開始までを、GHES の REST API を通じて扱う。出力は人が読む形式と JSON の両方があり、JSON はスクリプトと自動化向けだ。
進捗を定期的にチャットへ流す、カットオーバー前に失敗したリソースの一覧を機械的に検査する、といった運用は JSON 出力の側で組むことになるだろう。拡張のインストール手順と、使われる REST API のエンドポイントは changelog に載っていない。
対応する GHES は 6 系列、パッチ版に下限がある
| GHES の系列 | ELM が対応する最小パッチ版 |
|---|---|
| 3.17 | 3.17.18 以降 |
| 3.18 | 3.18.12 以降 |
| 3.19 | 3.19.9 以降 |
| 3.20 | 3.20.3 以降 |
| 3.21 | 3.21.3 以降 |
| 3.22 | 3.22.0 以降 |
出典：GitHub Changelog「Enterprise Live Migrations from GHES to ghe.com generally available」（2026年9月1日）
このリリースは最新の GHES パッチリリースとともに出荷される、と changelog は書いている。表の下限より古いパッチで動いている GHES は、ELM の対応範囲に入っていない。3.22 は 8月11日に changelog でリリース候補が案内された系列で、3.22.0 以降が最初から対象に入っている。
追加の移行経路へ広げる予定がある、とも書かれている。何が「追加の経路」に当たるのかは示されていないので、GHEC DR 以外の移行先を待つ判断はまだできない。
移行を計画しているなら、先に決めること
移行先の確認が先で、自動化の設計は最後に回る。
- 移行先が GHEC DR かを確認する。changelog が挙げる移行先はそれだけだ。
- 稼働中の GHES のパッチ版を上の表と突き合わせる。下限未満なら、移行計画の前にアップグレードが入る。
- リポジトリを二つに分ける。短い停止を許容できるものは GEI、停止窓が取れない大規模なものは ELM。並行実行は changelog が認めている。
gh elmの JSON 出力を前提に、進捗監視とカットオーバー判断の自動化を設計する。リソース単位の失敗はカットオーバー前に見えるので、そこで止める基準を先に決めておく。
料金と GHEC DR 側の前提条件は changelog に書かれていない。「処理中の変更」に git の push 以外、たとえば issue のコメントまで含まれるかも同様だ。契約と移行手順の詳細は、この changelog だけでは組めない。
GHES に残るチーム、および移行先が GHEC DR ではないチームにとって、この GA で変わることはない。