GitLabからGitHubへ移行する方法｜gh gl2ghの手順・対応範囲・制限

GitLabからGitHubへリポジトリを移行したいものの、「ソースコード以外のIssueやマージリクエストも引き継げるのか」「複数プロジェクトをまとめて移行できるのか」と悩む管理者は少なくありません。

2026年8月3日、GitHub Enterprise ImporterによるGitLabからGitHub Enterprise Cloudへの移行機能が一般提供されました。GitHub CLI拡張のgh gl2ghを使うことで、GitLab.comまたは保守対象バージョンのGitLab Self-Managedから、単体リポジトリと複数リポジトリをセルフサービスで移行できます。

移行先として利用できるのは、github.comまたはghe.com上のGitHub Enterprise Cloudです。オンプレミス版のGitHub Enterprise Serverは移行先にできません。また、ソースコードやIssue、マージリクエストなどは移行できますが、権限、CI/CD、Git LFSオブジェクトなどは別途対応が必要です。(The GitHub Blog)

GitLabからGitHubへの移行GAで何が変わったのか

今回の一般提供により、GitLabからGitHub Enterprise Cloudへのリポジトリ移行を、GitHubの支援サービスを前提とせず、管理者自身がgh gl2ghで実行できるようになりました。

主な対応範囲は次のとおりです。

項目	対応内容
移行元	GitLab.com、保守対象バージョンのGitLab Self-Managed
移行先	github.com上のGitHub Enterprise Cloud
データ所在地対応	ghe.com上のGitHub Enterprise Cloud
単体移行	`gh gl2gh migrate-repo`
一括移行	`gh gl2gh generate-script`で移行スクリプトを生成
アーカイブ保存先	GitHub管理ストレージ、AWS S3、Azure Blob Storage
非対応の移行先	GitHub Enterprise Server

GitLab Self-Managedについては、サポート終了済みの古いバージョンではなく、GitLabが現在保守しているバージョンが対象です。古いバージョンは、動作確認や評価が行われていないため、先にGitLabをアップグレードしてから移行するのが安全です。(GitHub Docs)

単純なGitミラー移行との違い

git clone --mirrorとgit push --mirrorでも、ブランチ、タグ、コミット履歴などはコピーできます。しかし、この方法ではIssue、コメント、マージリクエスト、マイルストーン、リリースなどのプロジェクト情報は移行できません。

GitHub Enterprise Importerは、GitLabプロジェクトを.tar.gz形式のアーカイブとしてエクスポートし、次の流れで移行します。

GitLabプロジェクトからGitデータとプロジェクトメタデータをエクスポートする
gh gl2ghを実行している端末にアーカイブを一時保存する
GitHubが読み取れるBlobストレージへアップロードする
GitLabの各データをGitHub上の対応するデータへ変換してインポートする

この仕組みにより、ソースコードだけでなく、開発履歴やコミュニケーション履歴も一定範囲で引き継げます。アーカイブを実行端末に一時保存するため、移行端末には対象プロジェクトのアーカイブを格納できる空き容量も必要です。(GitHub Docs)

移行できるデータと移行できないデータ

gh gl2ghは多くのプロジェクト情報を移行できますが、GitLabの設定を完全に複製する機能ではありません。移行後に何を再設定する必要があるか、事前に整理しておくことが重要です。

データ	移行結果
Gitソース、ブランチ、タグ、コミット履歴	移行される
リポジトリWiki	移行される
デフォルトブランチなど互換性のある設定	移行される
IssueとIssueコメント	移行される
Issueの状態、マイルストーン関連イベント	移行される
GitLabのマージリクエスト	GitHubのPull Requestへ変換される
マージリクエストのレビュー担当者、承認者	移行対象
マイルストーン	移行される
絵文字リアクション	移行される
添付ファイル	移行される
リリースとリリースアセット	移行される
プロジェクトメンバーの活動履歴	mannequinという仮ユーザーに関連付けられる
リポジトリ権限	移行されない
GitLabグループ設定、グループメンバー	移行されない
CI/CDパイプライン、スケジュール	移行されない
CI/CD変数、ジョブ成果物、トリガー	移行されない
Webhook	移行されない
Git LFSのバイナリオブジェクト	移行されない
Issue Board、スニペット、時間追跡	移行されない
脆弱性レポート	移行されない
マージトレイン、承認ルール、ミラーリング	移行されない

