Microsoft's Enterprise Live Migrations eases Azure DevOps-to-GitHub moves, but pipelines remain the catch

The tool and its catch

Microsoft's Enterprise Live Migrations (ELM) service is in public preview, and according to a practitioner write-up on dev.to it takes much of the pain out of transferring repositories from Azure DevOps into GitHub Enterprise. It can even reconnect existing pipelines after the move — provided those pipelines keep running in Azure DevOps. That caveat is what pushed one team toward a split-platform setup rather than a full migration.

The author explains that the hybrid pattern — CI in GitHub, CD left in Azure DevOps — was recommended to them by the GitHub team and is well established in the community, though every organisation places the boundary differently.

Why CI went to GitHub

The team's stated motivation for moving CI was standardisation: keeping builds next to the source, so developers see results without hopping between platforms. GitHub's reusable workflows let each repository carry a minimal CI file that delegates the real build steps to a shared, centrally maintained workflow. That gives platform staff one place to enforce required steps and roll out changes across every project at once.

The write-up also describes a tagging strategy for those shared workflows: a moving v1 tag tracks the latest iteration, minor tags record individual changes, and a future v2 tag would gate breaking updates so repositories can move over gradually.

Why CD stayed put

The blockers are data residency and private networking. ELM, the author notes, only supports GHE.com, and no UK region exists — a constraint that changes the calculus for regulated UK environments. Their GitHub Enterprise instance runs in Europe because that is the nearest region available, while their infrastructure sits in UK Azure regions. GitHub's VNet integration for runners does not cover UK South or UK West, which rules out deploying privately from GitHub Actions. Self-hosted runners inside the network would work, but the team would then own the operational burden and lose the benefits of managed runners.

Azure DevOps solves this with Managed DevOps Pools (MDPs): agent infrastructure deployed into your own Azure subscription, with agents injected through a delegated subnet and usable by any Azure DevOps pipeline. That delivers private networking without the patching and scaling work of self-hosted agents. The team is also keeping Azure Boards — which the author considers the more mature product for organisations wanting strict planning processes — linked via the GitHub-to-Azure Boards integration.

How the hand-off works

CI in GitHub builds the code and publishes artifacts to a GitHub release; an Azure DevOps pipeline then fetches that release and runs deployment. The trigger relies on the Azure/pipelines action, which starts an Azure Pipelines run straight from a GitHub Actions workflow but requires a personal access token to authenticate.

On the Azure side, the built-in task for downloading GitHub releases does not support GHE.com service connections, so the author fell back to a custom script that calls the GitHub API directly. It works, but it is code they now own and maintain, with credentials to manage — and they would switch back to the built-in task if it gains GHE.com support.

Immutability is central to the design. Release immutability in GitHub is not on by default; it must be enabled per repository or org-wide, and it only applies to releases created afterwards. With it in place, Azure DevOps deploys exactly the artifact that GitHub built and tested, rather than rebuilding and producing a divergent binary — and a rollback redeploys the identical artifact.

The author also flags a business decision that most online guidance skips: which event should promote a build into a given environment. Options include a manual workflow dispatch, a tag on a commit, or merges into a release branch, each with trade-offs that the right stakeholders should agree on and document.

Why it matters

ELM lowers the cost of the repository move itself, but this account shows that the harder question is what happens to your pipelines — and for teams with residency obligations or private-deployment requirements, the answer may be a hybrid that persists for years. The piece doubles as a checklist for anyone weighing the same move: verify runner VNet coverage for your regions before assuming GitHub Actions can deploy privately, weigh managed pools against self-hosted runners on both platforms, make release immutability explicit, and treat promotion triggers as a documented decision rather than a technical afterthought. It is one team's implementation rather than a template, but it maps the trade-offs that a preview tool's documentation will not spell out for you.