Die Kieler Nachrichten berichteten am 12. August 2025 unter dem Titel „Das Land will weg von Microsoft“ über einen tiefgreifenden Strategiewechsel der Landesregierung Schleswig-Holsteins. Demnach soll die Landesverwaltung – einschließlich Polizei, Justiz und Ministerien – in den kommenden Jahren konsequent von proprietärer Microsoft-Software auf Linux-basierte Betriebssysteme und quelloffene Anwendungen umgestellt werden. Bereits eingeführte Open-Source-Komponenten wie LibreOffice, Open-Xchange (E-Mail), Nextcloud (Dateispeicher) und Jitsi/OpenTalk (Videokonferenzen) sollen landesweit Standard werden. Als strategische Ziele werden digitale Souveränität, Kostensenkung durch Wegfall von Lizenzgebühren sowie eine größere Unabhängigkeit von US-amerikanischen Technologiekonzernen genannt.
Der Artikel verweist zugleich auf aktuelle technische Schwierigkeiten – unter anderem eine E-Mail-Störung – und weist darauf hin, dass Schleswig-Holstein als einziges Bundesland diesen Weg vollständig beschreitet. Damit stellt sich die Frage, ob dieser „Alleingang“ ökonomisch tragfähig und politisch durchhaltefähig ist.

Besondere Aufmerksamkeit verdient im Rahmen der geplanten Migration der Landes-IT die Justiz, sollte die Umstellung auch dort vollzogen werden.

Neben der vollständigen Umstellung der Arbeitsplatzumgebungen in Gerichten, Staatsanwaltschaften und Justizverwaltungen sind auch sicherheitskritische Übertragungswege wie das „besondere elektronische Anwaltspostfach“ (beA) betroffen. Zwar existieren inzwischen Linux-kompatible Versionen der beA-Client-Software, doch bestehen Unterschiede im Supportumfang und in den Releasezyklen gegenüber Windows. Hinzu kommt, dass zahlreiche Fachverfahren der Justiz bislang auf Windows-Architekturen und Microsoft-Frameworks basieren. Diese Abhängigkeiten erfordern entweder aufwendige Anpassungen oder den Parallelbetrieb virtueller Windows-Umgebungen. Für den fristgebundenen elektronischen Rechtsverkehr bedeutet dies, dass technische Mängel oder Verzögerungen in der Linux-Umsetzung unmittelbare verfahrensrechtliche Folgen haben können. Die landesweite Migration in Schleswig-Holstein muss daher nicht nur wirtschaftlich und organisatorisch, sondern gerade auch unter justizieller Funktionssicherung betrachtet werden.

1. Historische Referenz: Erfahrungen aus dem Münchener „LiMux“-Projekt

Das LiMux-Projekt der Stadt München (2003–2013) gilt als international beachtetes Open-Source-Vorhaben. Es zeigte:

• Technische Machbarkeit: Über 15.000 Arbeitsplätze wurden erfolgreich auf Linux und LibreOffice migriert. Das Vorlagensystem „WollMux“ funktionierte im Massenbetrieb stabil.

• Lizenzkosteneinsparungen: München und andere Städte (z. B. Toulouse) dokumentierten deutliche Einsparungen im Millionenbereich.

• Probleme: Heterogene IT-Strukturen, Kompatibilitätsprobleme mit proprietären Fachverfahren und eine politische Kehrtwende führten 2017 zur Rückkehr zu Windows. Die doppelte Kostenbelastung aus Migration und Rollback verdeutlicht, dass technische Umstellung ohne stringente Governance und Fachanwendungsstrategie scheitern kann.

Die zentrale Lehre lautet: Ein Open-Source-Umstieg ist nur nachhaltig, wenn er mit klarer Governance, vollständiger Fachverfahrensstrategie und stabiler politischer Unterstützung flankiert wird.

2. Ökonomische Analyse des Alleingangs in Schleswig-Holstein

2.1 Potenzielle Nutzen

• Lizenzkosteneinsparung: Wegfall laufender Microsoft-Lizenzgebühren, bei landesweiten Umstellungen potenziell mehrere Millionen Euro jährlich.

