Der Deutschland-Stack befreit niemanden von Microsoft – Grams IT

Der Deutschland-Stack soll die „nationale souveräne Technologie-Plattform“ für die Verwaltung werden. Am 12. Oktober 2026 hat der Deutsche Städte- und Gemeindebund über ein Webinar mit dem Digitalministerium berichtet, an dem am 3. Juli mehr als 400 Vertreter aus Städten, Gemeinden und Landesverbänden teilgenommen haben. Erste Lösungen sollen ab Beginn 2028 verfügbar sein.

Ich betreue die IT einer hessischen Gemeinde, und meine Frage an so ein Vorhaben ist schlicht: Hilft mir das, aus der Microsoft-Abhängigkeit herauszukommen? Windows 11 auf den Laptops, Windows Server 2019 und 2025 als virtuelle Maschinen, Active Directory, eine RDS-Farm, AD FS, AD LDS, SQL Server, Exchange, Office 2024, Sternberg SD.NET, die eAkte, ein Stapel Fachverfahren der ekom21 und im Bürgerservice die Geräte der Bundesdruckerei. Das ist kein Sonderfall, so sieht eine normale Kommune aus.

Ich habe die Webseiten des Stacks, den Beschluss des IT-Planungsrats samt Anlagen und die Sachstandspräsentation des Ministeriums durchgearbeitet. Die kurze Antwort: Der Deutschland-Stack löst dieses Problem nicht, und er will es auch gar nicht lösen. Er setzt Standards, die es mittelfristig lösbar machen. Bis dahin kommt er obendrauf.

Was der Deutschland-Stack ist und was beschlossen wurde

Verbindlich ist bisher ein Dokument: der Beschluss B-2026/03-IT des IT-Planungsrats vom 18. März 2026. Darin steht, dass der Bund den Stack federführend aufbaut und dass der einheitliche Plattformkern in erster Fassung aus fünf Basisdiensten besteht: Identität und Vertrauen, Datenaustausch, Datenabruf, Zahlungsabwicklung und Postfach.

Die Anlage „Portfolio“ nennt dazu die Produkte. Für Identität sind es eID und EUDI-Wallet, für das Postfach ZaPuK, für den Datenaustausch FIT-Connect, für den Datenabruf NOOTS, für Zahlungen ZBDS einschließlich ePayBL. Dazu kommen KIPITZ als KI-Plattform, Low-Code für Workflows, der Marktplatz Deutschland Digital, openCode für die Entwicklung und die Deutsche Verwaltungscloud als Betriebsumgebung. Als Zugang sind Bundesportal und Deutschland-App vorgesehen.

Zwei Formulierungen sollte man genau lesen. Bund, Länder und Kommunen „streben“ die Nutzung dieser Lösungen bei Neu- und Weiterentwicklungen „an“. Das ist kein Anschlusszwang. Und die Standards sind verbindliche Grundlage „der Lösungen des Deutschland-Stacks“, also der Bausteine selbst, nicht der IT im Rathaus.

Struktur des D-Stacks: sieben Schichten

Die Seite zur Struktur des Stacks ordnet alles in sieben Schichten: Infrastruktur, DevSecOps (Entwicklung, Sicherheit, Betrieb), Plattform, Basisdienst, Anwendungen und Dienstleistungen, Oberfläche und Zugang sowie Strategie, Architektur und Governance.

Wichtig ist die Trennung zwischen fachagnostisch und fachspezifisch. Fachagnostische Schichten gehören zum Stack, fachspezifische bauen nur darauf auf. Fachanwendungen stehen in der Schicht „Anwendungen und Dienstleistungen“ und sind damit ausdrücklich nicht Teil des Kerns. Ein Einwohnermeldeverfahren, ein Finanzwesen oder ein Sitzungsdienst bleibt Sache der Hersteller und der kommunalen IT-Dienstleister.

Das Zielbild in der Sachstandspräsentation zeigt dasselbe von oben: Portale wie ein „Digitales Rathaus“ sitzen auf Plattformdiensten, darunter liegen fachagnostische Plattformen, Basisdienste und Betriebsplattformen. Ein Verwaltungsarbeitsplatz kommt in diesem Bild nicht vor.

D-Stack Standards: was verbindlich festgelegt ist

Die beschlossenen Standards verteilen sich auf sieben Technologiefelder. Für Admins sind diese relevant:

