Migration zu souveränen Alternativen: Ein Framework

Bei der Bewertung ihrer Optionen ging es dem Kopenhagener Rechnungsprüfungsausschuss 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 genau zu einer Zeit, in der die Übergabe so vieler städtischer Daten an einen einzigen US-Anbieter aufgrund politischer Spannungen mit Washington von Jahr zu Jahr riskanter erschien. Die Konsequenz: die Trennung. Kopenhagen und Aarhus, die beiden größten Gemeinden Dänemarks, haben den Ausstieg aus dem Microsoft-Stack inzwischen fast vollständig vollzogen. 

Dieses Beispiel ist kein Einzelfall im Norden. Viele europäische Staaten und Regionen prüfen ihre Tech-Abhängigkeiten genauer, um auf souveräne Alternativen umzusteigen. Schleswig-Holstein wählte einen ähnlichen, aber bewussteren Weg. Statt eines abrupten Ausstiegs stellte das Bundesland sein Software-Portfolio Schritt für Schritt um: zuerst die Desktops, von denen heute 80 % mit LibreOffice statt Microsoft Office laufen; danach die E-Mails, mit über 40.000 Konten, die von Exchange migriert wurden.  

Weder Dänemark noch Schleswig-Holstein sahen den Wechsel zu souveränen Alternativen als eine einzige Entscheidung. Beide verstanden ihn als Dutzende kleinerer Schritte in einer logischen Reihenfolge.  

Genau diesen Teil sparen die meisten Souveränitätsdebatten in Unternehmen heute noch aus: ein klares Framework für die Frage, was jetzt migriert wird, was als nächstes folgt und was warten kann. 

Der folgende Beitrag erläutert dies im Detail. Er liefert ein praktisches Entscheidungsmodell für dringende Systemwechsel, einen Leitfaden für die Priorisierung und ehrliche Antworten auf die Fragen, die Migrationen oft schon vor dem Start blockieren. 

Wichtige Erkenntnisse

1. „Sollten wir auf souveräne Alternativen umsteigen?“ ist die falsche Frage. Es geht um viele kleine Entscheidungen. 

   Jedes Tool in Ihrem Stack birgt andere rechtliche Risiken und operative Abhängigkeiten. Wer das gesamte Portfolio als eine einzige Alles-oder-nichts-Entscheidung betrachtet, endet entweder gelähmt oder migriert alles auf einmal – und zwar schlecht. 

2. Die erste Hürde ist ein rechtlicher Test, kein Bauchgefühl: Verursacht dieses Tool im Moment ein echtes Risiko? 

   Regulierte personenbezogene Daten, Finanzdaten und geistiges Eigentum bei einem Anbieter unter US-Rechtsprechung sind eine ganz andere Risikoklasse als ein Marketing-Analytics-Tool. Sortieren Sie erst nach Datenklassifizierung, dann nach Anbieter. 

3. Bei der zweiten Hürde werden viele Frameworks nachlässig: „Geschäftskritisch“ ist kein Freibrief für Untätigkeit. 

   Ein System kann gleichzeitig geschäftskritisch und ein rechtliches Risiko sein. Die ehrliche Antwort lautet nicht „Es bleibt für immer“, sondern „Es bleibt bis zu einem bestimmten Trigger, danach handeln wir“. 

4. Der schwierigste Bereich (hohes rechtliches Risiko und hohe geschäftliche Relevanz) ist genau der, den „Sovereignty Washing“ ausspart. 

   Unternehmen, die unter Erfolgsdruck stehen, migrieren oft erst einfache, unbedeutende Systeme und erklären das Thema Souveränität für erledigt. Systeme mit Kundendaten oder Finanzen bleiben unangetastet, weil die Umstellung komplex ist. 

5. Selbst EU-Regulierungsbehörden bewerten Souveränität in Stufen, nicht als Ja/Nein-Entscheidung. Ihr Migrationsplan sollte das auch tun. 

   Das Cloud-Souveränitäts-Framework der Europäischen Kommission stuft Anbieter auf einer fünfstufigen Skala ein, nicht binär. Ein phasenweiser, ehrlicher Migrationsplan entspricht der Denkweise der Behörden. 

Die meisten Unternehmen stecken zwischen zwei schlechten Optionen fest

Laut einer Gartner-Umfrage vom November 2025 geben 61 Prozent der westeuropäischen CIOs und IT-Leiter an, dass geopolitischer Druck sie zu lokalen oder regionalen Cloud-Anbietern drängt. Die Sovereign-Cloud-Forschung von IDC zeigt, dass die Nutzung bei europäischen Unternehmen zwischen 2023 und 2025 von 30 % auf 40 % gestiegen ist, weitere 31 % planen den Einstieg. Der Wille ist da. Was fehlt, ist ein konkreter Plan für den Anfang. 

In der Praxis machen Unternehmen meist einen von zwei Fehlern. Der erste ist Lähmung: Digitale Souveränität wird zum Dauerthema auf der Agenda, führt aber nie zu Taten. Jedes System wirkt zu riskant für Veränderung und zu wichtig für Ausfälle. Der zweite Fehler ist gravierender: Ein übereilter, unstrukturierter Wechsel zu „souveränen“ Systemen, bei dem die einfachsten statt der wichtigsten Tools migriert werden. Marketing-Websites und interne Wikis machen den Anfang, weil es hier keine Diskussionen gibt. Kundendaten, HR-Systeme und Finanzplattformen – also die Systeme mit hohem regulatorischen Risiko – bleiben unberührt. Die Migration ist zu komplex, niemand will die Verantwortung übernehmen. Experten nennen das Sovereignty Washing: Eine Migration wird als Erfolg dargestellt, indem man einfache Siege feiert und riskante Systeme ignoriert. Das ist nicht nur ein Problem der Anbieter, sondern auch der Einkäufer. Ein Unternehmen kann nicht auf wenige erfolgreiche Migrationen verweisen und Gefahren für gebannt erklären, während das wichtigste System unangetastet bleibt. 

Beide Fehler haben dieselbe Ursache: Die Frage „Sollen wir migrieren?“ wird pauschal gestellt, anstatt jedes System durch zwei konkrete Kontrollpunkte zu schleusen. 

Hürde eins: Erzeugt das System aktuell ein rechtliches Risiko? 

Hürde eins besteht aus zwei getrennten Fragen. Die meiste Verwirrung um das Thema „Souveränität“ entsteht, weil sie vermischt werden. 

Erstens: Kann der Anbieter zur Herausgabe von Daten gezwungen werden?

Das hängt davon ab, wer der Eigentümer des Anbieters ist, nicht vom Standort der Daten. Der US CLOUD Act erlaubt es US-Behörden, ein in den USA registriertes Unternehmen zur Herausgabe von Daten zu zwingen – völlig unabhängig davon, wo diese physisch gespeichert sind. Ein Rechenzentrum in Frankfurt ändert daran nichts, weil der CLOUD Act an den Unternehmenssitz anknüpft, nicht an den Serverstandort. 

Zweitens: War der Datentransfer dorthin überhaupt legal?

Genau das regeln die DSGVO und das DSG: ob für personenbezogene Daten, die Grenzen überschreiten, die richtigen Mechanismen vorliegen – meist ein Angemessenheitsbeschluss oder Standardvertragsklauseln (SCCs). 

Hier liegt die Falle: Die Erfüllung der zweiten Frage sagt nichts über die erste aus. Ein Anbieter kann alle SCCs vorweisen, jedes Byte in der EU speichern und dennoch ein US-Unternehmen sein, das US-Vorladungen Folge leisten muss. Wer nur fragt „Sind wir DSGVO-konform?“, erhält oft ein Ja, während das tatsächliche Risiko der erzwungenen Datenherausgabe voll bestehen bleibt. 

Sobald ein Risiko bei einer der Fragen besteht, muss das System migriert werden. Nicht irgendwann, sondern zeitnah, da das Risiko ab dem Tag der Prüfung real ist.

Diese Entscheidung erfordert eine Klassifizierung der Daten vor der Bewertung der Anbieter. Ein einfaches Drei-Stufen-Modell reicht meist aus:

• Daten, für die Speicherort oder Souveränität gesetzlich vorgeschrieben sind:

  Ein eng gefasster Bereich regulierter Kategorien wie bestimmte Daten des öffentlichen Sektors, der nationalen Sicherheit, Patientenakten oder spezifische Finanzdaten unter nationaler Aufsicht.

• Daten, bei denen Souveränität dringend empfohlen wird, da die Alternative rechtliche Risiken birgt:

  Die meisten personenbezogenen Daten unter der DSGVO sowie geschäftskritische Informationen und geistiges Eigentum.

• Daten ohne jegliche Einschränkungen beim Speicherort: öffentliche Inhalte, unkritische Analysen usw. Eine vollständige Migration in diesem Bereich verschwendet Budget, das für die ersten beiden Stufen dringend benötigt wird.

Hürde zwei: Ist „geschäftskritisch“ ein Grund zum Warten? 

Die zweite Hürde prüft, ob das System so wichtig ist, dass ein Wechsel im Moment mehr operative Risiken im Betrieb erzeugen würde, als er rechtlich löst. Das ist ein legitimer Grund für einen Aufschub – aber nur mit einem klaren Plan statt einer dauerhaften Ausnahme. 

Zwei Kriterien helfen dabei, diese Hürde produktiv zu nutzen, statt sie als Ausrede gelten zu lassen.

