Sovereign Migration Framework: Was jetzt migriert wird – und was noch wartet

Als der Prüfungsausschuss von Kopenhagen seine Optionen abwägte, ging es ihm nicht darum, ein Zeichen für digitale Souveränität zu setzen. Er wollte erklären, warum die Microsoft-Rechnung der Stadt in fünf Jahren um 72 % gestiegen war – von 313 Millionen auf 538 Millionen dänische Kronen. Und das in einer Zeit, in der politische Spannungen mit Washington die Abhängigkeit von einem US-Anbieter Jahr für Jahr riskanter erscheinen ließen. Die Antwort des Ausschusses war der Ausstieg. Kopenhagen und Aarhus, die beiden größten Gemeinden Dänemarks, haben den Umstieg weg von Microsoft mittlerweile fast vollständig vollzogen. 

Dieses Beispiel ist kein Einzelfall. Viele europäische Staaten und Regionen prüfen ihre technologischen Abhängigkeiten genauer, um auf souveräne Alternativen umzusteigen. Schleswig-Holstein wählte einen ähnlichen, aber strategischeren Weg. Statt eines radikalen Schnitts modernisierte das Bundesland sein Softwareportfolio Schritt für Schritt: Zuerst die Desktops (80 % nutzen nun LibreOffice statt Microsoft Office), dann die E-Mails (mehr als 40.000 Konten wurden von Exchange migriert).  

Weder Dänemark noch Schleswig-Holstein sahen den Wechsel als eine einzige, große Entscheidung. Beide verstanden ihn als Dutzende kleine Entscheidungen, getroffen in einer logischen Reihenfolge.  

Genau diesen Teil übergehen die meisten Unternehmen heute noch bei Debatten über Souveränität: ein klares Framework, das festlegt, was jetzt migriert wird, was als Nächstes kommt und was warten kann. 

Dieser Artikel erklärt diese Logik im Detail. Er bietet ein praktisches Framework zur Entscheidungsfindung, einen Fahrplan für die Priorisierung und ehrliche Antworten auf die Fragen, die Migrationen oft vorab blockieren. 

Wichtige Erkenntnisse

1. „Sollen wir auf souveräne Alternativen umsteigen?“ ist die falsche Frage – es geht um viele kleinere Entscheidungen 

   Jedes Tool im Stack bringt ein anderes rechtliches Risiko und andere operative Abhängigkeiten mit sich. Wer das gesamte Portfolio als Einheit betrachtet, lähmt das Unternehmen oder riskiert eine übereilte, fehlerhafte Migration. 

2. Die erste Hürde ist rechtlicher Natur, kein Bauchgefühl: Erzeugt dieses Tool aktuell echte Risiken? 

   Regulierte personenbezogene Daten, Finanzdaten und IP bei einem US-Anbieter bergen ein völlig anderes Risiko als ein Marketing-Analytics-Tool. Sortieren Sie zuerst nach Datenklasse, erst dann nach Anbieter. 

3. Die zweite Hürde wird oft vernachlässigt: „Geschäftskritisch“ ist kein Freibrief für Untätigkeit 

   Ein System kann geschäftskritisch und gleichzeitig ein rechtliches Risiko sein. Die Lösung lautet nicht „Es bleibt für immer“, sondern „Es bleibt bis zu einem definierten Auslöser, dann handeln wir“. 

4. Der schwierigste Quadrant (hohes rechtliches Risiko und hohe Geschäftskritikalität) wird beim „Sovereignty Washing“ gern übersprungen 

   Unternehmen unter Erfolgsdruck migrieren oft zuerst einfache, unkritische Systeme, um Erfolge vorzuweisen. Die Systeme für Kundendaten oder Finanzen bleiben unangetastet, weil der Umstieg komplex ist. 

5. Selbst EU-Regulierungsbehörden bewerten Souveränität in Stufen – Ihr Migrationsplan sollte das auch tun 

   Das Cloud-Souveränitäts-Framework der EU-Kommission bewertet Anbieter auf einer fünfstufigen Skala, nicht binär. Ein phasenweiser, pragmatischer Migrationsplan entspricht der Denkweise der Gesetzgeber. 

