Migrate from Azure DevOps to GitHub
Repositories and pipelines together. Rewire Azure Pipelines to your new GitHub repositories on day one, or convert them to GitHub Actions on reusable workflows, team by team, with rollback at every step.
Repositories and pipelines both run in the apptrigger: [main]
resources:
repositories:
- repository: templates
type: git
name: platform/pipeline-templates
steps:
- template: steps/dotnet-build.yml@templates
parameters:
projects: '**/*.csproj'
configuration: Releasename: ci
on:
push:
branches: [main]
jobs:
build:
uses: acme/platform-workflows/.github/workflows/dotnet-build.yml@v2
with:
project: '**/*.csproj'
configuration: Release
secrets: inheritTrusted by teams moving to GitHub at scale
What moves
Everything your Azure DevOps estate runs on.
Repositories
Full history, connected with Microsoft sign-in or a token.
YAML pipelines
Templates and extends become reusable workflows; stages and jobs become jobs with needs.
Classic pipelines
Classic build and release definitions are imported and converted too.
Variable groups
Each group is split into one GitHub secret or variable per key.
Service connections
Moved to OpenID Connect, so no long-lived cloud keys are stored.
Server and Services
Pipelines from Azure DevOps Services and on-premises Server.
Two ways to move your pipelines
Rewire now, convert when you are ready.
Once your repositories are on GitHub, each Azure pipeline can go one of two ways. Most teams use both: rewire everything on day one, then convert to GitHub Actions in waves.
Rewire to GitHub
Keep Azure Pipelines running, pointed at the new GitHub repositories.
- Pipelines keep building in Azure DevOps, triggered from GitHub
- Hard-coded Azure DevOps URLs and submodules fixed as pull requests
- Pipeline definitions relinked in waves, with triggers verified
- Nothing for teams to relearn on day one
Best when: You need code on GitHub first, or a pipeline is not ready to convert.
Convert to GitHub Actions
Pipelines become GitHub Actions workflows on shared building blocks.
- YAML and Classic pipelines grouped into families and converted once
- Templates become reusable workflows your platform team owns
- Variable groups become secrets, service connections move to OIDC
- Azure Pipelines and its licenses retire when the last wave lands
Best when: You want one CI system, shared workflows and Azure DevOps switched off.
Choose per team or per pipeline. The Azure DevOps source stays enabled until its rewire pull requests merge, and every step can be rolled back.
- Discover, scan, and migrate them at the same time
- Every pipeline
- build and release pipelines both convert
- YAML + Classic
- of rewire and relinking at cutover, each one reversible
- 5 stages
How it maps
Azure DevOps concepts, in GitHub Actions terms.
Deprecated task versions are flagged during import so they are replaced, not carried over.
| Azure DevOps | GitHub Actions |
|---|---|
| UseDotNet@2 | actions/setup-dotnet |
| NodeTool@0 | actions/setup-node |
| Cache@2 | actions/cache |
| PublishPipelineArtifact@1 | actions/upload-artifact |
| AzureCLI@2 | azure/login (OIDC) + az |
| AzureWebApp@1 | azure/webapps-deploy |
| Docker@2 | docker/build-push-action |
| KubernetesManifest@1 | azure/k8s-deploy |
| template: / extends: | reusable workflow (workflow_call) |
| pool: vmImage | runs-on |
No surprises at cutover.
The parts that need a person are named in the plan up front, so they are decided before cutover, not discovered during it.
What needs a person
- Environment approvers and wait timers, which become GitHub Environment rules
- Self-hosted agent pools and their demands
- Secure files and cross-repository pipeline resources
- Secret values, which are entered in GitHub rather than exported
Rewire and rollback
- Confirms the repository map, then opens pull requests that fix hard-coded Azure DevOps URLs and submodules
- Relinks pipeline definitions to the new GitHub repositories in waves, then verifies triggers
- Rollback restores the original repository and triggers, in bulk or one at a time
The same method for every Azure DevOps estate.
See the full method- 01Inventory everything
- 02Convert families, not files
- 03Ship in waves of pull requests
- 04Cut over with rollback
Your migration, your way
Run it yourself, or run it with us.
Self-serve
Migration Assistant
The whole program in one app: inventory, families, waves of pull requests and cutover. Built for platform teams who want to drive.
- Inventory, families, waves and cutover in one app
- Pull requests to repository owners, not tickets
- Start free on 10 repositories, no card
With our migration team
Migration services
We scope, plan and run the move alongside your team, on the same platform, for the estates and deadlines that can't slip.
- GitHub Enterprise Cloud to EMU and data-residency moves
- Scoping, wave plans and cutover support
- The custom pipelines nobody wants to touch
- A team that has done this at enterprise scale
After the move
Land clean, then stay clean.
CodeCargo Manage keeps every repository on the standards and building blocks you migrated onto, fixing drift as pull requests, as far on its own as you allow.
Azure DevOps migration questions.
Don't see yours? Our migration team will walk through your Azure DevOps estate with you.
Do you migrate Azure Repos and Azure Pipelines together?
Yes. Repositories move with full history, and pipelines are converted onto reusable workflows. Cutover then rewires and relinks them, team by team.
Should we rewire our Azure pipelines or convert them to GitHub Actions?
Usually both, in order. Rewiring points your existing Azure Pipelines at the new GitHub repositories, so code moves first and nothing changes for your builds. Converting moves each pipeline onto GitHub Actions and shared reusable workflows, so Azure Pipelines can be retired. You can choose per team or per pipeline, and a rewired pipeline can convert in a later wave.
Can you convert Classic pipelines?
Yes. Classic build and release pipelines are imported and converted alongside YAML pipelines. Logic that only lived in the Classic UI is surfaced in the plan for a person to confirm.
What happens to variable groups and service connections?
Each variable group is split into one GitHub secret or variable per key, and service connections move to OpenID Connect, so no long-lived cloud credentials are stored in GitHub.
Can we roll back after cutover?
Yes. Every rewire step waits for an approval, and rollback restores the original repository and pipeline triggers, in bulk or one repository at a time.