Prepare for your migration from Azure DevOps to GitHub - GitHub Docs
https://docs.github.com/en/migrations/ado/prepare-for-your-migration-from-azure-devops-to-github • 155 KB fetched Open original page
Prepare for your migration from Azure DevOps to GitHub - GitHub Docs Skip to main content
GitHub Docs Version: Free, Pro, & Team
Search or ask Copilot Search or ask Copilot
Select language: current language is English
Search or ask Copilot Search or ask Copilot
Open menu
Collapse sidebar Expand sidebar
Scroll breadcrumbs left
* Home
* Migrations
* Migrate from Azure DevOps
* 4. Prepare to migrate
Scroll breadcrumbs right
Migrations
*
*
* Overview
* GitHub's migration tooling
* Migrations within GitHub
* Plan your migration
* Migration paths
* Locked repositories
* Mannequins and user activity
* Programmatic repository imports
* Migrate from Azure DevOps
* Get started
* 1. Understand migrations
* 2. Manage access
* 3. Configure GitHub Enterprise Importer
* 4. Prepare to migrate
* 5. Migrate repositories
* 6. Follow-up tasks
* Key differences
* Migrate with GraphQL API
* Migrator role
* Import source code
* GitHub Importer
* About GitHub Importer
* Import a repository
* Command line
* About source code imports
* Local code
* External Git repo
* Subversion
* Mercurial
* Team Foundation Version Control
* GitHub Enterprise Importer
* Understand GitHub Enterprise Importer
* About GitHub Enterprise Importer
* Migrate from Bitbucket Server
* About migrations
* Overview of a migration
* Manage access
* Migrate repositories
* Migrate between GitHub products
* About migrations
* Overview of a migration
* Manage access
* Migrate from Enterprise Server
* Migrate repositories from GitHub.com
* Migrate organizations from GitHub.com
* Migrate from GitLab
* Get started
* 1. Understand migrations
* 2. Plan your migration
* 3. Manage access
* 4. Configure GitHub Enterprise Importer
* 5. Configure storage
* 6. Migrate repositories
* 7. Follow-up tasks
* Migrate with GraphQL API
* Migrator role
* Complete migration
* Access migration logs
* Reclaim mannequins
* Live migrations (GHES to GHE.com)
* About live migrations
* Prepare for your migration
* Migrate your repository
* Complete your migration
* Troubleshooting
* Migrated data reference
* ELM CLI reference
* ghe-migrator
* About ghe-migrator
* Export from GHES
* Export from GitHub.com
* Migrate data
* Troubleshoot migrations
* Troubleshoot migrations
Prepare for your migration from Azure DevOps to GitHub
Plan your migration by understanding your timeline, what data will be migrated, and your organizational structure.
Copy as Markdown
Run your migration
Article 4 of 6
Next : Migrate your repositories from Azure DevOps to GitHub
In this article
* Determine how much you have to migrate
* Determine GitHub organizational structure
* Configuring repository permissions
Determine how much you have to migrate
Determine your timeline, which will largely dictate your approach. The first step for determining your timeline is to get an inventory of what you need to migrate.
* Number of repositories
* Number of pull requests
Note
Migration timing is largely based on the number of pull requests in a repository. If you want to migrate 1,000 repositories, and each repository has 100 pull requests on average, your migration will likely be very quick. If you want to migrate only 100 repositories, but the repositories each have 75,000 pull requests on average, the migration will take much longer and require more planning and testing.
We recommend the inventory-report command in the ADO2GH extension of the GitHub CLI. This command will connect with the Azure DevOps API, and then create several CSV files. repos.csv contains information about your repositories, including the number of pull requests.
To produce the CSV files, use the following command, replacing YOUR_ADO_ORG with your organization on Azure DevOps.
Shell gh ado2gh inventory-report --ado-org YOUR_ADO_ORG
gh ado2gh inventory-report --ado-org YOUR_ADO_ORG
After you take inventory of the repositories you need to migrate, weigh your inventory data against your desired timeline.
* If your organization can withstand a higher degree of change, then you might be able to migrate all your repositories at once, completing your migration efforts in a few days.
* If you have teams that are not able to migrate at the same time, you might want to batch and stagger your migrations to fit the teams' timelines, extending your migration effort.
Determine GitHub organizational structure
Next, plan the organizational structure you'll create in GitHub. ADO and GitHub have different ways of organizing an enterprise's work.
* ADO: Organization > team project > repositories
* GitHub: Enterprise > organization > repositories
After migrating to GitHub, you should have only one enterprise account and a small number of organizations owned by that enterprise. Each organization from ADO should correspond to a single organization on GitHub.
Note
The concept of a team project, which is used to group repositories in ADO, does not exist in GitHub. We do not recommend creating an organization on GitHub for each team project on ADO, as this may result in a large list of ungrouped repositories within each organization. However, you can manage access to groups of repositories by creating teams.
If you want to break your migration effort into batches, the new structure can help you determine them. If you have more than one organization in ADO, and each organization's repositories are reasonably sized batches, consider batching by organization.
* Decide what your new organization structure will be.
* Decide if you need to break up your migration effort into smaller batches.
* If so, decide how you want to break up your migrations.
Configuring repository permissions
Because permissions work differently in GitHub than in ADO, GitHub Enterprise Importer does not attempt to migrate repository permissions from ADO.
When you use ADO2GH CLI, GitHub Enterprise Importer will create two teams in GitHub for each team project in ADO. Each team is granted a different level of access to all repositories that originated from the team project.
Team Access to migrated repositories
TEAM-PROJECT-Maintainers Maintainer
TEAM-PROJECT-Admins Admin
To give access to migrated repositories, you can add people to these teams. You can do this manually on GitHub, or if you chose to link the teams to Azure Active Directory (AAD) groups during your migration, by managing group membership in AAD. For more information about manually managing team membership, see Adding organization members to a team .
Up next
Migrate your repositories from Azure DevOps to GitHub
Step 4 of 6 in Run your migration
Help and support
Did you find what you needed?
Yes No
Privacy policy Help us make these docs great!
All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.
Make a contribution Learn how to contribute
Still need help?
Ask the GitHub community
Contact support
Legal
* © 2026 GitHub, Inc.
* Terms
* Privacy
* Status
* Pricing
* Expert services
* Blog
Links found on this page
- Skip to main content [direct]
- GitHub Docs [direct]
- Migrations [direct]
- Migrate from Azure DevOps [direct]
- GitHub's migration tooling [direct]
- Migrations within GitHub [direct]
- Plan your migration [direct]
- Migration paths [direct]
- Locked repositories [direct]
- Mannequins and user activity [direct]
- Programmatic repository imports [direct]
- 1. Understand migrations [direct]
- 2. Manage access [direct]
- 3. Configure GitHub Enterprise Importer [direct]
- 5. Migrate repositories [direct]
- 6. Follow-up tasks [direct]
- Key differences [direct]
- Migrate with GraphQL API [direct]
- Migrator role [direct]
- About GitHub Importer [direct]
- Import a repository [direct]
- About source code imports [direct]
- Local code [direct]
- External Git repo [direct]
- Subversion [direct]
- Mercurial [direct]
- Team Foundation Version Control [direct]
- About GitHub Enterprise Importer [direct]
- About migrations [direct]
- Overview of a migration [direct]
- Manage access [direct]
- Migrate repositories [direct]
- About migrations [direct]
- Overview of a migration [direct]
- Manage access [direct]
- Migrate from Enterprise Server [direct]
- Migrate repositories from GitHub.com [direct]
- Migrate organizations from GitHub.com [direct]
- Get started [direct]
- 1. Understand migrations [direct]
- 2. Plan your migration [direct]
- 3. Manage access [direct]
- 4. Configure GitHub Enterprise Importer [direct]
- 5. Configure storage [direct]
- 6. Migrate repositories [direct]
- 7. Follow-up tasks [direct]
- Migrate with GraphQL API [direct]
- Migrator role [direct]
- Access migration logs [direct]
- Reclaim mannequins [direct]
- About live migrations [direct]
- Prepare for your migration [direct]
- Migrate your repository [direct]
- Complete your migration [direct]
- Troubleshooting [direct]
- Migrated data reference [direct]
- ELM CLI reference [direct]
- About ghe-migrator [direct]
- Export from GHES [direct]
- Export from GitHub.com [direct]
- Migrate data [direct]
- Troubleshoot migrations [direct]
- Run your migration [direct]
- Adding organization members to a team [direct]
- Privacy policy [direct]
- Make a contribution [direct]
- Learn how to contribute [direct]
- Ask the GitHub community [direct]
- Contact support [direct]
- Terms [direct]
- Status [direct]
- Pricing [direct]
- Expert services [direct]
- Blog [direct]
|
|