Die meisten Migrationsprojekte, die scheitern, scheitern nicht an der Zieltechnologie. Sie scheitern am Übergang — der unordentlichen Zwischenphase, in der alte und neue Systeme koexistieren, Identitäten zwei Welten überspannen und Daten sich bewegen müssen, ohne dass jemand es merkt.

Dieser Artikel ist der praktische Begleiter zu Warum digitale Souveränität jetzt ein IT-Planungsfaktor ist. Wo jener Artikel das Warum behandelt, geht es hier um das Wie: eine Sechs-Schritte-Methodik für den Wechsel von proprietärer zu Open-Source-Infrastruktur in realen, heterogenen Umgebungen — ohne Betriebsunterbrechung.

Warum Migrationen scheitern

Die typischen Fehlerbilder haben nichts mit Softwarequalität zu tun:

  • Identitätschaos: Benutzer können sich nicht anmelden oder haben unterschiedliche Zugangsdaten in Alt- und Neusystem.
  • Berechtigungsdrift: Zugriffsrechte gehen verloren, werden dupliziert oder still verändert.
  • Datenlücken: Dateien werden migriert, aber Metadaten, Versionshistorie oder Freigaberechte nicht.
  • Betriebsblindstellen: Das neue System ist live, aber Monitoring, Backups und Alerting sind noch nicht eingerichtet.
  • Alles-oder-nichts-Zeitpläne: Der Plan setzt einen sauberen Cutover voraus. Die Realität erfordert Monate des Parallelbetriebs.

Jedes dieser Szenarien ist vermeidbar — wenn der Übergang als vollwertiges Engineering-Problem behandelt wird, nicht als Nachgedanke.

Schritt 1: Inventur und Abhängigkeitsmapping

Bevor irgendein Tool gewählt wird, schaffen wir Klarheit über den Bestand:

  • Kritische Systeme: Welche Dienste hätten bei Ausfall unmittelbare geschäftliche Auswirkungen?
  • Datenstandorte: Wo liegen Daten? Welche Flüsse existieren zwischen Systemen?
  • Vertrags- und Lizenzbindungen: Welche Vereinbarungen binden — und wann laufen sie aus?
  • Schnittstellenabhängigkeiten: Welche Systeme müssen miteinander sprechen? Welche Protokolle und Formate sind zwingend?

Das Ergebnis ist eine priorisierte Migrationskarte: Quick Wins (geringes Risiko, hoher Nutzen), mittelfristige Ziele (erfordern Planung) und langfristige Ablösungen (komplex, hohe Abhängigkeit).

Diese Inventur ist keine einmalige Übung. Sie wird zum lebenden Dokument, das jede folgende Entscheidung leitet.

Schritt 2: Zielarchitektur mit Hybridbetrieb

Die Zielarchitektur muss eine Übergangsphase unterstützen. Das bedeutet, Hybridbetrieb von Anfang an einzuplanen — nicht als Workaround, sondern als bewusste Architekturentscheidung.

Leitprinzipien:

  • Offene Formate für allen Datenaustausch — damit Informationen fließen, unabhängig davon, welches System sie erzeugt hat.
  • Standardisierte APIs zwischen Komponenten — damit Ablösungen eingebaut werden können, ohne Integrationen neu zu bauen.
  • Saubere Netzwerk- und Identity-Grenzen — damit Alt- und Neusysteme ohne Sicherheitskompromisse koexistieren können.

Die entscheidende Nebenbedingung: Hybridbetrieb muss zeitlich begrenzt sein. Ausstiegsdaten definieren. Ohne sie betreibt man zwei Systeme auf Dauer — was schlimmer ist als jedes einzelne.

Schritt 3: Identity zuerst

Stabile Identitäten sind das Fundament jeder Migration. Wenn sich Benutzer nicht nahtlos in alten und neuen Systemen authentifizieren können, ist alles andere irrelevant.

Wir bauen oder konsolidieren einen Identity Provider (IdP), sodass Single Sign-On (SSO) von Anfang an in beiden Welten funktioniert.

Das hat einen strukturellen Vorteil über den Komfort hinaus: Es entkoppelt Systemmigrationen von der Benutzerverwaltung. Man kann eine Kollaborationsplattform, einen Fileserver oder eine Office-Suite ablösen, ohne jedes Mal die Identity-Schicht anzufassen. Migrationen werden modular statt monolithisch.

Gängige Muster:

  • Active Directory und LDAP in ein einheitliches Verzeichnis mit Föderationsfähigkeit konsolidieren.
  • SAML- oder OIDC-Föderation zwischen On-Premises- und Cloud-Identitätsquellen implementieren.
  • Sicherstellen, dass jedes neue System über den zentralen IdP angebunden wird, bevor es in Produktion geht.

Schritt 4: Datenmigration mit Verifikation

Datenmigration ist der Punkt, an dem Versprechen auf Realität treffen. Wir migrieren inkrementell, nicht in einem einzigen Batch:

  • Inkrementelle Syncs mit definierten Prüfpunkten — nicht „alles kopieren und hoffen."
  • Verifikationsroutinen: Stichproben, Hash-Vergleiche, Validierung des Berechtigungs-Mappings.
  • Metadaten-Erhalt: Dateidaten, Eigentümerschaft, Freigabeberechtigungen, Versionshistorie — alles verifiziert.

Jeder Migrationsplan enthält Rollback- und Fallback-Szenarien. Nicht als theoretisches Sicherheitsnetz, sondern als getestete, dokumentierte Verfahren mit definierten Auslösern: Wenn X schiefgeht, kehren wir innerhalb von Y Minuten zu Z zurück.

