Von GitLab zu fremforge migrieren

Diese Anleitung beschreibt die Migration von GitLab zu fremforge. Sie gilt für GitLab.com, selbst betriebenes GitLab (CE oder EE) und GitLab Dedicated. Die Unterschiede zwischen diesen Varianten zeigen sich vor allem bei der Authentifizierung und darin, welche GitLab-spezifischen Funktionen du aktiviert hast.

Kommst du von GitHub, lies zuerst die Anleitung zur Migration von GitHub. Einige der naheliegenden Schritte sind identisch, und wir wiederholen sie hier nicht.

Falls du die Checkliste vor der Migration noch nicht für deinen aktuellen GitLab-Mandanten durchgearbeitet hast, tu das zuerst. Speziell bei GitLab-Migrationen zeigt sie projektübergreifende include:-Verweise in GitLab CI (die du von Hand auflösen musst) und Deployments von GitLab Pages (die ein neues Zuhause brauchen, weil fremforge kein Pages-Produkt hat; siehe Schritt 6).

Bevor du beginnst

Was du auf deiner Seite brauchst:

• Ein Konto mit der Rolle Owner in den GitLab-Gruppen, die du migrierst.
• Einen persönlichen Zugriffstoken bei GitLab mit den Scopes api, read_repository, read_user und read_registry.
• Admin-Zugriff auf die fremforge-Organisation, in die du migrierst.
• Für die CI-Migration: eine Bestandsaufnahme der GitLab-CI-Vorlagen, der include:-Verweise und aller eigenen GitLab-Runner-Tags, auf die deine Pipelines angewiesen sind.

Was wir empfehlen:

• Friere Merges in die Standard-Branches während der Migration ein.
• Prüfe zuerst ein Repository von Anfang bis Ende. GitLab-CI-Pipelines unterscheiden sich strukturell stärker von Forgejo Actions als GitHub Actions, daher ist die Anpassung pro Repository aufwendiger.
• Hast du in GitLab CI viele projektübergreifende include:-Verweise, erfasse den Abhängigkeitsgraphen, bevor du mit der Migration beginnst. So vermeidest du halb migrierte Pipelines, die auf Vorlagen verweisen, die für sie nicht mehr sichtbar sind.

Zeitaufwand:

• Einzelnes kleines Repository mit einfacher .gitlab-ci.yml: 30 bis 60 Minuten einschließlich Anpassung der Pipeline.
• Mittleres Repository mit mäßig komplexer CI (DAG, needs:, Tags für eigene Runner): 2 bis 4 Stunden.
• Massenmigration von 20 bis 50 Repositorys, von denen viele GitLab-CI-Vorlagen per include: teilen: 3 bis 5 Entwicklertage, überwiegend für die CI-Umstellung.

Funktionsvergleich

Für Sicherheit und Authentifizierung gilt dieselbe Matrix wie im Funktionsvergleich der GitHub-Migration: fremforge liefert für beide Quellen dieselben Sicherheitsbausteine. Neue Organisationen nutzen bei fremforge standardmäßig Git-Zugriff nur über HTTPS (SSH ist seit dem 22.05.2026 standardmäßig ausgeschaltet), mit der vorregistrierten OAuth-App für Git Credential Manager; Entwickler erhalten MFA über den IdP deiner Organisation bei jeder Auffrischung beim Push. GitLab-spezifische Punkte:

Schritt 1: Repository und Historie migrieren

Der eingebaute Importer von Forgejo unterstützt GitLab als Quelle. Er kopiert die vollständige Git-Historie, Issues, Merge Requests (als Pull Requests importiert), Kommentare, Labels, Meilensteine, Wiki-Inhalte und Releases.

Mit dem eingebauten Importer (über die Oberfläche)

In der Verwaltungsoberfläche von fremforge für deine Organisation:

1. Klicke auf + → Neue Migration.
2. Wähle GitLab als Quelle.
3. Füge die URL des GitLab-Projekts ein (z. B. https://gitlab.com/acme/backend).
4. Füge deinen persönlichen Zugriffstoken von GitLab ein.
5. Hake die zu importierenden Inhalte an: Wiki, Issues, Merge requests, Releases, Labels, Milestones.
6. Wähle die Zielorganisation und den Repository-Namen bei fremforge.
7. Klicke auf Migrate repository.

Über die API (skriptbar)

# Build the JSON body via jq so the token is JSON-string-escaped safely
# (a token containing `"` or `\` would otherwise break the body).
jq -nc \
  --arg clone_addr "https://gitlab.com/acme/backend.git" \
  --arg auth_token "$GITLAB_TOKEN" \
  --arg repo_owner "acme" \
  --arg repo_name  "backend" \
  '{clone_addr: $clone_addr, auth_token: $auth_token,
    service: "gitlab", repo_owner: $repo_owner, repo_name: $repo_name,
    wiki: true, issues: true, pull_requests: true,
    releases: true, labels: true, milestones: true,
    lfs: true}' \
| curl -X POST "https://frem.sh/api/v1/repos/migrate" \
    -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
    -H "Content-Type: application/json" \
    -d @-

GitLab-Konzepte in fremforge

GitLab und Forgejo verwenden nicht dasselbe Vokabular. Der Importer deckt die üblichen Fälle ab:

Untergruppen

GitLab erlaubt beliebig tief verschachtelte Untergruppen. fremforge (Forgejo) verwendet ein flaches Modell aus Organisation und Repository. Ist deine GitLab-Struktur company / department / team / project, entscheide vor der Migration, ob du:

1. In eine einzige Organisation zusammenfasst: Alle Projekte werden zu Repositorys <company-slug>/<team>-<project> in einer Organisation. Einfachere Berechtigungen, aber ein Teil der Hierarchie geht verloren.
2. Eine Organisation pro Gruppe der obersten Ebene anlegst: <company-department-slug> mit flacher Benennung der Repos. Die Hierarchie auf Abteilungsebene geht verloren.
3. Eine Organisation pro Untergruppe anlegst: mehr Organisationen, mehr Verwaltung von Nutzern, jede einzeln abgerechnet. Nur sinnvoll, wenn die Untergruppen tatsächlich getrennte Anforderungen an Abrechnung und Zugriff haben.

Der Importer unterstützt Option 1 oder 2 direkt. Für Option 3 musst du mehrere fremforge-Organisationen anlegen und den Import N-mal ausführen.

Schritt 2: Secrets und CI/CD-Variablen

GitLab speichert CI/CD-Variablen auf Instanz-, Gruppen-, Projekt- und Umgebungsebene. fremforge Actions unterstützt Secrets und Variablen auf Ebene der Organisation, der Umgebung und des Repositorys: eine dreistufige Hierarchie, die sich sauber auf die üblichen Fälle in GitLab abbilden lässt.

Wichtig: Als „masked“ markierte CI/CD-Variablen in GitLab geben ihre Werte über die API nicht heraus. Du musst den Wert entweder kennen oder ihn aus deinem führenden Secret-Speicher holen. Das ist dieselbe Einschränkung wie bei der Migration von GitHub-Secrets.

Variablen neu eingeben

Entscheide für jede CI/CD-Variable in GitLab:

• Ist sie ein langlebiger Cloud-Zugang (AWS-Access-Key, Secret eines Azure-Service-Principals, AK/SK für T Cloud Public)? Dringende Empfehlung: Ersetze sie durch OIDC-Föderation zur Ziel-Cloud (siehe Schritt 4 unten), statt den statischen Zugang zu migrieren.
• Ist sie eine geschützte Variable (ein GitLab-Konzept, nur für geschützte Branches/Tags zugänglich)? fremforge bietet das Gegenstück über Umgebungs-Secrets. Konfiguriere die Zielumgebung mit einem Zugriff, der an den Branch-Schutz gebunden ist, und lege das Secret dort ab.
• Ist sie eine Dateivariable (GitLab speichert mehrzeilige Dateiinhalte als Variable)? fremforge unterstützt das über den normalen Secret-Speicher. Füge den mehrzeiligen Inhalt ein; der Runner stellt ihn zur Laufzeit des Jobs als benannte Umgebungsvariable bereit.

Lege Variablen und Secrets in der Verwaltungsoberfläche von fremforge im passenden Geltungsbereich an: Einstellungen → Secrets (Organisation) oder Repository → Einstellungen → Geheimnisse (Repository).

Schritt 3: GitLab CI → Forgejo Actions umstellen

