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.

Все репозитории переносятся как частные по умолчанию, и доступ к репозиторию будет иметь только пользователь, выполняющий миграцию и владелец организации. Если вы не хотите, чтобы репозиторий был частным, измените видимость.

Вы можете изменить видимость репозитория в браузере. Дополнительные сведения см. в разделе Настройка видимости репозитория.
В качестве альтернативы можно 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) относятся к удостоверениям заполнителей, называемым манекенами.

Примечание.

Только владелец организации могут восстановить манекины. Если вы предоставили роль миграции, обратитесь к владелец организации, чтобы выполнить этот шаг.

Решите, хотите ли вы восстановить манекины.
Запланируйте, когда вы завершите восстановление.
Восстановление манекенов. Дополнительные сведения см. в разделе Восстановление манекенов для GitHub Enterprise Importer.
Если любой из членов еще не имеет соответствующего доступа к репозиторию через членство в команде, предоставьте членам доступ к репозиторию. Дополнительные сведения см. в разделе Управление доступом пользователя к репозиторию организации.

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. Если вы отключили ограничения списка разрешений поставщика удостоверений для целевого предприятия, их можно повторно включить.

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

В этой статье