Azure DevOps to GitLab Migration

Q: What about TFVC, not just Azure Repos Git?

TFVC has no direct GitLab path. The common approach is converting TFVC history to Git first, typically with git-tfs, before that Git history goes through GitLab's normal repository import.

GitLab partner
Delivering since 1999
Public & private sector
Decades of migration experience

Azure DevOps bundles four things that are separate products almost everywhere else: Repos, Boards, Pipelines and Artifacts. That is exactly why an Azure DevOps to GitLab migration is not one migration, it is four, each with its own tooling, its own gaps, and its own honest answer about what an importer actually does for you.

ReleaseTEAM has been delivering DevOps tooling engagements since 1999, and we are a GitLab partner. We run these migrations end to end, part by part, and we will tell you plainly where the automation stops and where a human has to pick up the work.

The short answer: Azure Repos (Git) moves cleanly with GitLab’s built-in repository-by-URL importer, which carries commit history, branches and tags. Azure Boards work items, Azure Pipelines YAML and Azure Artifacts do not have a first-party GitLab importer on GitLab.com or self-managed today. GitLab’s own migration guidance points to Congregate, a GitLab Professional Services tool, for anything beyond the Git repository itself, and even there the pipeline conversion is a starting point you still have to finish by hand.

The four migrations inside “Azure DevOps to GitLab”

Azure Repos

Git repositories import cleanly by URL. TFVC repositories are a separate, older problem with no direct GitLab path.

Azure Boards

Work items have a real conceptual mapping to GitLab issues and epics, but no built-in importer moves them automatically.

Azure Pipelines

YAML pipelines need to be rewritten as .gitlab-ci.yml. There is no production-ready automatic converter; classic (non-YAML) pipelines need to be rebuilt from scratch.

Azure Artifacts

Packages and container images move to GitLab’s Package Registry and Container Registry, feed by feed, with no bulk importer.

Azure Repos: Git moves easily, TFVC does not

If your Azure Repos are already Git, this is the easy part. GitLab’s built-in “Repo by URL” import preserves commit history, branches and tags, and works project by project or in bulk. For larger estates, GitLab Professional Services’ Congregate tool wraps the same GitLab APIs to bulk-migrate many repositories at once, and according to GitLab’s own migration guidance it also carries over wikis, CI/CD variables, container images and packages where the simple URL import does not.

If you are still on TFVC (Team Foundation Version Control), that is a different and older problem. TFVC has no direct GitLab importer at all. The common path is converting TFVC history to Git first, most often with git-tfs, an open source Git/TFS bridge whose own maintainers describe it as no longer actively maintained, since its authors are no longer TFS users themselves, though it remains widely used and open to contributions. Full-fidelity conversion of an old, heavily-branched TFVC history is a real project in its own right, not a checkbox.

Azure Boards: a real mapping, but no automatic import

Azure Boards work items map conceptually onto GitLab’s planning tools. According to GitLab’s own migration guidance, Azure DevOps epics and features map to GitLab Epics, and other Azure DevOps work item types map to project-scoped GitLab issues, with parent-child relationships retained in the mapping model. That is a genuine, workable target model.

What does not exist is a one-click importer that does this for you today. Moving work items, their history, comments and hierarchy in practice means either a scripted migration against the Azure DevOps and GitLab APIs, or using Congregate as part of a services engagement. Keeping Azure Boards and connecting it to GitLab for source control and CI/CD is also a legitimate choice, and for teams already invested in Atlassian tooling, moving planning to Jira instead is worth a look: see our Jira and Confluence to GitLab migration guide.

Azure Pipelines: no automatic converter you should rely on in production

This is the part most teams underestimate. Azure Pipelines YAML and .gitlab-ci.yml share a “YAML pipeline” idea, but the stage, job, trigger and variable models differ enough that a straight syntax translation does not produce a working pipeline. GitLab’s own current migration guidance is candid about this: Congregate has an AI-assisted converter for multi-stage YAML pipelines, but it is described as working best for simple, single-file pipelines, and is meant to give you a starting point rather than a production-ready .gitlab-ci.yml file. Classic (non-YAML, UI-designed) release pipelines are not covered by that converter at all and have to be rebuilt as GitLab CI/CD jobs from the pipeline’s actual behavior.

Plan for two more mappings explicitly: Azure DevOps service connections and variable groups become GitLab CI/CD variables at the project or group level, and Azure DevOps branch policies become GitLab protected branches and merge request approval rules. Approval rules on protected branches, multiple required approvers, and Code Owners enforcement are Premium and Ultimate features; basic protected branches are on every tier. Check which tier your branch policies require before committing to a cutover date; our GitLab licensing comparison covers this tier-by-tier.

GitLab does not yet have an official Azure DevOps to GitLab CI/CD migration guide in its documentation set. A GitLab.org issue requesting one (issue 468540, “Add a guide for migrating from Azure DevOps to GitLab CI/CD”) is open as of this writing. GitLab’s own engineering blog published a migration walkthrough in December 2025 covering Repos, Boards, Pipelines and Artifacts, which is the most current first-party guidance available, but it sits on the blog rather than in the versioned docs. Treat any third-party “automatic Azure Pipelines converter” claim with the same skepticism you’d want us to bring: we have not found one that produces a production-ready result without review.

