Azure DevOps vs GitLab: which fits your team's source hosting and delivery needs
Teams weighing a move off Azure DevOps Services or Azure DevOps Server should know the short answer first: GitLab fits teams that want one self-managed platform for repositories, CI/CD and packages, while Azure DevOps fits teams that depend on Boards, Test Plans or Microsoft-managed hosting. GitLab covers the Repos, Pipelines and Artifacts parts of the suite in one application you run yourself. It does not give you an equivalent of Azure Boards work items or Test Plans out of the box, so those needs must be planned separately.
The decision turns on three questions. First, work tracking: list which Boards queries, work item types, dashboards and Test Plans features your teams use daily, because these are the areas where a GitLab move changes how people plan work. Second, data location and tier: confirm where your code, pipeline logs and artifacts must live, and which GitLab tier covers the features you need. The GitLab pricing page lists advanced CI/CD and priority support for Premium, and application security, compliance and vulnerability management for Ultimate, and both tiers are available for self-managed installations. Ask your vendor to confirm current tier contents in writing, since they change over time.
Third, operating capacity. Self-managed GitLab means someone owns upgrades, backups and capacity planning. The GitLab maintenance policy describes a yearly major release, a monthly minor release and patch releases twice a month, and GitLab requires upgrades to pass through named upgrade stops. Check whether your team can meet that cadence, what your GitLab maintenance policy commits you to, and how the license and support costs compare with the staff time you will spend running the platform.
Which option fits which scenario
This table matches common Azure DevOps situations with the option that usually fits better and the condition that tips the decision. Read each row as a starting point: the condition column names what you must confirm in your own environment before you commit. Most teams find the decision turns on work tracking, identity, hosting location and whether they have people to run a platform.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Boards-heavy agile teams using work item types, backlogs and sprints | Azure DevOps stays or Boards moves to a separate tool | GitLab issues and epics cover lighter planning, but Azure Boards process templates, work item links and queries need a mapping exercise before any move |
| Teams already on Entra ID with Microsoft tooling | Azure DevOps | Single sign-on, group sync and Microsoft licensing are already in place; a GitLab move means rebuilding identity mapping and access groups |
| Teams that need on-premises or air-gapped hosting | Self-managed GitLab | GitLab documents offline, air-gapped installs; confirm the scanners and AI features you need run offline, and compare with Azure DevOps Server if staying Microsoft-only matters |
| Teams with an audit requirement for data location | Self-managed GitLab in your own data center or chosen region | Azure DevOps keeps tokens and SSH keys in a US datacenter, so confirm with your assessor whether that is acceptable before relying on the EU geography alone |
| Teams with no platform staff | Azure DevOps Services, or GitLab with a fixed-scope implementation and retainer | Self-managed GitLab requires someone to handle upgrades along required upgrade stops, backups and monitoring; without that capacity, a hosted service or a support contract fits better |
| Teams that depend on Azure Pipelines YAML and many service connections | Azure DevOps | Moving to .gitlab-ci.yml means rewriting pipelines, variable groups and environments; the effort grows with the number of pipelines and deployment targets |
| Teams that need security scanning and compliance reporting in one place | Self-managed GitLab Ultimate | Confirm which scanners and compliance features your tier includes, since the GitLab pricing page lists them under Ultimate, which is custom priced |
| Teams that mainly need Git hosting and pull requests on a small footprint | Gitea or Forgejo, not GitLab | GitLab runs more components than a lightweight forge; choose GitLab when you need its CI/CD and security features rather than repositories alone |
Which GitLab tier covers what Azure DevOps teams use
GitLab Free, Premium and Ultimate are all available for self-managed installations, so the tier decision is about which features your teams need, not where the software runs. Free covers Git hosting, issues, merge requests and basic CI/CD, which is the starting point for teams replacing Azure Repos and a simple Azure Pipelines setup. Premium adds advanced CI/CD and priority support, and the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually. Ultimate, which adds application security testing, software supply chain security, vulnerability management and compliance features, is custom priced. Ask GitLab for a written quote that names the user count, the support level and the security features you need, and compare it against what you actually use today in Azure DevOps and any separate security scanners you pay for.
GitLab is open core, and the license split explains what you get at each level. Code outside the ee/ directory of the gitlab-org/gitlab repository is available under the MIT Expat license, so the core forge can be read, modified and self-hosted without a commercial agreement. Code under ee/ is licensed under the GitLab Enterprise Edition license and is what the paid tiers unlock. Your legal and procurement teams should read the GitLab LICENSE file before any internal fork or redistribution, because the boundary between the two licenses determines what you may change or share.
Before you buy a tier, map each Azure DevOps feature your teams rely on to a GitLab tier. Pipeline approvals, protected environments, branch policies and security scanning are the usual decision points, so list which of them you use and which were covered by separate Azure DevOps add-ons such as Advanced Security. Confirm the current feature matrix with GitLab, since tier contents change between releases. Plan a short trial on a non-production instance with your real pipelines and compliance reports, so the tier you buy matches the controls your auditors and security team will ask about.
Where your code and data live under each option
Azure DevOps Services, Azure DevOps Server and self-managed GitLab differ in who runs the servers, where data sits and who controls access. The cards below cover the decisions that change under each option, and the checks to run before a migration plan is approved.
Azure DevOps Services data geography
Azure DevOps stores customer data in the geography chosen for the organization, but tokens and SSH keys are kept in a US datacenter. For a team with an EU residency requirement, that split matters even when repositories stay in the EU. Ask Microsoft to confirm the current data location list for your geography, and map each data type (code, work items, pipeline logs, artifacts, credentials) to a location before comparing it with a GitLab deployment in your own data center.
Azure DevOps Server on your premises
Azure DevOps Server runs on infrastructure you operate, so the data stays inside your network, but you still carry patching, backups and upgrades. Microsoft announced on October 7, 2025 that the server drops the year from its name and moves to the Modern Lifecycle Policy, under which customers who stay current receive continuous support. Confirm which release your contract covers and how upgrades are scheduled before comparing its cost of ownership with GitLab.
Self-managed GitLab on your own hosts
GitLab can be installed on your own virtual machines with the Linux package, on Kubernetes with the Helm chart or GitLab Operator, or with Docker. The reference architecture docs say stateful components such as PostgreSQL and Redis should not run inside Kubernetes, so a Helm deployment usually uses a Cloud Native Hybrid layout with stateful services on VMs or managed services. Decide the install method, storage layout and backup target before you size the environment.
Offline and air-gapped operation
GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners and for GitLab Duo Self-Hosted. This matters for classified networks and for regulated sites that block outbound traffic. Confirm which features you need, such as scanners, container registry or AI features, and check each one against the offline guidance before you assume it works without internet access.
Identity through GitLab authentication
Azure DevOps authenticates users through Microsoft Entra ID, and GitLab has its own authentication and authorization model that you must configure for your own identity provider. Check how group membership maps to project roles, how SSO and SCIM provisioning are set up, and how personal access tokens and SSH keys are issued and revoked. Ask your identity team to test offboarding before go-live, because a leftover token is a common gap after migration.
Compliance evidence and audit scope
Moving code hosting to your own infrastructure changes which controls you own, including access reviews, backup restores, logging and change records. DeployOpen can plan, configure and document those controls and collect the evidence an assessment will ask for. DeployOpen does not issue audit reports or certifications; the independent auditor or certification body decides the outcome. Ask your assessor early which control evidence they expect from the new platform.
What running GitLab yourself requires in architecture and upkeep
Running GitLab yourself starts with choosing an installation method and an architecture sized to your user count, and the choice carries operating obligations for years. GitLab documents five installation methods: the Linux package, the Helm chart, the GitLab Operator, Docker and installation from source. The Linux package bundles PostgreSQL, Redis and Sidekiq and is described as the most mature and scalable method, which makes it the default starting point for most Azure DevOps teams moving off a hosted suite. Its reference architectures run from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 API requests per second, so sizing begins with a count of named users and the API load your pipelines and integrations generate.
For 3,000 or more users, GitLab generally recommends a high availability design built on Gitaly Cluster with Praefect for repository storage, PostgreSQL with Patroni, Redis Sentinel and Consul. Plan for the stateful components carefully: GitLab's reference architecture documentation states that running PostgreSQL and Redis inside Kubernetes is not supported. If you want Kubernetes, the Cloud Native Hybrid pattern runs stateless components there while PostgreSQL and Redis run on virtual machines or managed services. Ask your team to confirm the current component list for your chosen reference architecture before committing to hardware or cloud spend, because these recommendations change between releases.
Upkeep is the recurring cost that often surprises teams. GitLab ships a major release yearly, a minor release on the third Thursday of each month and patch releases twice a month, and it currently maintains the 19.3, 19.4 and 19.5 lines. Bug fixes go only to the current stable release, while security fixes also reach the previous two monthly releases, so your upgrade cadence needs to stay close to current. Upgrades must pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11 and 19.2. Build a test environment, a rehearsed backup and a dated upgrade calendar into your operating model, and confirm with your staff who owns each step.
What a move from Azure DevOps to GitLab involves at a high level
The sequence turns an Azure DevOps estate into an inventory, a migrated set of repositories and pipelines, and a validated GitLab instance that teams can cut over to with a known rollback path.
Inventory repositories, pipelines and permissions
Start by listing every Azure Repos Git repository, its branch policies, build and release definitions, service connections, variable groups, Artifacts feeds, and the users and groups that hold access to each project. Confirm who owns each item and which ones are still in use. Assign the inventory to a named engineering lead and the security team, and treat the output as the baseline for every later check. The step is done when each item has an owner and a keep, move or retire decision.
Set up and harden the GitLab instance
Install self-managed GitLab on infrastructure your organization controls, choosing an installation method that fits your operations model and, if needed, an offline configuration. Configure authentication through your identity provider, set group and project structures that mirror the Azure DevOps organization and projects, and apply the hardening guidance from GitLab's documentation. Confirm backups run and a restore has been tested. The step closes when the instance is reachable by administrators, backups have restored successfully in a test, and access is limited to approved groups.
Import Git repositories and history
Use GitLab's import tooling where a source platform is supported, and mirror Azure Repos repositories by URL for Git history otherwise. Azure Repos pull requests, comments and reviews do not move through a generic Git mirror, so record them in the inventory before import. Verify that every default branch, tag and commit count matches the source. The step is complete when each repository's branches and tags match the source and the team has confirmed the default branch.
Re-create branch protection and work item links
Translate Azure DevOps branch policies, required reviewers and build validation into GitLab protected branches, approval rules and merge request settings. Recreate Azure Repos pull request history only where it matters for audit, either through the Azure DevOps REST API or a documented export, and accept that most historical reviews will stay in the archive. Map Azure Boards work items to GitLab issues and epics, and agree which fields are dropped. The step closes when a test merge request on each critical repository enforces the same approvals as before.
Convert pipelines and re-enter secrets
Rewrite azure-pipelines.yml definitions as .gitlab-ci.yml, and translate variable groups, environments and approval gates into GitLab CI/CD variables and environments. Secret variables cannot be read back from Azure DevOps, so every secret must be re-entered from its source system and rotated where it was exposed to the old platform. Register GitLab Runners on your own infrastructure and confirm they can reach the artifact and deployment targets. The step is done when each pipeline runs on a runner and every secret has a recorded owner and rotation date.
Move Artifacts feeds
Inventory each NuGet, npm, Maven, Python and Universal Packages feed, its upstream sources and the consumers that reference it. Republish packages to the target registry, which may be GitLab's package registries or a separate repository manager, and update build and restore configurations to point to the new endpoints. Confirm with the development teams which feeds are still needed before migrating them. The step closes when consumers resolve packages from the new feeds in a test build.
Validate with a parallel run
Run the migrated pipelines and merge request workflows in GitLab alongside Azure DevOps for a agreed period, comparing build outputs, test results, deployments and approval behavior. Record every difference and fix it before cut-over. Confirm with the security and compliance owners that access, logging and retention meet your policy and that the evidence needed for any assessment is captured. The step is done when the outputs match and the owners sign off on the cut-over plan.
Cut over and retire the Azure DevOps source
Switch developer remotes, pipeline triggers and deployment credentials to GitLab, set Azure Repos to read-only for an agreed retention window, and keep a tested rollback path until the owners accept the new platform. Keep the exported inventory and backups under your retention rules before the Azure DevOps organization is closed. The step closes when all active projects point to GitLab, the rollback window has ended without use, and the archive is confirmed.
How cost splits between seats, infrastructure and staff time
The Azure DevOps side of the bill is mostly seats and consumption, and the GitLab side is mostly people and servers. On the Azure DevOps side, the recurring items are per-user access levels (Basic and Basic plus Test Plans), parallel jobs for pipelines, Artifacts storage above the included amount, and Advanced Security licensing per committer. Pull the current figures from your own invoice and the Azure DevOps pricing page, and confirm which of these your organization pays for today, because many teams find that parallel jobs or Artifacts storage, not seats, drive the largest share. On the GitLab side, the software can be free at the Free tier, so the recurring costs are the tier subscription if you choose one (Premium or Ultimate, billed per user), the virtual machines or Kubernetes nodes, storage for Git data and backups, and the people who run the platform. The GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, and Ultimate is quoted on request. Confirm current figures on that page before modeling.
Some costs are one-time and others recur, and the split matters for a multi-year comparison. One-time costs include the migration itself (importing repositories, work items and pipelines, and re-creating branch protection and permissions), converting Azure Pipelines definitions to .gitlab-ci.yml, and the initial architecture and hardening work. Recurring costs include the subscription, infrastructure, backup storage, monthly and yearly GitLab upgrades with required upgrade stops, support, and the platform engineer hours needed to keep the instance patched. Infrastructure and staff time scale with user count and availability needs. GitLab's reference architectures run from 1,000 users to 50,000 users, and the docs generally recommend a high availability strategy for 3,000 or more users, which adds cost in both machines and operations. Ask any implementation partner to price these as separate line items with the assumed user count, not a single lump sum.
When you request a quote, ask for each component on its own line: the subscription tier and user count you assume, the reference architecture or sizing you plan for, the number and size of virtual machines, storage and backup targets, the estimated effort for pipeline conversion and data migration by source, the upgrade and patch cadence, and support hours and response expectations. Ask what is excluded, such as runner capacity, Azure Boards replacement, and Artifacts feed migration. Also ask who owns each recurring item after handover. Compare these figures against your current Azure DevOps subscription and staff effort for the same period, using the same user count and growth assumptions, so the comparison reflects a single model rather than two different ones.
Questions teams ask before switching from Azure DevOps to GitLab
How much does it cost to switch from Azure DevOps to self-managed GitLab?
The cost is not a single number, because it is made of separate components: GitLab licensing, servers or cloud infrastructure, storage, migration labor, CI runner capacity, and ongoing administration. GitLab Free is listed at 0 dollars, while the GitLab pricing page lists Premium at 29 US dollars per user per month billed annually and Ultimate as custom priced, and all three tiers are available for self-managed installations. Your seat count, the features you need (advanced CI/CD, security scanning, compliance) and the number of projects drive the largest recurring figures. One-time costs include planning, repository and pipeline conversion, and cut-over. Ask any provider for a quote that separates one-time work from recurring hosting, licensing and support, and that names each assumption about seats, runners and storage.
How long does a migration from Azure DevOps to GitLab take?
Duration depends mainly on how many repositories, pipelines, work items and feeds you move, how much history must survive, and how many teams must be retrained at the same time. A team with a few repositories and simple YAML pipelines has a very different workload from an organization with hundreds of projects, classic release pipelines, service connections and branch policies. Pilot migrations of a small group of projects usually reveal the conversion effort before you commit to a schedule. Ask for a written plan that breaks the work into waves, states what is in and out of scope, and identifies which pipelines need rewriting rather than copying.
What does the switch require from our own engineering and operations staff?
Your staff keep ownership of the business decisions and the environment, even when an outside partner does the build. Platform engineers need to size and operate the GitLab instance, including PostgreSQL, Redis, Gitaly storage, backups and monitoring. Identity administrators must connect single sign-on and group mapping, and security staff must set access, secrets and runner policy. Developers must learn merge requests, the .gitlab-ci.yml syntax and the new permission model. Confirm with any provider which of these tasks they perform, which they train you to perform, and which remain with your team after handover.
Can our team run the migration without an outside implementation partner?
A capable internal team can complete a migration, provided it has time, GitLab administration skills and a clear pilot plan. The work that most often causes trouble is less the repository copy and more the pipeline conversion, identity mapping, runner security and the backup and restore test. Teams that do it alone usually underestimate the parallel effort of keeping Azure DevOps running during cut-over. An outside partner can take a defined part of the scope, such as the pipeline conversion or the hardening, under a fixed-scope written agreement. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and the split of work is agreed in writing before work starts.
Can GitLab issues and epics replace Azure Boards work items?
GitLab issues, epics and iterations cover much of the day-to-day work tracking that many teams use Azure Boards for, including backlogs, labels, milestones and linking issues to merge requests and commits. The mapping is not one to one, however. Azure Boards offers configurable work item types, process templates and detailed hierarchy rules that do not map directly onto GitLab's model, and Test Plans have no direct GitLab equivalent. Compare your actual work item types, custom fields, queries and reporting dashboards against the GitLab tier you select, and confirm each gap in writing. Export your Boards data before deciding, so you can see what must be redesigned rather than moved.
How do GitLab upgrades and required upgrade stops affect day-to-day operations?
GitLab ships a major release yearly, a minor release on the third Thursday of each month, and patch releases twice a month, and it currently maintains 19.5, 19.4 and 19.3. Bug fixes are backported only to the current stable release, while security fixes also go to the previous two monthly releases, so you must plan regular upgrades. GitLab also requires upgrades to pass through required upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11, for example 19.2, 19.5, 19.8 and 19.11. Skipping a stop means extra steps and a maintenance window, so build an upgrade calendar, a staging environment and a tested backup before each change.
Does self-managed GitLab run in air-gapped or offline environments?
Yes, GitLab documents running self-managed instances in offline, air-gapped environments, and it provides separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Offline operation requires you to plan how packages, container images, runner images, scanner data and updates reach the isolated network, since those components no longer download from the internet. Confirm which features you need, how dependency and vulnerability data will be refreshed, and whether your chosen installation method fits your transfer process. Read the offline environments documentation before you finalize the architecture, and have your team test an update cycle in the isolated network.
Which GitLab installation method suits a self-managed deployment?
GitLab documents several installation methods: the Linux package, the Helm chart, the GitLab Operator, Docker and installation from source. The Linux package bundles PostgreSQL, Redis and Sidekiq and is described as the most mature and scalable method. The Helm chart runs on Kubernetes, but GitLab's reference architectures state that running stateful components such as PostgreSQL and Redis inside Kubernetes is not supported, and the Cloud Native Hybrid architecture keeps stateless components on Kubernetes while stateful services run on VMs or managed services. Your team size, availability target and existing platform skills should drive the choice. Review the installation methods and reference architectures pages before you size the environment.
How DeployOpen helps evaluate, implement and migrate to self-hosted GitLab
DeployOpen plans, implements and supports self-hosted GitLab inside your own cloud accounts, data centers or air-gapped networks. We start from how your teams use Azure Repos, Boards, Pipelines and Artifacts today, then agree the scope in writing before any work begins.
How we scope
- We inventory the Azure DevOps projects, repositories, pipelines, feeds and work item types that the migration must cover.
- We confirm which GitLab tier covers the features your teams rely on, such as advanced CI/CD, compliance or security scanning.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support available as a retainer.
How we build
- We plan the GitLab installation method, reference architecture and high availability approach against your expected user count.
- We map azure-pipelines.yml and classic pipeline definitions to .gitlab-ci.yml and test each converted pipeline before cut-over.
- We rebuild permissions, branch protections and package feeds in GitLab, then test backup, restore and upgrade procedures.
How we hand over
- We document the installed architecture, configuration, access model and runbooks so your own staff can operate the platform.
- We deliver migration records that list which projects, pipelines and work items moved, and which were retired or left behind.
- We hand over the hardening, backup and upgrade procedures so your team can follow the GitLab maintenance policy after launch.
How we support
- We can support upgrades along GitLab's required upgrade stops, planned against the maintenance policy release schedule.
- We prepare the system, controls and evidence your compliance assessors need, while independent auditors issue any audit reports.
- Continuous testing and ongoing operations are available as a retainer, with the scope and fees set out in a written quote.
