GitHub's importer is good at what it does, and what it does is repositories. It will bring your Git repos across cleanly, wire up some pipelines, and leave you with a list titled "remaining assets." That list is your work items, your Test Plans, your classic release pipelines, your deployment groups, your variable groups, your service connections, your wiki, your package feeds, and, if you've been on TFS long enough, a TFVC tree nobody wants to touch.

That list is where migrations stall. Not in the repos. In the six months after the repos, when half the team is still living in Azure DevOps because the release process never came over, and the other half is on GitHub wondering why the tickets didn't.

I've been doing TFS and Azure DevOps work since 2005 and GitHub Enterprise work for the last several years, and the migration between them is most of what I do now. Two ways I can help: a fixed-price assessment that tells you what your migration actually involves, and the work that follows it.

Sound familiar?

"We moved the repos over a weekend. Six months later, deploys still run from Azure DevOps."

"Test Plans has 2,000 test cases. Nobody can tell me how many still get run."

"There are 40 release pipelines. Maybe 12 matter. Nobody's sure which 12."

"Our TFVC has fifteen years of history and a $/Main nobody dares branch."

"Leadership says we're on GitHub. The org chart says we're on GitHub. The deploys say otherwise."

"We asked GitHub how to migrate work items and they sent us a Marketplace link."

None of that means the migration was a bad idea. It means the migration was scoped as a code move, and a code move is the one part of it that's easy.

What GitHub's tooling moves, and what it leaves

The GitHub Enterprise Importer handles Git repositories, pull request history, and the identities behind them (as "mannequins" you reclaim afterward, which is its own project). GitHub Actions Importer can convert a good share of YAML pipelines and will tell you honestly which steps it couldn't.

Everything else is yours to figure out:

• Work items. Backlogs, hierarchies, iterations, area paths, custom fields, queries, dashboards. GitHub Projects is a different shape, and "different shape" is a design decision, not a script.
• Test Plans. GitHub has no test case management. The cases, the suites, the runs, the parameterized cases that were somebody's whole job: they don't have a place to land unless you make one.
• Classic releases and deployment groups. Approvals, gates, environment variables, the deployment agent on the box in the server room. GitHub Environments cover some of it. The rest is a rebuild.
• TFVC. Not a Git repo, so not an importer job. History, branches, the $/Main-$/Dev-$/Release model, the shelvesets, and the question of whether it should become one repo or nine.
• Governance. Who can do what, enforced where. Azure DevOps permissions don't map to GitHub rulesets one-to-one, and the gap is where compliance conversations start.
• The people. The team that's been on TFS for a decade doesn't become a Git team because the repo moved.

---

The GitHub Readiness Assessment

A fixed-price, two-week, remote diagnostic of your Azure DevOps estate that ends in a written report and a sequenced plan. It's for deciding what your migration involves before you commit budget, people, and a date to it.

The idea is simple: name the disease before you buy the cure. Most migrations that go badly went badly at scoping, when somebody counted repositories and called it a plan. The platform decision takes an afternoon. The decisions that actually matter take months, and this is where they get made on paper instead of in production.

What I look at

It starts with why. Teams that want to move are usually reacting to one of four things: strategic anxiety about Azure DevOps' future, pipelines and branches that are a mess, developers who want GitHub, or a consolidation after an acquisition. Each has a different real question underneath it, and the first conversation is about which one is yours. (For consolidations: are you consolidating, or just relocating?)