KI: Model Context Protocol (MCP), Agent2Agent (A2A), Agent Network Protocol (ANP), AG-UI
Daten und Dokumente: RDF, OWL, SPARQL, DCAT, JSON, XML, CSV, ODF und PDF/UA als Dokumentenformate, SQL mit ODBC und JDBC
Infrastruktur: MEF 70 für SD-WAN, Network Function Virtualization
DevSecOps und Schnittstellen: Git, CI/CD, Infrastructure as Code, SBOM, OWASP, Kubernetes, REST, gRPC, GraphQL, MQTT, OpenAPI
Cloud: Standards der Deutschen Verwaltungscloud, OpenStack, Sovereign Cloud Stack, EVB-IT
IT-Sicherheit: BSI IT-Grundschutz, Technische Richtlinien, C5, AES, RSA, ECC, ML-KEM für Post-Quanten-Kryptografie, OAuth, OpenID Connect, JWT, OTP für MFA
Workflowautomatisierung: kein Standard festgelegt

Auffällig ist, was fehlt. Es gibt keinen Standard für Betriebssysteme, keinen für Verzeichnisdienste, keinen für Laufzeitumgebungen. Weder Linux noch Windows, weder LDAP noch Kerberos, weder Java noch .NET werden genannt. Für die Verwaltung virtueller Maschinen ist ausdrücklich noch „Festlegungsbedarf“ vermerkt.

Drei Punkte aus der Liste wirken trotzdem bis in den Serverraum. ODF ist das Dokumentenformat, nicht OOXML. OAuth und OpenID Connect sind die Anmeldeprotokolle, nicht NTLM oder Kerberos. Und Kubernetes ist die Betriebsplattform, was faktisch Linux-Container bedeutet.

Tech-Stack Landkarte und Kriterien: Orientierung, keine Pflicht

Neben den Standards gibt es die Tech-Stack Landkarte, methodisch von der CNCF Landscape übernommen. Die Präsentation spricht von mehr als 100 Technologien und Standards. Das Ministerium schreibt selbst, die Zusammenstellung sei „aktuell keine rechtliche oder vertragliche Grundlage“.

Ähnlich steht es um die sechs Kriterien: digitale Souveränität, Interoperabilität, Zukunftsfähigkeit, Marktrelevanz, Vertrauenswürdigkeit, Nachhaltigkeit. Das geplante Reifegradmodell wurde nach Kritik aus der ersten Konsultation zurückgestellt, die Kriterien sind nur Orientierung. Als Mindestmaß für Souveränität nennt die Seite die Wechselfähigkeit zwischen Betreibern und Anbietern.

Unter den zehn Architekturprinzipien im Gesamtbild stehen „Made in EU first“, „Prefer Buy over Make“ und „Managed Services only“. Das letzte Prinzip sagt viel über das Betriebsmodell: Stack-Elemente sollen als Dienst bezogen werden, nicht im eigenen Keller laufen.

Was noch offen ist

Laut Sachstandspräsentation wird die Finanzierung der investiven und konsumtiven Kosten des Plattformkerns „aktuell geprüft“, ebenso die rechtssicheren Beauftragungs- und Bezugswege. Der Meilensteinplan soll erst auf der 52. Sitzung des IT-Planungsrats im März 2027 vorgestellt werden, so steht es auf der Zeitplan-Seite.

Das heißt: Eine Kommune weiß heute weder, was die Nutzung kostet, noch auf welchem Vertragsweg sie die Dienste bezieht, noch wann welcher Baustein fertig ist. Die im Webinar gestellten Fragen der Kommunen hat der DStGB gesammelt ans Ministerium gegeben, die Antworten sollen auf der BMDS-Seite erscheinen.

Die Gegenposition: Wem der Stack nicht weit genug geht

Die Open Source Business Alliance hat im Februar 2026 zur zweiten Konsultation Stellung genommen. Nach Bericht von heise kritisiert sie, dass „Lösungen europäisch souveräner Anbieter“ mit Open Source gleichgestellt werden, und nennt die Gefahr „Sovereignty Washing“. Ihr Vorstandsvorsitzender Peter Ganten sagt laut it-daily, ohne durchgängige Open-Source-Strategie „bleibt echte digitale Souveränität unerreichbar“.

Der Verein D64 fragte schon 2025 gegenüber netzpolitik.org, wer den Stack betreibt, finanziert und dafür haftet. Die DIHK verlangt in ihrer Stellungnahme vor allem Klarheit und Verbindlichkeit.

Fairerweise: Das Ministerium hat einen Punkt. Wer alles auf einmal vorschreibt, bekommt nichts fertig. Ein kleiner Plattformkern mit fünf Basisdiensten, der 2028 tatsächlich läuft, wäre mehr, als das Onlinezugangsgesetz in Jahren geliefert hat. Und das Ministerium betont, dass vorhandene Einzellösungen nicht verworfen werden müssen. Nur darf man dann nicht „Souveränität“ über das Ganze schreiben und den Arbeitsplatz ausklammern, an dem die Abhängigkeit jeden Morgen hochfährt.