Azure Artifacts and identity

Azure Artifacts feeds (NuGet, npm, Maven, universal packages) and Azure Container Registry images do not migrate in bulk automatically. Each package type maps to the matching GitLab Package Registry or Container Registry feature, and moving the packages themselves is a feed-by-feed or registry-by-registry exercise, sometimes assisted by Congregate depending on package type and engagement scope.

On identity: organizations using Microsoft Entra ID (formerly Azure AD) for single sign-on can configure GitLab SAML SSO for groups, available on Premium and Ultimate for GitLab.com, self-managed and GitLab Dedicated. SCIM user provisioning from Entra ID is supported, but SCIM group provisioning is not; GitLab’s own SCIM setup documentation notes that leaving group provisioning enabled on the Entra ID side won’t break user provisioning, but will generate errors in Entra ID’s provisioning log, so it’s worth disabling there rather than leaving it to fail quietly. Group membership can still be managed through GitLab’s separate SAML group sync feature.

How we run an Azure DevOps to GitLab migration

Assessment

Inventory of Azure Repos (Git and TFVC), Boards work item types and custom fields, Pipelines (YAML and classic), Artifacts feeds, service connections and branch policies.

Mapping

Work item types to GitLab issues and epics, branch policies to protected branches and approval rules, variable groups to CI/CD variables, agreed with your teams before anything moves.

Pilot

One team or one pipeline family moves end to end, including a working, reviewed .gitlab-ci.yml, before the rest follows.

Full migration & reconciliation

Repositories, work items and packages moved in phases, with counts and spot checks proving what arrived matches what left.

Parallel run

Azure DevOps kept available, typically read-only, until CI/CD is green and teams are confident in the new pipelines.

Training & licensing

Hands-on GitLab training for developers used to Azure DevOps’s UI, plus GitLab tier selection sized to the features you actually need.

Related migrations: Bitbucket to GitLab, SVN to Git, Jenkins to GitLab CI or CloudBees.

Frequently asked questions

Does GitLab have a dedicated Azure DevOps importer?

For Git repositories, yes: GitLab’s built-in repository-by-URL import handles Azure Repos Git projects directly, preserving commit history, branches and tags. For Boards work items, Pipelines and Artifacts, there is no built-in importer; GitLab Professional Services’ Congregate tool covers more ground in a services engagement, and an official documented Azure DevOps to GitLab CI/CD migration guide is still an open request (GitLab.org issue 468540) as of this writing.

Can we automatically convert Azure Pipelines YAML to .gitlab-ci.yml?

Not reliably in production. Congregate includes an AI-assisted converter for multi-stage YAML pipelines, but GitLab’s own guidance describes it as best suited to simple, single-file pipelines and as producing a starting point rather than a finished pipeline. Classic (non-YAML) release pipelines are not covered by that converter and need to be rebuilt from their actual behavior.

What happens to Azure Boards work items?

They map conceptually to GitLab: epics and features become GitLab Epics, other work item types become project-scoped issues, and parent-child relationships are retained in that mapping. Moving them in practice requires a scripted migration or a Congregate-based engagement, since there is no self-service importer for work items today.

Do our Azure DevOps branch policies survive the move?

They map to GitLab protected branches and merge request approval rules, but not automatically. Basic protected branches exist on every GitLab tier; multiple required approvers, approval rules on protected branches, and Code Owners enforcement need Premium or Ultimate. Check your policy requirements against your target tier before cutover.

What about TFVC, not just Azure Repos Git?

TFVC is a separate, older problem with no direct GitLab path. The common approach is converting TFVC history to Git first, typically with git-tfs, an open source Git/TFS bridge whose own maintainers describe it as no longer actively maintained (though still widely used and open to contributions), before that Git history goes through GitLab’s normal repository import.

Can we keep Azure DevOps for some things and use GitLab for others?

Yes. A common phased approach keeps Azure Boards for planning while moving source control and CI/CD to GitLab, or runs Azure DevOps read-only during a pilot before committing to a full cutover. We can help you scope a phased plan rather than a big-bang migration.

GitLab importer behavior, Congregate capabilities, SAML/SCIM tier and support details, and GitLab.org issue 468540’s status verified 26 September 2026 against docs.gitlab.com, GitLab’s engineering blog and gitlab.com/gitlab-org/gitlab. Git-tfs maintenance status verified against the git-tfs GitHub repository. Atlassian and Microsoft product names are used to describe compatibility only; ReleaseTEAM claims no Microsoft partnership. See all our tool migration services.

Four migrations, one plan

Repos, Boards, Pipelines and Artifacts each need their own approach. We’ll assess your Azure DevOps estate honestly, tell you what moves cleanly and what needs real engineering, and run the migration end to end.

Speak With An Expert