GitHub Enterprise Live Migrationsとは？GHESからGHE.com移行の変更点と確認ポイント

GitHub Enterprise Server（GHES）からGHE.comへ移行したいものの、「大規模リポジトリを長時間止められない」「海外拠点の開発チームが常に使っている」「データレジデンシー対応のGitHub Enterprise Cloudへ段階的に移りたい」と悩む管理者は多いはずです。

結論から言うと、GitHubのEnterprise Live Migrations（ELM）は、GHESからデータ所在地付きGitHub Enterprise Cloud、つまりGHE.comへリポジトリを移行する際、移行中も開発者がソースリポジトリを使い続けられるようにする新しい移行手段です。2026年5月の公式Changelogでパブリックプレビューとして案内され、従来の移行で課題になりやすかった長時間のコードフリーズを短縮することが狙いです。(The GitHub Blog)

ただし、ELMは「すべてを自動で移す万能ツール」ではありません。対象は基本的にリポジトリ単位の移行で、組織設定、チーム、プロジェクトなどの組織レベルのデータは移行対象外です。管理者は、GHESの対応バージョン、GHE.com側の組織設計、Personal Access Token、ネットワーク、開発者への周知、カットオーバー後のユーザー再紐づけまで確認してから導入する必要があります。(GitHub Docs)

Enterprise Live Migrationsは何が変わるのか

Enterprise Live Migrationsの大きな変更点は、移行の考え方が「リポジトリを止めてまとめて移す」から、「移行先へ継続的に同期し、最後に短時間で切り替える」に近づくことです。

GitHubの公式発表では、ELMはGHES上でサービスとして動作し、elm CLIで操作する移行ツールとして説明されています。初期データを移行した後も、Webhookを使ってコミットや設定変更などの更新を取り込み、最終カットオーバー時の停止時間を短くする仕組みです。(The GitHub Blog)

変更点	実務上の意味
移行中もソースリポジトリを使える	開発者は移行期間の大半で作業を継続できる。停止が必要なのは主に最終カットオーバー時
大規模モノレポを想定	深いGit履歴、大量のIssueやPull Request、常時更新されるリポジトリで効果が出やすい
GitHub Enterprise Importerと併用できる	すべてをELMに寄せるのではなく、重要リポジトリはELM、短時間停止が許容できるものはGEIという使い分けができる
進捗や失敗を細かく確認できる	カットオーバー前に失敗したリソースを確認し、切り替え判断をしやすい
GHE.comへの移行に特化	移行先はデータ所在地付きGitHub Enterprise Cloud、つまりGHE.comが前提になる

ポイントは、ELMが「GitHub Enterprise Importer（GEI）の完全な置き換え」ではないことです。公式ドキュメントでも、ELMとGEIは別ツールであり、リポジトリの規模や停止許容度に応じて使い分けることが示されています。ELMは、特に長時間止められない重要リポジトリや、GEIでは扱いにくい大規模・複雑なモノレポで検討価値が高いツールです。(GitHub Docs)

ELMを使うべき企業・リポジトリ

Enterprise Live Migrationsの対象は、GHESからGHE.comへ移行する企業です。GHE.comは、データ所在地付きGitHub Enterprise Cloudで、企業ごとの専用サブドメインを使って運用されます。日本を含む複数リージョンが用意されており、データの保存場所をより細かく管理したい企業に向いた構成です。(GitHub Docs)

ELMの優先度が高いのは、次のようなリポジトリです。

リポジトリの状態	ELMを検討すべき理由
事業継続に直結する本番系リポジトリ	長時間のコードフリーズがデプロイ停止や障害対応の遅れにつながる
グローバルチームが常時作業するリポジトリ	全拠点にとって都合のよい停止時間を確保しにくい
巨大なモノレポ	深い履歴、大量のPull Request、Issue、レビューコメントがあり、通常の移行負荷が高い
移行前に詳細な進捗を見たいリポジトリ	リソース単位の失敗を確認してからカットオーバー判断をしたい
GHE.comのデータレジデンシーへ移る中核リポジトリ	移行後のURL、API、IdP連携、CI/CDを含めて慎重に切り替える必要がある