マージリクエストはPull Requestへ変換されますが、GitLabのエクスポートに含まれる差分は最新のものだけです。差分情報が存在するコメントはレビューコメントとして移行されますが、それ以外は通常のIssueコメントとして扱われます。

また、GitLabのスレッド形式の議論は、そのままの階層構造ではなく、元のスレッド情報を含むフラットなコメントとして移行されます。移行前後でコメントの表示方法が変わる可能性があるため、複雑なレビュー履歴を持つリポジトリは試行移行で確認しておきましょう。(GitHub Docs)

GitLabとGitHubの組織構造の違いを先に整理する

技術的な移行コマンドを実行する前に、GitLabのグループ構造をGitHubのどの単位へ割り当てるか決める必要があります。

GitLabとGitHubでは、リポジトリを整理する構造が異なります。

GitLab	GitHub
インスタンス	Enterprise
トップレベルグループ	Organization
サブグループ	Teamやリポジトリ権限で代替
プロジェクト	Repository

GitLabではサブグループを複数階層にネストできます。一方、GitHubにはサブグループと完全に同じ階層構造がありません。

原則として、GitLabのトップレベルグループをGitHub Organizationへ割り当て、サブグループ単位のアクセス制御はGitHub Teamで再構成する方法が分かりやすいでしょう。サブグループごとにOrganizationを作成すると、Organization数が過剰になり、管理が複雑になる可能性があります。

さらに、GitLabのGuest、Reporter、Developer、Maintainer、Ownerといったロールは、GitHubの権限へ自動変換されません。グループメンバー、リポジトリ権限、継承関係も移行されないため、移行先のTeamと権限は事前に設計しておく必要があります。(GitHub Docs)

移行対象をinventory-reportで棚卸しする

複数プロジェクトを移行する場合は、最初にinventory-reportを実行します。

gh gl2gh inventory-report --gitlab-server-url https://gitlab.com --gitlab-group example-group

このコマンドを実行すると、GitLabグループをまとめたgroups.csvと、プロジェクト情報をまとめたprojects.csvが生成されます。projects.csvにはマージリクエスト数も含まれます。

移行時間はリポジトリ数だけでは決まりません。リポジトリ数が少なくても、各プロジェクトに大量のマージリクエストがある場合は、メタデータの変換とインポートに時間がかかります。移行バッチを分けるときは、単純なリポジトリ数ではなく、マージリクエスト数とプロジェクト規模も判断材料にしてください。(GitHub Docs)

グループを指定せずに実行すると、トークンで参照できるすべてのプロジェクトが対象になります。意図しないプロジェクトを含めないよう、通常は--gitlab-groupを指定するのが安全です。

移行前に確認すべきサイズ制限

大規模リポジトリや長期間運用しているプロジェクトでは、移行開始後ではなく、試行移行前にサイズを確認します。

制限対象	主な制限
1コミット	2GiB以下
1回のPush	2GiB以下
Git参照名	255バイト以下
移行中の単一ファイル	400MiB以下
移行後の通常ファイル	100MiB以下
GitHub Enterprise ImporterのGitソース	40GiB上限として案内
GitLab.comのプロジェクトエクスポート	メタデータを含むアーカイブ全体で40GB上限

GitLab Self-Managedのエクスポート上限は、GitLab.comと異なる場合があります。また、GitHub Enterprise Importerの40GiB制限は、公式ドキュメント上で提供状況が変更される可能性があるため、大規模移行では実施時点のドキュメントを再確認してください。

事前調査にはgit-sizerを利用できます。単純なリポジトリ全体サイズだけでなく、大きなBlob、コミット、ツリー、参照名など、移行失敗につながる要素を確認できます。(GitHub Docs)

GitHub Enterprise Importerの事前準備

GitHub側のPersonal Access Tokenを作成する

gh gl2ghで利用できるGitHubのトークンは、Personal Access Token classicです。Fine-grained personal access tokenは利用できません。

Organizationでclassic PATのアクセスを全面的に制限している場合、そのポリシーのままではGitHub Enterprise Importerを使用できません。移行期間中の例外を認めるか、セキュリティ管理者と事前に調整する必要があります。

必要なスコープは実行者によって異なります。

実行者	リポジトリ移行に必要なGitHub PATスコープ
Organization Owner	`repo`、`workflow`、`admin:org`
Migratorロールを付与された担当者	`repo`、`workflow`、`read:org`

Organization Owner以外が移行する場合は、先にそのユーザーまたはTeamへMigratorロールを付与します。(GitHub Docs)

