Contents
Azure DevOps GitHub 移行: 前提・対象読者・依存ツール
ここでは移行開始前に揃えるべき前提と、関係者・依存ツールを明示します。準備段階での齟齬を減らすことでパイロット以降の失敗を防ぎます。
対象読者・前提条件
次の役割を想定しています。
- 開発リード（移行範囲と優先度を決める）
- プラットフォーム／SRE（インフラ、ランナー、ネットワークを担当）
- セキュリティ／法務（データレジデンシー、監査要件の確認）
- 管理者（Azure DevOps と GitHub 側の管理権限を保持）
- CI 所有者（パイプラインの移行と検証を行う）
依存ツール一覧
移行でよく使われる公式／OSS／商用ツールの概要です。
| ツール | 用途 | 備考 |
|---|---|---|
| GitHub Enterprise Importer（公式） | 大量リポジトリの一括インポート | オンプレ環境ではエージェントが必要な場合あり。動作は環境依存 |
| GitHub REST API / gh CLI | 自動化、ポーリング、状態確認 | レート制限と認証スコープに注意 |
| git / git-lfs | リポジトリ操作、LFS オブジェクト転送 | LFS の容量課金・転送制限に注意 |
| Azure DevOps Migration Tools（OSS） | Work Item 移行支援 | ワークアイテム中心。添付や履歴の扱いは要確認 |
| OpsHub（商用） | フルフィデリティ移行の商用支援 | コストが発生。要 PoC で検証 |
| CI 変換スクリプト／カスタムツール | Azure Pipelines → Actions の変換 | 手作業を含むケースが多い。再利用化を推奨 |
各ツールの細かい制約や必要権限はバージョンや契約で変わります。必ず公式ドキュメントで最新仕様を確認してください。
Azure DevOps GitHub 移行の全体像とシナリオ選定（クラウド vs オンプレ、規模別）
移行は評価→計画→パイロット→本番→運用の順で進めます。クラウドかオンプレか、規模により推奨アプローチが変わります。
シナリオ別の推奨アプローチ
代表的なシナリオと実務的な進め方です。
- 小規模（単一〜数リポジトリ）
- 手動 UI インポートや gh CLI を使って短期移行を実行します。テストは手動検証中心です。
- 大規模（数十〜数千リポジトリ）
- GitHub Enterprise Importer や API 自動化を使います。ジョブを分割し段階的にロールアウトします。レート制御とログ管理を必須にしてください。
- オンプレ移行（Azure DevOps Server → GitHub Enterprise Server/Cloud）
- 帯域・ファイアウォール設定とデータレジデンシーの確認が必要です。アクセス不可な環境ではオフラインバンドルや物理メディア移行を検討します。Importer のエージェント要否やバルク処理上限は環境依存です。公式ドキュメントで要件を確認してください。
優先検証項目はコミット整合性、LFS、CI 互換性、認証・権限マッピングです。これらを最初に合格基準として定義します。
Azure DevOps GitHub 移行前の必須チェックとセキュリティ要件
本節では移行前に必ず確認すべき項目と、特に重要なセキュリティ手順を示します。種々の操作は権限と監査の観点で記録して進めてください。
権限と認証（SSO / SCIM / PAT）
認証設計は移行の成否に直結します。注意点は次の通りです。
- 必要な管理者権限を事前に確保してください。組織オーナーやエンタープライズ管理者が関与する必要があります。
- SCIM を使う場合は Azure AD 側の設定や管理者同意が必要です。事前にプロビジョニング要件を確認してください。
- 移行用トークンは最小権限で一時的に発行し、移行終了後に必ずローテーションしてください。正確なスコープは API ごとのドキュメントを参照してください。
シークレット・鍵の移行とローテーション
シークレットは直接エクスポートしないでください。安全な移行手順の例です。
- シークレットのインベントリを作成します（パイプライン変数、サービスコネクション、Actions secrets、パッケージ認証など）。
- 利用用途ごとに分類します（CI、デプロイ、外部サービス接続など）。
- 新しい認証情報を作成します。可能なら OIDC を用いて短期トークンに切り替えます。
- GitHub 側に Secrets を登録します。安全なストア（Azure Key Vault 等）経由の自動投入を推奨します。
- 切替後に旧トークン／鍵を無効化し、監査ログでアクセス履歴を記録します。
例（gh CLI を使った一時登録の骨子）：
|
1 2 3 |
# 例: 環境変数にある値をリポジトリシークレットへ登録 echo -n "$MY_SECRET" | gh secret set MY_SECRET --repo ORG/REPO |
実運用ではキーのライフサイクル管理と監査ログ保存を忘れないでください。
バックアップ／スナップショットとネットワーク
移行前に必ずオフラインのバックアップを取得します。ポイントは次の通りです。
- リポジトリは mirror クローンで取得します。DB とアプリケーションのスナップショットも保存します。
- LFS オブジェクトは別途バックアップを取得してください。
- ネットワークでは GitHub の接続先許可、プロキシ設定、帯域とタイムアウト設計を確認します。大容量転送では帯域制御や分割転送を計画してください。
リポジトリのミラー例（最終同期での利用）：
|
1 2 3 4 5 |
git clone --mirror https://dev.azure.com/ORG/_git/REPO tmp.git cd tmp.git git remote add gh https://github.com/ORG/REPO.git git push --mirror gh |
リポジトリ移行の実務（GitHub Enterprise Importer、LFS、検証）
ここではリポジトリ移行の段階的フローと LFS、検証基準を統合して示します。Importer と git レベルの両方で検査してください。
フェーズ1〜5の実務フロー
計画から切替までの主要作業です。
- フェーズ1: 計画
- 対象リポジトリのインベントリを作成します。サイズ、LFS 利用、ブランチ数、PR 数、サブモジュール、署名コミットを把握します。
- フェーズ2: 準備
- 目標組織の設定、チームとリポジトリポリシーを作ります。LFS の有効化、必要なトークンを最小権限で発行します。
- フェーズ3: 実行（インポート）
- GitHub Enterprise Importer や API を用いて移行します。オンプレ向けにはエージェントが必要な場合があります。バルクインポートの同時実行数や制限は環境依存なので公式を事前確認してください。
- フェーズ4: 検証
- コミット SHA、ブランチ、タグ、LFS オブジェクト数、CI 実行結果などを比較検証します。ログを保存し、問題は再試行可能な形で対処します。
- フェーズ5: 切替・事後作業
- 最終差分同期を凍結ウィンドウで実行し、旧環境を読み取り専用化してアーカイブします。権限・ブランチ保護をターゲットで再適用します。
Git LFS と大容量ファイルの移行
LFS はメタデータと実データが分離されます。転送方法と注意点です。
- 事前: ターゲットで LFS を有効化し、ストレージ見積りを確定します。
- 全オブジェクト取得（ソース）: git lfs fetch --all を実行して LFS オブジェクトを取得します。
- ミラーとプッシュ（例）:
|
1 2 3 4 5 6 7 |
GIT_LFS_SKIP_SMUDGE=1 git clone --mirror https://dev.azure.com/ORG/_git/REPO tmp.git cd tmp.git git lfs fetch --all git remote add gh https://github.com/ORG/REPO.git git push --mirror gh git lfs push --all gh |
- 大量データ時: git config lfs.concurrenttransfers で同時転送数を調整します。ネットワークやタイムアウトを監視してください。
- 履歴から大容量ファイルを除去する場合は、事前合意とフルバックアップを取り、git filter-repo や BFG でテストしてから実行してください。
検証と成功基準（統合）
合格条件を定量的に決めます。主要な検証コマンド例を示します。
- 主要ブランチ tip SHA が一致すること:
|
1 2 3 |
git -C old rev-parse refs/heads/main git -C new rev-parse refs/heads/main |
- コミット数とタグ数の比較:
|
1 2 3 4 |
git -C old rev-list --all --count git -C new rev-list --all --count git ls-remote --tags origin |
- ランダムコミットの内容比較は git show を使って行います。LFS オブジェクトは git lfs ls-files 等で確認します。
- ブランチ保護、CODEOWNERS、署名コミット、サブモジュール、リリース資産の整合性も検証対象です。PR の履歴やマージメタデータの完全性はツールに依存します。必要ならサンプル PR を実際にマージして動作を確認してください。
自動化とスクリプトの注意点
自動化は idempotent にし、リトライとログを必須にします。実装上の要点です。
- トークン権限は最小に限定し、使用後にローテーションする。
- API レート制限を考慮し、指数バックオフとポーリングを実装する。
- ジョブは部分的に再実行できるように状態管理（ステータス保存）を行う。
- 監査用ログを残し、失敗時は再現可能なログとメタデータを保管する。
簡単な API 呼び出しの骨子（ポーリングの例）：
|
1 2 3 4 5 |
# 登録とポーリングの疑似例。エラーハンドリングは実装必須 gh api -X POST /repos/ORG/REPO/import -f vcs_url="$DEVOPS_URL" -f vcs="git" # ポーリングで状態を確認する gh api /repos/ORG/REPO/import | jq '.status' |
実運用では HTTP ステータスや RateLimit ヘッダをチェックしてください。
コード以外の資産移行と CI/CD・権限移行（Boards、Wiki、Artifacts、Actions）
コード以外の資産は自動移行の制約が多いです。現実的な選択肢と実行手順を示します。
Azure Boards → Issues / Projects の移行方針
Boards の完全自動移行は難しい場合があります。代表的な選択肢です。
- 重要なチケットのみ API で移行し、履歴はコメントで残す
- 全件エクスポート後に要約データをインポートする（履歴は添付やリンクで保存）
- 旧 Boards を当面残し、GitHub 側から参照リンク運用とする
フィールドの基本マッピング例:
| Azure Boards | GitHub |
|---|---|
| Title | Issue title |
| Description | Issue body（履歴を引用で残す） |
| State | Labels / Milestone |
| AssignedTo | Assignee（未存在ならコメントで記録） |
| Tags | Labels |
| Comments | Issue コメント（タイムスタンプと作者を注記） |
移行ツール候補として Azure DevOps Migration Tools（OSS）や OpsHub（商用）を比較検討してください。履歴・添付の扱いはツールにより異なります。
Wiki の移行
Azure DevOps Wiki は git リポジトリとして扱えます。簡単な移行手順は次の通りです。
|
1 2 3 4 5 |
git clone https://dev.azure.com/ORG/PROJECT/_git/wiki cd wiki git remote add gh https://github.com/ORG/REPO.wiki.git git push gh --all |
添付ファイルのパスや内部リンクが変わる点に注意してください。場合によってはドキュメントをリポジトリ内の docs/ に統合する方が管理しやすいことがあります。
Artifacts / Packages の移行
多くの場合は再発行（republish）が現実的です。代表例です。
- npm: レジストリ設定を GitHub Packages にして各バージョンを npm publish で再発行します。クライアントの .npmrc を更新してください。
- NuGet: .nupkg を取得して dotnet nuget push で GitHub Packages にアップロードします。nuget.config の更新が必要です。
- Maven: distributionManagement を GitHub Packages 用に設定し mvn deploy を実行します。settings.xml の認証を更新します。
移行に伴いダウンストリームの依存先設定を更新し、互換性テストを行ってください。
Azure Pipelines → GitHub Actions の移行
CI の移行は段階的に行います。主な手順です。
- パイプラインのインベントリ作成（YAML／クラシック、外部タスク含む）。
- タスク変換マトリクスを作成し、Azure タスクと Actions の対応を整理する。
- パイロットリポジトリでワークフローを作成し動作検証する。
- 再利用可能なワークフローや composite action に分割して保守性を高める。
- 段階的にロールアウトし、キャッシュ・アーティファクトの動作差異を検証する。
Secrets は再生成し、可能な限り OIDC に移行して長期トークンを削減してください。ランナー設計は自己ホストか GitHub ホステッドかの運用コストを比較して決定します。
パイロット設計・切替・運用移行後の作業と検証（トラブルシューティング含む）
パイロットで十分に検証し、切替時のダウンタイムを最小化してください。問題発生時の初動と運用後タスクを整理します。
パイロット設計と合格基準
テストケースと合格基準を事前に決めます。代表例です。
- 小規模 E2E 移行（履歴、PR、CI）で成功すること。
- LFS を使う大容量リポジトリの移行でオブジェクト数が一致すること。
- 主要ワークフローが GitHub Actions 上で安定して通ること。
- ユーザー権限とレビュー設定が期待通りに再現されること。
- ステークホルダー承認が得られること。
最終差分同期と切替手順
最終同期は凍結ウィンドウで実行します。基本的な手順は次の通りです。
- 凍結ウィンドウを告知し、全コミットを停止する。
- ミラークローンで最終差分を取得してターゲットへ push する。LFS オブジェクトも同時に転送する。
- ターゲットでブランチ保護・CODEOWNERS・シークレットを適用する。
- 旧環境を読み取り専用にしてアーカイブする。
- 開発者へリモート URL 更新手順を周知する。
最終同期の LFS を含む例は前節のコマンドを参照してください。
検証ケース一覧（詳細）
移行完了後に実施する詳細検証項目です。
- ブランチ tip SHA とコミット数の一致。
- ランダムコミットのファイル内容比較。
- タグ（注釈付き／軽量）の存在と参照整合性。
- PR とマージ履歴の存在とメタデータ整合性。
- リリース資産と添付ファイルの確認。
- LFS オブジェクト数と総サイズの一致。
- ブランチ保護ルール、CODEOWNERS、ステータスチェックの動作。
- 署名（GPG）コミットの検証。
- サブモジュールの参照先有効性。
- CI ワークフローの合格とアーティファクト生成。
必要な検証は自動化してログ化すると再現性が高くなります。
よくある問題と一次対応
発生しやすい問題と初動の確認点です。
- 認証エラー：トークンのスコープ不足や期限切れを疑う。gh auth status や API ログを確認。
- Rate Limit による失敗：リトライやバックオフを実装して再実行。
- LFS 未転送：git lfs fetch --all と git lfs push --all を再実行し、ストレージ制限を確認。
- 履歴欠落：git rev-list / rev-parse で ref を比較し、refspec の不足を修正。
- パイプライン差分でのビルド失敗：ランナー環境差、依存バージョン、キャッシュ挙動を確認する。
ログと再現手順を揃えればトラブルシュートが容易になります。
運用後の作業
移行完了後に必要な初期運用タスクです。
- モニタリングとアラート設定（ワークフロー失敗、ランナー状態）。
- CI/CD の安定化とリファクタリング計画の実行。
- ドキュメント整備と開発者教育（操作手順、FAQ）。
- 定期的な棚卸と古いリポジトリのアーカイブ方針。
- 監査ログの長期保存とコンプライアンス対応の確認。
参考資料（主要な公式ドキュメント）
下記は必ず最新の公式ドキュメントを参照してください。括弧内は参照日です。
- Migrating from Azure DevOps to GitHub — https://docs.github.com/en/migrations/migrating-from-azure-devops-to-github（参照: 2026-05-16）
- GitHub Import API（Import a repository） — https://docs.github.com/en/rest/migrations/repos#import-a-repository（参照: 2026-05-16）
- GitHub Enterprise Importer / Migrations ドキュメント — https://docs.github.com/en/migrations（参照: 2026-05-16）
- Git LFS 公式サイト — https://git-lfs.github.com/（参照: 2026-05-16）
- GitHub Actions ドキュメント — https://docs.github.com/en/actions（参照: 2026-05-16）
- SCIM プロビジョニング（GitHub Enterprise Cloud） — https://docs.github.com/en/enterprise-cloud@latest/admin/identity-and-access-management/configuring-scim-provisioning-for-github-enterprise-cloud（参照: 2026-05-16）
- GitHub CLI マニュアル — https://cli.github.com/manual/（参照: 2026-05-16）
- Azure DevOps Migration Tools（OSS） — https://github.com/nkdAgility/azure-devops-migration-tools（参照: 2026-05-16）
- OpsHub（商用移行ソリューション） — https://www.opshub.com/（参照: 2026-05-16）
- Azure Artifacts ドキュメント — https://learn.microsoft.com/azure/devops/artifacts/（参照: 2026-05-16）
- GitHub Packages ドキュメント — https://docs.github.com/en/packages（参照: 2026-05-16）
上記リンクは移行方針やツール選定の判断材料です。製品機能や挙動は更新されます。実運用前に必ず最新ページを確認してください。
まとめ
移行は事前計画と明確な成功基準の設定が肝心です。まず対象範囲と検証ケースを決め、パイロットでコミット整合性、LFS、CI、認証を検証してください。シークレットは再生成して OIDC 等に移行し、最終同期は凍結ウィンドウで実施します。法務や監査要件を満たした上で本番切替を行ってください。