• Vendor-Lock-in-Reduktion: Mehr Unabhängigkeit von Preisanpassungen und Produktentscheidungen proprietärer Anbieter.

• Transparenz und Auditierbarkeit: Offener Quellcode ermöglicht Sicherheitsprüfungen und Anpassungen.

2.2 Kosten- und Risikofaktoren

• Migrationskosten (CAPEX): Daten- und Vorlagenmigration, Anpassung oder Ersatz von Fachverfahren, Schulungsaufwand.

• Dual-Stack-Kosten: Parallelbetrieb von Windows- und Linux-Systemen während der Übergangsphase kann Lizenzvorteile erheblich reduzieren.

• Produktivitätseinbußen: Temporäre Effizienzverluste durch Lernkurven und Kompatibilitätsfragen.

• Interoperabilitätsaufwand: Zusammenarbeit mit externen Behörden und Institutionen, die weiterhin Microsoft-Formate nutzen, erfordert Konvertierungs- und Testaufwand.

• Markt- und Supportrisiken: Eingeschränkte Anbieterbasis für Open-Source-Services im Behörden-SLA-Standard kann in der Anfangsphase Kosten und Ausfallrisiken erhöhen.

2.3 Alleingangs-Besonderheiten

Da Schleswig-Holstein ohne andere Bundesländer migriert, fehlen Skaleneffekte und geteilte Entwicklungskosten. Gleichzeitig steigt die Abhängigkeit von internen Strukturen und wenigen spezialisierten Dienstleistern. Politisch bedeutet dies, dass Ausfälle oder Projektverzögerungen nicht von einer größeren Open-Source-Community auf Länderebene abgefedert werden.

3. Risikomanagement und Erfolgsfaktoren

• Fachanwendungsstrategie: Frühzeitige Portierung oder Ablösung proprietärer Verfahren mit verbindlichen Terminen.

• Begrenzung der Dual-Stack-Phase: Klare Sunset-Termine, finanziell quantifizierte Mehrkosten pro Monat.

• Governance und Audit: Verbindliche Meilensteine, externe Projektprüfung, transparente Erfolgskriterien.

• Nutzerakzeptanz: Rollenbasierte Schulungen, Helpdesk mit klaren Service-Level-Agreements, Multiplikatoren-Netzwerk in der Verwaltung.

• Politische Resilienz: Absicherung des Projekts durch gesetzliche Vorgaben oder Haushaltsvermerke, um kurzfristige Kurswechsel zu verhindern.

4. Schlußfolgerung

Der in den Kieler Nachrichten skizzierte Strategiewechsel ist ambitioniert. Die positiven Referenzen aus München und Toulouse zeigen, dass Kosteneinsparung und technologische Unabhängigkeit erreichbar sind.

Ebenso klar ist jedoch: Ohne striktes Risikomanagement, klare Migrationspfade und politische Langfristbindung ist der finanzielle Vorteil schnell gefährdet – im schlimmsten Fall durch ein kostspieliges Rollback, wie es München erlebt hat.
Schleswig-Holstein steht daher vor der Herausforderung, nicht nur technisch, sondern vor allem organisatorisch und politisch konsequent zu liefern.

Der Umstieg von Microsoft-Produkten auf Linux / Open-Source-Lösungen hat für alle betroffenen Mitarbeiter und für das Land Schleswig-Holstein beträchtliche organisatorische und technische Folgen.

1. Arbeitsplatzumgebung und Bedienung

• Betriebssystemwechsel:
  Windows wird durch ein Linux-Derivat ersetzt. Die grafische Oberfläche kann Windows ähneln (z. B. KDE Plasma, GNOME mit Windows-ähnlichem Layout), dennoch ändern sich Tastenkombinationen, Systemeinstellungen, Datei-Explorer-Struktur.

• Office-Suite:
  Wechsel von MS Office (Word, Excel, PowerPoint, Outlook) zu LibreOffice (Writer, Calc, Impress) und Open-Xchange für E-Mail/Kalender.
  → Änderungen bei Formatierung, Makroausführung, Serienbrieffunktionen, komplexen Excel-Formeln.