Das Ziel ist nicht Perfektion beim ersten Versuch. Es ist Vorhersagbarkeit: genau wissen, was migriert wurde, was nicht — und was dagegen zu tun ist.

Schritt 5: Betrieb und Sicherheit als erstklassige Anforderungen

Ein System, das „läuft", ist nicht dasselbe wie ein System, das betrieben wird. Vor jedem Cutover muss Folgendes stehen:

  • Monitoring und Alerting: Dashboards, Schwellenwerte, Eskalationswege — für das neue System, nicht nur das alte.
  • Backup und Restore: Getestet. Nicht „konfiguriert" — tatsächlich getestet, mit zeitgesteuerten Restore-Übungen.
  • Patch- und Update-Strategie: Wer spielt Sicherheitsupdates ein? Wie schnell? Wie sieht das Rollback bei einem fehlerhaften Patch aus?
  • Berechtigungsmodelle: Dokumentiert, geprüft und mit der Sicherheitsrichtlinie der Organisation abgestimmt.
  • Logging und Auditing: Compliance-taugliches Logging ab Tag eins, nicht nachträglich ergänzt.
  • Klare Verantwortlichkeiten: Wer ist in der Übergangsphase wofür zuständig? Das muss schriftlich festgehalten und kommuniziert sein.

Das ist kein Overhead. Es ist der Unterschied zwischen einer Migration und einem Incident.

Schritt 6: Cutover-Muster

Die Cutover-Strategie hängt vom Dienst und seiner Unterbrechungstoleranz ab.

Zero-Downtime / Blue-Green

Wenn der Use-Case es hergibt, nutzen wir Zero-Downtime-Muster. Bei einem Blue/Green-Deployment laufen alte und neue Umgebung gleichzeitig. Der Traffic wird schrittweise umgeleitet — erst für eine Testgruppe, dann breiter, dann vollständig.

Der entscheidende Vorteil: Wenn etwas schiefgeht, leitet man den Traffic zurück. Kein Datenverlust, kein langer Ausfall.

Geplante Wartungsfenster

Für Systeme, bei denen Parallelbetrieb nicht möglich ist (z. B. bestimmte Datenbankmigrationen), definieren wir enge Wartungsfenster mit:

  • Vorab kommunizierten Zeitplänen an alle Betroffenen.
  • Schritt-für-Schritt-Runbooks mit definierten Abbruchkriterien.
  • Getesteten Rollback-Verfahren mit Zeitschätzungen.

Canary Deployments

Bei Diensten mit großer Nutzerbasis lassen Canary Deployments uns das neue System einer kleinen Gruppe aussetzen, Feedback und Metriken sammeln und erst bei bestätigtem Vertrauen erweitern.

Typische Migrationspfade

Je nach Organisation wählen wir pragmatische Einstiegspunkte:

  • Collaboration / Files / Groupware: Mit einer Abteilung oder einem Projektteam starten. E-Mail, gemeinsame Laufwerke und Kalender in Stufen migrieren. Nutzerfeedback messen, bevor man erweitert.
  • Virtualisierung / Compute: Auf KVM-basierte Plattformen wechseln. Workloads inkrementell migrieren, beginnend bei unkritischen Umgebungen.
  • Dev / CI: Reproduzierbare Builds, offene Artefakt-Repositories und Secrets-Management standardisieren. Oft der einfachste Einstieg, weil Entwicklerteams an Veränderung gewöhnt sind.
  • Monitoring / Logging: Observability auf dem neuen Stack etablieren, bevor Produktions-Workloads migriert werden. Man muss sehen, was passiert, bevor man darauf reagieren kann.

Der gemeinsame Nenner: Migration in Etappen, mit messbaren Kriterien in jeder Phase — Stabilität, Kosten, Risiko, Nutzerfeedback.

Was Entscheider davon haben

Für Geschäftsführung und IT-Leitung bringt eine gut umgesetzte OSS-Migration:

  • Planbare Kosten — lizenzfreie Software mit transparenten, kalkulierbaren Support-Verträgen statt undurchsichtiger jährlicher Steigerungen.
  • Risikoreduktion — weniger Einzelanbieter-Abhängigkeiten, auditierbarer Code und vollständige Betriebstransparenz.
  • Verhandlungsspielraum — glaubhafte Alternativen stärken die Position in jedem Anbietergespräch, auch für Dienste, die man behält.
  • Wissen im Haus — dokumentierte Architektur, Betriebs-Runbooks und Mitarbeitende, die den gesamten Stack verstehen, statt Anbieter-Tickets zu verwalten.

Das sind keine Wunschvorstellungen. Es sind die dokumentierten Ergebnisse von Organisationen wie Schleswig-Holstein, das nach der Migration von 80 % der Arbeitsplätze auf Open-Source-Alternativen geschätzte 15 Millionen Euro pro Jahr einspart.

Wie es losgeht

Wenn Sie vor einer OSS-Umstellung stehen — oder erstmal Abhängigkeiten und Optionen bewerten wollen — ist ein strukturierter Workshop ein guter Einstieg: Inventur, Zielarchitektur, Migrationspfade, Aufwand, Kosten und Risiko.

Wir arbeiten an der Schnittstelle von Betrieb und Strategie. Für Admins liefern wir klare technische Pfade und stabile Betriebsmodelle. Für Entscheider liefern wir nachvollziehbare Roadmaps mit Risiken, Kosten und Prioritäten.

Kontakt aufnehmen — wir besprechen Ihre Situation.

Weiterführende Artikel

Quellen