Prüfen Sie erstens, ob das System eine Abhängigkeit für andere Migrationen darstellt, statt nur die reine Geschäftsfunktion zu betrachten. Shared Infrastructure (Identitätsanbieter, Logging, Middleware-Integrationen) muss oft früh migriert werden, weil alle nachfolgenden Systeme davon abhängen – selbst wenn sie selbst nicht kundenrelevant wirken.

Trennen Sie zweitens zwischen „heute zu riskant für einen Wechsel“ und „wird immer zu riskant sein“. Ein System gehört nur dann auf die Warteliste, wenn es an einen klaren Trigger gekoppelt ist: das Datum der Vertragsverlängerung, ein definiertes End-of-Life-Szenario oder eine ohnehin anstehende Neugestaltung einer Schnittstelle.

Bei einem End-of-Life-Datum zählt nicht der endgültige Stichtag, sondern das letzte Zeitfenster, in dem eine kontrollierte Migration möglich ist. Ein geschäftskritisches System bis zum Stichtag aufzuschieben bedeutet, die riskanteste Migration zum schlechtesten Zeitpunkt zu planen: unter maximalem Zeitdruck, bei schwindendem Support und schrumpfenden Optionen. Die aktive Phase beginnt vor diesem Fenster, nicht am Tag der Abschaltung.

Ohne einen solchen Trigger wird „geschäftskritisch“ schnell zur Ausrede für Stillstand. So erklären Unternehmen Jahre später den Behörden, warum das erkannte Risiko nie behoben wurde. 

Das Ergebnis der zwei Hürden: Vier Kategorien

Wenn Sie jedes System durch beide Filter laufen lassen, ergeben sich vier Gruppen:

Geringes rechtliches Risiko + geringe Relevanz: herabstufen, jährlich neu bewerten.

Hohes rechtliches Risiko + geringe Relevanz: jetzt migrieren. Dies sind meist die schnellsten Erfolge. Sie schaffen intern Akzeptanz für die schwierigeren Aufgaben.

Geringes rechtliches Risiko + hohe Relevanz: zurückstellen mit einem definierten Trigger zur Neubewertung.

Hohes rechtliches Risiko + hohe Relevanz: Das ist der entscheidende Bereich. Ihn meiden sowohl die Gelähmten als auch die Macher von „Souveränitäts-Theater“. Denn dieser Bereich ist teuer, aufwändig und lässt sich nicht durch die einfache Migration unkritischer Systeme lösen. 

Keine der vier Kategorien liefert ein starres Urteil: Die technische Machbarkeit beeinflusst die Reihenfolge innerhalb jeder Gruppe.

Selbst ein System in der Kategorie „Jetzt migrieren“ erfordert einen ehrlichen Blick auf technische Altlasten: Undokumentierte Anpassungen, instabile Integrationen und Abhängigkeiten von Marktplatz-Apps bestimmen den Zeitplan und das Budget oft stärker als die rechtliche Dringlichkeit.

Das Beispiel Schleswig-Holstein zeigt dies in der Praxis. LibreOffice wurde zuerst eingeführt, weil es technisch und nicht nur rechtlich bereit war. OneDrive und SharePoint werden immer noch auf Nextcloud migriert, weil die darunter liegenden Abhängigkeiten komplexer waren.

Nutzen Sie die technische Bereitschaft, um die Reihenfolge innerhalb einer Kategorie anzupassen. Sie darf kein Grund sein, ein Risikosystem auf der Warteliste zu parken, nur weil die Migration kompliziert erscheint. 

Dieser letzte Bereich lässt sich auch nicht durch eine überstürzte Komplettablösung lösen: Migrationen des gesamten Portfolios unter Zeitdruck bergen Risiken für Datenverlust, Betriebsunterbrechungen und unkontrollierte Kosten – besonders wenn Standard-Migrationen unerwartete Anpassungen aufdecken.

Der realistische Pfad ist eine schrittweise, geplante Migration: Verbessern Sie Vertragsschutzklauseln, nutzen Sie kundenseitig kontrollierte Verschlüsselung und reduzieren Sie Datenflüsse, während die vollständige Migration vorbereitet wird. 

Es ist wichtig zu betonen, dass selbst die Europäische Kommission Souveränität nicht binär bewertet: Ihr Cloud-Souveränitäts-Framework stuft Anbieter auf einer fünfstufigen Skala ein – von keiner nachgewiesenen Souveränität bis hin zu einer vollständig von der EU kontrollierten Lieferkette. Diese Skala wurde direkt bei einer Ausschreibung über 180 Millionen Euro im April 2026 angewendet.

Wenn die Regulierer in Stufen denken, ist ein entsprechend abgestufter Migrationsplan keine Abkürzung, sondern entspricht der Praxis. 