• Kollaboration:
  MS Teams/SharePoint wird durch Jitsi/OpenTalk und Nextcloud ersetzt. Dateien werden nicht mehr in SharePoint-Bibliotheken, sondern in Nextcloud-Ordnern verwaltet. Die Synchronisations- und Versionsmechanismen unterscheiden sich.

2. Kompatibilitätsfragen im Arbeitsalltag

• Dateiformate:
  LibreOffice unterstützt OOXML (.docx, .xlsx, .pptx) – jedoch können komplexe Formatierungen, eingebettete Objekte und Makros fehlerhaft dargestellt oder nicht funktionsfähig sein.

• Makros und Add-ins:
  VBA-Makros funktionieren in LibreOffice nicht direkt; Umstellung auf LibreOffice Basic oder Python-Makros erforderlich.

• Schnittstellen zu Fachverfahren:
  Anwendungen, die bisher aus MS Office heraus gestartet wurden (z. B. über OLE-Verbindungen), müssen angepasst werden.

3. Qualifikations- und Akzeptanzaspekte

• Schulungsbedarf:
  Grundlagentrainings für alle, Vertiefungstrainings für Power-User und Schlüsselstellen (Sekretariate, Controlling, Justiz).

• Gewohnheitsänderung:
  Gewachsene Arbeitsweisen müssen umgestellt werden – insbesondere in Bereichen, die intensiv mit MS-spezifischen Workflows arbeiten.

• Akzeptanzrisiko:
  Widerstand kann entstehen, wenn der Mehrwert nicht sichtbar gemacht oder die Umstellung als rein politisches Projekt ohne praktischen Nutzen empfunden wird.

4. Technischer Aufwand

• Migration der Endgeräte:
  Installation des Linux-Betriebssystems, Konfiguration von Treibern, Sicherheitseinstellungen, Benutzerprofilen.

• Datenmigration:
  Umstellung bestehender Dokumente, Vorlagen, Makros, Datenbanken auf kompatible Formate.

• Integration in Fachverfahren:
  Anpassung oder Ersatz von Anwendungen, die nur unter Windows laufen; ggf. Bereitstellung via Terminalserver/VDI in Übergangsphase.

• Netzwerk- und Infrastrukturänderungen:
  Anpassung von Authentifizierungssystemen (Active Directory → LDAP/Kerberos), Anpassung der Backup- und Archivierungsprozesse.

5. Organisatorischer Aufwand

• Projektmanagement:
  Landesweite Koordination, Meilensteinplanung, Abnahmekriterien.

• Support-Struktur:
  Aufbau oder Erweiterung von Helpdesk-Teams mit Linux/Open-Source-Kompetenz.

• Schulungskonzepte:
  Erstellung von Lernpfaden, E-Learning-Angeboten, Präsenzschulungen.

• Pilotphasen:
  Erprobung in einzelnen Ressorts/Behörden vor landesweitem Rollout.

6. Wirtschaftlicher Aufwand (direkt und indirekt)

• Direktkosten:
  Hardware-Anpassung, Migrationsdienstleistungen, Schulungskosten, externe Beratung.

• Indirekte Kosten:
  Temporäre Produktivitätseinbußen während der Umstellungsphase, Mehrarbeit durch Dateikonvertierungen und Supportfälle.

7. Zeitlicher Rahmen (Erfahrungswerte aus München, Toulouse, anderen Projekten)

• Vorbereitung: 12–18 Monate (Bestandsaufnahme, Fachverfahrens-Analyse, Schulungsplanung).

• Pilotphase: 6–12 Monate.

• Rollout: 18–36 Monate je nach Ressortgröße und Komplexität der Fachverfahren.

• Gesamtdauer bis stabiler Betrieb: realistisch 4–5 Jahre, bei konsequenter Steuerung.

Auswirkungen auf die Landes-Justiz-IT allgemein

