We run an on-premises environment and are considering moving all of our DevOps teams from self-managed GitLab Enterprise to Azure DevOps Server. Our current GitLab platform and runners are hosted on Kubernetes. Has anyone gone through a similar migration to Azure DevOps Server? What technical, operational, or workflow challenges should we plan for, especially around migrating repositories, pipelines, agents, integrations, and Kubernetes-based infrastructure?
2 Answers
Be cautious with Azure DevOps Server for a large on-premises deployment. Some users feel the server edition trails the cloud service, and updates to tasks, agents, and newer SDKs can lag behind. That can create problems when adopting newer .NET versions or build tooling. Even organizations that are heavily invested in Microsoft technologies have chosen to move away from Azure DevOps, so evaluate the release cadence, task compatibility, agent management, and future product direction before committing. Also confirm how your Kubernetes-hosted runners would be replaced or integrated, since the operational model may differ significantly from GitLab.
Before planning the migration, I’d want a clear reason for making the change. If the main benefit is tighter integration with a .NET and Microsoft-heavy environment, Azure DevOps may fit, but that alone may not justify the effort of moving every team and pipeline. Inventory your existing GitLab features and integrations first, then compare them with what Azure DevOps Server actually supports on-premises.
The proposed motivation seems to be reducing friction for the .NET teams, but that should be weighed against the migration and long-term maintenance costs.
The biggest concern is being locked into older server components while cloud versions continue to advance. Test representative pipelines, especially builds using current .NET SDKs, before approving the migration.