Microsoft ablösen in der Kommune: Komponente für Komponente

Hier die Beispielkommune gegen den Stack gehalten. Die mittlere Spalte gibt wieder, was Beschluss und Standards hergeben, die rechte ist meine Einschätzung.

Komponente heute	Deutschland-Stack	Realistischer Weg
Virtualisierung (meist Hyper-V oder VMware)	nicht geregelt; für VM-Verwaltung „Festlegungsbedarf“	Proxmox VE als freie Alternative; die Microsoft-Lizenzen bleiben
Zugriffslizenzen je Benutzer (Server-, RDS-, Exchange-CALs, Office)	nicht geregelt	sinken erst, wenn die Dienste dahinter ersetzt sind
Windows 11 auf Laptops	nicht geregelt	Linux-Client erst, wenn Fachverfahren im Browser oder per Remote laufen
Windows Server 2019/2025	nicht geregelt; Kubernetes, OpenStack, SCS für Stack-Lösungen	Infrastrukturdienste schrittweise auf Linux, Windows nur noch als Anwendungsserver
Active Directory	nicht geregelt	Samba-AD, etwa über Univention, mit Einschränkungen
AD FS	OAuth, OIDC, JWT als Standard	Keycloak
AD LDS	nicht geregelt	LDAP-Verzeichnis nach Bedarf der Anwendung
RDS-Farm	nicht geregelt	bleibt als Brücke für Windows-Fachverfahren
MS SQL Server	SQL, ODBC, JDBC	SQL Server auf Linux oder Wechsel, wenn der Hersteller mitzieht
Exchange und Office 2024	ODF, PDF/UA	openDesk und LibreOffice, abhängig von Fachverfahren und Schulung
Bundesdruckerei-Geräte im Bürgerservice (Ausweisprüfung, PIN, Fingerabdruck)	nicht geregelt; eID und EUDI-Wallet sind Basisdienst	Windows-PC bleibt Pflicht, solange die Bundesdruckerei nichts anderes freigibt
SD.NET, eAkte, ekom21-Verfahren	Schicht „Fachanwendung“, außerhalb des Kerns	Hersteller und ekom21 entscheiden

Hyper-V, VMware, Proxmox: Der Hypervisor lässt sich tauschen

Unter den Windows-Servern liegt die Virtualisierung, und auch dort sitzt in den meisten Kommunen vermutlich ein proprietäres Produkt: Hyper-V, weil es bei Windows Server dabei ist, oder VMware. Zahlen dazu kenne ich nicht, das ist mein Eindruck. Wer VMware betreibt, hat seit der Übernahme durch Broadcom ein zusätzliches Problem. Um die neuen Lizenzbedingungen gibt es so viel Streit, dass sich laut Bericht von computing.co.uk die EU eingeschaltet hat.

Die freie Alternative heißt Proxmox VE, eine Open-Source-Plattform, die den KVM-Hypervisor und Linux-Container (LXC) zusammenführt. Der Hersteller, die 2005 gegründete Proxmox Server Solutions GmbH, verlangt nach eigener Angabe keine Lizenzkosten und bietet Subskriptionen optional an. Ich betreibe selbst einen Proxmox-Cluster und würde nicht zurückwechseln. Von allen Schritten in diesem Artikel ist das der, den eine Kommune am ehesten allein schafft.

Nur sollte niemand glauben, damit sei die Microsoft-Frage erledigt. Auf dem freien Hypervisor laufen weiter Windows-Server, und für die gilt Microsofts Lizenzmodell unverändert. Antworten in Microsofts eigenem Q&A-Forum sagen es ausdrücklich: Die Lizenz hängt an der physischen Hardware, nicht am Hypervisor, ob Hyper-V, VMware oder Proxmox.

Microsoft-Lizenzkosten: Die Rechnung läuft pro Benutzer

Wer über Microsoft-Kosten redet, denkt zuerst an die Serverlizenzen. In der Praxis sind sie der kleinere Posten. Laut Microsofts Lizenzleitfaden für Windows Server 2025 müssen alle physischen Kerne eines Hosts lizenziert werden, mindestens 16 pro Server. Die Standard-Edition deckt damit zwei virtuelle Maschinen ab, Datacenter beliebig viele. Datacenter rechnet sich deshalb erst, wenn genügend Windows-VMs auf dem Host laufen. Dann aber kosten die Windows-Betriebssysteme der Gäste nichts extra, und das einzelne Serverbetriebssystem ist kein Kostentreiber mehr.

Der große Posten sind die Lizenzen je Benutzer. Der Leitfaden verlangt für jeden Benutzer oder jedes Gerät, das auf einen lizenzierten Server zugreift, eine Windows-Server-CAL. CAL steht für Client Access License, also eine Zugriffslizenz. Für die RDS-Farm kommt je Benutzer eine RDS-CAL obendrauf, für das Postfach eine Exchange-CAL, dazu die Office-Lizenz. In einer typischen Kommune, die zentral in der RDS-Farm arbeitet, sind das vier Lizenzen pro Kopf, und jede neue Stelle bringt alle vier mit.

Dazu kommt, dass diese Lizenzen altern. Eine CAL erlaubt laut Leitfaden den Zugriff auf „the same version, or earlier versions“ der Serversoftware. Wer seine Server von 2019 auf 2025 hebt, braucht also für alle Benutzer neue CALs, auch wenn sich an deren Arbeit nichts ändert. Bei Exchange ist der Kauf auf Vorrat ganz vorbei: Für die Exchange Server Subscription Edition müssen nach den Product Terms, wie sie im Microsoft-Q&A zitiert werden, auch die CALs als Abonnement oder mit aktiver Software Assurance vorliegen. Office LTSC 2024 läuft im Oktober 2029 aus dem Support.

Das ist der Kern der Abhängigkeit, und er hat mit dem Hypervisor nichts zu tun. Eine Kommune kann Proxmox einführen, Datacenter-Lizenzen sauber ausnutzen und alle Infrastrukturdienste auf Linux ziehen. Solange die Beschäftigten sich an einer Windows-Domäne anmelden, in einer RDS-Sitzung arbeiten, ein Exchange-Postfach haben und Word öffnen, zahlt sie für jeden von ihnen weiter, und bei jedem Versionswechsel wieder.

Sparen lässt sich daher nur, indem man ganze Dienste ablöst: Fällt Exchange weg, fallen die Exchange-CALs weg. Fällt die RDS-Farm weg, fallen die RDS-CALs weg. Die Server-CAL verschwindet erst, wenn kein Benutzer mehr auf einen Windows-Server zugreift, also praktisch zuletzt. Der Deutschland-Stack sagt zu alledem nichts.

Active Directory, AD FS und AD LDS

Für AD FS gibt es die sauberste Antwort. Der Stack legt OAuth und OpenID Connect fest, und Keycloak spricht OpenID Connect, OAuth 2.0 und SAML, bindet LDAP und Active Directory als Benutzerquelle ein und hat eine Kerberos-Brücke. Man kann Keycloak also vor ein bestehendes AD stellen und AD FS ablösen, ohne die Domäne anzufassen. Das ist der eine Schritt, den ich jeder Kommune schon heute empfehlen würde.

Das Active Directory selbst ist schwieriger. Univention dokumentiert für UCS einen AD Takeover: Benutzer, Gruppen, Computerobjekte und Gruppenrichtlinien werden übernommen, die Windows-Clients müssen der Domäne nicht neu beitreten. Die Grenzen stehen ebenfalls im Handbuch: Microsoft-Domänencontroller können einer Samba-Domäne nicht beitreten. Samba bietet die Funktionsebene 2016 seit Version 4.20 nur als Option an, die laut Release Notes noch neu und nicht voreingestellt ist.

Schleswig-Holstein, das am weitesten ist, beschreibt den Microsoft-Verzeichnisdienst auf seiner Projektseite als Instanz, ohne die die Arbeitsfähigkeit der Behörden nicht sicherzustellen ist, und arbeitet an einer Teststellung für die Ablösung. Wenn ein Land mit Dataport im Rücken dafür Jahre braucht, sollte eine Gemeinde mit einer IT-Stelle das nicht als Wochenendprojekt planen. Ob Produkte wie eine Kennwortrichtlinien-Erweiterung oder eine Smartcard-Anmeldung an Samba-AD funktionieren, habe ich nicht getestet.

Windows Server und die RDS-Farm

Hier gibt es einen Termin, der unabhängig vom Deutschland-Stack läuft: Der erweiterte Support für Windows Server 2019 endet im Januar 2029. Windows Server 2025 läuft bis November 2034. Jede Kommune mit 2019er-Servern muss also bis Ende 2028 entscheiden, was neu aufgebaut wird, und das ist der Moment, an dem man Dienste trennen kann. Es ist auch der Moment, an dem die neuen CALs fällig werden.

Datei-, Druck-, DNS- und DHCP-Dienste brauchen kein Windows. Die RDS-Farm braucht es, solange die Anwendungen darauf Windows-Programme sind. Ich halte sie deshalb nicht für das Problem, sondern für die Brücke: Wenn die Fachanwendung zentral auf einem Session Host läuft, ist dem Endgerät das Betriebssystem egal. Schleswig-Holstein plant genau so und will Fachverfahren, die nicht betriebssystemunabhängig laufen, ersetzen oder über einen Remote-Dienst bereitstellen.

Die Brücke hat ihren Preis: Jeder Nutzer, der sie betritt, braucht Server-CAL und RDS-CAL. Wer den Laptop auf Linux umstellt und die Fachverfahren per RDS liefert, spart die Windows-Lizenz am Client und zahlt den Rest weiter.

MS SQL Server

Der Stack nennt SQL, ODBC und JDBC, also Schnittstellen und keine Produkte. SQL Server läuft laut Microsoft-Dokumentation seit Version 2017 auf Linux, mit derselben Datenbank-Engine, unterstützt auf Red Hat und Ubuntu bis einschließlich SQL Server 2025. SUSE wird ab 2025 nicht mehr unterstützt.

Das nimmt Windows aus der Gleichung, nicht Microsoft. Der Wechsel auf PostgreSQL hängt allein am Hersteller der Anwendung. Solange ein Fachverfahren nur für SQL Server freigegeben ist, verliert man mit einer anderen Datenbank den Support.

Exchange, Office 2024 und openDesk

Office LTSC 2024 wird bis Oktober 2029 unterstützt, einen erweiterten Support gibt es nicht. Der Stack setzt ODF und PDF/UA als Dokumentenformate.

Die Alternative des Bundes heißt openDesk, entwickelt vom ZenDiS, einer GmbH des Bundes. Aktuell ist Version 1.19.1 vom 6. Oktober 2026. Das ist eine Web-Suite mit E-Mail, Kalender, Dateien, Dokumentenbearbeitung, Chat, Videokonferenz, Projekten und Identitätsmanagement; laut einer Pressemitteilung vom Juli sind 100.000 Verwaltungsarbeitsplätze damit ausgestattet. openDesk ersetzt Exchange, SharePoint und Teams, aber kein Betriebssystem und kein Client-Management. Im beschlossenen Portfolio des Deutschland-Stacks taucht openDesk nicht auf.

Für die Lizenzrechnung ist Exchange der lohnendste Kandidat, weil mit dem Dienst eine ganze CAL-Schicht verschwindet und E-Mail am wenigsten an Fachverfahren hängt. Bei Office ist es umgekehrt. Die eAkte-Broschüre der ekom21 wirbt mit der Integration von Microsoft-Office-Werkzeugen, das Modul „eAkte Office“ übergibt Dokumente aus Word per Knopfdruck. Bei SD.NET sind die Dokumentvorlagen laut ekom21-Broschüre Word-Dateien, dazu kommt eine Outlook-Schnittstelle.

Schleswig-Holstein hat für seine E-Akte eine LibreOffice-Erweiterung beauftragt und arbeitet nach eigenen Angaben mit fast 80 Prozent der Arbeitsplätze auf LibreOffice. Dort hat das Land die Anpassung bezahlt. In Hessen müsste das jemand bei der ekom21 bestellen.

Bürgerservice: Die Geräte der Bundesdruckerei laufen nur an Windows-PCs

Ein Punkt fehlt in fast jeder Linux-Debatte, und er wiegt schwerer als Office. Im Bürgerservice stehen Geräte der Bundesdruckerei: das Lesegerät, mit dem Personalausweise geprüft werden, das Änderungsterminal, an dem Bürger ihre PIN setzen oder ändern, und der Fingerabdruckscanner für Pass und Ausweis. Ohne diese Geräte stellt eine Kommune kein einziges Ausweisdokument aus.

Aus meiner Praxis: Diese Geräte laufen ausnahmslos an einem Windows-PC, und zwar direkt am Arbeitsplatzrechner. Das ist keine Bequemlichkeit der Kommune, sondern Vorgabe der Bundesdruckerei. Ein Linux-Client scheidet damit aus, und die Brücke über die RDS-Farm, die bei anderen Fachverfahren trägt, hilft hier nicht, weil die Hardware lokal am Windows-Gerät hängen muss. Eine öffentlich zugängliche Systemanforderung der Bundesdruckerei, die das schwarz auf weiß zeigt, habe ich nicht gefunden; der Produktkatalog der Bundesdruckerei-Gruppe nennt die Geräte, aber keine Betriebssysteme.

Das Unangenehme daran ist der Absender. Die Bundesdruckerei gehört dem Bund. Derselbe Bund schreibt mit dem Deutschland-Stack „Souveränität“ über sein größtes Digitalvorhaben und macht die EUDI-Wallet zum Basisdienst für Identität. An der Stelle, an der diese Identität im Rathaus entsteht, schreibt ein Bundesunternehmen den Kommunen Windows vor.

Solange das so bleibt, gibt es in jeder Kommune mit Pass- und Ausweisbehörde Windows-Arbeitsplätze, egal was mit dem Rest passiert. Man kann sie auf den Bürgerservice begrenzen. Abschaffen kann man sie nicht.

.NET Framework unter Linux: warum die alte Abhängigkeit bleibt

Sie fragen sich vielleicht, warum man die Windows-Programme nicht einfach unter Linux startet. Die Antwort steckt in der Unterscheidung zwischen zwei Dingen, die beide „.NET“ heißen.

Das alte .NET Framework 4 ist laut Microsoft eine reine Windows-Version und gilt als Bestandteil des Betriebssystems. Das moderne .NET ist plattformübergreifend und läuft auf Linux. Eine Serveranwendung auf ASP.NET Core lässt sich also in einen Linux-Container packen und passt damit zum Kubernetes-Standard des Stacks.

Bei Desktop-Programmen hilft das nicht. Windows Forms ist auch in der modernen Fassung ein Framework für Windows-Desktop-Anwendungen. Und beim Portieren fallen Techniken weg, die ältere Fachverfahren gern benutzen: Microsoft listet unter den nicht verfügbaren Technologien Application Domains, .NET Remoting, COM+ über System.EnterpriseServices und Workflow Foundation. WCF-Server gibt es nur noch über das Community-Projekt CoreWCF.

Der frühere Ausweg hieß Mono, eine freie Nachbildung des .NET Framework samt Windows Forms für Linux. Microsoft hat das Projekt im August 2024 an WineHQ abgegeben. Das letzte große Release stammt vom Juli 2019, und Microsoft empfiehlt den Umstieg auf das moderne .NET. Für ein Fachverfahren mit Herstellersupport ist das keine Grundlage.

Für SD.NET heißt das konkret: Die ekom21 bietet den Betrieb im Rechenzentrum über Citrix an, alternativ den autonomen Betrieb im eigenen Haus. Welche Laufzeit und Datenbank der Client genau verlangt, steht in der Broschüre nicht, die Systemvoraussetzungen gibt es auf Anfrage. Dass es sich um einen Windows-Client auf .NET handelt, legen Name und Bereitstellung nahe, belegt habe ich es nicht. Der Citrix-Weg zeigt aber die Richtung: Citrix liefert eine Workspace-App für Linux, derzeit nur für X11 und nicht für Wayland.

Ein Linux-Arbeitsplatz in der Kommune funktioniert also dann, wenn jedes Fachverfahren entweder im Browser läuft oder aus dem Rechenzentrum gestreamt wird. An der Abhängigkeit von Windows ändert das auf dem Server nichts. Sie zieht nur vom Laptop ins Rechenzentrum um, samt Lizenzen. Und im Bürgerservice zieht sie nicht einmal um.

Die größte Hürde: die Menschen am Arbeitsplatz

Bis hierher ging es um Technik und Lizenzen. Wenn Microsoft wirklich ersetzt werden soll, liegt die größte Hürde woanders, nämlich bei den Mitarbeitenden. Viele in der Verwaltung kommen mit Word und Excel gerade so zurecht und nutzen Outlook für ihre E-Mails. Mehr haben sie nie gebraucht, und mehr hat ihnen meist auch niemand beigebracht. Das ist kein Vorwurf. Eine Sachbearbeiterin im Ordnungsamt ist für Ordnungsrecht eingestellt, nicht für Software.

Für diese Kolleginnen und Kollegen ist der Wechsel auf LibreOffice, ein anderes Mailprogramm oder gar einen Linux-Desktop kein Detail. Jeder Handgriff, der seit Jahren sitzt, liegt plötzlich woanders. Die Serienbrief-Vorlage sieht anders aus, die Excel-Tabelle mit den Makros des Vorgängers rechnet nicht mehr, der Kalender lässt sich nicht mehr so freigeben wie gewohnt. Was die IT als gleichwertigen Ersatz verbucht, kommt am Schreibtisch als Störung an, und zwar mitten in der laufenden Arbeit mit Fristen und Publikumsverkehr.