一方で、短時間の停止が問題にならない小規模リポジトリや、組織設定ごと一括で移したいケースでは、ELMだけで要件を満たせない可能性があります。ELMの移行は1回につき単一リポジトリが対象で、組織設定、チーム、プロジェクトなどは移行に含まれません。(GitHub Docs)

管理者・開発者への影響範囲

ELMの影響は、GitHub管理者だけにとどまりません。移行先がGHE.comになるため、認証、URL、API、Actions、開発者のGit操作、組織メンバーシップまで確認が必要です。

対象者	主な影響	確認すべきこと
GHESサイト管理者	`elm` CLIの実行、GHES設定、移行監視を担当	対応バージョン、HTTPS、移行機能、BLOBストレージ、PATの権限
GHE.com Enterprise Owner	移行先Enterpriseと組織の管理を担当	Enterprise Managed Users、IdP連携、移行先組織、課金、データ所在地
Organization Owner	移行後のアクセス復元や組織設定を担当	メンバー追加、チーム、ポリシー、プロジェクト、Mannequinの再割り当て
開発者	移行中の作業ルールと移行後の接続先変更が必要	force pushを避ける、カットオーバー時間を把握する、remote URLを更新する
CI/CD・SRE担当	Actions、Webhook、API、レジストリURLの確認が必要	`api.github.com`やGitHub.com前提のURLをGHE.com向けに見直す
セキュリティ担当	トークン、監査、ネットワーク許可リストを確認	PATの保管、SSO承認、ホスト名・IPアドレス、SSHフィンガープリント

GHE.comでは、GitHub.comとはURLやAPIエンドポイントの形式が異なります。たとえばREST APIやGraphQL APIを使う連携は、企業の専用GHE.com URLに向ける必要があります。また、GHE.comではパブリックリポジトリが利用できないため、公開リポジトリをそのまま移行する前提は避けるべきです。(GitHub Docs)

移行されるデータと移行されないデータ

ELMはリポジトリレベルのデータを広く移行しますが、組織レベルの設定は対象外です。この線引きを誤ると、移行後に「チーム権限がない」「プロジェクトがない」「Webhookが動かない」といったトラブルにつながります。

分類	移行される主なデータ	注意点
リポジトリ設定	リポジトリメタデータ、可視性、説明、既定ブランチ、PR設定、Actions設定、Branch protection、リポジトリWebhookなど	Organization-level webhookは対象外
Gitデータ	refs、objects、履歴、LFSオブジェクト、Wiki	LFSはソース側で有効化されている必要がある
Issue関連	Issue、コメント、リアクション、ラベル関連付け、タイムラインイベントなど	一部のライブ更新イベントは対象外
Pull Request関連	Pull Request、レビュー、レビューコメント、スレッド、状態など	fork由来のPull Requestや未送信レビューは移行対象外
リリース・CI	Releases、Release assets、Commit status checks、Check runs、Check suitesなど	Release assetは1ファイル2GBまで。Check runsなど一部は初期移行のみでライブ更新対象外
ユーザー情報	参照されたGHESユーザーはMannequinとして表現される	移行後に実ユーザーへ再割り当てが必要

公式ドキュメントでは、ELMは「ほぼすべてのリポジトリレベルのデータ」を移行する一方、チーム、プロジェクト、組織設定、組織Webhookなどの組織レベルリソースは移行対象外とされています。さらに、ライブ更新に含まれない操作もあるため、移行中に開発者が行う操作がすべて移行先へ反映されるとは限りません。(GitHub Docs)

導入前に確認すべき設定

GHESの対応バージョンを確認する

ELMを使うには、対応するGitHub Enterprise Serverのパッチリリースへアップグレードしておく必要があります。公式ドキュメントでは、最小バージョンとして3.20.2、3.19.6、3.18.9、3.17.15が示されています。ELMはパブリックプレビューで変更される可能性があるため、実行前には必ず最新のGitHub Docsで対象バージョンを確認してください。(GitHub Docs)

確認項目は次のとおりです。

項目	確認内容
GHESバージョン	対応パッチリリース以上か
GHES URL	HTTPS URLを使用しているか。HTTPはサポートされない
移行機能	Management ConsoleのMigrations設定が有効か
BLOBストレージ	移行用のBLOBストレージが構成済みか
管理権限	実行者がGHESのsite adminであり、GHE.comのenterprise ownerでもあるか

GHE.com側の組織設計を先に決める

ELMは、移行先のGHE.com組織が存在しない場合にターゲット組織を作成できます。ただし、ソース組織の設定まで移行するわけではありません。新しい組織を作る場合は、移行前に以下を決めておくべきです。

設計項目	決めること
組織名	既存組織へ移すか、新規組織を作成するか
リポジトリ可視性	GHE.comではpublicが使えないため、internalまたはprivateで運用する
チーム設計	既存GHESのチーム構成を再現するか、移行を機に整理するか
IdP連携	Entra IDやOktaなどでユーザー・グループをどうプロビジョニングするか
命名規則	組織名、リポジトリ名、チーム名、環境名のルールを統一するか

移行は、単なるデータコピーではなく、GitHub運用を見直す機会でもあります。特にGHE.comではEnterprise Managed Usersが前提になるため、個人アカウント中心の運用から、IdPを起点にした企業管理のアカウント運用へ変わる点に注意が必要です。(GitHub Docs)

Personal Access Tokenはclassicを使う

ELMでは、ソースのGHESと移行先のGHE.comの両方に対して、personal access token classicが必要です。fine-grained tokenではなく、classic PATが前提です。

作成場所	必要なスコープ
GitHub Enterprise Server	`repo`、`admin:org`、`admin:repo_hook`、`admin:org_hook`
GHE.com	`repo`、`workflow`、`admin:org`、`admin:repo_hook`、`admin:enterprise`

GHE.com側の組織でSAML SSOが強制されている場合は、作成したトークンをSSOに対して承認する必要があります。また、同一GHESインスタンスから複数のELM移行を並行実行する場合は、同じ実行者が同じトークンを使ってelmコマンドを実行する必要があります。(GitHub Docs)

ネットワークとURL差分を確認する

GHE.comへ移行すると、URLや接続先がGitHub.comとは異なります。特に、CI/CD、Webhook、GitHub Apps、社内プロキシ、ファイアウォール、監視ツールは影響を受けやすい領域です。

確認対象	見直すポイント
Git clone	SSHでは`[email protected]:OWNER/REPO.git`のような形式を使う
REST・GraphQL API	`api.github.com`ではなく、GHE.com専用API URLへ向ける
GitHub Actions	Marketplace由来のActionや外部API呼び出しがGHE.comで動くか確認する
Container registry	GitHub.com前提の`ghcr.io`だけでなく、GHE.com側のレジストリURLを確認する
OIDC	ActionsのOIDC発行元URLが変わるため、クラウド側の信頼設定を更新する
許可リスト	GHE.comのホスト名、IPアドレス、SSHフィンガープリントを許可する

公式ドキュメントでは、GHE.comのネットワーク詳細として、専用サブドメイン、GitHub関連ホスト名、リージョン別IPアドレス、SSHの利用方法が案内されています。移行前に、開発端末だけでなく、CIランナー、デプロイ環境、社内ネットワーク機器から接続できるか検証しておきましょう。(GitHub Docs)

移行の基本フロー

