At the end of my TFVC-to-Git migration post, I suggested that if you're migrating your Azure DevOps TFVC code to Git, you're probably going to want to redo your build and release pipelines, too. Once you've got your TFVC stuff converted to Git, your world is kind of your overwhelming oyster.

It usually goes something like this: "well, if we're going to rewrite our builds and releases in YAML, should we just chuck Azure DevOps entirely and move everything to GitHub?"

It's a really good question. But it might not be the right question. At least not yet.

The Short Version

• The question teams ask is "Azure DevOps or GitHub?" The question that actually matters is usually something else entirely.
• Teams that want to switch platforms are often reacting to strategic anxiety, messy pipelines, developer frustration, or post-acquisition sprawl. Each of those has a real question hiding underneath it.
• If your code is still in TFVC, the platform choice isn't even the right conversation yet. Get to Git first. That's the migration that changes everything.
• Git doesn't change what's possible. It changes what's easy. And in software delivery, friction is the enemy.
• Once you're on Git, it's all just Git. AzDO and GitHub are both excellent. The real tradeoff is one platform (simpler) vs. two platforms (more flexible, more integration overhead).
• The problems that actually slow your team down -- database versioning, legacy apps, manual QA, tech debt, poor requirements, too much WIP -- will follow you to any platform.
• DevOps is in the same danger zone that Scrum was in. Don't adopt the tools without addressing the problems the tools are supposed to help you find.

"Which Do We Use? Azure DevOps or GitHub or Both?"

When I discuss "Azure DevOps vs. GitHub" with customers, the questions always seem to be about feature comparisons. Trying to compare features is definitely a valid thing to consider but what tends to get missed are the people & process things.

My advice: start with the people stuff first and choose tooling that supports and streamlines the people stuff rather than choosing cool features. People and organizational stuff first. Always.

In each of the patterns below, the question teams ask me is about tooling. The question they actually need to answer is usually about something else entirely.

"GitHub Is the Future. Microsoft Is Sunsetting Azure DevOps."

This one tends to be a 50/50 mix of "fear of choosing the wrong option" and "fear of missing out". Choosing the wrong option is usually about the fear of being "Silverlighted". Basically, the fear that Microsoft is going to abruptly dump Azure DevOps and leave you high and dry with nothing but bad options. As someone who got "silverlighted" back in the day, I still feel the sting -- but in this case, it's not going to happen. Azure DevOps is popular and it's here to stay.

When I say that, the question that follows is always something like "yah but all the heat and investment and cool-factor is happening in GitHub and not in Azure DevOps." To a certain extent, this is true. Microsoft has been investing heavily and publicly in GitHub. The Enterprise Live Migrations tool. Copilot everywhere. There's clear and obvious time, money, and effort happening on the GitHub side.

But just because the new and shiny stuff is happening on GitHub doesn't mean that Microsoft is killing off Azure DevOps. They've been very carefully NOT saying Azure DevOps is going away. They keep shipping new features every sprint. The platform is actively maintained and actively improved.

Is the long-term gravity toward GitHub? Probably. Is that gravity strong enough to justify a migration right now? That depends on a lot of things that have nothing to do with what Microsoft might do in three years. Making a major infrastructure decision based on what you think a vendor might announce is a rough way to run a program.

Plus, I wouldn't be surprised to find out that they stay forever separate and simply target different types of customer.

The real question: Is the anxiety and FOMO driving a premature move? Or do you have actual operational reasons to switch?

"Our Branches and Pipelines Are a Mess. Maybe Fresh Tooling Will Help."

This is the big one. This is the one where I put on my therapist hat. The grass is not necessarily greener on the other side of the street.

If your classic pipelines are undocumented spaghetti that only three people understand -- and one of them left the company last year -- switching to GitHub Actions doesn't fix that. You're moving the spaghetti to a different plate.

And actually it's worse than that. The act of migrating creates an opportunity to either clean up the mess or reproduce the mess. Most teams reproduce the mess. They do a 1:1 translation of their existing pipeline into the new syntax and call it done. Same dysfunction, different YAML, plus a team that doesn't know the new platform yet.

Additionally, if your pipelines were written in 2008 and they no longer really actually match the way you work now and the current needs of the business, that 1 for 1 rewrite isn't going to help much.

A couple things that tend to come along for the ride in this pipeline discussion: "our branches are nasty" and "our QA process takes forever." They're usually all related to one another. If it were a medical issue, you'd call it a comorbidity.

New tools don't fix bad process.

The real question: Is the problem your tooling or your pipeline design? Because if it's the design, you can fix that on AzDO YAML without migrating anything.

"Our Developers Want GitHub."

Developer experience is a legitimate concern. Happy developers who like their tools are more productive than unhappy developers fighting their tools. That's real. I'm very sympathetic to this one because a lot of times this turns into a bit of an HR problem: it can become tough to recruit new talent or retain existing talent.

But before you make any moves, it's worth it to dig one layer deeper. Do your developers want GitHub specifically? Or do they just want to stop fighting the current tooling? Those are different problems with different solutions.

