Abschied von der US-Cloud: Lehren für die Open Source Cloud Migration aus dem Wechsel des Schweizer Militärs zu OpenDesk

Die geopolitische Wende: Warum das Schweizer Militär die Microsoft Cloud verließ

Als das Kommando Cyber der Schweizer Armee den Wechsel zur Open-Source-Workplace-Suite OpenDesk ankündigte, löste dies in der europäischen IT-Branche eine Welle der Überraschung aus. Diese Migration ist keine geringfügige politische Anpassung, sondern eine fundamentale Abkehr von proprietären Software-Ökosystemen. Unter der Führung von Armeechef Thomas Süssli und dem Leiter des Kommandos Cyber, Simon Müller, stellt das Militär seine primären Arbeitsplatzlösungen von Microsoft-Cloud-Umgebungen um. Bis Oktober 2026 sollen die Arbeitsplätze des Kommandos Cyber vollständig auf souveränen Open-Source-Alternativen laufen.

Der Treiber hinter dieser Entscheidung ist simpel: digitale Souveränität. In der Schweiz sind rund 90 % der militärischen Dokumente als „intern“ oder „geheim“ eingestuft. Nach den Schweizer Bundesrichtlinien ist die Verarbeitung dieser Informationen in einer Public Cloud, die von US-amerikanischen Konzernen kontrolliert wird, rechtlich problematisch und operativ unsicher. Der US Cloud Act ermöglicht es US-Strafverfolgungsbehörden, amerikanische Unternehmen zur Herausgabe von Daten zu zwingen, die auf ihren Servern gespeichert sind – unabhängig davon, wo sich diese Daten physisch befinden.

Zudem wies das Militär auf das Risiko obligatorischer „Call-Home“-Telemetriefunktionen in proprietärer Software hin – undokumentierte Datenübertragungen, die Systeminformationen an ausländische Server weitergeben. Um dieses Risiko zu minimieren, baut das Kommando Cyber eine eigene Private Cloud-Infrastruktur auf. Dieses selbst gehostete Setup stellt sicher, dass sämtliche Kommunikation und Daten in physischen Rechenzentren auf Schweizer Boden verbleiben. Die Strategie des Militärs bringt bereits aktive Software hervor: Kürzlich wurde das maßgeschneiderte Open-Source-Such- und Analysewerkzeug „Loom“ (Version 1.0.0, veröffentlicht Mitte 2026) freigegeben, um große Mengen unstrukturierter Daten lokal und ohne jegliche Internetverbindung zu durchsuchen.

Definition des Kernproblems: Die Vendor Lock-in-Falle

Sowohl für Privatunternehmen als auch für die öffentliche Verwaltung stellt der Vendor Lock-in ein wachsendes finanzielles und operatives Risiko dar. Wenn Sie Ihren gesamten IT-Stack auf einen einzigen proprietären Anbieter ausrichten, geben Sie die Preishoheit, die Data Governance und die operative Kontrolle ab. Betrachten wir die Zahlen: Ein Microsoft 365 E5-Abonnement kostet derzeit 57 USD pro Benutzer und Monat. Für ein mittelständisches Unternehmen mit 5.000 Mitarbeitern bedeutet dies wiederkehrende Software-Lizenzkosten von 285.000 USD pro Monat – beziehungsweise 3,42 Millionen USD jährlich.

Wenn der Anbieter beschließt, die Preise über Nacht um 15 % zu erhöhen oder eine Migration auf eine weniger sichere Cloud-Stufe zu erzwingen, hat das Unternehmen kaum Handlungsoptionen. Die Migration von Millionen von Dateien, E-Mail-Archiven und Benutzerprofilen ist eine enorme technische Herausforderung, die schnelle Übergänge fast unmöglich macht. Dies ist der gelebte „Cloud-Zwang“. Unternehmen werden gedrängt, lokale Server außer Betrieb zu nehmen und in Public Clouds zu migrieren, wodurch sie die Kontrolle darüber verlieren, wo ihre Daten verarbeitet werden und wer Zugriff darauf hat.

Neben dem finanziellen Druck ist Compliance eine gewaltige Hürde. Unter der DSGVO und dem Schrems-II-Urteil erfordert die Übertragung personenbezogener Daten europäischer Bürger in US-Cloud-Dienste strenge Schutzmaßnahmen, die bei öffentlichen SaaS-Konfigurationen oft nicht einzuhalten sind. Wenn Telemetriedaten mit IP-Adressen, Protokollen über Benutzeraktivitäten und Dokumenten-Metadaten an ausländische Server gesendet werden, riskieren Unternehmen empfindliche behördliche Bußgelder.

OpenDesk: Die Architektur souveräner Zusammenarbeit