GitLab側のPersonal Access Tokenを作成する

GitLabのPersonal Access Tokenには、次のスコープが必要です。

api
read_repository

GitLab Self-Managedから移行する場合は、完全なエクスポートとユーザー属性の保持のため、管理者のトークンが必要です。対象プロジェクトでは、プロジェクトエクスポートも有効になっていなければなりません。(GitHub Docs)

トークンを環境変数へ設定する

PowerShellでは次のように設定します。

$env:GH_PAT="GITHUB_TOKEN"
$env:GITLAB_PAT="GITLAB_TOKEN"

macOSやLinuxのターミナルでは次のように設定します。

export GH_PAT="GITHUB_TOKEN"
export GITLAB_PAT="GITLAB_TOKEN"

トークンをスクリプトやGitリポジトリへ直接書き込まないでください。移行専用の短い有効期限を設定し、作業完了後に失効させる運用が安全です。gh gl2ghは、このGH_PATとGITLAB_PATを使用して移行元と移行先へ接続します。(GitHub Docs)

GitHub CLIとgh gl2ghをインストールする

GitHub CLIをインストールした後、GL2GH拡張を追加します。

gh extension install github/gh-gl2gh

すでにインストールしている場合は、移行前に最新版へ更新します。

gh extension upgrade github/gh-gl2gh

公式ドキュメントではGitHub CLI 2.4.0以上が必要とされていますが、実務では最新の安定版GitHub CLIと最新のgh gl2ghを使用してください。拡張機能は頻繁に更新されるため、試行移行と本番移行の直前にバージョンを確認することが重要です。(GitHub Docs)

移行アーカイブの保存先を選ぶ

GitLabからエクスポートしたアーカイブは、GitHubが読み取れるストレージへ一時的に配置されます。

保存先	指定方法	適しているケース
GitHub管理ストレージ	`--use-github-storage`	特別な保存要件がなく、簡単に移行したい
AWS S3	`--aws-bucket-name`など	独自のネットワーク要件や保管要件がある
Azure Blob Storage	接続文字列を環境変数などで指定	Azure上で移行アーカイブを管理したい

通常は、追加設定が不要な--use-github-storageが適しています。GitHub管理ストレージでは、成功した移行のアーカイブは自動削除され、失敗した移行のアーカイブも7日後に削除されます。

AWS S3やAzure Blob Storageを利用した場合、GitHubはアーカイブを削除しません。保存期間と削除ルールは利用者側で設定します。Azure Blob Storageは、ストレージアカウントのアクセスキーを含む接続文字列が必要で、SASはサポートされていません。(GitHub Docs)

外部ストレージが適しているのは、主に次のようなケースです。

ファイアウォールや通信経路の制約がある
移行アーカイブを監査目的で一定期間保持したい
自社管理の暗号化、ライフサイクル、アクセスログを適用したい
移行処理とストレージ利用を組織内のクラウド基盤に統一したい

保持要件がない場合は、アーカイブの削除漏れや認証情報の管理が増えるため、GitHub管理ストレージのほうが運用しやすいでしょう。

gh gl2ghで単一リポジトリを移行する手順

試行移行用のOrganizationを準備する

本番Organizationへ直接移行するのではなく、最初に試行移行用のOrganizationを作成します。

たとえば、本番がexample-orgなら、試行用をexample-org-sandboxとします。代表的なプロジェクトを選び、次の点を確認します。

Gitデータが正常に移行できるか
IssueやPull Requestの状態が想定どおりか
添付ファイルやリリースを参照できるか
移行後にCI/CDや権限を再構成できるか
実際の移行にどの程度の時間がかかるか

GitHubも、本番前に試行移行を行い、利用者に結果を検証してもらうことを強く推奨しています。(GitHub Docs)

migrate-repoを実行する

次の例では、GitLab.comのparent-group/subgroupにあるsample-appを、GitHubのexample-orgへ移行します。

gh gl2gh migrate-repo --gitlab-server-url https://gitlab.com --gitlab-group parent-group/subgroup --gitlab-project sample-app --github-org example-org --github-repo sample-app --use-github-storage --target-repo-visibility private

主な引数は次のとおりです。

引数	指定内容
`--gitlab-server-url`	GitLab.comまたはGitLab Self-ManagedのURL
`--gitlab-group`	プロジェクトを含むグループのフルパス
`--gitlab-project`	移行元プロジェクト名
`--github-org`	移行先Organization
`--github-repo`	移行後のリポジトリ名
`--use-github-storage`	GitHub管理ストレージを使用
`--target-repo-visibility`	`private`、`internal`、`public`から指定

