• 12 min čtení
When we spoke about Mr. RIGANTI, our new SaaS that adds AI code reviews & agentic coding capabilities to Azure DevOps, we are frequently asked: "Wouldn't it be easier to just migrate to GitHub?" All the new AI features are coming there, while Azure DevOps looks somewhat stuck in the past.
Well, no - at least in our scenario. At RIGANTI, we have used Azure DevOps since the days it was called Visual Studio Team Services. We have more than 50 active projects, and when we explored what it would take to move them from Azure DevOps to GitHub, we found numerous challenges. Unfortunately, many of them were not obvious at first glance, and we are quite sure that if you run on Azure DevOps, you may run into a good bunch of them yourself.
Many companies face the same decision: migrate the projects to GitHub, or stay in Azure DevOps and find another way to leverage AI capabilities there. If you prefer to stay, check out Mr. RIGANTI - our integration of AI coding agents into Azure DevOps organization that lets you assign pull requests and work items to be reviewed or implemented by AI agents of your choice.
If you decide to move to GitHub, this article lists some of the challenges you may run into.
Use Azure DevOps and GitHub side by side, or move completely?
The first thing to consider is whether you want to migrate only the Git repository, keeping work items, build pipelines, artifacts, and other assets in Azure DevOps. This option looks quite simple: you can just push all branches of the repository to GitHub, configure branch policies (such as which branch will be the default one), and start using Copilot and other useful GitHub features, such as Codespaces.
User accounts, permissions, customer access
In our company, most people don't have access to all projects - they are assigned only to some teams. In most of our projects, we didn't use all the complicated layers of the Azure DevOps permission model - we assigned several people to be Project administrators, and the rest were normal team members.
There were some exceptions, though. Since we are a consulting company, some of our customers also needed to access the project. Sometimes they needed full Git permissions; in other cases, they mostly accessed work items, sometimes only with Stakeholder access (which is available free of charge).
If you keep both GitHub and Azure DevOps, you need to manage permissions in two different places, which can easily get out of sync. If you use GitHub Enterprise, you can at least configure Azure Entra ID authentication, potentially using the same user identities in both places. Without that, it will be quite confusing - the same user will likely use a different identity on GitHub and another on Azure DevOps.
Pull requests
Because the Git repo will move to GitHub, you will need to stop using pull requests in Azure DevOps and use them on GitHub instead. This is also necessary because of Copilot, which will start a new branch and PR when you ask to work on an issue.
There are some advantages to that. I believe it is not just my opinion; the UI for viewing files changed in a PR, and GitHub's code review tools are way better. However, all old pull requests will remain in Azure DevOps (including comments), so when you need to look at history, you will have to switch tools.
Once we had a customer who needed to access the pull requests to see the actual state of work, as the work items were updated with some delay. In this case, they would likely need a GitHub account. They were not developers, and it would be a bit weird to ask them to create a GitHub account.
Pipelines, and letting Copilot access their logs
In the simple scenario, the build and release pipelines remain in Azure DevOps. You will need to do some edits to them to rewire them to the new repository location. It takes quite a bit of clicking, and the Azure DevOps UI is not very helpful, but it is doable.
The bigger issue comes when you start using Copilot on GitHub. When the pipelines run in GitHub Actions, Copilot can access their results and logs. When they stay in Azure DevOps, there is no easy way around it - you would need to give Copilot the Azure DevOps MCP server. There is a chance it gets improved in the future, and to be fair, Mr. RIGANTI doesn't have this feature implemented yet, but I think it is quite important.
Work Item links
In some projects, we require developers to create links between pull requests and work items so the work item status can be automatically updated when the PR is approved and merged. When work items stay in Azure DevOps and pull requests are on GitHub, the links must be maintained manually, or you will lose valuable information.
Artifacts, and allowing Copilot to use them
Many of our projects publish internal NuGet and npm packages. Accessing them in Azure DevOps is quite easy; there is a pipeline task for that, and it usually works.
If you keep the pipelines in Azure DevOps, no changes are required. However, Copilot is way more powerful if it can build the application, run unit tests, or even run the entire application for E2E (end-to-end) testing. You will probably want to create a separate GitHub Action for Copilot.
AI can help with that, but if the project uses private NuGet packages hosted in Artifacts, you will need to configure a few secrets and ensure Copilot can access those packages.
Submodules
Some of our projects used Git submodules. If you have never used them, you can think of them as a repo inside a repo. For example, we have our Shared Infrastructure repo, which we link to the libs/infra path in the project's main Git repository. If we need to add a feature or fix something in the submodule, we can make a branch in the submodule, commit and push our changes, and use pull requests as you would with a normal Git repo. The new version will eventually propagate to the other projects using the submodule (they have to explicitly pull the new changes), and it is easier than using internal NuGet packages, especially if the library is "live" and many changes are worked on simultaneously.
If you cannot move the main repo and the submodules at the same time, it can get complicated. You may need to update submodule origins, and there will be a few challenges, making sure the build pipelines can clone the repo, including the submodules that may have moved elsewhere.
We even have submodules inside submodules - this is the point when it starts to be crazy.
Licensing
I am not an expert in licensing, and there are many ways to obtain GitHub Pro or GitHub Enterprise licenses. However, until now, users needed only Azure DevOps licenses, which are either included with a Visual Studio subscription or purchased per user. Additionally, each Azure DevOps organization got several free licenses.
Now, you will need to ensure that GitHub licenses are in place for all users, including customers who need to access the Git repository. These extra costs should definitely be included in the comparison.
Move completely to GitHub
If you decide to abandon Azure DevOps completely, there are more things to migrate.
Pipelines
You can use AI to rewrite Azure DevOps pipelines to GitHub Actions syntax. We have done this in the past, with quite a reasonable success rate.
The problem is when the pipeline depends on something else.
In some projects, we use chained pipelines (a pipeline is triggered when another pipeline finishes). These are not trivial to migrate, and you need to keep them together.
Release pipelines often use many secrets and depend on production environments, sometimes even in customer tenants. Transferring these can mean a lot of work, and the secrets cannot be easily retrieved - either you stored them somewhere else, or you may need to generate new ones (especially when using Federated Identity or other mechanisms).
Custom Build Agents
Another complication would be the build agents. Some of our projects have quite specific requirements - they even occasionally need to access internal resources in our private network (for example, we sign MSI and EXE files using a certificate on a hardware token).
Also, we weren't happy with the performance of Microsoft-hosted agents - it takes time to obtain one, and if you need SDKs that aren't pre-installed there, the build would take too long because it needs to download and install them.
We created Dockerfiles to build our custom Windows and Linux build agents, and we have infrastructure for them to run (including splitting them between our two office locations). For building mobile apps, we also have physical machines running macOS. All this would have to be replicated for GitHub Actions as well.
Work Items
I don't know many people who would like to use work items in Azure DevOps. I never know which screen to look at them on - it seems each section offers a different set of features, and I often look for a feature in the Boards view only to find I need to go to the Backlogs view.
However, there are many good things about them as well. The hierarchy helps a lot in avoiding getting lost among the thousands of requirements. We sometimes customize which fields we need to see, which simplifies creating activity reports for our customers and so on.
I can imagine using other tools for work item management, but what GitHub offers is insufficient for most of our scenarios. Most scenarios can surely be handled with a clever use of tags or the GitHub Projects feature, but we have never reached a point where it is at least not worse than Azure DevOps.
Artifacts
GitHub offers similar tools for hosting private packages, and it is not that complicated to migrate those.
However, we have several customers who access our private feeds from their projects, and the migration would require coordinating the changes on their side as well. It is more of a communication and organizational issue than a technical one, but still, it will require some effort.
What would we gain if we went to GitHub?
In RIGANTI, we use AI agents in various ways. For smaller tasks, people just use GitHub Copilot, Claude Code, or Codex - either in the command line or through its integration in Visual Studio or VS Code. When we need to implement something larger, we usually want the agent to work independently, and it is useful to have traceability (what was the purpose of these code changes). Creating a GitHub issue to describe the task and assigning it to the agent feels natural.
Another useful feature is AI code review. Before any code gets merged into the main branch, it must be seen by at least one other person. AI is another pair of eyes, and with clever prompting, you can make it focus on finding security issues, identifying potential performance problems, or verifying the completeness of the implementation. Many times, the AI agent found issues we wouldn't have noticed and saved us from trouble that might come later.
The capabilities of GitHub Copilot are quickly improving - recently, the planning mode was added. A few days ago, a preview of GitHub Copilot App was announced - it promises a different approach to interacting with coding agents. Not seeing any code there looks a bit disturbing, but that is probably the new world we have to get used to. We can surely expect more features to come there.
Wouldn't you lose access to the new features with Mr. RIGANTI?
Currently, Mr. RIGANTI adds capabilities similar to those you can get with Copilot on GitHub:
- You can assign him to review an Azure DevOps pull request, just as you do on GitHub.
- You can assign him an Azure DevOps work item, just as you do in GitHub.
- If you want changes, you can mention him in comments in a pull request. Highlight a line of code and ask him to refactor or update it.
- Copilot on GitHub runs inside GitHub Actions. Mr. RIGANTI runs inside Azure Pipelines - again, very similar capabilities.
- Currently, Mr. RIGANTI runs OpenCode for Anthropic models, and Codex for OpenAI models. It is extensible to use GitHub Copilot SDK, which is a feature in our backlog.
- Mr. RIGANTI comes with a web interface where you can assign him ad hoc tasks (with attachment support) and view the progress of active sessions. We want to expand the web interface's functionality to work well on mobile devices (e.g., you can get a notification when Mr. RIGANTI finishes something, or you can assign him more work when you are out of the office).
- We also think about more integrations, such as connecting it to Microsoft Teams or Slack. What if he could attend your team meetings and automatically implement the ideas and changes you mention?
- We plan to allow connecting services such as Application Insights, Google Search Console, and others. If there are any errors on your website, Mr. RIGANTI can investigate the issue and open a pull request with a suggested fix.
- We did several experiments with AI-powered exploratory testing. Mr. RIGANTI will be able to test the feature implemented in your pull request and post screenshots or videos showing the walkthrough. In some cases, you won't even need to run the project locally to verify it works.
The nice thing about agentic coding is that adding more features is no longer difficult. More than 50% of code of Mr. RIGANTI was implemented by Mr. RIGANTI itself. We pushed this on purpose to get familiar with the new development workflows, and we're quite confident we can keep up with GitHub and other platforms' speeds.
If you are still running Azure DevOps, check out Mr. RIGANTI. You can try it without a monthly commitment by applying for the Single plan. You will still pay for the actual token usage, but it is capped at $10 per month, unless you increase the limit.