Die meisten Unternehmen stecken zwischen zwei Fehlern fest 

Laut einer Gartner-Umfrage vom November 2025 geben 61 % der westeuropäischen CIOs und IT-Leiter an, dass geopolitischer Druck sie zu lokalen oder regionalen Cloud-Anbietern treiben wird. Die Sovereign-Cloud-Forschung von IDC zeigt, dass die Nutzung in europäischen Unternehmen von 2023 bis 2025 von 30 % auf 40 % gestiegen ist – weitere 31 % planen die Einführung. Der Wille ist da. Was fehlt, ist ein konkreter Startpunkt. 

In der Praxis führt dies zu zwei Fehlern. Der erste ist Lähmung: Digitale Souveränität wird zum Dauerthema ohne Ergebnisse, weil jedes System zu riskant für Veränderungen und zu wichtig für Ausfälle scheint. Der zweite Fehler ist gravierender: Ein übereilter, unstrukturierter Wechsel auf „souveräne“ Systeme. Migriert wird, was einfach ist, nicht, was wichtig ist. Marketing-Seiten und interne Wikis ziehen zuerst um, weil es keine Diskussionen gibt. Kundendaten, HR-Systeme und Finanzplattformen verbleiben am alten Ort. Umzug zu komplex, Zuständigkeit unklar. Experten nennen das Sovereignty Washing: Eine Migration wird schöngeredet, indem man einfache Erfolge zählt, die riskanten Kernsysteme aber ignoriert. Das ist nicht nur ein Problem der Anbieter, sondern auch der Einkäufer, wenn Organisationen ein paar Alibi-Migrationen vorweisen, das Hauptrisiko aber bestehen bleibt. 

Beide Fehler haben dieselbe Ursache: Die Frage „Sollen wir migrieren?“ wird pauschal gestellt, statt jedes System einzeln durch zwei Prüfstufen zu schicken. 

Prüfstufe 1: Erzeugt das System aktuell echte rechtliche Risiken? 

Diese Prüfstufe besteht aus zwei Fragen. Die häufige Verwirrung um Souveränität entsteht, weil diese vermischt werden. 

Erstens: Kann der Anbieter rechtlich zur Herausgabe von Daten gezwungen werden? Das hängt vom Firmensitz des Anbieters ab, nicht vom Speicherort. Der US CLOUD Act berechtigt US-Behörden, Daten von US-Unternehmen einzufordern – egal, wo die Server physisch stehen. Ein Rechenzentrum in Frankfurt ändert nichts am Zugriff, da der CLOUD Act dem Hauptsitz des Anbieters folgt. 

Zweitens: War der Datentransfer dorthin überhaupt legal? Das regeln DSGVO und DSG: Ob für den grenzüberschreitenden Datenverkehr die richtigen Mechanismen vorliegen – meist ein Angemessenheitsbeschluss oder Standardvertragsklauseln (SCCs). 

Die Falle dabei: Wer die zweite Frage mit „Ja“ beantwortet, hat die erste noch nicht gelöst. Ein Anbieter kann alle SCCs vorweisen, Daten in der EU speichern und dennoch als US-Unternehmen einer US-Vorladung unterliegen. Wer nur nach DSGVO-Konformität fragt, wiegt sich oft in falscher Sicherheit, während das tatsächliche Zugriffsrisiko bestehen bleibt. 

Besteht bei einer der beiden Fragen ein Risiko, muss das System weichen. Und zwar bald, da das Risiko ab dem Tag der Prüfung real ist.

Um diese Entscheidung zu treffen, müssen Daten vor den Anbietern klassifiziert werden. Sinnvoll ist eine dreistufige Aufteilung: Daten, deren lokale Speicherung gesetzlich zwingend vorgeschrieben ist (z. B. öffentlicher Sektor, nationale Sicherheit, bestimmte Gesundheits- oder Finanzdaten), Daten mit starker Präferenz für lokale Speicherung wegen rechtlicher Risiken (die meisten personenbezogenen Daten unter der DSGVO sowie IP) und Daten ohne jegliche Einschränkungen (öffentliche Inhalte, unkritische Analysen). Wer für die dritte Kategorie eine souveräne Migration erzwingt, verschwendet Budget, das für die ersten beiden nötig wäre.

