Digitale Souveränität beginnt nicht mit der Auswahl einer Office-Suite, sondern mit der Kontrolle über Daten, Identitäten, Dateiformate und den späteren Betrieb. Für KMU ist der richtige erste Schritt daher kein Komplettwechsel, sondern ein begrenzter Pilot mit klaren Ausstiegskriterien. Stand: 12.10.2026.

Aktueller Anlass: Vom 13. bis 15. Oktober stellt das Zentrum für Digitale Souveränität (ZenDiS) auf der Smart Country Convention in Berlin seine Projekte rund um digitale Souveränität vor. Das Thema ist damit nicht nur ein Beschaffungsthema der Verwaltung. Es liefert auch für Unternehmen eine praktische Frage: Wie abhängig ist der eigene Arbeitsalltag von einzelnen Cloud-, Office- und Entwicklerplattformen?

Auf einen Blick

  • Open Source allein schafft keine Souveränität; entscheidend sind Daten, Identitäten, Formate und Betrieb.
  • Ein Pilot mit einer abgegrenzten Nutzergruppe reduziert Migrations- und Akzeptanzrisiken.
  • DOCX, XLSX und PPTX müssen mit echten Arbeitsdokumenten getestet werden, nicht nur mit Beispieldateien.
  • openCode ist für den Quellcode-Austausch gedacht; Office- und Kollaborationsplattformen lösen andere Aufgaben.
  • Vor dem Rollout braucht jedes Team ein klares Rückfall- und Supportkonzept.

Warum die Lieferkette wichtiger ist als das einzelne Produkt

Viele Gespräche über digitale Souveränität starten bei einer Produktliste: Microsoft 365 ersetzen, eine europäische Office-Suite auswählen oder Git-Hosting verlagern. Das greift zu kurz. Im Alltag hängt ein Arbeitsplatz an mehreren Bausteinen: Anmeldung und Rollen, Dateiablage, gemeinsame Bearbeitung, Kalender, Videokonferenzen, Schnittstellen, Backups und die Frage, wer bei einer Störung handeln kann.

Wenn nur das Frontend ersetzt wird, bleiben oft die wichtigsten Abhängigkeiten bestehen. Beispiel: Eine Office-Anwendung kann Open Document Format unterstützen, während die Freigabeprozesse, die Identitätsverwaltung oder die wichtigsten Vorlagen weiterhin an externe Dienste gebunden sind. Souveränität ist deshalb keine Ja-Nein-Eigenschaft eines Produkts. Sie ist die Fähigkeit, kritische Teile der eigenen Arbeitsumgebung nachvollziehbar zu betreiben, zu wechseln oder wiederherzustellen.

Für eine erste Einordnung helfen die drei Plattformen, die wir auch auf unserer Seite zu Open-Source-Software betrachten: OpenDesk als kollaborativer Arbeitsplatz, Euro-Office als europäische Office-Suite und openCode als Plattform für Open-Source-Code. Sie sind nicht austauschbar. Ein belastbarer Plan ordnet zunächst die jeweiligen Aufgaben zu.

Welche Frage sollte vor einem Pilot beantwortet werden?

Die Kernfrage lautet nicht: „Kann die neue Lösung alles wie bisher?“ Sie lautet: „Welche Arbeitsabläufe müssen nach dem Pilot nachweislich funktionieren – und welche können wir bewusst anders gestalten?“ Daraus entsteht ein Testkatalog statt einer Bauchentscheidung.

Für Office-Arbeit gehören dazu reale Vorlagen, umfangreiche Tabellen, Präsentationen mit externen Inhalten, Kommentare, Freigaben und gemeinsame Bearbeitung. Wer in DACH-Teams regelmäßig DOCX-, XLSX- oder PPTX-Dateien mit Kunden austauscht, sollte genau diese Dateien testen. Technische Kompatibilitätsangaben sind hilfreich, ersetzen aber keinen Test mit den zehn Dokumenten, die im Betrieb wirklich kritisch sind.