GitLabのネストされたサブグループにあるプロジェクトは、parent-group/subgroupのようにフルパスを指定します。

--target-repo-visibilityを省略した場合、移行先リポジトリは非公開として作成されます。公開範囲を誤ると情報漏えいにつながるため、原則として試行移行と本番移行はprivateで開始し、検証後に変更する運用が安全です。(GitHub Docs)

GHE.comへ移行する場合

データ所在地に対応したghe.com環境へ移行する場合は、Enterprise固有のAPI URLを追加します。

GitHub管理ストレージを使用するときは、アップロード用URLも指定します。

gh gl2gh migrate-repo --gitlab-server-url https://gitlab.com --gitlab-group example-group --gitlab-project sample-app --github-org example-org --github-repo sample-app --use-github-storage --target-api-url https://api.acme.ghe.com --target-uploads-url https://uploads.acme.ghe.com

acmeの部分は、利用しているEnterpriseのサブドメインへ置き換えます。--target-uploads-urlを省略するとgithub.com側のアップロードURLが既定値となるため、ghe.comとGitHub管理ストレージを組み合わせる場合は指定漏れに注意してください。(GitHub Docs)

自己署名証明書を使用している場合

GitLab Self-Managedが自己署名証明書を使用している場合は、--no-ssl-verifyを追加できます。

gh gl2gh migrate-repo --gitlab-server-url https://gitlab.example.local --gitlab-group example-group --gitlab-project sample-app --github-org example-org --github-repo sample-app --use-github-storage --no-ssl-verify

このオプションは、gh gl2ghからGitLabへ接続する部分のSSL検証を無効にします。通常の公開証明書を利用できる環境では指定せず、証明書チェーンを正しく構成することを優先してください。(GitHub Docs)

複数リポジトリを一括移行する方法

移行スクリプトを生成する

複数リポジトリは、generate-scriptでPowerShellスクリプトを生成して移行します。

gh gl2gh generate-script --gitlab-server-url https://gitlab.com --gitlab-group example-group --github-org example-org --output migrate-example-group.ps1 --use-github-storage

生成されるスクリプトには、プロジェクトごとに1つのmigrate-repoコマンドが記述されます。

--gitlab-groupを省略すると、GitLabトークンでアクセスできる全プロジェクトが含まれます。管理者トークンを使用している場合、想定以上の数が対象になる可能性があるため、グループを明示してください。(GitHub Docs)

生成されたスクリプトを必ず確認する

スクリプトをそのまま実行せず、次の項目を確認します。

移行対象外のプロジェクトが含まれていないか
移行先Organizationが正しいか
リポジトリ名がGitHubの命名方針に合っているか
同名リポジトリが移行先に存在しないか
リポジトリの公開範囲が適切か
GHE.com用のAPI URLとアップロードURLが設定されているか
使用するストレージが正しいか

対象外の行は削除またはコメントアウトできます。リポジトリ名を変更する場合は--github-repoを、公開範囲を変更する場合は--target-repo-visibilityを編集します。(GitHub Docs)

PowerShellスクリプトを実行する

Windows PowerShellでは次のように実行します。

.\migrate-example-group.ps1

macOSやLinuxでもPowerShellを導入すれば実行できます。生成される一括移行スクリプトはPowerShell形式であるため、通常のBashスクリプトではない点に注意してください。(GitHub Docs)

本番移行ではGitLabへの書き込みを停止する

GitHub Enterprise Importerは差分移行に対応していません。

移行処理の開始後にGitLabで追加されたコミット、Issue、コメント、マージリクエストなどは、移行先へ自動反映されません。差分だけを後から取り込む機能もないため、本番移行では更新停止時間を設ける必要があります。(GitHub Docs)

実務では、次の順序で切り替えると混乱を減らせます。

フェーズ	実施内容
事前準備	対象一覧、容量、MR数、組織構造、権限を整理
試行移行	代表的な小規模・大規模リポジトリを移行
本番直前	Team、Actions、Secrets、Webhookの設定案を準備
更新停止	GitLabへのPush、Issue更新、MR操作を停止
本番移行	`migrate-repo`または生成スクリプトを実行
検証	Migration Log、Git履歴、Issue、PR、添付を確認
移行後作業	権限、CI/CD、LFS、Webhook、mannequinを設定
利用再開	開発者へGitHubのURLと運用ルールを案内
旧環境整理	GitLab側を参照専用として扱い、移行先を明示