Prüfstufe 2: Ist „geschäftskritisch“ ein Aufschubgrund? 

Die zweite Prüfstufe hinterfragt, ob das System so kritisch ist, dass ein jetziger Austausch mehr operative Risiken schafft als löst. Das ist ein legitimer Grund für einen Aufschub – aber nur mit einem konkreten Plan statt einer dauerhaften Ausnahme. 

Zwei Kriterien helfen, Ausflüchte zu verhindern. Erstens: Ist das System Voraussetzung für andere Migrationen? Gemeinsame Infrastruktur (Identity-Provider, Logging, Middleware) muss oft zuerst migriert werden, weil nachgelagerte Systeme davon abhängen – auch wenn sie selbst nicht direkt kundenrelevant wirken. Zweitens: Unterscheiden Sie zwischen „heute riskant zu wechseln“ und „immer riskant zu wechseln“. Ein System kommt nur mit einem konkreten Auslöser auf die Warteliste: Vertragsverlängerung, End-of-Life-Termin oder ein ohnehin geplanter Umbau der Integration. Ohne furchungsbasierten Auslöser blockiert „geschäftskritisch“ jeden Fortschritt. Und führt Jahre später zu Erklärungsnot gegenüber den Aufsichtsbehörden. 

Das Ergebnis der beiden Stufen: Vier Kategorien

Nach der Analyse aller Systeme ergeben sich vier Gruppen. Geringes rechtliches Risiko, geringe Kritikalität: Priorität senken, jährlich prüfen. Hohes rechtliches Risiko, geringe Kritikalität: Jetzt handeln. Dies sind schnelle Erfolge, die intern Akzeptanz für größere Projekte schaffen. Geringes rechtliches Risiko, hohe Kritikalität: Zurückstellen mit festem Prüf-Auslöser. Hohes rechtliches Risiko, hohe Kritikalität: Das ist der entscheidende Quadrant. Genau diesen meiden Lähmung und Aktionismus gleichermaßen, weil er komplex und teuer ist und sich nicht durch Alibi-Migrationen lösen lässt. 

Keine der Kategorien liefert ein starres Urteil: Die technische Machbarkeit bestimmt die Feinsortierung. Ein System der Kategorie „Jetzt handeln“ erfordert eine ehrliche Analyse der Altlasten: Undokumentierte Workflows, instabile Schnittstellen und App-Abhängigkeiten bestimmen Zeitplan und Budget ebenso wie rechtliche Fristen. Das zeigt das Beispiel Schleswig-Holstein: LibreOffice kam zuerst, weil es technisch bereit war. SharePoint wird noch auf Nextcloud migriert, weil vorgelagerte Abhängigkeiten dies verhinderten. Technische Hürden dürfen die Reihenfolge anpassen, aber kein Grund sein, hochriskante Systeme stillschweigend aufzuschieben. 

Dieser letzte Quadrant lässt sich nicht durch einen harten, übereilten Komplettwechsel lösen. Migrationen unter Zeitdruck bergen enorme Risiken für Datenverlust, Ausfälle und ungeplante Kosten durch unentdeckte Spezialkonfigurationen. Der einzig realistische Weg ist ein schrittweiser Umstieg: Anpassung der Verträge, kundenkontrollierte Verschlüsselung und Reduzierung von Datenströmen, während die Migration geplant wird. 

Sogar die EU-Kommission bewertet Souveränität differenziert: Ihr Cloud-Souveränitäts-Framework stuft Anbieter auf einer fþnfstufigen Skala ein (von nicht nachgewiesen bis zu komplett EU-kontrolliert) und wandte diese Skala direkt bei einer Ausschreibung über 180 Millionen Euro im April 2026 an. Wenn Regulierungsbehörden in Abstufungen denken, ist ein phasenweiser Migrationsplan kein Kompromiss, sondern die einzig pragmatische Lösung. 