Das ist der größte Schritt einer GitLab-Migration. GitLab-CI-Pipelines sind strukturell anders aufgebaut als Forgejo Actions: stages, jobs, extends, include, rules, artifacts und cache lassen sich nicht eins zu eins auf jobs, steps, needs und uses von GitHub Actions abbilden.

Es gibt keinen automatischen Konverter. Eine automatische Umstellung steht auf der Roadmap, abhängig von der Nachfrage der Kunden. Zum Start liefern wir Dokumentation und manuelle Umstellungsmuster für die üblichen Fälle.

Umstellungsmuster

Stages → Jobs mit needs:

GitLab CI gliedert Pipelines in aufeinanderfolgende Stages. Forgejo Actions gliedert sie in parallele Jobs mit expliziten DAG-Abhängigkeiten über needs:.

GitLab CI:

stages: [build, test, deploy]

build:
  stage: build
  script: make build

test:
  stage: test
  script: make test

deploy:
  stage: deploy
  script: make deploy

Entsprechung in Forgejo Actions (.forgejo/workflows/main.yaml):

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: make build

  test:
    needs: build
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: make test

  deploy:
    needs: test
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: make deploy

extends: → wiederverwendbare Workflows oder Composite Actions

extends: in GitLab CI erbt die Konfiguration eines Jobs. Forgejo Actions hat zwei Entsprechungen:

1. Wiederverwendbare Workflows (workflow_call), um ganze Jobs über Workflows hinweg zu erben.
2. Composite Actions (runs: using: composite), um Abfolgen von Steps zu erben.

Die Umstellung ist Handarbeit: Ermittle den übergeordneten Job hinter .extends: in GitLab, kopiere sein script: und Setup in eine Composite Action unter .forgejo/actions/<name>/action.yml und rufe sie in den nutzenden Workflows mit uses: ./.forgejo/actions/<name> auf.

Projektübergreifende Vorlagen mit include:

include: project: in GitLab CI holt CI-Konfiguration aus einem anderen Projekt. In Forgejo Actions gibt es keine direkte Entsprechung. Wiederverwendbare Workflows (uses: owner/repo/.forgejo/workflows/template.yaml@ref) kommen dem am nächsten und funktionieren innerhalb derselben fremforge-Organisation.

Gibt es bei der Migration gemeinsame Vorlagenprojekte (häufig in Organisationen mit CI-Plattformteams), migriere zuerst das Vorlagen-Repository und passe die uses:-Verweise in den nutzenden Repositorys bei deren eigener Migration an.

rules: und only:/except: → if:-Ausdrücke

GitLab CI hat drei sich überschneidende Mechanismen für die bedingte Ausführung von Jobs. Forgejo Actions verwendet dieselbe if:-Ausdruckssyntax wie GitHub Actions.

GitLab:

deploy:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success
    - when: never
  script: make deploy

Forgejo Actions:

deploy:
  if: github.ref == 'refs/heads/main'
  runs-on: fremforge
  steps:
    - uses: actions/checkout@v4
    - run: make deploy

artifacts: → upload-artifact / download-artifact

Artefakte in GitLab CI werden automatisch zwischen Stages weitergegeben. Forgejo Actions verlangt ein explizites actions/upload-artifact im erzeugenden Job und actions/download-artifact im nutzenden Job.

cache: → actions/cache

cache: in GitLab CI entspricht actions/cache@v4 mit derselben Semantik für Cache-Key und Restore-Keys.

services: → Sidecars in Steps starten (NICHT den services:-Block des Workflows)

services: aus GitLab CI (Sidecar-Postgres/-Redis usw.) lässt sich bei fremforge heute nicht in einen services:-Block übersetzen: Forgejo Actions unterstützt den services:-Block nur eingeschränkt. Die Deklarationen werden ohne Fehler gelesen, starten aber nie etwas, sodass dein Test sich mit localhost:5432 verbindet und fehlschlägt. Workflows, die auf den eingebauten services:-Block angewiesen sind, funktionieren nicht.