1. Betriebssystemkompatibilität der Fachanwendungen

   • Viele Fachverfahren in der Justiz (z. B. ForumStar, EUREKA-Fach, JUDICA, web.erb, elektronische Aktenführung) sind historisch auf Windows-Clients ausgelegt und setzen oft Microsoft-Frameworks (z. B. .NET, ActiveX) voraus.

   • Unter Linux ist der Betrieb häufig nur über Terminalserver, Virtualisierungs- oder Containerlösungen möglich (z. B. Citrix, VMware Horizon, RemoteApp).

   • Das erhöht den Migrations- und Wartungsaufwand und kann zu Performance- und Bedienungsabweichungen führen.

2. Integration in justizinterne Netzwerke

   • Landesweite Justiznetze sind oft eng an Microsoft Active Directory gekoppelt (Authentifizierung, Gruppenrichtlinien).

   • Ein Wechsel zu Linux erfordert die Umstellung auf LDAP/Kerberos- oder hybride Authentifizierungslösungen, die mit den Bund-/Länder-Justiznetzen interoperabel bleiben müssen.

3. Dateiformat- und Vorlagenmanagement

   • Justizdokumente enthalten oft Word-Vorlagen mit komplexen Formatierungen und Makros (z. B. Formularzwang, Gerichtsbriefkopf, automatisierte Aktenzeichen).

   • Die vollständige Funktionsübernahme dieser Vorlagen in LibreOffice ist nur mit Anpassungen möglich, Makros müssen teils neu programmiert werden.

4. Schnittstellen zu Bund-/Länder-Infrastruktur

   • Die Justiz nutzt zentrale Plattformen wie EGVP (Elektronisches Gerichts- und Verwaltungspostfach) oder XJustiz-Schnittstellen. Diese sind plattformunabhängig möglich, setzen aber teilweise Java- oder .NET-Komponenten voraus, die für Linux getestet werden müssen.

beA-spezifische Aspekte

1. Technische Anbindung

   • Das beA der BRAK ist webbasiert, erfordert jedoch ein lokales Client-Sicherheitsmodul (beA Client Security) für die Smartcard-Authentifizierung.

   • Die BRAK bietet dieses Modul für Windows, macOS und seit einiger Zeit auch offiziell für Linux an – allerdings mit unterschiedlichem Supportumfang und oft späteren Versionsfreigaben.

   • Unter Linux müssen Java-Laufzeitumgebung und Browserintegration (meist Firefox ESR) exakt konfiguriert werden; Abweichungen in der Java-Version können zu Funktionsstörungen führen.

2. Signaturgeräte und Kartenleser

   • beA setzt auf Chipkartenleser mit qualifizierter Signatur nach eIDAS. Die Treiber (CT-API oder PC/SC) sind unter Linux verfügbar, aber nicht jeder Marktleser ist offiziell freigegeben.

   • In einer Landes-IT-Umgebung muss Hardwarekompatibilität zentral geprüft und garantiert werden.

3. Sicherheitszertifikate

   • beA arbeitet mit TLS-Zertifikaten und einem separaten Zertifikatsspeicher.

   • Unter Linux muss die Einbindung dieser Zertifikate systemweit und für alle relevanten Browser (v. a. Firefox ESR) sichergestellt werden, damit keine Sicherheitswarnungen auftreten.

4. Updates und Support

   • Die BRAK stellt regelmäßig Updates für beA Client Security bereit. In einer Linux-Umgebung muss sichergestellt werden, dass diese Updates automatisiert und kompatibel mit der jeweiligen Distribution (z. B. Debian/Ubuntu LTS) ausgerollt werden.

   • Verzögerte Freigaben oder Kompatibilitätsprobleme können die Nutzung im Fristenverkehr beeinträchtigen.

Besondere Risiken

• Fristversäumnisse: Bei Störungen in beA oder Fachverfahren drohen im Justizbereich unmittelbare Rechtsfolgen (z. B. unwirksame Klageeinreichung wegen technischer Hinderungsgründe).

• Kompatibilitätsprobleme: Fachverfahren, die tief mit Windows-Komponenten verzahnt sind, könnten unter Linux nur eingeschränkt laufen oder hohe Virtualisierungskosten verursachen.

• Abhängigkeit von BRAK-Releasezyklen: Wenn Linux-Versionen von beA-Software später erscheinen oder nicht vollständig unterstützt werden, drohen Sicherheits- und Funktionslücken.