Follow-up tasks

Checking the migration status

First, check whether your migration succeeded or failed.

The way you check the status of your migration depends on how you ran the migration.

If you ran the migration using the GitHub CLI, by default, the process will display whether the migration succeeded or failed once the migration is complete. If the migration failed, you will see the reason for failure.
```
Migration completed (ID: RM_123)! State: SUCCEEDED
```
If you ran the migration using the GitHub CLI with the optional --queue-only argument, the process will exit immediately after queueing the migration, and will not tell you if the migration succeeded or failed. You can check a migration's status using the wait-for-migration command, or by reviewing the migration log.

Reviewing the migration log

You should review the migration log for each migrated repository. People with read access to a repository can access the migration log for the repository on GitHub.

Navigate to the migrated repository in your destination organization.
リポジトリ名の下にある [Issues] をクリックします。
Click the issue with the title "Migration Log."

For more information, see GitHub Enterprise Importer の移行ログへのアクセス.

Setting repository visibility

すべてのリポジトリは、既定ではプライベートとして移行され、移行を実行したユーザーと組織の所有者のみが、リポジトリにアクセスできます。リポジトリをプライベートにしたくない場合は、可視性を変更します。

リポジトリの可視性はブラウザーで変更できます。詳しくは、「リポジトリの可視性を設定する」をご覧ください。
または、 GitHub CLI を使用して、コマンドラインからリポジトリの可視性を変更することもできます。詳細については、gh repo editドキュメントのGitHub CLIを参照してください。

For example, replace YOUR_ORG with your organization name, and the command below will set all of the organization's repositories to internal visibility.
Bash
```
export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
```
```
export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
```

Reclaiming mannequins

GitHub Enterprise Importer を使って移行を実行した後、移行されたリポジトリでのすべてのユーザーアクティビティ (Git コミットを除く) は、マネキンと呼ばれるプレースホルダー ID に帰属します。

メモ

マネキンを回収できるのは organization 所有者だけです。移行者ロールが付与されているユーザーは、Organization 所有者にこのステップの実行を依頼してください。

マネキンを回収するかどうかを決めます。
いつ回収を完了するかを計画します。
マネキンを回収します。 GitHub CLI を使用して、またはブラウザーで、各マネキンの履歴を組織メンバーに再属性付けできます。 GitHub CLI を使用する場合は、マネキンを一括で回収できます。詳細については、「GitHub Enterprise Importer のマネキンの回収」を参照してください。
チームメンバーシップを介してリポジトリへの適切なアクセス権をまだ持っていないメンバーがいる場合は、そのメンバーにリポジトリへのアクセス権を付与します。詳しくは、「Organization のリポジトリへの個人のアクセスを管理する」をご覧ください。

If you added the IP ranges for GitHub Enterprise Importer to the IP allow list for your destination organization, you can remove those entries. 移行先 Enterprise に対する ID プロバイダーの IP 許可リスト制限を無効にした場合は、ここでもう一度有効にできます。

Configure Azure Pipelines and Azure Boards

If you used Azure Pipelines or Azure Boards previously and want to continue using them with your repositories now they are hosted on GitHub, you can follow these guides on Microsoft Learn to configure the relevant extension.

Supporting your developers in their new environment

There are some difference between Azure DevOps and GitHub that would be helpful for you and your developers to know. Share Azure DevOps と GitHub の主な違い with them.

Run your migration

この記事で