Die Verlängerung beim aktuellen Anbieter ist nur für die beiden Kategorien mit geringem rechtlichem Risiko eine Option. Bei hohem rechtlichen Risiko (schnelle Erfolge und der kritische Quadrant) verschiebt eine Verlängerung das Problem nur, ohne Zeit zu gewinnen.

Wo sovara ins Spiel kommt: Eine Kategorie unter vielen 

Wendet man dieses Framework auf ein reales Portfolio an, müssen diverse Tool-Kategorien gleichzeitig souverän ersetzt werden: Identitätsverwaltung, Speicher, Kollaboration, Projektmanagement und mehr. Kein einzelner Anbieter deckt alles ab. Etwas anderes zu behaupten, wäre genau die Art von Scheinversprechen, die dieses Framework entlarven soll. 

sovara, die souveräne Work-Management-Plattform von rready, bedient einen spezifischen Bereich: den Teil des Stacks, der auf Jira und Confluence basiert. Hier setzt sovara an, sobald Prüfstufe 1 das Risiko identifiziert und Prüfstufe 2 den Handlungsbedarf bestätigt hat. 

sovara läuft auf Schweizer und EU-Infrastruktur. Die Betreibergesellschaft hat ihren Sitz in Zürich (eingetragen im Schweizer Handelsregister) ohne jegliche US-Muttergesellschaft. Zudem verfügt sovara über ISO/IEC 27001:2022 und BSI C5 Testate (unabhängig geprüfte Standards). Kunden können eigene KI-Endpunkte einbinden, ein gehostetes Modell nutzen oder KI ganz deaktivieren. 

Für die Migration gilt: Präzision statt vager Versprechen. Standardmigrierungen für Jira und Confluence (Tickets, Workflows, Automatisierungen, Grund-Setups) sind garantiert. Wird dieser Umfang nicht geliefert, wird die Migrationsgebühr erstattet. Davon ausgenommen sind Marktplatz-Apps und Individualcode; stark modifizierte Umgebungen erfordern eine Vorabanalyse. 

Auch bei den Gesamtbetriebskosten (TCO) ist Transparenz entscheidend: Lizenzen sind nur ein Teil der Wahrheit. Ein realistischer Vergleich umfasst Lizenzen, das Migrationsprojekt, interne Aufwände für Change Management und Schulungen sowie die Behebung von App-Kompatibilitäten. Diese Faktoren vorab klar zu benennen, verhindert böse Überraschungen nach der Vertragsunterzeichnung. 

Der nächste Schritt ist einfacher als gedacht 

Sie benötigen kein unternehmensweites Riesenprogramm für den Start. Es reicht eine einfache Tabelle aller Systeme, die konsequent durch die beiden Prüfstufen geschickt werden. Die meisten Systeme lassen sich schnell zuordnen. Der eigentliche Wert der Arbeit liegt in der Identifizierung der Systeme im unbequemen Quadranten – also genau jener, die bei einer oberflächlichen Betrachtung meist ignoriert werden. 

Häufig gestellte Fragen (FAQs)

Muss jedes System irgendwann auf eine souveräne Alternative migriert werden? 

Nein. Für Systeme mit öffentlichen Inhalten oder unkritischen Daten gibt es keinen rechtlichen Grund für einen Wechsel. Sie sollten nicht priorisiert werden. Das Ziel des Frameworks ist die richtige Priorisierung, nicht die maximale Anzahl an Migrationen. 

Was tun mit einem System, das hochriskant und gleichzeitig geschäftskritisch ist? 

Dieser Quadrant erfordert einen detaillierten, schrittweisen Plan statt eines übereilten Austauschs oder dauerhaften Aufschubs. Nutzen Sie temporäre Sicherheitsmaßnahmen während der Planungsphase: Vertragsanpassungen, eigene Verschlüsselung oder reduzierte Datenströme. 

Wie oft sollte die Liste der zurückgestellten Systeme überprüft werden? 

Gesteuert durch Ereignisse, nicht nur nach Kalender: Vertragsverlängerungen, Abkündigungen durch den Anbieter, Umbauten an Nachbarsystemen oder Gesetzesänderungen. Ohne konkreten Auslöser blockieren diese Systeme auch noch in drei Jahren Ihre Roadmap.