“Should we be on GitHub?”
The question usually arrives from two directions at once. The board wants a modernisation answer it can defend. Your developers already live half their day in GitHub and want the rest of it there too. And somewhere in your estate sit years of work items, test plans, and pipelines that nobody asking the question has thought about.
The honest answer is rarely “move everything”. It is one of three, and only one of them involves paying anyone.
One word matters on this page. Azure DevOps Server is the on-premises product, the successor to TFS. Azure DevOps Services is Microsoft's cloud. Check which one you are on before picking a path.
The three honest answers
1. Hybrid: repos move, Boards stays. This is the most common honest outcome. Repos (and often pipelines) move to GitHub, where your developers want to work. Boards stays in Azure DevOps and keeps what GitHub has no home for: process templates, portfolio backlogs, test plans, and the compliance evidence built on them. The two are linked end to end, so commits and pull requests in GitHub still connect to work items in Boards. Your developers get the GitHub workflow. Your process and audit trail stay intact. Nothing was forced through a lossy conversion for the sake of a clean-looking org chart.
2. All in, with the losses named before you commit. Everything moves. For repos that is fine: GitHub’s own Enterprise Importer covers repositories and their pull-request history, and a capable team can run it themselves. The losses are on the other side of the estate, and they are real: work items forced into GitHub Issues lose hierarchy, custom fields, and process structure, and test plans have no GitHub equivalent at all. Sometimes those losses are acceptable. The point is to accept them on purpose, in writing, before the move, not to discover them after.
3. Stay, for now. If Boards is load-bearing for your process and compliance, and your developers’ actual complaint is solvable with integration rather than migration, then GitHub is not yet earning its disruption. That is a legitimate answer, it costs nothing, and we will give it when it is true.
There is no packaged product for these moves, ours or anyone’s. Every GitHub migration we deliver is a custom, scripted plan built for the specific estate, scoped by exactly one question: which layers move, and which stay.
What you will have when it is done
- Developers working where they want to work, with history they can still trace.
- Process, test plans, and compliance evidence either intact in Boards (hybrid) or consciously retired (all in). Never silently dropped.
- A written record of what moved, what stayed, and what was accepted as lost.
Where to start
Start with a migration assessment . For a GitHub move it answers the scoping question first: what is in the estate, which layers can move cleanly, what the losses would be, and what order holds delivery together. The plan is yours either way, including when its conclusion is “hybrid” or “stay”.
If a GitHub move is already half done, repos in one place, work items in another, and nobody sure what got lost on the way, that is a migration rescue .
This is not for you if you are only moving repositories and your team is comfortable running GitHub’s importer: use it, with our blessing. Repos are the easy part.
Being asked the GitHub question?
Tell me what's in your estate: repos, work items, test plans, pipelines. I'll tell you which of the three answers fits, and what it would actually take.
Get in touch