GitHubのライブ移行が正式版に、停止時間は数分でも対象版に条件

GitHubは2026年9月1日、GitHub Enterprise Server（GHES）からデータレジデンシー対応のGitHub Enterprise Cloud（GHE.com）へリポジトリを移すEnterprise Live Migrations（ELM）を一般提供した。GitHubの一般提供告知 では、移行中もデータを継続同期し、開発者が作業を続けたまま、最終カットオーバーを数分に短縮できるとしている。

対象は任意のGitHub環境間ではなく、対応パッチを適用したGHESからGHE.comへのリポジトリ移行だ。9月3日付の 独立した技術更新まとめ も、同じ経路でELMが一般提供になったことと、大規模または常時更新されるリポジトリで運用上の選択肢が増えたことを報じている。

一般提供時の対象GHES版にはパッチ条件がある

一般提供の告知に記載された移行元は、GHES 3.17.18以降、3.18.12以降、3.19.9以降、3.20.3以降、3.21.3以降、3.22.0以降だ。同じ3.17系や3.20系でも、それより古いパッチは一般提供時の対応範囲に含まれない。

このため、「GHES 3.17以降」というメジャー・マイナー番号だけでは適格性を判断できない。GitHubは今後、対応する移行経路を拡大する方針も示しているため、実行時には稼働中の完全なバージョン番号を最新の準備要件と照合する必要がある。

移行先にも制約がある。今回正式版になった経路はGitHub Enterprise Cloud with Data Residency、すなわちGHE.com向けであり、通常のGitHub.comを含むあらゆる移行先に使える汎用複製機能ではない。

ELMとGitHub Enterprise Importerは置き換え関係ではない

ELMはGitHub Enterprise Importer（GEI）の全面的な後継ではなく、両者はリポジトリの性質と許容停止時間で使い分ける。短い計画停止を受け入れられる比較的単純な移行にはGEI、長時間止めにくい重要リポジトリや、深いGit履歴を持つ大規模モノレポにはELMが想定されている。

ELMの違いは、最初のデータ転送が終わるまで移行元を固定するのではなく、その後の対応する変更も移行先へ送り続ける点にある。カットオーバー時に処理するのは主に残っている変更であり、「数分」とされるのは移行計画全体ではなく、この最終停止区間だ。

方式は企業全体で一律に決める必要はない。同じ移行計画の中で、停止の影響が大きいリポジトリをELMへ、短い停止を許容できるものをGEIへ割り当てる構成も可能だ。

バックフィルからカットオーバーまでの工程表

実作業は、適格性の確認から初回バックフィル、継続同期の監視、失敗リソースの評価、カットオーバーへ進む。停止時間を短くできても、準備と検証を省略できるわけではない。

1. 経路と版を確認する：移行元の完全なGHESパッチ番号と、移行先がGHE.comであることを確かめる。
2. 環境と認証を準備する：GHES側の移行サービス、移行先への通信、GitHub CLIのELM拡張機能、移行元と移行先の管理権限および認証情報を設定する。
3. 移行を作成して開始する：移行元・移行先の組織とリポジトリを指定し、事前チェックを通過した後に初回データのバックフィルとライブ更新を動かす。
4. 状態を監視する：移行先にデータと対応する更新が届いているかを確認し、リソース単位で示される失敗を調べる。
5. 切替可否を決める：重要な欠落がなく、対象外データを別途再構成できる状態になってからカットオーバーを開始する。

移行中も開発者は原則として移行元を利用できるが、すべての操作を安全に差分同期できるわけではない。特にGit履歴を書き換えるforce pushは増分同期で整合できないため、実行中の運用ルールとして避ける必要がある。

移るのは主にリポジトリデータ、組織情報には除外がある

GitHubの移行データ一覧 によると、Gitの参照・オブジェクト・履歴、Issueとコメント、Pull Request、提出済みレビュー、ラベル、マイルストーン、リリース、リポジトリ単位の設定などは広く対象になる。一方、組織の設定、チーム、Projects、組織Webhookは移行されず、移行先で再構成しなければならない。

リポジトリ単位でも完全な複製ではない。リポジトリruleset、forkからのPull Request、未提出のレビューは対象外で、ブランチ保護は一部だけが移る。別リポジトリを参照するリンクも移行先に合わせて書き換えられないため、関連リポジトリを同時に移しても参照先の確認が要る。

ライブ更新にも対応イベントと非対応イベントがある。初回バックフィル後はWebhookで変更を捕捉するが、リポジトリの削除・名称変更・移管や、一部の削除操作などは反映されない。Check runs、Check suites、GitHub Pages設定は初回バックフィルのみで、その後の変更はライブ更新の対象外だ。

GHESユーザーに関連付いた移行データは、Gitコミットを除き、移行先でmannequinという仮IDに結び付けられる。移行完了後は、実アカウントへの活動の再帰属と、移行先組織でのメンバーシップやアクセス権の設定が別途必要になる。

切替可能の表示だけでは判断を終えられない

ELMはリソース単位の進捗と失敗をカットオーバー前に確認できる。全体が切替可能な段階へ進んでも個別リソースの失敗が残る可能性があるため、状態名だけで承認せず、欠落したIssue、Pull Request、コメント、設定などが業務に与える影響を判定する必要がある。

カットオーバーを開始すると、残っている対応可能な変更が送られ、移行元リポジトリはアーカイブされて読み取り専用になる。承認条件には、重要なGit履歴と作業項目が移行先にあること、許容できない失敗がないこと、対象外の組織設定や権限を復元できることを含めるのが妥当だ。

2026年9月11日時点で一般提供が確認できるのは、指定パッチを満たすGHESからGHE.comへの経路である。最終停止を数分に抑える仕組みは正式利用できるようになったが、実際の切替時期は、ライブ更新の対象外操作とリソース別の失敗を確認したうえで決めなければならない。