更新停止は、GitLabプロジェクトを先に削除したり、エクスポート不能な状態にしたりするのではなく、権限制御や組織内ルールで書き込みを止める方法が安全です。

移行後に必ず実施する確認作業

Migration Logを確認する

移行コマンドが成功しても、すべてのデータが問題なく変換されたとは限りません。

移行先リポジトリの「Issues」を開き、「Migration Log」というIssueを確認します。成功した移行にも、一部データを移行できなかった警告や、形式を変えて移行したことを示す警告が記録される場合があります。

--queue-onlyを使用した場合は、コマンドが移行完了を待たずに終了します。その場合はwait-for-migrationまたはMigration Logで結果を確認してください。(GitHub Docs)

リポジトリの内容を検証する

最低限、次の項目を移行元と比較します。

デフォルトブランチが正しい
主要ブランチとタグが存在する
最新コミットのハッシュが一致する
Wikiを参照できる
Issueの状態、コメント、添付ファイルを確認できる
マージリクエストがPull Requestへ変換されている
リリースとリリースアセットを参照できる
Migration Logに重大な警告がない
リポジトリの可視性が正しい

コード検索用インデックスの再作成には時間がかかることがあります。移行直後にコード検索結果が不足していても、リポジトリ自体の移行失敗とは限りません。数時間後に再確認してください。(GitHub Docs)

Git LFSオブジェクトを別途移行する

Git LFSのポインターファイルはGit履歴と一緒に移行されますが、実体となるバイナリオブジェクトは移行されません。

移行後はGit LFSオブジェクトを移行先へ別途Pushし、次の点を確認します。

git lfs pullでファイルを取得できる
GitHub側のLFS容量と帯域が足りている
ビルド環境や開発端末からLFSへアクセスできる
古いGitLab LFS URLへの依存が残っていない

LFSを使用しているリポジトリを通常のGitデータだけで検証すると、ポインターファイルを実データと誤認することがあります。画像、動画、学習データ、設計ファイルなどを実際に開けるか確認してください。(GitHub Docs)

mannequinを実ユーザーへ再関連付けする

Issue、Pull Request、コメントなどのユーザー活動は、移行直後にはmannequinと呼ばれる仮ユーザーへ関連付けられます。Gitコミット以外の活動を実際のGitHubユーザーへ結び付けるには、mannequinの再関連付けが必要です。

まずCSVを生成します。

gh gl2gh generate-mannequin-csv --github-org example-org --output mannequins.csv

CSVに対応するGitHubユーザー名を記入した後、一括反映します。

gh gl2gh reclaim-mannequin --github-org example-org --csv mannequins.csv

mannequinを再関連付けできるのはOrganization Ownerです。また、関連付け先のユーザーは、事前にOrganizationメンバーになっている必要があります。

リポジトリを別のOrganizationへ移管した後はmannequinを再関連付けできないため、Organization間のリポジトリ移管を予定している場合は、先にこの作業を完了してください。(GitHub Docs)

Teamとアクセス権を設定する

mannequinの再関連付けは、リポジトリへのアクセス権を付与する処理ではありません。

GitLabのグループメンバーやプロジェクト権限は移行されないため、GitHub側で次の設定が必要です。

Organizationメンバーの追加
Teamの作成
Teamへのユーザー追加
リポジトリごとのRead、Triage、Write、Maintain、Admin権限
Branch protectionやRuleset
CODEOWNERS
Pull Requestのレビュー要件

移行直後のリポジトリは、既定では非公開です。移行実行者とOrganization Owner以外がアクセスできない状態になるため、Team設定を完了してから開発を再開します。(GitHub Docs)

CI/CD、Secrets、Webhookを再構成する

.gitlab-ci.ymlはリポジトリ内のファイルとして残る場合がありますが、GitHub ActionsのWorkflowへ自動変換されるわけではありません。

次の項目は別プロジェクトとして移行します。

GitLab CI/CDからGitHub Actionsへの変換
CI/CD変数からGitHub Actions SecretsやVariablesへの移行
RunnerからGitHub-hosted runnerまたはself-hosted runnerへの切り替え
Container RegistryやPackage Registryの参照先変更
Webhookの再作成
外部サービスのリポジトリURL変更
デプロイキー、Deploy Token、サービスアカウントの見直し
ブランチ保護と承認フローの再設計