Der unterstützte Weg ist, den Sidecar explizit in einem Step zu starten. Docker ist auf dem Runner verfügbar (siehe Runner-Images), also funktioniert docker run -d postgres:16 in einem Setup-Step. Viel häufiger lässt man die Abhängigkeit direkt mit dem laufen, was das jeweilige Sprach-Ökosystem bietet (Testcontainers für Java, pytest-docker für Python, testcontainers-go usw.). Für Testtopologien mit mehreren Containern ist ein Aufruf von docker compose in der VM innerhalb eines Steps das übliche Muster.

Die Unterstützung des eingebauten services:-Blocks steht auf der Roadmap der Plattform. Bis sie kommt, lautet die Empfehlung für die Migration: Schreibe services:-Blöcke aus GitLab in docker run / docker compose / Testcontainers innerhalb von Steps um, nicht in services:-Blöcke von Forgejo.

Runner-Tags

tags: in GitLab CI wählt bestimmte Runner aus. In Forgejo Actions erreichst du dasselbe mit runs-on:. Die von fremforge gehosteten Runner tragen das Label fremforge (Betriebssystem und Toolchain des Runners unter Runner-Images). Eigene Runner können sich mit eigenen Labels registrieren, und runs-on: spricht sie über den Label-Namen an.

Hat sich deine GitLab CI auf bestimmte private Runner gestützt (tags: [gpu], tags: [macos], tags: [on-prem]), müssen diese eigenen Runner bei fremforge über die Registrierung eigener Runner eingerichtet werden. Die gehosteten Runner von fremforge sind ausschließlich Linux amd64 (siehe Runner-Images); GPU und macOS gibt es im Standardtarif nicht.

Schritt 4: OIDC-Föderation für Deployments

Deployen deine GitLab-CI-Pipelines in Cloud-Infrastruktur, ist es bei der Migration Best Practice, langlebige Zugangsdaten durch OIDC-Föderation zu ersetzen. fremforge unterstützt OIDC-Token-Föderation zu T Cloud Public nativ; für AWS, Azure und GCP funktionieren die üblichen Muster der OIDC-Föderation.

Einrichtung:

1. In der Verwaltungsoberfläche von fremforge: Einstellungen → Runner-OIDC-Föderation → Ziel hinzufügen.
2. Für T Cloud Public: Gib die URN der Ziel-Agency an. Der Runner-Workflow erhält ein kurzlebiges JWT mit eingeschränktem Geltungsbereich, dem die Agency in T Cloud Public vertraut und das sie gegen eingeschränkte Zugangsdaten tauscht.
3. Für AWS/Azure/GCP: Konfiguriere das OIDC-Vertrauen im IAM der Ziel-Cloud mit https://frem.sh/_app/runner/oidc als Aussteller (ein einziger globaler Aussteller für alle Mandanten; die Trennung pro Mandant wird über die Bedingung auf den Claim repository_owner erzwungen, das mit GitHub Actions kompatible Muster). Unter build/runners/oidc/ findest du den JWKS-Endpunkt, den vollständigen Satz an Claims und Beispiele für Vertrauensrichtlinien pro Cloud.

Nach der Einrichtung nutzen die Workflows die Föderation statt statischer Schlüssel. Jeder Runner-Job erhält unter $ACTIONS_ID_TOKEN_REQUEST_URL ein kurzlebiges OIDC-ID-Token und tauscht es beim Start des Jobs gegen eingeschränkte Zugangsdaten für T Cloud Public:

- name: Federate to T Cloud Public
  run: |
    OIDC_TOKEN="$(curl -sSf -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
      "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=tcloud-${ORG_SLUG}")"
    CREDS_JSON="$(curl -sSf -X POST \
      "https://iam.eu-de.otc.t-systems.com/v3.0/OS-FEDERATION/token-exchange" \
      -H 'Content-Type: application/json' \
      -d "{\"identity\":{\"id_token\":{\"id\":\"$OIDC_TOKEN\"}},\"scope\":{\"agency\":{\"name\":\"fremforge-deploy\",\"domain\":{\"name\":\"$TCLOUD_DOMAIN\"}}}}")"
    {
      echo "TCLOUD_AK=$(jq -r '.credential.access' <<<"$CREDS_JSON")"
      echo "TCLOUD_SK=$(jq -r '.credential.secret' <<<"$CREDS_JSON")"
      echo "TCLOUD_TOKEN=$(jq -r '.credential.securitytoken' <<<"$CREDS_JSON")"
    } >> "$GITHUB_ENV"

