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.ymlautomatisch - 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:
- Test-Destination in GitLab erstellen (GitLab.com: dedicated Group/Namespace; Self-managed: Top-level Group)
- Authentication vorbereiten (Azure DevOps PAT, GitLab Personal Access Token mit api und read_repository Scopes)
- Trial Migrations durchführen (Repos only: eingebauter Import; Repos + PRs/MRs: Congregate)
- Post-Trial Follow-up (Repo-History, Branches, Tags, Merge Requests, Issues/Epics, Labels, Relationships verifizieren)
- Permissions/Roles, Protected Branches, Runners/Tags, Variables/Secrets, Integrations/Webhooks prüfen
- Pipelines (
.gitlab-ci.yml) oder konvertierte Pipelines validieren - User-Validierung für Functionality und Data-Fidelity
- 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:
