Linux im Unternehmen einführen: dein Fahrplan vom Pilot zum Regelbetrieb

Die meisten Organisationen starten nicht bei null. Linux läuft längst auf Servern, im Container-Stack und in der CI, während Arbeitsplätze, Fachverfahren und Verzeichnisdienst weiter an Windows hängen. Dieser Mischbetrieb ist der Normalfall und kein Übergangszustand von ein paar Monaten, sondern eine Architektur, die du bewusst planen musst: Identitäten über Kerberos und LDAP beziehungsweise Active Directory, Dateidienste über Samba oder NFS, dazu Drucken, Zertifikate, Backup und Monitoring.

Der zweite typische Bruch liegt bei den Fachanwendungen. Eine ehrliche Inventarisierung trennt Anwendungen, die nativ oder im Browser laufen, von solchen, die eine Terminalserver-Sitzung, eine VM oder eine Ablösung brauchen. Wer diese Liste erst nach dem Pilotstart erstellt, verhandelt anschließend unter Zeitdruck mit Herstellern, die für Linux keine Supportzusage geben. Genauso häufig unterschätzt wird die Peripherie: Spezialhardware, Kartenleser und Treiber, die es nur für einen bestimmten Kernel-Zweig gibt.

Der dritte Punkt ist der Betrieb. Eine Distribution auszuwählen ist schnell erledigt, ein Lebenszyklus dagegen nicht. Du brauchst eine Antwort darauf, wer Pakete freigibt, wie Updates gestaffelt ausgerollt werden, wie CVE-Meldungen bewertet werden und was passiert, wenn ein Kernel-Update einen Treiber bricht. Ohne definierten Patch- und Rollback-Weg entstehen genau die handgepflegten Einzelsysteme, wegen derer Linux später als schwer beherrschbar gilt, obwohl das Problem der fehlende Prozess ist.