GitHub Enterprise Migration

How Azure DevOps maps to GitHub

Most Azure DevOps features have a GitHub equivalent, but they don't all need to move at the same time:

• Azure Repos to GitHub repositories
• Azure Pipelines to GitHub Actions workflows
• Azure Boards to GitHub Issues and Projects, or kept and linked to GitHub
• Azure Artifacts to GitHub Packages, or existing feeds kept
• Service connections to Actions secrets or OpenID Connect federation with Azure
• Teams and permissions to GitHub teams and repository roles

Many organizations move repositories and pipelines first, keep Boards and Artifacts, and revisit them later once teams are settled on GitHub.

Converting pipelines to GitHub Actions

GitHub Actions Importer can audit your existing pipelines and produce draft GitHub Actions workflows, which removes much of the repetitive work. The output still needs review. Custom tasks, variable groups, approvals and deployment environments rarely map one to one.

We convert, test and tidy each pipeline, and switch deployments to Azure over to OpenID Connect federation, so no long-lived credentials are stored in GitHub.

Identity: Enterprise Managed Users or standard accounts

With Enterprise Managed Users, GitHub accounts are created, updated and removed by your identity provider, such as Microsoft Entra ID, and belong to the company rather than the developer. With standard accounts, developers use their own GitHub accounts, linked to your enterprise through single sign-on.

Enterprise Managed Users gives the most control and suits organizations with strict access requirements, at the cost of those accounts not contributing to public repositories outside your enterprise. The choice is hard to reverse later, so we settle it during planning.

Planning waves and cutover

Big-bang migrations are where history gets lost and teams lose a week. A wave plan looks like this:

• A pilot wave with a willing team and non-critical repositories
• Dry-run migrations for each wave, with validation reports
• A freeze window per team rather than for the whole organization
• Integrations, webhooks and service hooks redirected to GitHub
• Source repositories archived read-only once the move is validated
• Hypercare support for each team in the days after cutover

Each team experiences a short, planned freeze with support on hand, rather than an organization-wide disruption.

What needs its own plan

Repository migration is well automated. Several other pieces are not, and they're where timelines slip if nobody planned for them:

• Pipeline run history, which stays in Azure DevOps for reference
• Variable groups, secure files and service connections
• Branch policies, which become GitHub branch protection or rulesets
• Azure Artifacts feeds and the pipelines that publish to them
• Wikis, dashboards and service hooks
• Integrations with chat, ticketing and deployment tools

We inventory all of these during the assessment and give each one an owner and an approach, so there are no surprises in the week of cutover.