Meine Reise vom Linux-Arbeitsplatz zur Enterprise-Firmenplattform begann früher, als ich zunächst dachte: nicht im Unternehmen und auch nicht auf einem Server, sondern auf meinem privaten PC.
Dort installierte ich Linux Mint parallel zu Windows als Dual-Boot-System. Ich wollte nicht nur ausprobieren, ob Linux grundsätzlich funktioniert. Mein Ziel war konkreter: Ich richtete den Rechner so ein, als müsste ich damit bereits einen kleinen Betrieb führen.
Dieser Praxisbericht eröffnet das erste Kapitel unserer Themenwelt „Vom Linux-Arbeitsplatz zur Enterprise-Firmenplattform“. Im Mittelpunkt steht zunächst eine einfache Frage: Kann ein normaler Büroarbeitsplatz mit Linux tatsächlich produktiv betrieben werden?
Nicht das Betriebssystem, sondern die Aufgaben entscheiden
Ein Unternehmen benötigt nicht einfach „Windows“ oder „Linux“. Es benötigt funktionierende Arbeitsabläufe. Dazu gehört, im Internet zu recherchieren, E-Mails und Nachrichten zu bearbeiten, mit Kunden und Partnern zu kommunizieren, Dokumente, Tabellen und Präsentationen zu erstellen, Angebote und Rechnungen zu schreiben, Dateien zu übertragen, Passwörter zu verwalten, Bildschirmaufnahmen anzufertigen, Bilder, Ton und Videos zu bearbeiten sowie Webseiten und Software zu entwickeln.
Deshalb habe ich nicht zuerst nach einem möglichst Windows-ähnlichen Linux gesucht. Ich habe geprüft, welche Programme und Abläufe ich für meine tägliche Arbeit wirklich benötige.
Mein erster Linux-Arbeitsplatz
Linux Mint war für mich ein guter Einstieg. Die Oberfläche war verständlich, das System ließ sich ohne große Hürden installieren, und viele benötigte Anwendungen standen direkt zur Verfügung.
Für die Internetrecherche und Webanwendungen genügte ein gewöhnlicher Webbrowser, für die Bürokommunikation nutzte ich WhatsApp Web und Microsoft Teams direkt im Browser. Textverarbeitung und Tabellen liefen über LibreOffice und zeitweise über ONLYOFFICE, Videos schnitt ich mit Kdenlive, Ton bearbeitete ich mit Audacity. Für die Dateiübertragung setzte ich auf FileZilla, für Bildschirmaufnahmen auf SimpleScreenRecorder und für die Passwortverwaltung auf KeePassXC. Bei der Webentwicklung half mir der Bluefish Editor, bei der Quellcodebearbeitung VSCodium, Diagramme und Abläufe hielt ich mit draw.io fest, und vorhandene PSD-Dateien bearbeitete ich mit Photopea.
Damit konnte ich einen großen Teil meines normalen Büroalltags bereits unter Linux erledigen.
VSCodium ersetzte dabei für meine Aufgaben Visual Studio Code – allerdings kein vollständiger Ersatz für jede Entwicklungsumgebung oder jeden speziellen Visual-Studio-Workflow. Auch das gehört zu einer ehrlichen Bewertung: Eine Software kann für einen bestimmten Arbeitsplatz hervorragend geeignet sein, ohne sämtliche Einsatzbereiche des ursprünglichen Programms abzudecken.
Die größte Herausforderung waren über 400 Dokumente
Der Linux-Desktop war relativ schnell arbeitsfähig. Deutlich mehr Aufwand verursachten meine vorhandenen Daten. Ich besaß mehr als 400 DOCX-Dokumente, viele davon mit Zeichnungen, Abläufen und miteinander verbundenen Formen, die direkt mit den Diagrammwerkzeugen von Microsoft Word erstellt worden waren.
Beim Öffnen und Übertragen in andere Formate wurden diese Elemente nicht immer so dargestellt, wie ich es erwartete. Teilweise verschoben sich Formen, Verbindungen oder Beschriftungen. Eine einfache Konvertierung in das freie ODT-Format reichte deshalb nicht aus.
Ich entschied mich, die wichtigen Diagramme in draw.io neu zu erstellen. Das war viel Arbeit, hatte aber einen entscheidenden Vorteil: Die Diagramme waren anschließend nicht mehr fest an Microsoft Word gebunden. Sie konnten separat gepflegt, exportiert und in unterschiedlichen Dokumenten verwendet werden.
Gerade Zusammenfassungen, Prozessdarstellungen und technische Dokumentationen musste ich teilweise vollständig nachzeichnen. Rückblickend hat sich dieser Aufwand trotzdem gelohnt: Die Dokumente lassen sich heute mit LibreOffice zuverlässig bearbeiten, während die Diagramme als eigenständige Dateien erhalten bleiben.
Datenkonsistenz ist wichtiger als eine schnelle Konvertierung
Bei einer Migration darf es nicht nur darum gehen, ob sich eine Datei öffnen lässt. Entscheidend ist, ob ihre Inhalte vollständig und langfristig nutzbar bleiben. Für wichtige Dokumente hat sich bei mir deshalb ein mehrstufiges Vorgehen bewährt: Die ursprünglichen Dateien werden zunächst unverändert archiviert, kritische Dokumente einzeln in der neuen Anwendung geprüft und eine PDF-Version als optische Referenz aufbewahrt. Dokumente für die weitere Bearbeitung speichere ich möglichst in einem offenen Format, Diagramme, Bilder und andere eingebettete Inhalte lege ich zusätzlich als eigenständige Quelldateien ab. Erst nach erfolgreicher Kontrolle erkläre ich die neue Datei zur führenden Arbeitsversion – und alle Versionen fließen in ein funktionierendes Backup ein.
So bleibt nachvollziehbar, wie das Original aussah und welche Datei zukünftig weiterbearbeitet werden soll.
LibreOffice wurde zu meiner Hauptlösung
Anfangs nutzte ich LibreOffice und ONLYOFFICE parallel. ONLYOFFICE half mir besonders bei komplexeren DOCX-Dateien, deren Gestaltung sich stark an Microsoft Word orientierte. LibreOffice überzeugte mich dagegen durch seine lange Entwicklungsgeschichte, die offene Projektstruktur und die gute Unterstützung des OpenDocument-Formats.
Heute ist LibreOffice meine zentrale Office-Lösung auf dem Arbeitsplatz. ONLYOFFICE ist weiterhin installiert und wird von mir vor allem als Kompatibilitätswerkzeug eingesetzt, auch in meiner Nextcloud-Umgebung, weil meine dort verwendeten DOCX- und ODT-Dokumente zuverlässig dargestellt werden.
Meine Entscheidung gegen ONLYOFFICE als alleinige Hauptlösung ist keine Bewertung seiner technischen Leistungsfähigkeit. Sie beruht auf meiner persönlichen Risikobewertung der öffentlich diskutierten Eigentums-, Entwicklungs- und Kontrollstrukturen. Der Hersteller erklärt, dass die Rechte an ONLYOFFICE bei der lettischen Ascensio System SIA liegen, die zu einer Holding in Singapur gehört. Das Euro-Office-Projekt kritisiert dagegen unter anderem mangelnde Transparenz, schwer nachvollziehbare Entwicklungsprozesse und einen weiterhin großen Anteil russischer Entwickler. Für Anwender ergibt sich damit kein einfacher Schwarz-Weiß-Befund, sondern ein Punkt, der bei sensiblen Einsatzbereichen geprüft werden sollte.
Warum ich Euro-Office aufmerksam beobachte
Euro-Office ist aus einem Fork der freien ONLYOFFICE-Codebasis entstanden. Das Projekt wird von einer europäischen Initiative unterstützt, zu der unter anderem Nextcloud, IONOS, OpenProject, XWiki und weitere Organisationen gehören.
Die Codebasis soll öffentlich überprüft, bereinigt und unter einer transparenteren europäischen Governance weiterentwickelt werden. Gleichzeitig befindet sich das Projekt noch in einer frühen Entwicklungsphase. Es ist aktuell vor allem als integrierbare Online-Komponente gedacht; Desktop- und Mobilanwendungen werden erst weiterentwickelt.
Deshalb beobachte ich Euro-Office mit großer Erwartung, betrachte es aber noch nicht automatisch als fertigen Ersatz für LibreOffice. Das Projekt muss in der Praxis erst zeigen, wie gut Kompatibilität, Stabilität, nachvollziehbare Entwicklung und langfristige Wartung zusammenspielen. Für meinen Arbeitsplatz bleibt LibreOffice deshalb vorerst die Hauptlösung, ONLYOFFICE dient als Kompatibilitätsbrücke, und Euro-Office wird in das weitere OpenBüro-Praxislabor aufgenommen.
Bestehende Photoshop-Dateien müssen nicht verloren gehen
Eine ähnliche Herausforderung entsteht bei Photoshop-Dateien. Wer über viele PSD-Dateien verfügt, kann nicht immer sämtliche Vorlagen sofort mit GIMP oder Krita neu aufbauen. Hier kann Photopea als Übergangslösung helfen: Die Anwendung läuft im Browser, kann PSD-Dateien öffnen und wieder im PSD-Format speichern. Nach Angaben des Anbieters erfolgt die Verarbeitung lokal auf dem verwendeten Gerät. Trotzdem bleibt Photopea eine browserbasierte, nicht vollständig freie Anwendung und sollte daher als Kompatibilitätswerkzeug betrachtet werden.
Auch hier gilt: Wichtige Dateien müssen einzeln geprüft werden. Besondere Schriften, Effekte, Smart Objects oder komplexe Ebenen können eine Nachbearbeitung erfordern.
Dual Boot als risikoarmer Einstieg
Ein Unternehmen muss seinen vorhandenen Windows-Arbeitsplatz nicht an einem einzigen Tag ersetzen. Ein Dual-Boot-System kann eine gute Möglichkeit sein, Linux zunächst parallel aufzubauen. Dabei wird Linux zusätzlich zu Windows installiert, und beim Start des Computers kann ausgewählt werden, welches Betriebssystem verwendet werden soll. So lassen sich Programme, Drucker, Scanner, Dokumente und Arbeitsabläufe Schritt für Schritt testen.
In der Praxis bewährt sich dabei ein klarer Ablauf: Zunächst werden die benötigten Programme und Dateiformate erfasst, dann wird Linux parallel installiert und die wichtigsten Anwendungen eingerichtet. Anschließend führt man reguläre Arbeitstage vollständig unter Linux durch, dokumentiert problematische Abläufe und erarbeitet Lösungen dafür. Erst wenn das zuverlässig funktioniert, wird Linux schrittweise zum Hauptsystem, während Windows nur noch für einzelne Ausnahmefälle vorgehalten wird. Dadurch wird aus einem theoretischen Test ein echter Pilotbetrieb.
Ist Dual Boot auch eine Störreserve?
Teilweise. Wenn beispielsweise die Windows-Installation durch ein fehlerhaftes Update nicht mehr startet, kann das Linux-System weiterhin verfügbar sein. Der Rechner bleibt arbeitsfähig, und wichtige webbasierte Dienste, E-Mails oder Dokumente können unter Umständen weiter genutzt werden.
Eine vollständige Störreserve ist Dual Boot jedoch nicht. Beide Systeme befinden sich auf demselben Computer – fällt die SSD, das Mainboard oder ein anderes wichtiges Bauteil aus, sind beide Betriebssysteme betroffen. Eine echte Störreserve benötigt deshalb zusätzlich einen zweiten einsatzbereiten Computer oder Datenträger, eine dokumentierte Installation, aktuelle Datensicherungen, Zugangsdaten und Wiederherstellungsschlüssel sowie regelmäßig getestete Wiederanlaufverfahren.
Dual Boot schützt damit vor bestimmten Softwareproblemen und erleichtert die Migration. Es ersetzt aber weder ein Backup noch einen unabhängigen Ersatzarbeitsplatz.
Wo ein Linux-Arbeitsplatz weiterhin Grenzen hat
Für einen normalen Büroarbeitsplatz lässt sich heute sehr viel mit Linux abdecken. Schwierigkeiten entstehen vor allem bei stark proprietären oder spezialisierten Abläufen – etwa bei branchenspezifischen Windows-Programmen, komplexen Microsoft-Office-Makros, Access-Datenbanken, speziellen Teams- oder Outlook-Erweiterungen, Herstellerprogrammen für Maschinen und Messgeräte, Hardware ohne geeignete Linux-Treiber, Dokumenten mit ungewöhnlichen Schriftarten und eingebetteten Objekten sowie Entwicklungsprojekten, die zwingend eine vollständige Visual-Studio-Umgebung benötigen.
Deshalb sollte die Entscheidung nicht lauten: „Funktioniert Linux in unserem Unternehmen?“ Die bessere Frage ist: Welche Aufgaben muss dieser konkrete Arbeitsplatz erfüllen – und welche davon können bereits zuverlässig unter Linux erledigt werden?
Fazit: Der langsame Wechsel war der richtige Weg
Mein Linux-Arbeitsplatz entstand nicht durch einen radikalen Austausch. Er entwickelte sich aus einem privaten Testsystem, wurde nach und nach mit produktiver Software ausgestattet und übernahm immer mehr Aufgaben.
Der größte Aufwand bestand nicht in der Installation von Linux. Die eigentliche Arbeit lag in der Übertragung meiner Dokumente, Diagramme und gewachsenen Arbeitsweisen. Mehr als 400 Dateien zu prüfen und teilweise neu aufzubereiten war zeitintensiv – gleichzeitig entstand dadurch eine deutlich unabhängigere und besser strukturierte Arbeitsumgebung.
Für kleine Unternehmen ist genau dieser schrittweise Weg besonders interessant: Linux zunächst parallel einsetzen, reale Arbeitsabläufe testen, Daten kontrolliert migrieren und erst danach den vollständigen Wechsel durchführen.
Ein produktiver Linux-Arbeitsplatz ist damit kein Selbstzweck. Er ist der erste Baustein einer größeren Entwicklung – vom einzelnen unabhängigen Rechner bis hin zur souveränen Enterprise-Firmenplattform.