Um dem Vendor Lock-in entgegenzuwirken, hat das Bundesministerium des Innern und für Heimat (BMI) OpenDesk initiiert, einen webbasierten Open-Source-Arbeitsplatz. OpenDesk ist als direkter, modularer Konkurrent zu Microsoft 365 und Google Workspace konzipiert. Statt eines monolithischen SaaS-Modells bündelt OpenDesk ausgereifte, unabhängige Open-Source-Projekte zu einer einheitlichen, nahtlosen User Experience.

Die modulare Architektur von OpenDesk ermöglicht es, die Komponenten in einer Private Cloud-Umgebung zu betreiben – entweder on-premises gehostet oder bei europäischen Cloud-Anbietern mit strengen Souveränitätsgarantien. Diese Struktur stellt sicher, dass Organisationen die volle administrative Kontrolle über die Datenflüsse behalten. Das offene Ökosystem bedeutet, dass kein einzelner Anbieter die Daten Ihres Unternehmens als Geisel nehmen oder einseitig die Abonnementgebühren erhöhen kann.

Wichtige OpenDesk-Komponenten und offene Alternativen

Diese Architektur stützt sich bei der Orchestrierung stark auf Kubernetes und Helm-Charts, was sie hochgradig reproduzierbar und skalierbar macht. Wenn ein Unternehmen diesen Stack bereitstellen möchte, kann es die vollständige Kontrolle über die Datenströme behalten, jegliche Telemetrie deaktivieren und sicherstellen, dass keine Daten seine Virtual Private Cloud (VPC) verlassen.

Code-Walkthrough: Durchführung der Datenmigration aus Microsoft Graph

Der Abschied von Microsoft 365 erfordert eine zuverlässige Methode, um Daten aus proprietären APIs zu extrahieren und in die von OpenDesk genutzten offenen Standards zu importieren. Unten finden Sie ein Python-Migrationsskript, das zeigt, wie Sie Kalenderereignisse aus Microsoft Graph extrahieren und in einen souveränen CalDAV-Server (wie Nextcloud oder Open-Xchange) importieren.

Dieses Skript übernimmt die OAuth2-Authentifizierung mit Microsoft Graph, ruft Kalendereinträge ab, konvertiert sie in das standardmäßige GFM-iCalendar-Format und überträgt sie über WebDAV-APIs direkt an den Ziel-CalDAV-Server.

import os
import datetime
import requests
from caldav import DAVClient
from icalendar import Calendar, Event

# Configuration for source MS Graph and target CalDAV server
GRAPH_API_URL = "https://graph.microsoft.com/v1.0"
CLIENT_ID = os.getenv("MS_CLIENT_ID")
CLIENT_SECRET = os.getenv("MS_CLIENT_SECRET")
TENANT_ID = os.getenv("MS_TENANT_ID")

CALDAV_URL = "https://nextcloud.internal/remote.php/dav/calendars/username/personal/"
CALDAV_USER = "migration_admin"
CALDAV_PASS = os.getenv("CALDAV_PASSWORD")

def get_graph_token() -> str:
    """Retrieve OAuth2 token for Microsoft Graph API via Client Credentials Flow."""
    url = f"https://login.microsoftonline.com/{TENANT_ID}/oauth2/v2.0/token"
    headers = {"Content-Type": "application/x-www-form-urlencoded"}
    data = {
        "client_id": CLIENT_ID,
        "scope": "https://graph.microsoft.com/.default",
        "client_secret": CLIENT_SECRET,
        "grant_type": "client_credentials"
    }
    response = requests.post(url, headers=headers, data=data)
    response.raise_for_status()
    return response.json()["access_token"]

def fetch_exchange_events(token: str, user_email: str, start_date: datetime.datetime, end_date: datetime.datetime) -> list:
    """Fetch calendar events for a specific user from MS Exchange via Graph API."""
    url = f"{GRAPH_API_URL}/users/{user_email}/calendarView"
    headers = {"Authorization": f"Bearer {token}"}
    params = {
        "startDateTime": start_date.isoformat(),
        "endDateTime": end_date.isoformat(),
        "$top": 100
    }
    response = requests.get(url, headers=headers, params=params)
    response.raise_for_status()
    return response.json().get("value", [])

def convert_to_ical(graph_event: dict) -> str:
    """Convert MS Graph event structure to standard vCalendar/iCalendar format."""
    cal = Calendar()
    cal.add('prodid', '-//[ProjectMakers](https://projectmakers.de) Sovereign Migration Tool//EN')
    cal.add('version', '2.0')
    
    event = Event()
    event.add('summary', graph_event.get('subject', 'Untitled Event'))
    
    # Parse UTC times (MS Graph outputs timezone-naive format with 'Z')
    start_str = graph_event['start']['dateTime'].replace('Z', '+00:00')
    end_str = graph_event['end']['dateTime'].replace('Z', '+00:00')
    start_time = datetime.datetime.fromisoformat(start_str)
    end_time = datetime.datetime.fromisoformat(end_str)
    
    event.add('dtstart', start_time)
    event.add('dtend', end_time)
    event.add('description', graph_event.get('bodyPreview', ''))
    event.add('uid', graph_event.get('id'))
    
    cal.add_component(event)
    return cal.to_ical().decode('utf-8')

