Phase 6. 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.
Under your repository name, click Issues.
Click the issue with the title "Migration Log."

For more information, see Accessing your migration logs for GitHub Enterprise Importer.

All repositories are migrated as private by default, and only the user that ran the migration and organization owners will have access to the repository. If you don't want the repository to be private, change the visibility.

You can change a repository's visibility in the browser. For more information, see Setting repository visibility.
Alternatively, you can use GitHub CLI to change repository visibility from the command line. For more information, see gh repo edit in the GitHub CLI documentation.

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

After you run a migration with GitHub Enterprise Importer, all user activity in the migrated repository (except Git commits) is attributed to placeholder identities called mannequins.

Note

Only organization owners can reclaim mannequins. If you've been granted the migrator role, contact an organization owner to perform this step.

Decide if you want to reclaim mannequins.
Plan when you'll complete reclaims.
Reclaim mannequins. You can reattribute the history for each mannequin to an organization member with the GitHub CLI or in your browser. If you use the GitHub CLI, you can reclaim mannequins in bulk. For more information, see Reclaiming mannequins for GitHub Enterprise Importer.
If any of the members do not already have appropriate access to the repository via team membership, give the members access to the repository. For more information, see Managing an individual's access to an organization repository.

Configuring IP allow lists

If you added the IP ranges for GitHub Enterprise Importer to the IP allow list for your destination organization, you can remove those entries. If you disabled your identity provider's IP allow list restrictions for your destination enterprise, you can re-enable them now.

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 Key differences between Azure DevOps and GitHub with them.

In this article