Deshalb braucht eine Ablösung erheblich mehr Schulung, als in den meisten Projektplänen steht. Schleswig-Holstein hat das erkannt: Die Projektseite des Landes nennt ein eigenes Schulungspaket und Schulungen für die Beschäftigten als festen Teil der LibreOffice-Einführung, und das Land stellt nach eigenen Angaben für 2026 neun Millionen Euro an einmaligen Investitionen für Migration und Weiterentwicklung den eingesparten Lizenzkosten gegenüber. Eine Gemeinde hat dafür weder ein Budget noch eine Fortbildungsabteilung.

Ich halte diesen Punkt für entscheidender als jede Frage nach Samba oder Kubernetes. Eine technisch saubere Migration scheitert, wenn nach drei Wochen der halbe Fachbereich beim Bürgermeister steht und Word zurückverlangt. Wer Microsoft ablösen will, muss die Schulung von Anfang an mitfinanzieren, mit Zeit für die Beschäftigten, mit Ansprechpartnern im Haus und mit Geduld über Monate. Im Deutschland-Stack kommt das Thema nicht vor, bei den Festlegungsbedarfen zur IT-Sicherheit steht lediglich ein „Format zu Sensibilisierung von Nutzenden“.

Der Stack kommt obendrauf: Kosten und Kubernetes-Know-how

Aus alledem folgt etwas, das in keiner Präsentation des Ministeriums steht. Der Deutschland-Stack ersetzt in einer Kommune zumindest derzeit keine einzige Microsoft-Komponente. Er liefert Identität, Postfach, Datenaustausch, Registerabruf und Bezahlen für Bürgerdienste. Domäne, RDS-Farm, Exchange, Office und die Fachverfahren laufen daneben unverändert weiter, mit allen Lizenzen.

Für den Haushalt heißt das: Was die Stack-Dienste kosten werden, kommt zu den Microsoft-Lizenzen hinzu, nicht an ihre Stelle. Wie viel das ist, weiß niemand, die Finanzierung wird ja noch geprüft. Vielleicht trägt der Bund den Plattformkern, vielleicht landet ein Teil über Umlagen und Entgelte der IT-Dienstleister bei den Kommunen. Sicher ist nur die Richtung der Rechnung. Wer im Gemeindevorstand „Souveränität“ hört und Einsparungen erwartet, sollte das vorher wissen.

Der zweite Punkt betrifft die Technik. Der Stack setzt auf Kubernetes, CI/CD-Pipelines und Infrastructure as Code. Das ist Stand der Technik und für eine zentrale Plattform richtig. Nur hat nach meinem Eindruck kaum eine Kommune jemanden, der Kubernetes betreibt oder auch nur nutzt. Die IT-Abteilung einer Gemeinde besteht oft aus ein oder zwei Leuten, die Windows-Server, Netzwerk, Telefonie und den Drucker im Standesamt betreuen. Zahlen dazu habe ich nicht, aber ich kenne kein Rathaus dieser Größe mit einem Kubernetes-Cluster.

Das Ministerium hat darauf eine Antwort, und sie steht in den Architekturprinzipien: „Managed Services only“. Die Kommune soll den Stack gar nicht selbst betreiben, sondern Dienste beziehen. Das ist ehrlich, hat aber zwei Folgen. Erstens entsteht eine neue Abhängigkeit, diesmal vom Betreiber der Plattform und vom IT-Dienstleister, der sie vermittelt. Zweitens bleibt das Wissen dort. Wechselfähigkeit, das Mindestmaß an Souveränität laut Kriterienkatalog, setzt voraus, dass jemand im Haus beurteilen kann, was er da bezieht.

Ich halte das nicht für ein Argument gegen den Stack. Eine Gemeinde mit 12.000 Einwohnern soll keinen Cluster betreiben. Aber es zeigt, für wen er gebaut ist: für Länder, IT-Dienstleister und Softwarehersteller, die darauf Dienste entwickeln. Die Kommune ist Kundin, nicht Betreiberin, und sie zahlt künftig an zwei Stellen.

Was Sie als Admin jetzt tun können

Ich würde nicht auf 2028 warten, und ich würde auch nicht den großen Umstieg ausrufen. Diese Schritte kosten wenig und passen zu dem, was der Stack festlegt:

Fachverfahren inventarisieren: Client-Typ, Laufzeit, Datenbank, Office-Kopplung, Anmeldeverfahren, angeschlossene Hardware. Ohne diese Liste ist jede Linux-Diskussion Meinung.
Die Lizenzen pro Benutzer aufschreiben: Server-CAL, RDS-CAL, Exchange-CAL, Office. Dann sieht man, welcher Dienst welche Schicht verursacht und wo eine Ablösung sich rechnet.
Neue Anmeldungen nur noch über OpenID Connect oder SAML bauen und AD FS durch Keycloak ersetzen.
Bei jeder Beschaffung drei Fragen stellen: Gibt es einen Web-Client? Läuft der Serverteil auf Linux und PostgreSQL? Kann das Verfahren ODF?
Den Neuaufbau der 2019er-Server bis Ende 2028 nutzen, um Infrastrukturdienste von Windows zu lösen, und vorher klären, welche CALs dabei neu fällig werden.
Den Hypervisor prüfen. Der Wechsel von VMware zu Proxmox spart die VMware-Kosten, an der Microsoft-Rechnung ändert er nichts.
ODF intern als Ablageformat einführen, soweit die Fachverfahren es zulassen.
Schulung als eigenen Posten planen, bevor irgendetwas am Arbeitsplatz ersetzt wird: Zeit für die Beschäftigten, feste Ansprechpartner je Fachbereich, und zuerst eine Pilotgruppe, die freiwillig mitmacht.
Linux- und Container-Wissen im eigenen Haus aufbauen, in kleinen Schritten. Ein paar Dienste in LXC-Containern oder mit Docker reichen, um mitreden zu können. Einen eigenen Kubernetes-Cluster braucht dafür niemand.
Im Haushalt keine Einsparung durch den Stack einplanen und den IT-Dienstleister fragen, welche Entgelte für Stack-Dienste zu erwarten sind.
Die ekom21 schriftlich fragen, welche Verfahren wann ohne Windows-Client und ohne Microsoft Office nutzbar sein werden.
Den Bürgerservice als eigene Geräteklasse planen: Diese Arbeitsplätze bleiben auf Windows. Und die Frage nach Linux-Unterstützung der Bundesdruckerei gehört in die Feedbackrunden zum Deutschland-Stack.

Punkt 11 und 12 entscheiden darüber, ob eine Ablösung überhaupt möglich wird, Punkt 8 darüber, ob sie gelingt. Die ersten beiden liegen nicht im Rathaus, sondern bei den Herstellern der Fachverfahren, beim kommunalen IT-Dienstleister und bei einem Unternehmen des Bundes.

Fazit

Der Deutschland-Stack ist ein Plattformkern für Bürgerdienste: Anmeldung, Postfach, Datenaustausch, Registerabruf, Bezahlen. Beschlossen sind dafür fünf Basisdienste und eine Liste offener Standards. Betriebssystem, Verzeichnisdienst, Virtualisierung, Terminalserver und Fachverfahren kommen darin nicht vor, und Finanzierung, Bezugswege und Meilensteine sind offen bis mindestens März 2027.

Für die Microsoft-Ablösung liefert er trotzdem etwas Brauchbares, nämlich Argumente für Ausschreibungen. ODF, OpenID Connect, offene Schnittstellen und Kubernetes sind vom IT-Planungsrat beschlossen. Wer das in Leistungsbeschreibungen schreibt, zwingt Hersteller in die richtige Richtung.

Was die Kommune selbst tun kann, ist überschaubar: Proxmox statt VMware oder Hyper-V, Keycloak statt AD FS, Linux für die Infrastrukturdienste. Das ist richtig, aber es ändert an der Microsoft-Rechnung wenig. Die läuft pro Benutzer, über Server-, RDS- und Exchange-CALs und über Office, und sie wird mit jeder neuen Version neu gestellt. Solange Fachverfahren eine Windows-Domäne, eine RDS-Sitzung und Word verlangen, bleibt jeder Beschäftigte ein Lizenzfall.

Der Stack kommt deshalb vorerst obendrauf, als zweite Rechnung neben der ersten, gebaut auf einer Technik, die im Rathaus kaum jemand beherrscht. Das spricht nicht gegen ihn. Es spricht dagegen, ihn den Kommunen als Entlastung zu verkaufen.

Und selbst wenn Hersteller und Bund morgen alle technischen Hürden abräumten, säße die größte noch am Schreibtisch. Menschen, die seit zwanzig Jahren mit Word, Excel und Outlook arbeiten, wechseln nicht per Beschluss. Ohne Geld und Zeit für Schulung bleibt jede Ablösung ein Papier.

Was fehlt, ist ein Baustein für den Verwaltungsarbeitsplatz samt Verzeichnisdienst und eine Pflicht für Fachverfahrenshersteller, betriebssystemunabhängige Clients zu liefern. Anfangen könnte der Bund bei sich selbst: Solange die Geräte der Bundesdruckerei nur an Windows-PCs laufen, bleibt jede Pass- und Ausweisbehörde im Land an Microsoft gebunden. Das halte ich für die eigentliche Lücke im Stack, und ich finde, die Kommunen sollten sie in den angekündigten Feedbackrunden benennen.