The same tools we use. Free.
The Azure DevOps Migration Tools move data between TFS, Azure DevOps Server, and Azure DevOps Services, in any direction, including from Services back to a server of your own: work items with revision history, links, and attachments, test plans and suites, and the relationships between them. Martin built the first version inside a Fortune 500 consolidation in 2013. They have been maintained and hardened across hundreds of real migrations since.
If your migration is straightforward and you have the engineering capacity, you may not need us at all. That is not false modesty. It is how the tools are meant to work:
- Free and open source. MIT licensed. No feature gates, no trial limits.
- Deep work item migration. Revisions, links, attachments, and test artefacts, with field and process-template mapping when source and target do not match. Replay-based, which is what makes selective moves possible, and honestly not full fidelity: not everything carries its complete history across. The one byte-perfect path is Microsoft’s whole-collection import , which is why we test it first on every migration.
- Incremental by design. Run it again and it picks up what changed. Your teams keep working until a small, controlled cutover.
- Documented. Reference documentation, configuration guidance, and samples live at devopsmigration.io .
Be honest with yourself about the sharp edges
Powerful tools assume you know what you are doing. Field mapping, process-template reshaping, and multi-collection sequencing are where DIY migrations burn their timelines. Not because the tooling cannot do it, but because each decision is easy to get wrong the first time you make it.
A rough self-test:
- One project, matching process templates, no test plans? You will likely be fine on your own. Start with the docs .
- Custom process templates, test suites, or several collections? Budget real engineering time, and consider a guided migration so your first mistake is not a production one.
- Hard deadline, compliance constraints, or no capacity to spare? That is what a managed migration is for.
One more honest note: the tools are one instrument, not the whole answer. On engagements we use whatever fits your estate, including Microsoft’s own import service and custom tooling. If a different instrument fits yours, we will say so. And the tools do not migrate to GitHub at all: if that is the question you arrived with, start at the GitHub question .
Either way, start with the documentation. If you get stuck, ask us . We answer questions about the tools whether or not you ever hire us. Community issues and discussions live on GitHub .
Stuck mid-migration, or sizing one up?
Describe your estate and where you are with the tools. I'll tell you whether you can finish it yourself, and what to look at next if so.
Get in touch