Die Verlängerung mit dem aktuellen Anbieter ist nur für die beiden Kategorien mit geringem rechtlichem Risiko (Herabstufen und Zurückstellen mit Trigger) eine Option, da sie kein neues Risiko erzeugt. Sobald das rechtliche Risiko hoch ist, entfällt diese Option. Das gilt sowohl für die schnellen Erfolge als auch für den kritischen letzten Bereich: Hier verlängert ein neuer Vertrag nur das bereits identifizierte Risiko und bringt keinen echten Zeitgewinn.

Wo sovara hineinpasst: Eine Kategorie von vielen 

Wenden Sie dieses Framework auf ein reales Portfolio an, benötigen meist mehrere Tool-Kategorien gleichzeitig einen souveränen Ersatz: Identitätsverwaltung, Speicher, Kollaboration, Projektmanagement und mehr. Kein einzelner Anbieter deckt alles ab. Etwas anderes zu behaupten, wäre genau die Art von falschem Versprechen, die dieses Framework entlarven soll. 

sovara, die souveräne Arbeitsmanagement-Plattform von rready, deckt eine spezifische Kategorie ab: den Bereich, der in den meisten Unternehmen auf Jira und Confluence basiert. In diesem Bereich kommt sovara ins Spiel, sobald Hürde eins das Risiko aufgezeigt und Hürde zwei den Handlungsbedarf bestätigt hat. 

sovara läuft auf einer Infrastruktur in der EU und der Schweiz. Die Betreibergesellschaft hat ihren Sitz in Zürich und ist im Schweizer Handelsregister eingetragen – ohne US-Mutterkonzern in der Eigentümerstruktur. Zudem verfügt sovara über eine ISO/IEC 27001:2022-Zertifizierung sowie ein BSI C5-Testat (unabhängig geprüfte Standards). Kunden können ihre eigenen KI-Endpunkte anbinden, ein gehostetes Modell nutzen oder KI vollständig deaktivieren. 

Bei der Migration selbst setzen wir auf präzise Zusagen statt vager Versprechen: Standard-Konfigurationen von Jira und Confluence (Tickets, Workflows, Automatisierungen und Core-Setup) sind garantiert. Sollte dieser Leistungsumfang nicht erbracht werden, erstatten wir die Migrationsgebühr. Ausgenommen von dieser Garantie sind Marktplatz-Apps und Individualcode. Umgebungen mit vielen Anpassungen müssen vorab individuell bewertet werden.

Auch bei den Gesamtbetriebskosten (TCO) sorgen wir für Klarheit: Lizenzen sind nur ein Teil des Bildes. Ein realistischer Vergleich vor dem Wechsel umfasst Lizenzen, das Migrationsprojekt, interne Aufwände für Change Management und Schulungen sowie – bei komplexen Umgebungen – die Kosten für die Migration von Individualcode. Das Vorab-Nennen dieser Kostenblöcke verhindert unangenehme Überraschungen nach der Vertragsunterzeichnung. 

Der nächste Schritt ist einfacher als gedacht 

Sie benötigen kein unternehmensweites Souveränitätsprogramm, um zu starten. Eine einfache Tabelle, eine Liste aller genutzten Systeme und die ehrliche Bewertung anhand der beiden Hürden genügen. Der Großteil der Liste klärt sich schnell: Welche Systeme sofort migriert werden müssen und welche warten können, ist nach der Datenklassifizierung meist offensichtlich. Der eigentliche Wert der Arbeit liegt in den Systemen, die im unbequemen Bereich landen. Denn genau diese werden bei Souveränitätsprüfungen sonst gerne übersehen. 

FAQs

Muss mittelfristig jedes System auf eine souveräne Alternative umgestellt werden? 

Nein. Systeme für öffentliche Inhalte oder unkritische Daten haben keinen rechtlichen Migrationsdruck. Sie sollten nicht vor kritischen Systemen priorisiert werden. Das Framework soll verhindern, dass Unternehmen entweder alles oder gar nichts migrieren. Das Ziel ist die richtige Priorisierung, nicht die maximale Anzahl an Migrationen. 

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

Dieser Bereich erfordert einen präzisen, schrittweisen Plan statt eines riskanten Schnellschusses oder dauerhaften Aufschubs. Setzen Sie Übergangslösungen um, während die eigentliche Migration geplant und budgetiert wird: Vertragsanpassungen, Schlüsselkontrolle und die Reduzierung von Datenflüssen. 

Wie oft sollte die Warteliste überprüft werden? 

Immer gekoppelt an einen Trigger, nicht nur nach dem Kalender: bei Vertragsverlängerungen, End-of-Life-Ankündigungen von Anbietern, der Modernisierung verknüpfter Systeme oder Gesetzesänderungen. Ohne konkreten Trigger bleibt ein System auf der Warteliste oft jahrelang unberührt.