Migration von Azure DevOps zu GitLab systematisch planen

Enterprise-Migrationen in regulierten Branchen wie Finanzwesen und Automobilindustrie erfordern systematisches Risikomanagement gemäß NIS2-Richtlinie Artikel 21. Die mehrstufige Migrationsstruktur mit Testläufen vor Produktions-Wellen und kontrollierten Change-Freezes demonstriert Business-Continuity-Management in der Praxis. GitLab Professional Services organisiert Migrationen in Wellen von 200-300 Projekten, um Komplexität zu managen und API-Rate-Limits zu respektieren.

Überblick

GitLab bietet Congregate (maintained by GitLab Professional Services) und eingebauten Git-Repository-Import für Migrationen von Azure DevOps (ADO). Beide Optionen unterstützen Repository-basierte oder Bulk-Migration und erhalten Git-Commit-History, Branches und Tags. Mit Congregate werden zusätzliche Assets wie Wikis, Work Items, CI/CD-Variablen, Container-Images, Packages und Pipelines migriert (siehe Feature-Matrix).

Enterprises folgen typischerweise einem mehrstufigen Ansatz:

• Repositories von ADO zu GitLab migrieren (Congregate oder eingebauter Import)
• Pipelines von Azure Pipelines zu GitLab CI/CD migrieren
• Verbleibende Assets wie Boards, Work Items und Artifacts zu GitLab Issues, Epics und Package/Container Registries migrieren

Mehrstufige Migrationsphasen (siehe Diagramm):

• Prerequisites (IdP, Runners, Change Management)
• Migration Phase (Source Code, History, Work Items)
• Post-Migration (Pipelines, Assets, Security)

Migration planen

Zentrale Planungsfragen:

• Wie schnell muss die Migration abgeschlossen werden?
• Was genau wird migriert?
• Wer führt die Migration durch?
• Welche Organisationsstruktur wird in GitLab benötigt?
• Welche Einschränkungen, Limitierungen oder Fallstricke müssen berücksichtigt werden?

Die Timeline bestimmt weitgehend den Migrationsansatz. Identifizierung von Champions oder Teams mit ADO- und GitLab-Erfahrung unterstützt Adoption und Guidance.

Inventar erstellen:

Das GitLab Professional Services Evaluate-Tool produziert ein vollständiges Inventar der Azure DevOps Organisation: Repositories, PR-Counts, Contributors, Pipelines, Work Items, CI/CD-Variablen. Bei Professional Services Engagements wird dieser Report mit Engagement Manager oder Technical Architect geteilt für Migrationsplanung.

Migrations-Timing wird primär bestimmt durch Pull-Request-Count, Repository-Größe und Contribution-Menge. Beispiel: 1.000 kleine Repositories mit wenigen PRs migrieren schneller als wenige Repositories mit Zehntausenden PRs. Inventar-Daten ermöglichen Aufwands-Schätzung und Test-Run-Planung.

In Professional Services Engagements werden Migrationen in Wellen von 200-300 Projekten organisiert, um Komplexität zu managen und API-Rate-Limits zu respektieren (sowohl GitLab als auch ADO).

Tool-Auswahl:

GitLabs eingebauter Repository-Importer migriert Git-Repositories (Commits, Branches, Tags) einzeln. Congregate erhält Pull Requests (in GitLab: Merge Requests), Kommentare und Metadata; der eingebaute Import fokussiert auf Git-Daten (History, Branches, Tags).

Assets die typischerweise separate Migration oder manuelle Neuerstellung erfordern:

• Azure Pipelines → GitLab CI/CD Pipelines (siehe CI/CD YAML oder CI/CD Components). Alternativ: AI-basierte Pipeline-Konvertierung in Congregate.
• Work Items und Boards → GitLab Issues, Epics, Issue Boards
• Artifacts, Container-Images (ACR) → GitLab Package/Container Registry
• Service Hooks, externe Integrationen → in GitLab neu erstellen

Permissions-Modelle unterscheiden sich zwischen ADO und GitLab. Permissions-Mapping planen statt exakter Preservation zu erwarten.

Organisationsstruktur in GitLab:

Empfohlener Ansatz: ADO-Organisationen auf GitLab-Groups mappen (nicht viele kleine Groups). Migration als Gelegenheit nutzen, GitLab-Struktur zu rationalisieren (siehe Struktur-Diagramm):

• ADO Organization → GitLab Top-level Group
• ADO Project → GitLab Subgroup (optional)
• ADO Repository → GitLab Project

Weitere Empfehlungen:

• Subgroups und Project-Level-Permissions für verwandte Repositories nutzen
• Zugriff über GitLab Groups und Group-Membership managen
• GitLab Permissions und SAML Group Links für Enterprise-RBAC-Modell evaluieren

ADO Work Items Migration:

ADO Boards und Work Items mappen zu GitLab Issues, Epics und Issue Boards. ADO Epics und Features werden GitLab Epics. Andere Work-Item-Typen (User Stories, Tasks, Bugs) werden project-scoped Issues. Standard-Felder bleiben erhalten; ausgewählte Custom Fields können migriert werden. Parent-Child-Relationships bleiben erhalten. Links zu Pull Requests werden zu Merge-Request-Links konvertiert.

Pipelines-Migration:

Congregate bietet AI-basierte Konvertierung für multi-stage YAML-Pipelines von Azure DevOps zu GitLab CI/CD. Die automatisierte Konvertierung funktioniert optimal für einfache Single-File-Pipelines und liefert einen funktionalen Ausgangspunkt, nicht ein produktionsreifes .gitlab-ci.yml-File. Das Tool generiert funktional äquivalente GitLab-Pipelines zur weiteren Optimierung.

• Konvertiert Azure Pipelines YAML zu .gitlab-ci.yml automatisch
• Geeignet für straightforward Single-File-Pipeline-Konfigurationen
• Liefert Boilerplate zur Migrations-Beschleunigung, nicht finales Production-Artifact
• Erfordert Review und Anpassung für komplexe Szenarien, Custom Tasks oder Enterprise-Requirements
• Unterstützt keine Azure DevOps Classic Release Pipelines

Repository-Owner sollten GitLab CI/CD Dokumentation konsultieren für weitere Pipeline-Optimierung nach initialer Konvertierung.

Migrationen durchführen

Nach der Planung werden Migrationen in Stages durchgeführt, beginnend mit Trial Runs. Trial Migrations identifizieren organisations-spezifische Issues frühzeitig und ermöglichen Duration-Messung, Outcome-Validierung und Approach-Finetuning vor Production.

Was Trial Migrations validieren:

• Ob Repository und Assets erfolgreich migrieren (History, Branches, Tags; plus MRs/Comments bei Congregate)
• Ob Destination sofort nutzbar ist (Permissions, Runners, CI/CD-Variablen, Integrationen)
• Wie lange jeder Batch benötigt für Schedule- und Stakeholder-Expectations

Downtime-Guidance:

GitLabs eingebauter Git-Import und Congregate erfordern inhärent keine Downtime. Für Production-Wellen: Changes in ADO freezen (Branch-Protections oder Read-only), um verpasste Commits, PR-Updates oder mid-migration Work Items zu vermeiden. Trial Runs erfordern keine Freezes.

Batching-Guidance:

Trial-Batches back-to-back durchführen für kürzere elapsed Time. Teams validieren Results asynchron. Geplante Group/Subgroup-Struktur für Batch-Definition nutzen und API-Rate-Limits respektieren.

Empfohlene Schritte:

1. Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)
2. Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)
3. Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)
4. Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)
5. Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen
6. Pipelines (.gitlab-ci.yml) oder konvertierte Pipelines validieren
7. User-Validierung für Functionality und Data-Fidelity
8. Production-Migrationen in Waves durchführen (Change-Freezes in ADO erzwingen, Progress und Logs monitoren)

Zentrale ADO-zu-GitLab-Mappings

Wichtigste Struktur-Mappings für Migrationsplanung:

• ADO Organization → GitLab Group (Top-level Namespace)
• ADO Project → GitLab Group oder Subgroup (Permissions-Boundary)
• ADO Repository → GitLab Project (Git-Repo plus Issues, CI/CD, Wiki)
• Pull Request → Merge Request (Code Review, Approvals)
• Azure Pipelines → GitLab CI/CD (.gitlab-ci.yml)
• Agent Pools → GitLab Runners (Job-Execution)
• Work Items → GitLab Issues/Epics (Planning-Funktionalität)
• Variable Groups → CI/CD Variables (Project/Group/Instance Level)

Für vollständige Terminologie-Referenztabelle mit allen Mappings siehe englische Originalversion.

Professional Services Migrationsmuster

GitLab Professional Services nutzt bewährte Muster für Enterprise-Migrationen:

Systematische Planung: Evaluate-Tool liefert vollständiges Inventar (Repositories, PRs, Contributors, Pipelines, Work Items). Klassifikation nach Komplexität (Work Items = Planning-Team-Involvement; Pipelines = Conversion-Requirements) ermöglicht Timeline-Schätzung und Batch-Definition.

Controlled Execution: Wellen von 200-300 Projekten managen Komplexität und respektieren API-Rate-Limits. Trial-Migrationen vor Production-Waves identifizieren Issues frühzeitig. Change-Freezes in ADO während Production-Wellen vermeiden mid-migration Updates.

Risikominimierung: Multi-Phase-Ansatz (Prerequisites → Migration → Post-migration) mit Validierungs-Checkpoints an jeder Phase. Trial-Runs ermöglichen asynchrone Team-Validierung ohne Production-Impact.

Praktische Implementierung

Für vollständige Implementierungsdetails, Konfigurationsbeispiele, Pipeline-Konvertierungs-Patterns und detaillierte Post-Migration-Checklisten siehe englische Originalversion.

Weitere Professional Services Ressourcen:

• Professional Services Full Catalog
• Congregate Migration Tool
• Evaluate Inventory Tool