Ditching the US Cloud: Lessons in Open Source Cloud Migration from the Swiss Military's Move to OpenDesk

The Geopolitical Shift: Why the Swiss Military Ditched Microsoft Cloud

When the Swiss Armed Forces' Cyber Command (Kommando Cyber) announced its transition to the open-source workplace suite OpenDesk, it sent shockwaves through the European IT sector. This migration is not a minor policy adjustment; it is a major pivot away from proprietary software ecosystems. Led by army chief Thomas Süssli and Kommando Cyber head Simon Müller, the military is transitioning its primary workspace solutions away from Microsoft Cloud environments. By October 2026, the Cyber Command's workspaces are scheduled to run entirely on sovereign, open-source alternatives.

The driver behind this decision is simple: digital sovereignty. In Switzerland, approximately 90% of military documentation is classified as "internal" or "geheim" (secret). Under Swiss federal guidelines, processing this information in a public cloud controlled by US-based corporations is legally problematic and operationally insecure. The US Cloud Act allows US law enforcement to compel American companies to hand over data stored on their servers, regardless of where that data physically resides.

Furthermore, the military flagged the risk of mandatory "call home" telemetry functions in proprietary software—undocumented data transmissions that leak system information to foreign servers. To mitigate this risk, the Cyber Command is building a private cloud infrastructure. This self-hosted setup ensures that all communication and data remain within physical data centers located on Swiss soil. The military's strategy is already producing active software: they recently released a custom open-source search and analysis tool called "Loom" (version 1.0.0 released in mid-2026) to search large volumes of unstructured data locally, without any internet connection.

Defining the Core Problem: The Vendor Lock-In Trap

For private enterprises and public administrations alike, vendor lock-in is a growing financial and operational risk. When you build your entire IT stack on a single proprietary vendor, you surrender pricing power, data governance, and operational control. Consider the numbers: a Microsoft 365 E5 subscription currently costs $57 per user/month. For a mid-sized organization with 5,000 employees, this represents a recurring software license cost of $285,000 per month—or $3.42 million annually.

If the vendor decides to increase prices by 15% overnight, or force a migration to a less secure cloud tier, the enterprise has little recourse. Migrating millions of files, email archives, and user profiles is a massive technical challenge, making rapid transitions almost impossible. This is "Cloud-Zwang" (forced cloud adoption) in action. Companies are pushed to decommission local servers and migrate to public clouds, losing control over where their data is processed and who has access to it.

Beyond financial pressure, compliance is a massive hurdle. Under GDPR and the Schrems II ruling, transferring personal data of European citizens to US cloud services requires rigorous safeguards that are often impossible to meet under public SaaS configurations. When telemetry data containing IP addresses, user activity logs, and document metadata is sent to foreign servers, organizations run the risk of heavy regulatory fines.

OpenDesk: The Architecture of Sovereign Collaboration

To counter vendor lock-in, the German Federal Ministry of the Interior (BMI) initiated OpenDesk, an open-source web-based workplace. OpenDesk is designed as a direct, modular competitor to Microsoft 365 and Google Workspace. Instead of a monolithic SaaS model, OpenDesk aggregates mature, independent open-source projects into a single, cohesive user experience.

The modular architecture of OpenDesk allows components to be run in a private cloud environment, hosted either on-premises or by European cloud providers with strict sovereign guarantees. This structure ensures that organizations retain full administrative control over data flows. The open ecosystem means no individual vendor can hold your company's data hostage or unilaterally raise subscription fees.

Key OpenDesk Components and Open Alternatives

This architecture relies heavily on Kubernetes and Helm charts for orchestration, making it highly reproducible and scalable. If a company wants to deploy this stack, they can maintain complete control over data streams, disable all telemetry, and ensure that no data leaves their virtual private cloud (VPC).

Code Walkthrough: Executing the Data Migration from Microsoft Graph

Moving away from Microsoft 365 requires a reliable method for extracting data from proprietary APIs and importing it into the open standards utilized by OpenDesk. Below is a Python migration script that demonstrates how to extract calendar events from Microsoft Graph and import them into a sovereign CalDAV server (such as Nextcloud or Open-Xchange).

This script handles OAuth2 authentication with Microsoft Graph, retrieves calendar entries, converts them into standard GFM iCalendar format, and pushes them directly to the target CalDAV server via WebDAV APIs.

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()

Explaining the Migration Architecture

