Code hosting migration

Azure DevOps → GitLab

Move repositories, refs, pull requests, issues, users, LFS, pipelines, packages, permissions, webhooks, and audit evidence from Azure DevOps into GitLab with an explicit exception ledger and evidence-based cutover.

Typical timeline15–35 business days70–140 hours active work

Statusneeds review

Source testedAzure DevOps documentation reviewed 2026-07-19

Destination testedGitLab documentation reviewed 2026-07-19

Last reviewed2026-07-19

Sources2

Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Azure DevOps

Reasons to stay

Repos, boards, pipelines, artifacts, and enterprise controls are tightly integrated
Repository-centered workflows keep code, review, and automation close together

Reasons to leave

The interface and administration model can feel heavy outside Microsoft-centric organizations
Advanced governance and automation can become configuration-heavy

New platform

GitLab

What gets better

A comprehensive DevSecOps platform offers deep CI/CD and self-hosting options
Repository-centered workflows keep code, review, and automation close together

What gets worse

Breadth, upgrades, and administration can be heavy for smaller teams
Advanced governance and automation can become configuration-heavy

Best of the move

GitLab: A comprehensive DevSecOps platform offers deep CI/CD and self-hosting options. This removes a major source-side concern: The interface and administration model can feel heavy outside Microsoft-centric organizations.

Worst of the move

What you lose: Repos, boards, pipelines, artifacts, and enterprise controls are tightly integrated. What you inherit: Breadth, upgrades, and administration can be heavy for smaller teams.

01At a glance

Know the shape of the move.

Transfer outcome12 features audited

Clean1

Partial8

Manual3

Lost0

Mapping route9 of 9 fields have a destination path

SourceAzure DevOps9 mapped fields

Automatic2

Transform4

Manual3

Unsupported0

DestinationGitLab9 supported paths

This timeline assumes

Up to 100 repositories, 500 GB of Git data, and 250 users
Administrators control both platforms, identity mapping, DNS, registries, and every repository integration.
A representative repository set is migrated into an isolated destination organization first.
The source remains read-only until developers and automation pass one complete release cycle.
The migration team records evidence for every blocking verification check.

02Loss matrix

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

Item	Outcome	Impact	What happens	Mitigation
Git repositories, branches, tags, commits, and selected work metadata	partial	critical	Core git repositories, branches, tags, commits, and selected work metadata can move, but Azure DevOps and GitLab use different models, limits, identifiers, and import behavior.	Pilot every feature class, preserve source IDs, and reconcile accepted, transformed, rejected, and excluded items.
Boards, Pipelines, Artifacts, permissions, service connections, and post-snapshot changes	manual	critical	Azure DevOps services outside Git require separate import, rebuild, integration, archive, or retirement decisions.	Inventory every active dependency, approve its destination disposition, and test the replacement before source writes stop.
Git repositories and commit history	clean	critical	Git source, branches, tags, and commits can move through supported importers or mirror pushes.	Compare refs, commit graphs, default branches, submodules, signatures, and shallow state.
Pull or merge requests	partial	critical	Metadata migration depends on the selected importer and supported source version.	Pilot open, closed, merged, draft, forked, and large requests.
Issues, comments, and discussions	partial	high	Coverage, formatting, attribution, timestamps, and cross-links vary by migration path.	Preserve source IDs and URLs and reconcile representative conversations.
Users and contribution attribution	partial	critical	Email and username differences can create placeholders or migration identities.	Freeze an identity map and reclaim or annotate unmapped activity.
Git LFS and large binaries	partial	critical	Git history can move while LFS objects, package blobs, and releases require separate transfer.	Inventory object counts and compare hashes after migration.
Branches, tags, and protections	partial	critical	Refs move more easily than approval, push, merge, and signing policies.	Recreate rules before developers receive write access.
CI/CD pipelines and secrets	manual	critical	Pipeline syntax, runners, caches, artifacts, environments, and secret stores differ.	Translate and rehearse every active build and release workflow.
Packages, containers, and releases	partial	high	Registries and release assets do not necessarily follow repository data.	Copy immutable artifacts and update package coordinates and credentials.
Wikis, snippets, projects, and planning	partial	high	Collaboration products have different models and importer coverage.	Archive history and migrate only active shared knowledge and work.
Organizations, groups, teams, and permissions	manual	critical	Account hierarchy and inherited access never map safely by assumption.	Design and test least-privilege destination access first.

03Field and feature mapping

Where each thing goes.

Source	Destination	Method	Notes
Azure DevOps repository	GitLab repository	automatic	Preserve stable source URL and default branch.
Git branch and tag	Git branch and tag	automatic	Compare all refs after import.
Pull or merge request	Destination pull or merge request	transform	Depends on selected metadata importer.
Issue and comment	Destination issue and comment	transform	Preserve author, timestamp, ID, and URL.
Source user	Destination identity	manual	Freeze an identity map before migration.
Branch protection	Destination ruleset or branch restriction	manual	Rebuild before write access.
CI pipeline	Destination workflow	transform	Review every generated or translated step.
Package, release, or LFS object	Destination registry, release, or LFS object	transform	Copy binaries and compare hashes.
Group, team, or permission	Destination organization, team, and role	manual	Apply least privilege.

04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Azure DevOps data, configuration, and operating evidence before any destination write.

Inventory and export Azure DevOps repositories, metadata, users, permissions, pipelines, packages, releases, webhooks, and settings.
Mirror every Git repository and fetch Git LFS objects.
Record counts by repository, ref, pull request, issue, user, package, and integration.
Hash archives and migration manifests.

Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.

Transformation · Platform inventory tools and migration workbook

Repository and identity manifest

