Poonam Gupta wrote this on the Azure DevOps Blog on 3 June 2026. She is Partner Director of PM for 1ES and Azure DevOps. The example is Microsoft’s own Copilot, Agents, and Platforms group, which the post calls CAP. She is sharing it at Build 2026, as a path other Azure Repos customers could study.
CAP runs about 4,000 active repositories across 53 Azure DevOps organizations. The group owns Copilot products and other business and industry services. Two engineering leads and a small bench did the move. The post says that was enough, and that a large central team was the thing people would have assumed.
The Azure DevOps → GitHub playbook splits repos from Boards, Pipelines, and Artifacts. CAP’s cut is the same split. Repos moved. Boards and Pipelines stayed. The post never gives a downtime number for the repos that already moved.
Two percentages, one page
In the body, Gupta says CAP has moved more than 80% of its in-scope repositories and 45% of its developers. She turns that into over 1,600 repositories and 3,100 developers in six months. Read 1,600 as her translation of the 80%, and 3,100 as her translation of the 45%. Large repos for Dynamics CRM and omnichannel CRM are in that set.
Further down, the lessons say CAP has migrated more than 70% of its active, in-scope repositories, and that many of the largest ones are still on Azure DevOps. “In-scope” and “active, in-scope” are not the same phrase, and 80 and 70 are both printed. The page also never says what made a repo in scope, so the 4,000 active repos and the in-scope subset can be different piles.
The complex repos, including mono repos, are the leftover. She expects Enterprise Live Migrator to speed that next phase. Expects, not finished. She does not say which tool moved the 1,600. GitHub Enterprise Importer and Enterprise Live Migrator are both named as tools the product teams built. The CAP story does not assign the finished repos to either one.
What those tools are, in Microsoft’s later posts
Five days later, on 8 June 2026, Soo Stahl and Bhuvan Shah posted that Enterprise Live Migrations was in limited public preview. On 31 August 2026 Stahl posted that it was in public preview. These are product posts. They are not a log of CAP’s six months.
The shape they describe is why Gupta points at it for the repos still left. The Azure DevOps repo stays writable. Changes sync to GitHub in the background. Cutover is a final sync, and they say the downtime is typically under 30 minutes for most repositories. They contrast that with older moves that could take days. The stages they print are validate, synchronize, then cut over.
The destination is narrow. ELM supports GitHub Enterprise Cloud with data residency, the ghe.com URLs. It does not support ordinary GitHub Enterprise Cloud on github.com. Stahl answered a comment on 25 June, and again on 13 August, that they hope to add more destinations and that GitHub had not committed a date for the github.com path. Gupta’s post never says which GitHub CAP landed on, so “we expect ELM” does not tell you the 1,600 already sit on ghe.com.
The August post lists what the sync carries. Repositories, commit history, branches, tags, branch policies converted to rulesets, and pull request metadata, comments, and user history. It can coordinate more than one repo. It does not migrate work items, pipeline definitions, releases, wikis, test artifacts, or Azure Artifacts. It can clone pipelines so a team can test them, then rewire the originals to the GitHub repo at cutover. Boards can stay. That split matches the hybrid CAP already describes. It is still the product’s list, not a statement that CAP ran this workflow.
Why the repos moved
The reason on Gupta’s page is where AI features show up. Copilot Coding Agent, code review, Copilot chat, and other agent workflows are the list. She also names the surfaces. VS Code, Visual Studio, the Copilot CLI, GitHub Mobile, and the Copilot app. CAP engineers already run some of those workflows on the migrated repos. Scans look for security, performance, and governance issues, open GitHub Issues, and hand a fix to the coding agent. Windows runners are part of that setup, so the agents are not Linux-only.
A second gain is search. One GitHub organization replaces work that was spread across 53 Azure DevOps organizations. Review on a phone, in the CLI, or on the desktop is the other practical gain she names, separate from the agents.
The comments under her post are not CAP’s results. One reader writes that a recent repo migration slowed them down, and that code review was better in Azure DevOps. Another writes that Copilot’s price is why a smaller company would stay. A longer comment asks why the agents are not coming to Azure Repos, what the hybrid costs to run, and what a regulated mono repo should do. The thread is closed without her answers.
What they refused to move
Azure Boards and Azure Pipelines still do the planning and the CI. CAP connects pipelines with the Azure Pipelines GitHub app. Pull requests link to work items with AB# syntax.
Day to day, GitHub asks for a different kind of customization. The post says the shift is away from UI extensions and toward APIs, Actions, and integrations. People who already knew GitHub passed habits along. The hybrid setup is how they kept the old boards while that happened. Other Microsoft teams are on their own paths. She does not describe those paths.
If you copy this, write down which repos are in scope before anyone publishes a percent. CAP’s own page uses two. Move an ordinary repo before you bet a mono repo on Enterprise Live Migrator, and check that the GitHub you are aiming at is one ELM supports. Decide, on the same list, which Boards and Pipelines stay. The playbook treats those as a separate job from the git history.