GitLabパイプラインの移行には、GitHub Actions Importerを別途利用できます。ただし、すべての構文やキャッシュ、外部サービス連携を完全変換できるわけではないため、変換後のWorkflowをレビューし、テスト環境で実行してください。(GitHub Docs)

移行で失敗しやすいポイントと対処法

症状	主な原因	確認・対処
GitHubで401、403エラー	PATのスコープ不足	classic PATか、`repo`、`workflow`、`admin:org`または`read:org`があるか確認
classic PATを作成してもアクセスできない	Organizationポリシーでclassic PATを制限	EnterpriseまたはOrganizationのPATポリシーを確認
GitLabのエクスポートに失敗する	プロジェクトエクスポート無効	GitLab側でエクスポート設定を有効化
Self-Managedでユーザー情報が不足する	管理者以外のGitLab PATを使用	管理者トークンで試行移行をやり直す
一部のリポジトリだけ移行に失敗する	大容量ファイル、巨大コミット、長いref	`git-sizer`とMigration Logで問題箇所を確認
Ruleset関連で失敗する	移行履歴がOrganizationのルールに違反	RulesetのBypass listへ「Repository migrations」を追加
移行後にユーザーがアクセスできない	権限とメンバーシップは移行対象外	GitHub Teamとリポジトリ権限を設定
移行後に最新変更が不足する	移行中もGitLabが更新された	差分移行はできないため、更新停止後に新しい移行先へ再実行するか手動反映
GHE.comでアップロードに失敗する	API URLまたはUploads URLの指定漏れ	`--target-api-url`と`--target-uploads-url`を確認
LFSファイルを開けない	LFS実体が未移行	Git LFSオブジェクトを別途Push
CIが動かない	GitLab CI/CDは自動移行されない	GitHub Actionsを作成し、SecretsやRunnerを設定

移行先のOrganizationやEnterpriseでRulesetを利用している場合、既存のコミット履歴が現在のルールに違反して移行に失敗することがあります。該当RulesetのBypass listへ「Repository migrations」を追加すると、移行処理中だけルールをバイパスできます。移行後の新しい変更には、通常どおりRulesetが適用されます。(GitHub Docs)

gh gl2ghを選ぶべきケースと別手段を検討すべきケース

gh gl2ghが適しているケース

移行先がGitHub Enterprise Cloudである
Issueやマージリクエストも含めて移行したい
GitLab.comまたは保守対象のGitLab Self-Managedを使用している
複数プロジェクトをスクリプトで一括移行したい
移行後に権限やCI/CDを再設定できる
本番切り替え時に更新停止時間を設けられる

別の移行計画が必要なケース

移行先がGitHub Enterprise Serverである
サポート終了済みの古いGitLab Self-Managedを使用している
classic PATの利用を組織ポリシー上認められない
移行中もGitLabを継続更新し、差分同期が必要である
GitLabのグループ権限やCI/CDを完全に自動変換したい
リポジトリやエクスポートアーカイブが上限を超えている

特に、ghe.comとGitHub Enterprise Serverは名称が似ていますが、異なるサービスです。ghe.comはGitHub Enterprise Cloudのデータ所在地対応環境であり、今回の移行対象です。自社サーバーやプライベートクラウドに構築するGitHub Enterprise Serverは対象外です。(The GitHub Blog)

GitLabからGitHubへ安全に移行するための進め方

GitLabからGitHub Enterprise Cloudへの移行は、gh gl2ghによって単体・一括の両方をセルフサービスで実行できるようになりました。ソースコードだけでなく、Issue、マージリクエスト、マイルストーン、添付ファイル、リリースなどを移行できることが大きな利点です。

一方で、GitLabの権限、グループ構造、CI/CD、Webhook、Git LFSオブジェクトは自動移行されません。また、差分移行に対応していないため、本番移行時の更新停止が必要です。

最初に行うべきことは、本番コマンドの実行ではありません。inventory-reportで対象プロジェクトとマージリクエスト数を棚卸しし、GitLabグループとGitHub Organization・Teamの対応関係を決めてください。その後、代表的なリポジトリを試行用Organizationへ移行し、Migration Log、CI/CD再構築、権限設定、LFS移行、mannequin再関連付けまで完了できることを確認します。

この一連の手順を試行移行で再現できてから、更新停止を伴う本番移行へ進むことが、移行後の開発停止やデータ欠落を防ぐ最も確実な進め方です。

この記事を書いた人

佐藤健司

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