Preserve repository scope, Git refs, users, and metadata ownership.

Inventory source values and exceptions.
Define explicit destination mappings.
Reject unmapped critical records.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Official importer, CI converter, and verification scripts

Workflow and integration conversion

Rebuild delivery and connected services safely.

Normalize encoding, dates, identifiers, and blanks.
Run a representative pilot.
Reconcile accepted, rejected, and transformed rows.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Migration

A code-only move is mistaken for a metadata migration

criticalpossible likelihood

Git refs exist while pull requests, issues, users, or settings are missing.

Consequence: Collaboration and control history disappears.
Mitigation: Choose and verify the required migration fidelity explicitly.

Stop if: Any required metadata class lacks a supported path.

Cutover

Both platforms accept writes

criticalpossible likelihood

Developers or bots push and update work in both systems.

Consequence: Repositories and release state diverge.
Mitigation: Freeze source writes and change remotes in one controlled window.

Stop if: Any unapproved source writer remains active.

Access

Permissions or secrets are over-broad

criticalpossible likelihood

Migrated users or automation receive more authority than intended.

Consequence: Code, packages, or production systems are exposed.
Mitigation: Apply least privilege before opening repositories.

Stop if: An unauthorized test identity can perform a protected action.

06Precise timeline

Do the work in this order.

Estimate forUp to 100 repositories, 500 GB of Git data, and 250 users

Total elapsed15–35 business days

Active work70–140 hours

BufferAdd time for large exports, unsupported Azure DevOps features, destination limits, identity exceptions, regulated data, or strict downtime requirements.

Days 1–3Inventory and decisions2–3 days

Days 3–5Backup and reconcile1–3 days

Days 5–12Map and pilot3–8 days

Days 10–20Final delta and switch1–5 days

Days 12–40Observe and close3–10 days

1
Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting
- Inventory Azure DevOps data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Azure DevOps and GitLab administrator access
Stop / go checkpoint
Export?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
2
Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting
- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpoint
Transform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
3
Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting
- Configure GitLab and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpoint
Scale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
4
Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting
- Freeze production writes in Azure DevOps.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpoint
Open production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
5
Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting
- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpoint
Close rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make GitLab the only production system without losing the final Azure DevOps delta.

Recommended window: A low-volume weekday morning with platform, data, DNS, and business owners available.

Freeze production writes and scheduled actions in Azure DevOps.
Export, transform, and reconcile the final delta.
Apply the approved delta to GitLab.
Switch domains, forms, integrations, sending, or sync ownership as applicable.
Run every blocking verification check and keep the source intact.

Proof to capture: GitLab owns production, totals reconcile, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Azure DevOps without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, or billing are changed.

Stop new writes and scheduled actions in GitLab.
Restore the prior Azure DevOps routing, forms, integrations, sending, or sync ownership.
Export the GitLab post-cutover delta.
Review and apply safe destination-era changes to Azure DevOps.
Run the same blocking checks against the restored source.

Proof to capture: Azure DevOps again owns production with current data and no duplicate destination action.

Rollback immediately when

Unexplained critical count or value variance
Missing or exposed critical data
Duplicate production action
Failed access, routing, delivery, or integration check
A critical feature has no safe destination replacement

08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

ID	Check	Method	Expected result	Evidence
`V-01`Blocking	Repository and ref parity	Compare repositories, commits, branches, tags, default branches, submodules, and LFS.	Every scoped Git object is accounted for.	Git manifest.
`V-02`Blocking	Collaboration coverage	Compare pull requests, issues, comments, releases, wikis, and projects by source class.	Every required item is migrated or explicitly archived.	Metadata ledger.
`V-03`Blocking	Attribution mapping	Inspect active, inactive, bot, and external contributors.	Every required author has a destination or annotation.	Identity map.
`V-04`Blocking	Teams and repository rules	Test representative users and protected actions.	Least privilege and branch controls match policy.	Access report.
`V-05`Blocking	Build and release parity	Run representative workflows from identical commits.	Tests, artifacts, approvals, and deployments match.	Workflow evidence.
`V-06`Blocking	Packages, releases, and LFS	Compare counts, coordinates, sizes, and hashes.	Every required binary is present and retrievable.	Artifact manifest.
`V-07`Blocking	Connected services	Exercise each webhook, app, key, and notification.	One correct destination callback per event.	Integration log.
`V-08`Blocking	Single repository authority	Inspect developer remotes, bots, and source protections.	GitLab alone accepts approved writes.	Cutover checklist.

09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.

Create final Azure DevOps exports and archive verification evidence.
Revoke temporary credentials, API keys, webhooks, and elevated roles.
Remove obsolete embeds, forms, jobs, integrations, and DNS records.
Keep the source intact through the approved retention window.
Cancel paid plans only after billing, legal, and recovery review.
Schedule the next GitLab backup, access, and migration-playbook review.

Sources and maintenance

Built to be reviewed.

Tested 2026-07-19. Next scheduled review: 2026-10-19.

Azure DevOps: official migration documentationAccessed 2026-07-19
GitLab: official migration documentationAccessed 2026-07-19

Know the shape of the move.

This timeline assumes

What survives the move.

Where each thing goes.

Make the move recoverable.

Create the source-of-truth backup

Repository and identity manifest

Workflow and integration conversion

The things most likely to hurt.

A code-only move is mistaken for a metadata migration

Both platforms accept writes

Permissions or secrets are over-broad

Do the work in this order.

Inventory and decisions

Export?

Backup and reconcile

Transform?

Map and pilot

Scale?

Final delta and switch

Open production?

Observe and close

Close rollback?

Cut over with a way back.

Cutover

Rollback

Prove the migration worked.

Remove the scaffolding safely.

Built to be reviewed.