ELMの移行は、準備、作成、開始、監視、カットオーバー、移行後対応の順で進めます。公式ドキュメントでは、site adminがSSH経由のターミナルでelm CLIを実行し、ソースと移行先のPATを使って操作する流れが示されています。(GitHub Docs)

手順	作業内容	失敗しやすいポイント
移行対象を選ぶ	重要リポジトリ、巨大モノレポ、停止できないリポジトリを優先する	全リポジトリを一度にELMへ寄せようとする
GHESを設定する	ELM関連設定、移行機能、BLOBストレージを確認する	設定反映時の短い停止を周知していない
トークンを用意する	GHESとGHE.comのclassic PATを作成する	SSO承認やスコープ不足で失敗する
migrationを作成する	ソース組織・リポジトリ、ターゲット組織・リポジトリを指定する	publicリポジトリや組織設定の扱いを誤る
migrationを開始する	backfillとlive updateを開始する	開発者にforce push禁止を伝えていない
状態を監視する	`elm migration status`で進捗と失敗を確認する	ready表示だけを見て失敗リソースを見落とす
カットオーバーする	ソースをロックし、最終更新を反映する	業務時間中に実行して開発を止める
移行後対応を行う	ユーザーアクセス、Mannequin、チーム、組織設定を復元する	移行完了直後に開発者が使えない

基本コマンドの流れは次のイメージです。実際の値は、自社の組織名、リポジトリ名、GHE.comのAPI URLに置き換えてください。

elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO \
  --target-api GHEC-API-URL \
  --pat-name system-pat

移行IDを保存したら、開始と監視を行います。

elm migration start --migration-id $MIGRATION_ID
elm migration status --migration-id $MIGRATION_ID

カットオーバー可能な状態になったら、最終切り替えを実行します。

elm migration cutover-to-destination --migration-id $MIGRATION_ID

カットオーバー時にはソースリポジトリがロックされ、開発者はソース側を利用できなくなります。ELMは停止時間を短くするための仕組みであり、停止時間を完全になくすものではありません。(GitHub Docs)

開発者へ事前に伝えるべきこと

ELMの導入で管理者が見落としやすいのは、開発者への周知です。移行中もソースリポジトリを使えるとはいえ、通常時と同じように何をしてもよいわけではありません。

特に伝えるべき内容は次のとおりです。

周知内容	理由
リポジトリは新しい場所へ移動する	移行後にclone URL、remote URL、ブックマーク、ドキュメントを更新する必要がある
最終カットオーバー時は短時間使えなくなる	作業中のpushやレビューを避ける時間帯を決めるため
移行中のforce pushは禁止する	ELMが解決できない形でGit履歴が変わる可能性がある
一部の操作は移行先に反映されない可能性がある	ライブ更新対象外の操作を理解してもらうため
移行後のアクセス権が変わる場合がある	GHE.com側の組織メンバーシップやチーム権限が必要になるため

開発チームには、単に「移行します」と伝えるのではなく、「いつからいつまで通常作業できるのか」「どの時間帯にpushを避けるべきか」「移行後にどのURLを使うのか」を具体的に知らせることが重要です。公式ドキュメントでも、移行中はforce pushを避けるべきこと、移行中の一部操作が移行先に反映されない可能性があることが明記されています。(GitHub Docs)

移行後に必ず行う作業

ELMでカットオーバーが完了しても、移行プロジェクトは終わりではありません。GHE.com側でユーザーが実際に作業できる状態にするには、アクセス権とユーザーアクティビティの整理が必要です。

移行後タスク	内容
ユーザーを組織に追加する	GHESとGHE.comでは認証・プロビジョニングが異なるため、組織メンバーシップは自動で引き継がれない
リポジトリアクセスを付与する	移行済みリポジトリに必要なメンバーやチームを追加する
Mannequinを再割り当てする	Issue、PR、コメントなどのアクティビティを実ユーザーへ紐づける
Gitコミットの著者情報を確認する	コミット著者はメールアドレスに基づいてGitHubユーザーへ紐づく
組織設定を再作成する	ポリシー、チーム、プロジェクトなどをGHE.com側で設定する
CI/CDを再実行する	Actions、Webhook、外部連携、デプロイフローがGHE.comで動くか確認する

