Enterprise Live Migrations

Microsoft built the tool for the hybrid answer

The most common honest outcome of the GitHub question has always been hybrid: repositories move to GitHub, where your developers want to work, and Boards stays, keeping the process, test plans, and compliance evidence GitHub has no home for. Microsoft’s Enterprise Live Migrations (ELM) is that answer with vendor tooling behind it. It moves repositories from Azure DevOps Services to GitHub Enterprise Cloud, re-points your Azure Pipelines at the new repository, and creates the Boards connection. It is free, and currently in limited preview with a sign-up.

The mechanism is genuinely new for this space. Every other migration tool copies a snapshot and reconciles the drift. ELM syncs continuously: your repository is already at GitHub before cutover day, your teams keep pushing to Azure DevOps until then, and cutover becomes choosing when to stop. The read-only window at cutover is typically under 30 minutes.

What it moves, and the clock it starts

• Git history, branches, and tags move. So do pull request titles, descriptions, comments, and user history. Branch policies become GitHub rulesets.
• Work items, pipeline definitions, releases, wikis, test plans, and artifacts do not move. Neither does Git LFS yet.
• The sync starts a clock. Cutover must complete within 21 days of the first sync. Wave planning, cutover ownership, and the decisions about everything ELM leaves behind need to exist before you press start.
• The estate must be in shape. No single file over 400 MB in history, branch and tag names under the length limit, a self-hosted Linux agent that stays online, and a GitHub Enterprise admin to install the app.
• It only leaves Azure DevOps Services, and only lands on GitHub Enterprise Cloud with data residency. On Azure DevOps Server, your path is two moves in sequence: Microsoft’s import into Services first, then ELM. Landing on plain GitHub Enterprise Cloud, GitHub’s Enterprise Importer is still the right tool.

When it is the wrong tool

ELM moves the layer that was always the easy part. The move around it is where migrations earn their scars: what happens to ten years of work items, the test plans your auditors ask about, and the pipelines that reference everything. ELM leaves all of that where it is. If the whole estate is going, work items included, that is still a real migration: engineered and scripted for your estate, with the losses GitHub’s model imposes on Boards data named and agreed in writing before anything moves. If Boards stays but must be reshaped around the move (organisations merged, a division carved out after a sale), that is selective work-item migration inside Azure DevOps, the trade of our open-source tools .

Scoping all of that, and whether your estate can survive the 21-day clock, is exactly what a migration assessment produces. And if the repos have already cut over cleanly while everything else sits stranded, that is a migration rescue .

This is not for you if you are moving repositories only, you are on Services, and your estate fits the limits: sign up, run it, and don’t hire anyone. The repos were always the easy part.