This script is structured to ensure that data transformation occurs entirely on local, secure systems. By pulling JSON event objects from Microsoft's Graph API, parsing the fields, and generating standard RFC 5545 iCalendar (.ics) formats, we bypass any proprietary calendar databases. The standard string representation is then directly committed to the sovereign CalDAV server via a secure HTTP request.

Using standard protocols like CalDAV and WebDAV ensures that if you switch your backend provider again (for example, from Nextcloud to Open-Xchange or SOGo), your code and tools remain functional. This level of protocol-level independence is a cornerstone of digital sovereignty. It reduces migration complexity for future updates and prevents new forms of vendor lock-in.

The Technical Challenges of an Open Source Cloud Migration

While open-source cloud migrations provide unparalleled security and cost control, they are complex systems engineering projects. A successful migration is not merely about spinning up Docker containers; it requires managing data schemas, identity provisioning, and user workflows. Organizations must approach these challenges with structured development methodologies.

Data structures must be cleaned, transformed, and validated to avoid corrupting calendar timezones or losing email attachments. To prevent costly rework and align security teams, companies must invest in detailed pre-migration planning. Understanding the collaborative software modeling benefits before writing the first migration script is critical for coordinating how different services like Nextcloud and Open-Xchange interact.

Mapping out user directories, authentication flows, and container network topologies ensures that all systems integrate seamlessly. Furthermore, user resistance is a major factor, as employees are accustomed to Microsoft or Google interfaces. The transition to OpenDesk requires active change management and thorough user training to prevent the emergence of shadow IT.

Beyond Office Suites: Sovereignty Across the Entire Stack

Digital sovereignty extends beyond office productivity tools like mail and documents; it applies directly to software development lifecycle (SDLC) tooling. If your organization hosts its source code, build chains, and CI/CD pipelines in centralized US-owned repositories, you face the exact same geopolitically motivated security risks. The movement toward open-source hosting and self-managed code bases is gaining momentum across Europe.

High-profile shifts show that developers want sovereign spaces, as seen with initiatives like Thomas Dohmke's GitHub alternative Entire, which aims to provide dedicated repositories for AI development outside centralized tech monopolies. Running code repositories, document sharing, and identity management on infrastructure you control protects your intellectual property from external interference. This structural resilience is exactly what the Swiss military achieved with its migration strategy.

Actionable Best Practices for Your Migration Strategy

If your organization is planning an open source cloud migration, avoid a "big bang" switchover. Instead, follow a structured, risk-mitigated pathway. The following tips will help ensure a smooth transition to sovereign systems.

Standardize Data Formats Prior to Migration Before migrating any files, enforce open standards like OpenDocument Format (ODF) for office files and iCalendar for schedules. Run validation scripts to identify documents containing proprietary macros or formats that will break during conversion.
Establish a Hybrid Federated Identity Model Do not attempt to migrate your entire user directory overnight. Implement an open identity broker (such as Keycloak) that bridges your legacy Active Directory to your new sovereign services. This allows users to authenticate across both old and new systems using single sign-on (SSO) during the transition.
Establish Clear Data Governance and Disable Telemetry When deploying OpenDesk components, audit every configuration file to disable external tracking, analytics, and auto-update checks that might contact external servers. Set up egress firewalls to ensure that the hosting environment only communicates with authorized IP addresses.
Implement Continuous Load Testing on Sovereign Nodes Self-hosted collaboration suites require careful infrastructure sizing. Before onboarding users, run synthetic load tests using tools like Locust or JMeter to simulate simultaneous document editing and video calls. This ensures that your Kubernetes cluster scales dynamically under peak traffic.

Partnering for Digital Sovereignty

Building a secure, compliant open-source cloud infrastructure in-house requires highly specialized expertise. Setting up Kubernetes deployments, configuring federation via Keycloak, and managing secure migration pipelines is a full-time engineering challenge. Hiring a dedicated devops team for a temporary transition is expensive and introduces operational risks.

An experienced partner like ProjectMakers delivers this transition as a managed, fixed-price project, ensuring your systems are set up for long-term scalability without vendor lock-in. We build custom software solutions, design enterprise architectures, and help organizations establish fully sovereign, open-source infrastructures. Our team ensures that your digital transformation aligns with European data protection regulations.

Planning a sovereign software, cloud, or app migration project? Get in touch with ProjectMakers for a free initial consultation.

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