Then read-only access to your Azure DevOps organization (or Server), a handful of conversations with the people who actually run things, and whatever documentation exists (I'll take "none"). For each of these, what you have, what's live, what's dead, and what it'll take to move or retire:

• Repositories. Git and TFVC. Size, history, branch model, what's actually active, what should become what on GitHub.
• Work items. Process templates, customizations, the hierarchy in use versus the hierarchy configured, queries and dashboards people depend on, and what a GitHub Projects shape for it looks like.
• Test Plans. How many cases, how many suites, how many parameterized, how many run in the last year, how many are tied to requirements that still exist. This is usually the number nobody has.
• Pipelines. YAML and classic, build and release, which ones ran in the last 90 days, what they depend on (service connections, variable groups, secure files, agents, extensions).
• Release governance. Approvals, gates, environments, who signs off and where that's recorded. What has to survive an audit. Builds usually convert without drama, classic or YAML. Releases are where migrations go to die, and this is where the assessment spends its attention.
• Deployment topology. Where the agents live, what they can reach, and what a self-hosted GitHub runner on your network would need to replace them. On-premises deployment targets are the second place migrations stall.
• Identity and permissions. Entra ID, groups, the permission model in use, and what it maps to on GitHub (EMU or SAML, teams, rulesets).
• Integrations. Marketplace extensions, package feeds, service hooks, the things bolted on over the years that somebody's process depends on.

What you get

A written report. Not slides. Specifically:

1. The inventory. What's there, with counts, and what's live versus abandoned. You'll be surprised by the abandoned number, and everything abandoned is something you don't have to move.
2. The findings. The things that will make this migration harder than the repo count suggests, stated as findings with their consequence, so you can decide what to do about them.
3. The plan. A sequenced migration in phases, with what moves, what gets rebuilt, what gets retired, and what stays on Azure DevOps on purpose, including a recommendation on repository structure for TFVC, which is where most of the arguing happens. Sometimes what stays is a lot: code on GitHub and work tracking in Azure Boards is a legitimate pattern, not a failed migration, and the plan says so when it's the right one.
4. A rough sizing. Enough to budget with. Not a quote for the migration; you can take the plan to anyone, including your own team.

How it goes

• Week one. Inside your Azure DevOps and with your people. Not a questionnaire and two discovery calls: I spend the week in the organization itself, reading what's there, and in conversations with the people who run it. Usually four to six of those, 45 minutes each: the release manager, the person who knows the pipelines, whoever owns Test Plans, an engineering lead, and whoever will have to defend the plan to the budget.
• Week two. The write-up, a draft you react to, and a readout with whoever needs to hear it.

Two weeks assumes one Azure DevOps organization or Server instance and reasonable access on day one. Bigger estates take longer and I'll say so on the call.

What it costs

Fixed price: $10,000, for one Azure DevOps organization or Server instance. If the estate is bigger than that, I'll tell you on the intro call before anyone spends anything.

What it isn't

It's not a sales document for a migration project. Sometimes the honest answer for a piece of your estate is "don't migrate this," and sometimes it's "don't migrate yet." The report says that when it's true. You can take the plan and run it yourself, hand it to your own team, or hand it back to me. All three happen.

Book the intro call Or email

---

What usually follows

The assessment ends in a plan. These are the parts of the plan I get asked to do:

• TFVC to Git conversion. History preserved where it's worth preserving, repository structure per the plan, branch model redesigned for pull requests. There's no path from TFVC to GitHub that doesn't go through this. Staying on Azure DevOps and only need the source control question answered? There's a TFVC-only assessment at the same price. Why it's harder than you think →
• Pipeline and release conversion to GitHub Actions. Builds are the easy half, classic or YAML. Releases are a redesign, because classic kept build and release as two things with two editors and Actions doesn't: workflows with Environments, approvals, and OIDC to Azure instead of stored credentials, and a conversation about what each gate was actually protecting. A 1:1 translation reproduces the spaghetti on a different plate.
• Self-hosted runners on your network. For the deployment targets GitHub-hosted runners can't reach. Placement, permissions, what they can see, and how they're kept patched.
• Work item and Test Plans migration beyond what the free import handles: more projects, deeper history, attachments, custom fields, and a GitHub Projects shape designed rather than defaulted.
• GitHub Enterprise setup. EMU versus SAML, organization and team structure, rulesets, Packages, Advanced Security, Copilot policy. The governance conversation, with the compliance people in the room.
• Azure DevOps Server upgrades for the teams staying put, including moving on-premises Server to Azure DevOps Services.
• Git and GitHub training for the people who have to live in it afterward. The decade-on-TFS team, specifically.

Start with the import

If you'd rather see it before you book anything: Honest Cheetah is the product I built for the part of the migration GitHub doesn't have, and it includes a free import. Point it at one Azure DevOps team project and it brings the backlog, the tasks, the test cases, and the throughput history onto a GitHub Projects board in one sitting, showing you what will and won't come over before it moves anything.

It's built for one team project, once, with limits it states on the page. If your estate is bigger than that, the import is a fine way to find out exactly how, and the assessment is the next step.

Reading

• Azure DevOps or GitHub? Make sure you're asking the right question
• Migrating TFVC to Git: it's harder than you think
• Vibe-Process: what replaced Scrum (and why it's not working), for the "the tool isn't the problem" conversation you'll have somewhere around week two

Book a free 30-minute call