公式ドキュメントでは、移行後にユーザーアクセスの復元、Mannequinの再割り当て、Gitアクティビティの再割り当て、組織設定の再作成が必要とされています。特にEnterprise Managed Users環境では、ユーザーが自分でメールアドレスを追加してコミット著者を再紐づけできない場合があるため、IdP側のメールアドレス設計も確認しておくべきです。(GitHub Docs)

よくある失敗と回避策

ELMは便利な移行手段ですが、プレビュー段階の機能であり、設計や周知を省略するとトラブルが起きやすくなります。

失敗例	原因	回避策
完全無停止だと思っていた	ライブ同期はするが、カットオーバー時にソースがロックされる	短い停止時間を前提に、カットオーバー時間を決めて周知する
移行後にチーム権限がない	組織レベルのチームや設定は移行されない	GHE.com側でチーム、ポリシー、プロジェクトを事前に作る
publicリポジトリが移行できない	GHE.comではpublicリポジトリを使えない	移行前にinternalまたはprivate運用へ切り替える
PAT認証で失敗する	スコープ不足、fine-grained token使用、SSO未承認	classic PAT、必要スコープ、SSO承認をチェックリスト化する
Actionsが移行後に動かない	API URL、OIDC、Marketplace由来Action、外部参照がGitHub.com前提	本番移行前にGHE.com上でワークフローを検証する
ユーザーの貢献履歴が期待通り表示されない	Mannequin再割り当てやメールアドレス紐づけが未完了	移行後タスクとしてユーザー再紐づけを必ず実施する
リンクが一部期待通りにならない	別リポジトリへの参照は同じ宛先を指し続ける場合がある	クロスリポジトリ参照を棚卸しし、重要リンクは手動確認する

特に、GHE.comへの移行ではURL差分が広範囲に影響します。GitHub Actionsのワークフロー、社内スクリプト、GitHub Apps、Bot、Webhook、ドキュメント内リンクにgithub.comやapi.github.comがハードコードされている場合は、移行前に洗い出しておきましょう。(GitHub Docs)

管理者が最初にやるべきこと

Enterprise Live Migrationsをすぐに本番適用するのではなく、まずは移行対象の優先順位と検証計画を作るべきです。おすすめの進め方は次のとおりです。

優先順	作業	成果物
1	GHESからGHE.comへ移すリポジトリを棚卸しする	リポジトリ一覧、サイズ、重要度、停止許容時間
2	ELM向きのリポジトリを選ぶ	重要リポジトリ、巨大モノレポ、常時稼働リポジトリの候補
3	GHESとGHE.comの前提条件を確認する	バージョン、HTTPS、移行設定、IdP、ネットワーク、PAT
4	小さめの代表リポジトリでパイロット移行する	手順書、所要時間、失敗パターン、復旧手順
5	開発者向け周知文を作る	作業禁止事項、カットオーバー時間、移行後URL
6	本番リポジトリを段階的に移行する	リポジトリごとの実行計画、監視、移行後チェックリスト

ELMの価値は、単に「移行時間を短くする」ことではありません。重要なのは、停止時間を短くしながら、移行前に進捗や失敗を確認し、開発者への影響をコントロールできる点です。

まずは、止めにくいリポジトリ、大きすぎて通常移行が不安なリポジトリ、GHE.com移行後のCI/CD影響が大きいリポジトリを洗い出してください。そのうえで、GHESの対応バージョン、GHE.comの組織設計、classic PAT、ネットワーク、移行後のMannequin再割り当てまで含めたチェックリストを作ることが、ELM導入の最初の一歩です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。