How Microsoft Is Moving 4,000 Repos to GitHub (And What You Can Learn From It)

So Microsoft published a post about how their internal CAP (Copilot, Agents, and Platforms) organization is migrating away from Azure DevOps to GitHub, and it's actually worth reading — not for the corporate cheerleading, but for the honest bits about what a migration at this scale actually looks like.

Let me break it down for you without the marketing fluff.

The situation: 53 Azure DevOps orgs. Really.

CAP manages roughly 4,000 active repositories spread across 53 separate Azure DevOps organizations. Fifty-three. I don't know how you end up in that situation without someone at some point saying "maybe we should rethink this," but here we are. That kind of fragmentation is death by a thousand org boundaries — code discovery gets painful, cross-team visibility is basically non-existent, and onboarding new people is a nightmare.

The migration started about six months ago. So far they've moved over 1,600 repos and around 3,100 developers. That's more than 80% of the in-scope repositories and 45% of developers — done. Not bad.

Why GitHub and why now?

The honest answer: Copilot. GitHub Copilot Coding Agent, Code Review, agentic security scanning, all the AI-first stuff that's baked into GitHub — it's not coming to Azure DevOps at the same pace. If you're a big org and you want earlier access to that tooling, you move where the development is happening.

CAP teams are already running AI-driven workflows for security scanning and issue remediation post-migration. That's not a feature you wait for — it's table stakes now if you want to stay competitive on developer productivity.

The secondary win is consolidation. Going from 53 fragmented orgs down to one GitHub organization means code discovery actually works. Engineers can find each other's repos. That sounds boring until you've lived in a multi-org sprawl and wasted two weeks just tracking down where some shared library lives.

The two-person migration team (yes, really)

Here's the part that surprised me: they did this with two dedicated engineering leads and a small supporting bench. Not a 20-person migration task force. Two leads.

That's a real data point worth keeping when someone in your org tells you you'll need a six-month planning phase and a dedicated team of eight to migrate 100 repos. Tooling has gotten good enough that you don't need armies anymore, you need the right process and the right automation.

What they didn't move: the hybrid reality

This isn't a full rip-and-replace. And honestly, that's the right call.

Azure Boards and Azure Pipelines are staying put for now. Existing CI/CD pipelines keep running. The connection between GitHub repos and Azure Pipelines is handled via the Azure Pipelines GitHub app, and work item linking uses the AB# syntax to keep Boards references working from GitHub commits and PRs.

So the dev workflow looks like: code lives in GitHub, you get Copilot and AI tooling there, but your pipelines and planning boards haven't changed. That's a much easier migration to sell to teams than "we're rewriting everything at once."

I genuinely don't understand why more orgs don't start here — migrate the repos first, prove the value, then tackle pipelines when you actually have capacity and motivation.

The sequencing: don't start with your nightmare repos

This is the most tactically useful part of the whole post. Microsoft deliberately migrated the simpler, more active repositories first — about 70% of the active repos — while leaving the largest and most complex monorepos behind temporarily.

Those big repos are waiting on tooling: specifically GitHub's Enterprise Live Migrator (ELM). ELM hit public preview in May 2026 and it's built exactly for this problem — massive repos with deep histories that would choke the standard GitHub Enterprise Importer. ELM syncs continuously so developers keep working during migration, and only requires a short cutover window at the end. Minimum downtime for repos that genuinely cannot afford a code freeze.

The lesson here isn't "use ELM" (though you probably should). It's that sequencing matters. If you try to start with your hardest problem, you'll stall out before you've built any momentum. Start with the repos where migration is relatively painless, ship them, let teams adjust, then tackle the scary ones once you have a playbook and the right tooling.

What GEI doesn't give you

One thing the Microsoft post doesn't dwell on, but anyone who's done this migration knows: GitHub Enterprise Importer handles repositories well, but it doesn't migrate permissions, service hooks, pipeline run history, or work items. You're rebuilding parts of that from scratch.

The structural model difference is also real. Azure DevOps is project-centric — your repo, boards, pipelines, and wikis all live under one project roof. GitHub is repository-centric. Issues, actions, and discussions hang off individual repos. If you're used to one, the other feels weird for a while. It's not better or worse, just different, and you need to communicate that to your teams before they hit it.

The elephant in the room: pricing, lock-in, and "why are we paying for two platforms?"

