In vielen Roadmaps taucht gerade ein Begriff wieder auf: digitale Souveränität.

Der politische Druck nimmt zu – unter anderem, weil das EU-Parlament mehr Unabhängigkeit von US-Infrastrukturen und mehr europäische Open-Source-Software (OSS) fordert. Gleichzeitig zeigt die Debatte: Es geht nicht um Symbolpolitik, sondern um Risiko- und Kostensteuerung im IT-Betrieb – besonders dort, wo ein Wechsel nicht „auf der grünen Wiese" stattfindet, sondern mitten im laufenden Geschäft.

Dieser Beitrag erklärt, wie wir bei do IT smart. OSS-Migrationen in realen, heterogenen Umgebungen umsetzen: ohne Big-Bang, ohne Produktivitätsbruch – und mit einem Übergangsbetrieb, der für Admins ebenso funktioniert wie für Entscheider.

Warum das Thema gerade hochkocht

Drei Treiber sehen wir aktuell besonders häufig:

1) Recht & Compliance

Globale Anbieterstrukturen bringen Themen wie CLOUD Act oder transatlantische Streitfragen rund um Regulierung (z. B. Digital Services Act (DSA)) auf die Agenda – teils unabhängig davon, ob man „Cloud" nutzt oder nicht.

2) Kosten & Abhängigkeiten

Bei Lizenzen, Datenegress, Support-Bindungen und Roadmap-Abhängigkeiten entstehen klassische Vendor-Lock-in-Effekte.

3) Beschaffung & Standards

Politik und Verwaltung diskutieren stärker über offene Standards und Interoperabilität – inklusive „Public Money, Public Code".

Die praktische Realität: Migration passiert selten „rein" oder „in einem Schritt"

Viele Organisationen sind heute ein Mix aus:

  • Windows-/Linux-Servern, Legacy-Anwendungen, Fachverfahren
  • mehreren Identity-Welten (AD, LDAP, Cloud-Identitäten)
  • Mail/Groupware, Fileshares, Collaboration, Telefonie, Clients
  • Cloud- und On-Prem-Anteilen, oft parallel

Genau hier scheitern Umstellungen häufig – nicht an Technik, sondern an Übergängen: Berechtigungen, Identitäten, Datenflüsse, Fachanwendungen, Betriebsprozesse.

Unsere Leitfrage ist daher nicht: „Wie ersetzen wir alles?" Sondern: „Wie erreichen wir das Ziel, ohne den Betrieb zu gefährden?"

Unser Ansatz bei do IT smart.: „Sanft migrieren" heißt „stabil weiterbetreiben"

1) Inventur + Abhängigkeiten sichtbar machen

Wir starten nicht mit Tool-Debatten, sondern mit Klarheit:

  • Welche Systeme sind kritisch?
  • Wo liegen Daten? Welche Datenflüsse existieren?
  • Welche Verträge/Lizenzen binden euch?
  • Welche Schnittstellen sind zwingend?

Ergebnis: eine priorisierte Migrationskarte (Quick Wins, mittelfristig, langfristig).

2) Zielbild, das Übergänge erlaubt (statt „perfekt oder gar nicht")

Wir planen so, dass ein Hybridbetrieb möglich ist – und nicht zum Dauerzustand wird.

Typisch: offene Formate, standardisierte APIs, saubere Netzwerk- und Identity-Grenzen.

3) Identity zuerst – weil alles daran hängt

Stabile Identitäten sind der Schlüssel. Wir bauen oder konsolidieren einen Identity Provider (IdP) so, dass Single Sign-On (SSO) in Alt- und Neuwelt funktioniert.

Damit werden Migrationen „entkoppelt": Man kann Systeme wechseln, ohne jedes Mal Benutzerverwaltung neu zu erfinden.

4) Datenmigration ohne Überraschungen

Wir migrieren Daten schrittweise, mit Prüfroutinen (Stichproben, Hashes, Rechte-Mapping).

Wichtig: Der Plan enthält immer Rollback und Fallback, nicht nur „Go Live".

5) Betrieb & Security als erstklassige Anforderungen

„Es läuft" reicht nicht. Wir liefern:

  • Monitoring/Alerting, Backups, Restore-Tests
  • Patch- und Update-Strategien
  • Berechtigungsmodelle, Logging/Auditing
  • klare Verantwortlichkeiten in der Übergangsphase

6) Cutover ohne Stillstand, wo es möglich ist

Wenn der Use-Case es hergibt, nutzen wir Zero-Downtime-Muster, etwa Blue/Green.

Wenn nicht möglich: definierte Wartungsfenster, Kommunikation, Wiederanlaufpläne.

Typische Migrationspfade (praxisnah, ohne Dogma)

Je nach Organisation wählen wir sinnvolle Einstiegspunkte:

  • Collaboration / Files / Groupware: erst Teilbereiche, dann breiter Rollout
  • Virtualisierung/Compute: z. B. KVM-basierte Plattformen, danach Workload-Verlagerung
  • Dev/CI: Reproduzierbare Builds, Artefakt-Handling, Secrets, Deployments
  • Monitoring/Logging: Transparenz schaffen, bevor man umbaut

Der gemeinsame Nenner: Migration in Etappen, mit messbaren Kriterien (Stabilität, Kosten, Risiko, Nutzerfeedback).

Was Entscheider davon haben (ohne IT-Märchen)

  • Planbare Kosten statt Lizenz-/Roadmap-Überraschungen
  • Risikoreduktion durch weniger Abhängigkeiten und transparenten Betrieb
  • Mehr Verhandlungsspielraum (auch gegenüber Dienstleistern)
  • Wissen im Haus: dokumentierte Architektur, Prozesse, Runbooks

Wie wir arbeiten

do IT smart. spricht beide Welten: Betrieb/Administration und Management/Strategie.

  • Für Admins: klare technische Pfade, saubere Übergänge, stabile Betriebsmodelle
  • Für Entscheider: nachvollziehbare Roadmaps, Risiken, Kosten, Compliance, Prioritäten

Wenn ihr vor einer OSS-Umstellung steht – oder „erstmal nur" die Abhängigkeiten und Optionen sauber bewerten wollt – ist ein guter Start ein gemeinsamer Workshop: Ist-Zustand, Zielbild, Migrationspfade, Aufwand/Kosten/Risiko.

Quellen & weiterführende Links