Eine Wrapper-Action, die den curl-Aufruf verbirgt, ist geplant; die Inline-Form oben hält den rohen OIDC-Vertrag sichtbar und funktioniert schon heute.

Lösche die zugehörigen statischen Zugangsdaten-Secrets sowohl in GitLab als auch in fremforge.

Schritt 5: SSH-Schlüssel neu registrieren

Gleicher Ablauf wie in Schritt 4 der GitHub-Migration. Jeder Entwickler fügt seinen öffentlichen SSH-Schlüssel seinem fremforge-Konto hinzu.

SSH-Zertifizierungsstellen (eine Funktion von GitLab EE) importierst du über <your-org>/_admin/auth-policy: Der Abschnitt zur SSH-CA liegt unter dem Schalter „SSH-Protokoll erlauben“ (seit dem 26.05.2026 Teil der Authentifizierungsrichtlinie). Es ist dieselbe Verwaltungsoberfläche wie bei der GitHub-Migration; Details zur Einrichtung im Abschnitt zur SSH-Zertifizierungsstelle.

Schritt 6: GitLab Pages → externes Hosting (keine Pages-Entsprechung in Forgejo)

fremforge bietet kein Pages-Produkt. Das Upstream-Forgejo hat kein Pages-Modul, und wir haben keines gebaut. Migrationen von GitLab Pages müssen woanders landen; wähle die Option, die zu deinem Fall passt:

1. Markdown-Dokumentation, die in einer Pages-Site auf Basis eines Repo-Wikis lag: Schalte im migrierten Repo das öffentliche Doku-Wiki von fremforge ein. Das Wiki unter frem.sh/<org>/<repo>/wiki[/...] liefert gerendertes Markdown mit anonymem Lesezugriff, pro Repo einschaltbar. Hinweis: Es liefert gerendertes Markdown, kein beliebiges statisches HTML/JS. Es deckt also Pages-Sites im Stil einer Dokumentation ab, nicht Pages-Deployments von Single-Page-Apps.

2. Statische HTML/JS-Sites (Single-Page-Apps, Ausgabe von Hugo / Jekyll / Astro): extern hosten und per CNAME von deiner eigenen Domain darauf zeigen. Sinnvolle, EU-freundliche Optionen sind Bunny Edge Storage + Bunny CDN (derselbe Stack, auf dem die eigene Marketing-Site von fremforge läuft), Cloudflare Pages, Netlify oder Vercel. Verbinde den Build wieder über Runner-Workflows von fremforge, die bei jedem Push deployen.

3. Nur eigene Domain: Hast du GitLab Pages bisher wegen des TLS-Zertifikats für die eigene Domain genutzt (statt wegen des Build-Schritts), richte dein DNS auf deinen externen Host aus und nutze die Runner-OIDC-Föderation von fremforge, um direkt aus dem Workflow zu deployen. Ein Proxy über fremforge ist nicht nötig.

Hast du eine nicht triviale GitLab-Pages-Pipeline (eigene CI, Weiterleitungen, Deployments pro Branch), schreib an support@frem.sh. Wir besprechen gern die passende Form des externen Hostings für deinen Fall, bevor du dich auf einen Migrationsplan festlegst.

Schritt 7: Integrationen von Drittanbietern neu verbinden

Die Integrationen von GitLab (Webhook-Ziele, Jira-Synchronisierung, Slack-Benachrichtigungen usw.) verbindest du genauso neu wie in Schritt 5 der GitHub-Migration. Die meisten Integrationen unterstützen Forgejo von Haus aus.

GitLab-spezifische Integrationen ohne direkte Entsprechung:

• Aggregation im GitLab Security Dashboard: Die Ansicht Befunde in der Verwaltungsoberfläche von fremforge erfüllt denselben Zweck für den mitgelieferten Supply-Chain-Stack.
• Value Stream Analytics / DORA-Metriken: fremforge liefert DORA-Metriken (Deployment-Häufigkeit, Durchlaufzeit, Änderungsfehlerrate, MTTR), siehe Org-Verwaltung → DORA. Ein externes Tool, das Webhook-Ereignisse und API-Abfragen auswertet, ist nicht nötig.

Schritt 8: Prüfen und stilllegen

Wie in Schritt 7 der GitHub-Migration:

1. Klonen, bauen, prüfen, dass die Tests durchlaufen.
2. Einen Beispiel-PR durch den Pre-Receive-Scanner, den Abhängigkeitsscanner und die Prüfung signierter Commits schicken.
3. Prüfen, dass Webhooks zugestellt werden.
4. Die SSO-Anmeldung für jeden Nutzer prüfen.
5. Die Dokumentation auf die neuen URLs aktualisieren.
6. Nach 30 Tagen erfolgreichem Betrieb die GitLab-Projekte archivieren (nicht löschen).

Typische Stolperfallen bei GitLab-Migrationen

Die Umstellung der Pipelines dauert länger als geschätzt.

Eine komplexe .gitlab-ci.yml mit vielen Stages, DAGs, extends:, include: und services: kann pro Repository einen halben Tag dauern, bis sie sauber portiert ist. Plane 2 bis 4 Stunden pro Pipeline mittlerer Komplexität ein. Die Kompatibilitätsmatrix unter docs.frem.sh/marketplace-compat konzentriert sich auf GitHub Actions; für Muster speziell aus GitLab CI nutze Schritt 3 dieser Anleitung und die Dokumentation von Forgejo Actions.

Genehmigungsregeln für Merge Requests

Die Genehmigungsregeln von GitLab (N Genehmigende verlangen, bestimmte Gruppen von Genehmigenden, Genehmigung anhand von Code-Ownern) entsprechen den Branch-Schutzregeln von Forgejo, aber mit geringerer Granularität. Hängt dein GitLab-Projekt von ausgefeilten Genehmigungsregeln ab (z. B. „andere Genehmigende für sicherheitskritische Pfade“), prüfe vor der Migration, ob das auf CODEOWNERS basierende Modell erforderlicher Reviewer in Forgejo ausreicht.

Funktionen von GitLab Premium/Ultimate

Für License Compliance von GitLab liefert fremforge eine direkte Entsprechung: Das Lizenz-Scanning führt bei jedem PR die Lizenzerkennung von Trivy aus, ordnet jede Abhängigkeit nach SPDX einer Richtlinienkategorie zu und kann den Merge bei verbotenen oder eingeschränkten Lizenzen blockieren; zu sehen unter Sicherheit › Befunde › Lizenzen. Für den Rest der Sicherheitssuite von GitLab Ultimate (DAST, Fuzz-Tests, SAST mit den Schweregradregeln von Ultimate, Dependency Firewall, Security Dashboards auf Gruppenebene) bietet fremforge keine direkten Entsprechungen. SAST (OpenGrep), das Scannen von Abhängigkeiten und CVEs (osv-scanner) und das Container-Scanning (Trivy) decken aber die häufigsten Fälle ab. Was wir abdecken und was ausdrücklich nicht, steht im Beitrag zur KI-Haltung auf www.frem.sh und auf der Produktseite von fremforge.

GitLab-Runner mit Tags für Compliance-Kontexte

Tags von GitLab-Runnern wie compliance, restricted-network oder no-internet werden oft für Runner verwendet, die das öffentliche Internet nicht erreichen können. Die gehosteten Runner von fremforge erfüllen diese Anforderung von vornherein: uses:-Anweisungen werden über die reinen EU-Action-Spiegel unter https://frem.sh/<owner>/<repo> aufgelöst (die maßgebliche Beschreibung steht auf der GitHub-Migrationsseite §Schritt 3: Actions-Workflows anpassen), und ausgehender Verkehr über den Proxy ist auf diesen Spiegel, gespiegelte Paket-Registrys und die ausgehenden Webhooks des Kundenmandanten beschränkt. Verlangt dein Compliance-Kontext Runner ganz ohne Internet, betreibe eigene Runner in deinem Netz und richte sie auf den Registrierungs-Endpunkt für Runner von fremforge aus.

Hilfe bekommen

Schreib an support@frem.sh mit dem Betreff MIGRATION, GITLAB, <your-specific-issue>. Kunden aus der frühen Phase haben direkten Zugang zum Entwicklungsteam.

Siehe auch: Anleitung zur GitHub-Migration · Anleitung zur Azure-DevOps-Migration · Kompatibilitätsmatrix der Top-20-Marketplace-Actions · Checkliste vor der Migration.