If the frustration is something like "our classic pipelines are impossible to debug" -- YAML pipelines on azdo fix/help that. You don't need to change platforms.

If the frustration is "I want the Actions marketplace and GitHub's PR workflow" -- that's a genuine GitHub-specific value proposition. Worth evaluating.

If the frustration is "everything about our development process is painful and GitHub seems nicer" -- that's almost certainly not really a tooling problem. GitHub is not going to fix it.

The real question: What specifically is frustrating your developers? Can you fix it without switching platforms?

"We're Consolidating Platforms."

This is often the most rational reason. You grew through acquisition. You've got three Azure DevOps orgs, two GitHub orgs, and a Jenkins server that nobody admits to owning. Different departments adopted different tools over the years. Now someone's been told to clean it up.

Consolidation is legitimate. But consolidation without examination just produces a single platform with two generations of technical debt instead of two platforms with one generation each. If you're consolidating, the migration is the moment to simplify. Not to import.

The real questions: Are you consolidating or are you just relocating? And what can you simplify or just stop doing entirely?

TFVC: The Migration That Actually Matters

If there's one question that matters more than "Azure DevOps or GitHub," it's this: is your code on Git yet? Azure DevOps has two different version control flavors: Git and Team Foundation Version Control (TFVC). And they're real different.

YAML pipelines -- on either platform -- require Git. If you're on TFVC, you're stuck on classic pipelines no matter what. The strategic migration -- the one that actually changes your delivery capability -- is TFVC to Git. I wrote a whole post about why that's harder than you think.

But here's what I want to emphasize: the TFVC-to-Git migration isn't just a version control upgrade. It's a philosophy change.

It's not so much that Git changes what's possible. You can do feature branches in TFVC. You can do code reviews in TFVC. You can manage dependencies in TFVC. All of it is technically possible. It's more like Git changes what's easy.

In software development, friction is the enemy of good delivery practices and process.

In TFVC, creating a feature branch means copying a directory tree. It's a deliberate, heavyweight act. In Git, it's git checkout -b feature/my-thing. The practice is the same. The friction is completely different. One team does feature branches because they've committed to a process and they're disciplined about it. The other team does feature branches because...that's just how you work in Git. It's not even a decision.

Pull requests? They're native to Git-hosted platforms. Code reviews happen as part of the natural workflow, not as an extra ceremony you bolt on. Branch policies? Built in. Path-based triggers for CI/CD? Trivial.

The Virtuous Cycle of Dependency Management

And then there's the dependency management shift that nobody really talks about. In TFVC, teams check binary dependencies into source control because it's easy and it works. Shared DLLs in a $/Lib/ folder. Projects referencing assemblies across the directory tree. It's fine because there's only one repo.

In Git, that approach falls apart fast. Repo size bloats. Clone times go up. Cross-repo references break. So you set up a private NuGet feed. You start packaging your shared libraries. You version them independently. Teams consume them through package references instead of file paths.

It's a virtuous cycle. Almost by accident, you've built yourself a real dependency management infrastructure. Teams can share code cleanly, version it independently, and consume it without tangling their repos together. That's not a source control improvement. That's an architecture improvement that fell out of a source control decision.

If you've got shared libraries or common components that multiple teams depend on, this is a world changer.

The cascade goes like this: TFVC → Git → packages → clean repo boundaries → meaningful CI/CD events → pipelines that actually make sense. The tooling choice -- AzDO vs. GitHub -- is the last step in that chain. And it's the one everyone wants to talk about first.

Once You're On Git, It's All Just Git

I know this isn't the definitive answer that people are hoping for. But here it is.

Git on Azure DevOps is Git. Git on GitHub is Git. Git on GitLab is Git. It's all the exactly same Git. You can move repos between hosts. You can mirror them. You can push to multiple remotes. The version control itself is platform-agnostic.

Everything else is the tooling around it. Pipelines. Work tracking. Package feeds. Security scanning. Environments. Approvals. Marketplace and extensions. That's where the platforms differentiate. And honestly? Both Azure DevOps and GitHub are genuinely good at all of it.

The real tradeoff isn't features. It's integration complexity.

One platform means everything is connected by default. Your work items link to your PRs link to your pipelines link to your deployments. No integration to maintain. No syncing. No "which system is the source of truth" conversations. Pick AzDO if you're deep in the Azure Boards / Test Plans ecosystem and that stuff is working for you. Pick GitHub if your code's already there and you want GitHub Projects, GitHub Issues, Actions, Advanced Security, and the marketplace.

Two platforms gives you flexibility. Source code on GitHub, work tracking in Azure Boards -- that's a legitimate and increasingly common pattern. New pipelines in GitHub Actions, legacy pipelines still running on AzDO -- also legitimate. But now you've got integration to maintain. AB#1234 links. Webhook connections. Two sets of permissions. Two sets of documentation. Two sets of "how do I do X" questions from every new hire. Multiple places to do stuff.

