Migration und Transformation: Zwei Fliegen mit einer Klappe schlagen

Von Mäusen und Migrationen

Transformationen sind noch riskantere Vorhaben, da sie auf Widerstand gegen Veränderungen stoßen. Wer bei klarem Verstand würde also eine Migration und eine Transformation gleichzeitig durchführen?

Tatsächlich empfehlen wir bei Eficode immer, diesen mutigen Schritt zu gehen und jede Migration als Chance für Veränderungen zu nutzen – auf bessere Tools umzusteigen, Prozesse zu verbessern, die Sicherheitslage zu stärken und vieles mehr. Jede Migration, die nicht zumindest ein Element der Transformation enthält, ist eine verpasste Chance, die eigene Arbeitsweise zu verbessern.

Diese Bereiche könnt ihr bei einer Migration fast immer verbessern:

• Automatisierung: In den Prozessen eines großen Unternehmens gibt es kaum jemals zu viel Automatisierung.

• Sicherheit: Angesichts der sich ständig wandelnden Cybersicherheitslandschaft ist es unwahrscheinlich, dass eure Sicherheitslage jemals zu gut wird.

• Prozessoptimierung: Engpässe oder Redundanzen in Workflows identifizieren und sie vereinfachen, um schneller auszuliefern und die Zusammenarbeit zu verbessern.

• Kultureller Wandel: Neue Arbeitsweisen fördern, Innovationen vorantreiben und Teams dabei unterstützen, neue Praktiken und Tools effektiv einzuführen.

Klingt verlockend? Sicherlich ist das teurer, oder? Nun, ja und nein. Veränderungen zu planen, kostet immer Aufwand und erfordert Ressourcen, ist aber auch eine Investition in zukünftige Produktivitätsgewinne. Die Kombination aus Migration und Transformation erhöht jedoch nicht zwangsläufig die Komplexität des Vorhabens. Mit einer guten Bestandsaufnahme, einem klaren Verständnis des gewünschten Zielzustands, angemessenen Ressourcen und guter Vorausplanung kann eine Migrationstransformation die Arbeitsweise und Leistung eurer Organisation verbessern.

Bei einer unserer jüngsten Migrationstransformationen haben wir einem Kunden geholfen, einen höheren Reifegrad im Platform Engineering zu erreichen, seine Systeme für Identity and Access Management weiterzuentwickeln und Self-Service-Migrationstools in seine Plattform zu integrieren – bei minimalen Ausfallzeiten seiner kritischen Systeme. Diese Geschichte möchten wir mit all unseren Kunden teilen.

Migration als Teil des Platform Engineering

Beim betreffenden Kunden gab es einen abgelaufenen Bitbucket Server, der schnellstmöglich zu GitHub Enterprise Cloud mit Enterprise Managed User migriert werden musste.

Für Bitbucket gab es weder ein zentralisiertes Zugriffsmanagement noch eine Governance-Richtlinie. Außerdem wurden die gesamte Administration des Produkts und die Benutzerverwaltung manuell durchgeführt. Kurz gesagt: das typische Chaos. Ein Tool, das jahrelang vernachlässigt worden war, hatte einen Zustand erreicht, in dem es nicht nur die Entwicklungsarbeit behinderte, sondern auch Compliance- und Sicherheitsrisiken mit sich brachte.

Der gewünschte Zielzustand des Kunden war der Umstieg auf GitHub bei gleichzeitiger Umsetzung grundlegender Änderungen an der Strukturierung der Codebase und der Benutzerverwaltung:

• Migration vom veralteten Bitbucket zu GitHub Enterprise Cloud mit Enterprise Managed Users.

• Einführung von C4, einem Framework für Softwarearchitektur.

• Implementierung eines IAM-Modells auf Basis von Zero-Trust-Konzepten wie Role Based Access Control, Just Enough Access und der vollständigen Verwaltung eines Identity Lifecycle.

Bei über 4.000 Repositories und 58 Entwicklerteams gibt es viel Veränderung auf einmal umzusetzen. Doch ein Jahr nach Beginn der Arbeit hat der Kunde den gewünschten Zielzustand erreicht – und das problemlos und ohne größere Katastrophen.

Migration im Self-Service

Angesichts der Komplexität des Migrations- und Transformationsprozesses wollten wir so viel wie möglich standardisieren und automatisieren. Deshalb entschieden wir uns, die vorhandenen Tools des Kunden zu nutzen – konkret Backstage, Platform API, Entra ID und MyAccess. Die bestehenden Migrationstools wurden in die vom Kunden verwalteten Tools integriert, um in der internen Entwicklungsplattform Backstage des Kunden eine „Migration im Self-Service“ zu ermöglichen. Die Endnutzer mussten in einer von Backstage bereitgestellten GUI die erforderlichen Informationen eingeben, um eine End-to-End-Pipeline auszulösen, die den gesamten Lifecycle der Repository-Migration abwickelte. Die automatisierte Migrationspipeline übernahm anschließend alles von Anfang bis Ende:

• Migration von Git-Repositories und zugehörigen Metadaten (Issues, PRs, Anhänge usw.) von Bitbucket zu GitHub gemäß dem C4-Modell.
  Versetzen aller Branches im Quell-Repository während der Migration in den schreibgeschützten Modus.
  Konfliktlösung während der Migration.
  Migration der Inhalte aus dem Large File Storage.
  Entzug der Benutzerzugriffe für alle Benutzer und Gruppen in der Bitbucket-Umgebung (effektive Sperrung der Quellumgebung).
  Umbenennung des Repositorys durch Hinzufügen eines Präfixes zum Repository-Namen vor der Verschiebung in das Archivierungsprojekt (z. B. PRJ.<repo_name>).

• Validierung der Datenintegrität des Repositorys nach der Migration durch Abgleich des jeweils neuesten Commit-Hash-Werts jeder Branch zwischen Quell- und Ziel-Repository.

• Erstellung RBAC-konformer GitHub-Teams und Entra-ID-Gruppen, die anschließend in der GitHub-Umgebung bereitgestellt wurden, um Benutzer reibungslos in die neue Umgebung zu migrieren.

• Protokollierung des gesamten Prozesses in Grafana.

• Hinzufügen der richtigen Einstellungen zum GitHub-Repository im Rahmen des Prozesses nach der Migration.

• Während der Migration wurden alle Branches im Quell-Repository in den schreibgeschützten Modus versetzt.

• Konfliktlösung im laufenden Betrieb.

• Migration von Large File Storage-Inhalten.

• Allen Benutzern und Gruppen in der Bitbucket-Umgebung wurden die Zugriffsrechte entzogen (effektive Sperrung der Quellumgebung).

• Das Repository wurde umbenannt, um dem Repo-Namen vor der Verschiebung in das Archivierungsprojekt ein Präfix hinzuzufügen (z. B. PRJ.<repo_name>).

Vor den Produktionsmigrationen wurde der gesamte Migrationsprozess umfassend getestet und dokumentiert, um die Migrationen in großem Umfang zuverlässig durchführen zu können. Während des Migrationsprozesses stand Support zur Verfügung, um mögliche Probleme vorsorglich zu beheben. Dabei traten keine wesentlichen Fehler auf; lediglich einige wenige Probleme wurden erkannt und alle innerhalb von 24 Stunden behoben.

Dadurch wurden nicht nur die Kundendaten aus einem Legacy-Tool in eine neue GitHub Enterprise Cloud migriert, sondern dies geschah auch mit nahezu keinen Ausfallzeiten und Unterbrechungen.

Gleichzeitig wurde ein kultureller Wandel umgesetzt. Strenge Zugriffskontrollen beschränkten Aktionen wie das Erstellen von Repositories auf Service Accounts (SAs) und Organisationsadministratoren. So entstand ein zentralisiertes Governance-Modell auf Grundlage von Zero-Trust-Prinzipien.

Benutzer müssen nun Anfragen über MyAccess einreichen, um repositorybezogene Aktionen auszuführen. Das Löschen von Repositories wurde eingeschränkt und ist nur über einen formalen Antrags- und Prüfprozess möglich. Auch der Zugriff auf Repositories muss beantragt werden, damit Berechtigungen effektiv verwaltet werden können. Insgesamt ist alles automatisiert, zentralisiert, überwacht und protokolliert.

Nach der Migration

Das Projekt hielt, was es versprach: Die Kundendaten wurden termingerecht von Bitbucket zu GitHub migriert, ohne den Geschäftsbetrieb zu beeinträchtigen. Darüber hinaus wurden zahlreiche weitere ebenso wichtige Transformationen umgesetzt.

Verbesserte Sicherheits- und Compliance-Position

Die Prozesse für Identity and Access Management wurden vollständig überarbeitet. Sie basieren nun auf Zero-Trust-Prinzipien. Zusammen mit der Automatisierung der IAM-Prozesse stärken sie die Sicherheitsposition des Unternehmens und unterstützen die Einhaltung relevanter Frameworks wie ISO 270001 und NIS2.

Automatisierung von IT-Prozessen

Ein wesentlicher Bestandteil des Migrationsprozesses war der Aufbau von Automatisierung für die Benutzerbereitstellung und die Einrichtung der für die Entwicklungsarbeit benötigten Ressourcen.

Die neu etablierten automatisierten Prozesse fördern Konsistenz, Effizienz und Sicherheit. Sie heben die DevSecOps-Standards an und geben dem DevSecOps-Team mehr Zeit für Aufgaben mit hohem Mehrwert, statt wiederkehrende Routineaufgaben wie das Erstellen von Repositories oder Anfragen zur Benutzerverwaltung zu erledigen.

Organisatorischer Wandel

Die Migration wurde genutzt, um einen Paradigmenwechsel im Architektur-Framework für Software umzusetzen, Entwicklungspraktiken zu verbessern und den umfangreichen Codebestand besser verwaltbar und verständlich zu machen.

Stärkere Ausrichtung auf Platform Engineering

Der Migrationsprozess basierte auf bestehenden Tools der Entwicklerplattform (Backstage, Platform API), die umfassend genutzt wurden. Dadurch erreichte das Unternehmen einen neuen Reifegrad im Platform Engineering.