Every Azure DevOps to GitHub migration conversation I’ve been in hits the same wall. Someone asks “so how long do the developers have to stop pushing code?” and the room goes quiet. Nobody wants to tell forty engineers to down tools for a day whilst the repos get copied across and everyone crosses their fingers.
Back in May I wrote about why now is the right time to move from Azure DevOps to GitHub Enterprise, and the downtime question was the one I didn’t have a great answer for. Microsoft have now put something in public preview that goes straight at it.
What it actually is#
Enterprise Live Migrations (ELM) moves Azure DevOps repositories to GitHub Enterprise Cloud whilst developers keep working. Rather than a one-shot copy, changes are continuously synchronised in the background, and then you do a final cutover when you’re ready. The announcement says the cutover downtime is typically “less than 30 minutes for most repositories”.
It works as a staged process in three phases: Validate, Synchronize and Cut over. You can drive it from the Azure DevOps CLI or from the web UI.
What comes across, and what doesn’t#
This is the bit worth reading carefully before you promise anyone anything. According to the announcement, ELM migrates:
- Repository data, including commit history, branches and tags
- Branch policies, which get converted into GitHub rulesets
- Pull request metadata, comments and user history
- Multiple repositories, not just one at a time
What it does not move is work items, pipeline definitions, releases, wikis, test artifacts or Azure Artifacts. So this is a source control migration, not a whole-platform one.
That’s less of a problem than it sounds, because ELM can rewire your existing Azure Pipelines to point at the migrated GitHub repositories. Teams can also keep using Azure Boards for work tracking whilst their code lives in GitHub. For a lot of organisations that hybrid setup is exactly the sensible first step – move the code, keep the pipelines and boards running, and deal with Actions later on your own timetable.
The big caveat#
ELM only supports GitHub Enterprise Cloud with data residency – the ones on a ghe.com URL. Standard GitHub Enterprise Cloud on github.com is “not currently supported”. If your enterprise lives on github.com, this isn’t for you yet, and you’re still looking at GitHub Enterprise Importer for now. The announcement doesn’t say whether or when that will change, so I wouldn’t plan around it.
It’s also a public preview, so treat it that way. Try it on repos nobody will cry over first, not your most important monorepo.
Getting started#
The documentation, including the prerequisites, is at aka.ms/adoELM. I’d start there, check your target is a data-residency enterprise, then pick a small, low-risk repo and run it through all three phases end to end. Pay particular attention to how your branch policies come out as rulesets and whether your pipelines behave after the rewiring. Those are the two things that will bite you on the real migration if you don’t check them now.
Final thoughts#
If you’re on GitHub Enterprise Cloud with data residency and you’ve been putting off a migration because of the downtime conversation, this removes the main excuse. Pick one repo this week, run it through ELM, and see how the cutover feels. Full details are in the original announcement.