def import_to_caldav(ical_data: str, event_id: str):
    """Write standard iCalendar data directly into the sovereign CalDAV server."""
    client = DAVClient(url=CALDAV_URL, username=CALDAV_USER, password=CALDAV_PASS)
    principal = client.principal()
    calendars = principal.calendars()
    
    if not calendars:
        raise RuntimeError("No active calendars found on the target sovereign server.")
        
    target_calendar = calendars[0]
    target_calendar.save_event(ical_data)
    print(f"Successfully migrated event: {event_id}")

def execute_migration():
    """Orchestrate the migration flow for the target user."""
    try:
        token = get_graph_token()
        target_user = "[email protected]"
        
        # Migrate events for the upcoming 30 days
        start = datetime.datetime.utcnow()
        end = start + datetime.timedelta(days=30)
        
        print(f"Starting migration for {target_user}...")
        events = fetch_exchange_events(token, target_user, start, end)
        print(f"Retrieved {len(events)} events from Microsoft Graph API.")
        
        for event in events:
            try:
                ical_data = convert_to_ical(event)
                import_to_caldav(ical_data, event['id'])
            except Exception as item_error:
                print(f"Error migrating event {event.get('id', 'unknown')}: {item_error}")
                
    except Exception as api_error:
        print(f"Migration script aborted due to fatal API error: {api_error}")

if __name__ == "__main__":
    execute_migration()

Erläuterung der Migrationsarchitektur

Dieses Skript ist so strukturiert, dass die Datentransformation vollständig auf lokalen, sicheren Systemen erfolgt. Indem wir JSON-Ereignisobjekte aus der Graph-API von Microsoft abrufen, die Felder parsen und das Standardformat RFC 5545 iCalendar (.ics) generieren, umgehen wir proprietäre Kalenderdatenbanken. Die standardmäßige String-Repräsentation wird anschließend über einen sicheren HTTP-Request direkt an den souveränen CalDAV-Server übergeben.

Die Verwendung von Standardprotokollen wie CalDAV und WebDAV stellt sicher, dass Ihr Code und Ihre Werkzeuge funktionsfähig bleiben, falls Sie den Backend-Anbieter erneut wechseln (beispielsweise von Nextcloud zu Open-Xchange oder SOGo). Diese Unabhängigkeit auf Protokollebene ist ein Grundpfeiler der digitalen Souveränität. Sie reduziert die Migrationskomplexität bei zukünftigen Updates und verhindert neue Formen des Vendor Lock-in.

Die technischen Herausforderungen einer Open Source Cloud Migration

Obwohl Open Source Cloud Migrationen eine beispiellose Sicherheit und Kostenkontrolle bieten, handelt es sich dabei um komplexe Systems-Engineering-Projekte. Eine erfolgreiche Migration besteht nicht nur darin, Docker-Container zu starten; sie erfordert die Verwaltung von Datenschemata, Identity Provisioning und Benutzer-Workflows. Organisationen müssen diese Herausforderungen mit strukturierten Entwicklungsmethoden angehen.

Datenstrukturen müssen bereinigt, transformiert und validiert werden, um eine Beschädigung von Kalender-Zeitzonen oder den Verlust von E-Mail-Anhängen zu vermeiden. Um kostspielige Nachbesserungen zu verhindern und die Sicherheitsteams aufeinander abzustimmen, müssen Unternehmen in eine detaillierte Pre-Migration-Planung investieren. Das Verständnis der Vorteile kollaborativer Softwaremodellierung vor dem Schreiben des ersten Migrationsskripts ist entscheidend, um das Zusammenspiel verschiedener Dienste wie Nextcloud und Open-Xchange zu koordinieren.

Die Konzeption von Benutzerverzeichnissen, Authentifizierungs-Flows und Container-Netzwerktopologien stellt sicher, dass sich alle Systeme nahtlos integrieren. Darüber hinaus ist die Akzeptanz der Nutzer ein wesentlicher Faktor, da die Mitarbeiter an Schnittstellen von Microsoft oder Google gewöhnt sind. Der Übergang zu OpenDesk erfordert ein aktives Change Management und gründliche Anwenderschulungen, um die Entstehung von Schatten-IT zu verhindern.

Jenseits von Office-Suites: Souveränität über den gesamten Stack