Für Entwicklerteams kommen weitere Fragen hinzu: Wo liegen Repositories und Artefakte? Welche CI/CD-Jobs, Paketquellen oder Container-Images werden benötigt? Wie werden Zugriffe entzogen, wenn Mitarbeitende das Team verlassen? Die öffentliche Plattform openCode richtet sich auf den rechtssicheren Austausch von Open-Source-Code zwischen Verwaltung und Anbietern. Für ein KMU kann sie deshalb ein Referenzpunkt für offene Zusammenarbeit sein, ersetzt aber nicht automatisch die eigene Entscheidung für internes Git-Hosting oder eine Entwicklungsplattform.

Ein Pilot braucht vier Grenzen

Ein Pilot wird beherrschbar, wenn sein Umfang bewusst klein bleibt. Erstens braucht er eine Nutzergruppe, deren Arbeit repräsentativ, aber nicht geschäftskritisch in jeder Minute ist. Zweitens braucht er einen Zeitraum mit einem festen Auswertungstermin. Drittens braucht er vorab definierte Erfolgskriterien: etwa die fehlerfreie Bearbeitung bestimmter Vorlagen, funktionierende Rechteverwaltung oder eine akzeptable Supportlast. Viertens braucht er eine Rückfalloption für den Fall, dass eine kritische Funktion noch nicht zuverlässig abgedeckt ist.

Das ist kein Zeichen fehlender Entschlossenheit. Es verhindert, dass ein Wechsel zur Schatten-IT führt: Mitarbeitende würden sonst im Zweifel private Tools, persönliche Accounts oder nicht abgestimmte Exportwege nutzen. Gerade bei personenbezogenen Daten und vertraulichen Dokumenten gehört die Migrationsplanung daher mit der IT-Sicherheit zusammen. Rollen, Mehrfaktor-Authentisierung, Protokollierung, Backup und Wiederherstellung sind vor dem breiten Rollout zu prüfen.

Was muss technisch und organisatorisch dokumentiert sein?

Eine gute Pilotdokumentation ist kurz, aber konkret. Sie hält fest, welche Daten migriert wurden, welche Daten bewusst nicht migriert werden, wie Konten angelegt und gesperrt werden, wer Administratorrechte besitzt und wohin sich Nutzende bei Problemen wenden. Ebenso wichtig ist ein Export- und Restore-Test. Daten gelten erst dann als kontrollierbar, wenn ein Team sie in einem verständlichen Format exportieren und wieder einspielen kann.

Bei Office- und Kollaborationssystemen sollte auch die Zusammenarbeit mit Externen geklärt sein: Welche Freigaben sind erlaubt? Wie lange bleiben Links gültig? Welche Dokumente dürfen per E-Mail versendet werden? Für Code-Plattformen kommen Lizenzhinweise, Zugriffsrechte für Dienstleister und die Behandlung von Secrets hinzu. Kein Tool nimmt diese Entscheidungen ab.

Wann ist ein schrittweiser Betrieb sinnvoll?

Für die meisten KMU ist ein hybrider Übergang realistischer als ein Stichtag. Einzelne Teams oder klar definierte Abläufe wechseln zuerst. Der Parallelbetrieb darf aber kein Dauerzustand ohne Regeln werden. Sonst entstehen doppelte Dateien, widersprüchliche Berechtigungen und unklare Verantwortlichkeiten.

Deshalb sollte jede Übergangsphase ein Ende haben: Welche Gruppe wechselt wann, welche Systeme bleiben aus welchem Grund parallel, und welches Ereignis beendet die Ausnahme? Das schafft Transparenz für Management und Mitarbeitende. Es macht außerdem Kosten, Supportaufwand und Risiken sichtbar, bevor sie sich im Betrieb verstecken.

Fazit

Die aktuelle Sichtbarkeit von ZenDiS und openCode auf der Smart Country Convention macht deutlich: Digitale Souveränität wird praktisch, wenn sie als Betriebsfrage behandelt wird. Für KMU lautet die Priorität nicht „alles ersetzen“, sondern Abhängigkeiten sichtbar machen und einen messbaren Pilot sauber betreiben. OpenDesk, Euro-Office und openCode können Bausteine sein. Ob sie passen, entscheidet sich an realen Dokumenten, klaren Rollen, getesteten Exporten und einem Betrieb, der auch ohne Improvisation funktioniert.

Quellen