Here's what the Microsoft blog post doesn't say — and what the comment section immediately did.

The most common reaction from people who actually use these products every day wasn't "wow, great migration strategy." It was a version of: "wait, you're telling me I need both GitHub Enterprise and Azure DevOps now?" And that's a completely fair question.

GitHub Enterprise starts at $21 per user per month. Azure DevOps Basic is $6. If your org is currently all-in on Azure DevOps, a move to GitHub doesn't replace that cost — it adds to it, at least during the transition period, and potentially permanently if you're keeping Boards and Pipelines running. Add Copilot Business on top ($19/user/month) and you're at $40/seat. For a 500-person engineering org, you're looking at real budget conversations.

Microsoft's official line is that Azure DevOps Basic is included with GitHub Enterprise Cloud when connected via Entra ID, so you're not necessarily paying double forever. But "included" only helps if you've actually made the full jump. During the hybrid phase — which the Microsoft post basically endorses as the right strategy — you're running both, and the licensing math gets complicated fast.

Then there's the reliability angle. Several commenters made the point that Azure DevOps has historically been the more stable platform, and the data in 2026 doesn't fully contradict them. GitHub had three major outages in January 2026 alone — 14 combined hours of developers unable to push code — and February hit a low of around 90% uptime. The culprit, per GitHub's own postmortems: AI agent traffic growing at a scale the architecture wasn't designed for. Which is ironic, given that "AI-native" is the whole pitch for moving to GitHub in the first place.

Look, Azure DevOps isn't flawless — it had its own ugly 159-hour performance degradation event earlier in 2025. But the community perception is clear: you're trading a somewhat boring, stable platform for a more dynamic one that occasionally falls over at the worst possible moment.

The deeper concern is vendor lock-in. A few commenters put it bluntly: this isn't a technical migration, it's a commercial migration. GitHub Copilot is the main reason to move, but Copilot only makes sense inside GitHub. Once your workflows depend on it — code review automation, agentic security scanning, coding agents running in your CI — you're not really evaluating platforms anymore. You're committed. And Microsoft knows that.

Honestly, I think that's fine if you go in with your eyes open. The productivity gains are real. But the framing of "move to GitHub for better AI" without acknowledging the cost delta and the platform dependency is a bit convenient coming from the company that owns both products. The commenters who called it "just another way to get customers to pay more" are being uncharitable — but not entirely wrong.

The thing that bugs me most is the silence around feature parity for project management. Azure Boards is genuinely good. Test Plans are genuinely good. GitHub Issues is fine, GitHub Projects has gotten better, but if you're running a team that depends on Boards-level work item tracking and sprint management, the GitHub equivalent currently doesn't fully replace it. Several commenters asked Microsoft directly: either build parity in GitHub, or at least be honest that you're expecting everyone to run a permanent hybrid stack. Silence on that question is its own kind of answer.

What this means if you're planning something similar

A few things to take away if you're staring down a similar migration:

Pick your migration tool based on repo size. Standard repos: GitHub Enterprise Importer works fine. Anything with a massive history or a monorepo situation: wait for ELM or plan around it.

Hybrid is not a dirty word. Keeping pipelines on Azure DevOps temporarily isn't a failure state, it's a risk mitigation strategy. You don't have to move everything at once to get the benefits of GitHub hosting.

Consolidation has value beyond tooling. Moving 53 orgs into one isn't just administrative cleanup. It changes how people collaborate and discover code. Don't underestimate that.

Two people can migrate 1,600 repos. If you're getting budget for a massive migration team, maybe start with two leads and see how far good tooling gets you before you scale up.

Do your own pricing math before you commit. Don't let a blog post from the vendor tell you the costs work out. Run the numbers for your actual headcount and your actual feature needs, including the hybrid period.

The migration isn't finished — 45% of developers still need to move, and the complex repos are still pending. But the structure is solid and the direction is clear. At this point it's mostly execution, and Microsoft has clearly figured out how to run that playbook at scale.

For a company that owns both products, it's a fairly honest look at what a real enterprise migration involves. The fact that they're still running Azure Pipelines in parallel tells you everything you need to know about not overselling the "just flip the switch" version of this story. The community concerns about pricing and lock-in are real though — and anyone planning a similar migration deserves to hear those alongside the success story.