That's the decision. One platform is simpler. Two platforms give you flexibility with integration overhead. And plenty of organizations end up running both -- sometimes on purpose, sometimes because the migration is still in progress, sometimes because different teams made different choices. That's fine. Microsoft designed these tools to interoperate. It's a supported scenario, not a compromise.

Either way -- this decision takes an afternoon. The decisions that actually matter take months.

The Questions Worth Spending Your Time On

So if "Azure DevOps or GitHub" isn't the right question, what is? Here's where I want to get real for a minute. When I work with teams on this stuff, the platform choice is almost never the thing that's actually slowing them down. The conversations I end up having are about much more fundamental things -- and these are the questions worth your time and energy.

The Technical Stuff

Is the database under version control? Can you validate and deploy schema changes alongside the application code? Or does every release involve someone manually running scripts against production while everyone holds their breath and/or prays to the deity of their choice?

Are there legacy applications that are actively hostile to automated deployment? Apps that require manual configuration, manual IIS setup, manual "copy this DLL to that server" steps that nobody's had time to fix? (Aka. deployment tech debt.)

Is there a mountain of manual QA regression tests that have to be run for every release? Tests that take two weeks and involve a spreadsheet and six people?

Does the branching structure make sense? Or has it been carrying forward branch-per-environment, zombie branches, and a merge strategy that nobody can fully explain that doesn't particularly match how you work anymore?

Are there regular production outages or production bugs that erode trust in every release?

These are real, concrete problems. They're probably 75% technical and 25% people. And they're solvable -- with engineering discipline, architectural investment, and time. But they're solvable on either platform. The YAML syntax you're writing is not the bottleneck here.

The Organizational Stuff

And then there are the things that make managers and executives and stakeholders just kinda...grumpy. Not as much is getting done as they'd expect. Things feel slow. Promises don't match delivery. Nobody's really sure why.

It might be tech debt that has accumulated over years until it's silently consuming 40% of every sprint.

It could be estimation problems -- the same "how long will this take" theater that every team has been performing since the invention of project management.

It could be communications problems -- requirements that change mid-sprint, stakeholders who can't agree on priorities, or the classic "everything is priority one."

In all likelihood, it's some combination of poor requirements, poor prioritization, and too much work in progress.

None of these will be even minimally improved by picking Azure DevOps over GitHub or GitHub over Azure DevOps. Not even a little bit. These are leadership problems, organizational problems, and delivery discipline problems. They exist upstream of your CI/CD pipeline and they'll follow you to any platform you migrate to.

The Scrum Warning

I want to close with something that's been on my mind a lot lately.

Scrum did a lot of good. I mean that sincerely. It gave teams a shared vocabulary. It introduced the idea of inspecting and adapting. It taught a whole generation of developers that process matters and that you should pay attention to how you work, not just what you produce. That was genuinely valuable. (Oh...and I made a bunch of money teaching it and helping companies roll it out. That was good, too.)

But Scrum didn't fail because the ceremonies were bad. Scrum lost its way because the ceremonies surfaced problems that nobody had the organizational power or political will to actually fix. The retrospective tells you the truth. The truth is uncomfortable. Nobody acts on it. Eventually the retrospective becomes theater. People stop believing in it. And the whole thing gradually collapses under the weight of its own unfulfilled promises.

I think "DevOps" is meandering toward that same cliff.

There's a lot of observability out there now. A lot of telemetry. A lot of dashboards. All of it telling you things about your delivery. But if the org can't act on what the data says -- if the culture won't allow it, if the politics prevent it, if the org chart makes it structurally impossible -- then the dashboards are just a more sophisticated way of documenting dysfunction. "DevOps-as-cure" is just as magical a thought as "tool-as-cure" or "Scrum-as-a-cure".

Being "successful at DevOps" is starting to feel like it has the same rapidly depreciating value as "good at Scrum." I don't want to see teams "do DevOps" the way other teams "did Scrum" -- adopting the tools and the ceremonies without ever addressing the underlying problems that the tools and ceremonies were supposed to help you find.

So What Should You Actually Do?

Focus on delivering done, working software. That's the job. It's always been the job. Use DevOps thinking to help you optimize that delivery. Measure what matters. Act on what you measure. Fix the things you can fix.

Get your code on Git if it isn't already. That's the strategic migration -- the one that changes what's easy, not just what's possible. Once you're on Git, the whole landscape of modern development practices opens up in front of you.

Then pick a tool. AzDO or GitHub -- they're both excellent. Each has different areas of investment. Pick one and stop worrying about it. Pick two if you need the flexibility and can handle the integration overhead. But don't spend months agonizing over this decision.

The right question was never "Azure DevOps or GitHub." The right question is whether your team can ship done, working software -- and what's standing in the way.

Spend your time on that.

-Ben

If your team is navigating a TFVC-to-Git migration, a pipeline rewrite, or trying to figure out whether any of this will actually make things better -- that's the kind of work I do. Let's talk.