Digitale Souveränität geht über Office-Produktivitätswerkzeuge wie Mail und Dokumente hinaus; sie betrifft direkt das Tooling im Software Development Lifecycle (SDLC). Wenn Ihre Organisation ihren Quellcode, ihre Build-Chains und ihre CI/CD-Pipelines in zentralisierten Repositories im Besitz von US-Unternehmen hostet, stehen Sie vor genau denselben geopolitisch motivierten Sicherheitsrisiken. Die Bewegung hin zu Open-Source-Hosting und selbstverwalteten Codebasen gewinnt in ganz Europa an Dynamik.

Prominente Verschiebungen zeigen, dass Entwickler souveräne Räume anstreben. Dies belegen Initiativen wie Thomas Dohmkes GitHub-Alternative Entire, die darauf abzielt, dedizierte Repositories für die KI-Entwicklung außerhalb zentralisierter Tech-Monopole bereitzustellen. Der Betrieb von Code-Repositories, Dokumentenfreigaben und Identity Management auf einer von Ihnen kontrollierten Infrastruktur schützt Ihr geistiges Eigentum vor externer Einflussnahme. Diese strukturelle Resilienz entspricht genau dem, was das Schweizer Militär mit seiner Migrationsstrategie erreicht hat.

Praktikable Best Practices für Ihre Migrationsstrategie

Wenn Ihre Organisation eine Open Source Cloud Migration plant, vermeiden Sie eine „Big-Bang“-Umstellung. Folgen Sie stattdessen einem strukturierten, risikominimierten Pfad. Die folgenden Tipps helfen Ihnen, einen reibungslosen Übergang zu souveränen Systemen zu gewährleisten.

Datenformate vor der Migration standardisieren Legen Sie vor der Migration von Dateien offene Standards wie das OpenDocument-Format (ODF) für Office-Dateien und iCalendar für Zeitpläne fest. Führen Sie Validierungsskripte aus, um Dokumente mit proprietären Makros oder Formaten zu identifizieren, die bei der Konvertierung Probleme verursachen.
Hybrides föderiertes Identitätsmodell etablieren Versuchen Sie nicht, Ihr gesamtes Benutzerverzeichnis über Nacht zu migrieren. Implementieren Sie einen offenen Identity-Broker (wie Keycloak), der Ihr bestehendes Active Directory mit den neuen souveränen Diensten verbindet. Dies ermöglicht es den Benutzern, sich während der Übergangsphase über Single Sign-on (SSO) sowohl an alten als auch an neuen Systemen zu authentifizieren.
Klare Data Governance etablieren und Telemetrie deaktivieren Überprüfen Sie bei der Bereitstellung von OpenDesk-Komponenten jede Konfigurationsdatei, um externes Tracking, Analysen und automatische Update-Prüfungen zu deaktivieren, die externe Server kontaktieren könnten. Richten Sie Egress-Firewalls ein, um sicherzustellen, dass die Hosting-Umgebung nur mit autorisierten IP-Adressen kommuniziert.
Kontinuierliche Load-Tests auf souveränen Nodes durchführen Selbst gehostete Collaboration-Suites erfordern eine sorgfältige Dimensionierung der Infrastruktur. Führen Sie vor dem Onboarding der Benutzer synthetische Load-Tests mit Tools wie Locust oder JMeter durch, um die gleichzeitige Bearbeitung von Dokumenten und Videoanrufe zu simulieren. Dies stellt sicher, dass Ihr Kubernetes-Cluster bei Spitzenlast dynamisch skaliert.

Partnerschaft für digitale Souveränität

Der Aufbau einer sicheren, complianten Open-Source-Cloud-Infrastruktur im eigenen Haus erfordert hochspezialisiertes Fachwissen. Die Einrichtung von Kubernetes-Deployments, die Konfiguration der Föderierung über Keycloak und das Management sicherer Migrations-Pipelines sind eine Vollzeit-Engineering-Heraforderung. Die Einstellung eines dedizierten DevOps-Teams für eine vorübergehende Übergangsphase ist teuer und birgt operative Risiken.

Ein erfahrener Partner wie ProjectMakers realisiert diesen Übergang als gemanagtes Festpreisprojekt und stellt sicher, dass Ihre Systeme ohne Vendor Lock-in für langfristige Skalierbarkeit gerüstet sind. Wir entwickeln maßgeschneiderte Softwarelösungen, entwerfen Enterprise-Architekturen und unterstützen Organisationen beim Aufbau vollständig souveräner Open-Source-Infrastrukturen. Unser Team sorgt dafür, dass Ihre digitale Transformation mit den europäischen Datenschutzbestimmungen übereinstimmt.

Planen Sie ein souveränes Software-, Cloud- oder App-Migrationsprojekt? Kontaktieren Sie ProjectMakers für ein kostenloses Erstgespräch.

Quelle: Cyber-Spezialisten des Schweizer Militärs verlassen Microsoft-Cloud