Die Kosten eines Systems, das nicht gehen kann

Die Kosten eines Systems, das nicht gehen kann

Die Tür, die es nur auf dem Papier gibt

Ein Vertrag kann eine Ausstiegsklausel enthalten und trotzdem eine Einbahnstraße sein. Die Klausel kann besagen, dass eine Organisation ihre Daten exportieren, zu einem anderen Anbieter wechseln und angemessene Unterstützung erhalten kann. Sie kann sogar das beruhigende Wort Portabilität verwenden. Dann stellt jemand die praktische Frage: Was würden wir am Montagmorgen tatsächlich mitnehmen?

Die Antwort ist selten ein Ordner voller Dateien. Es ist ein funktionierender Dienst, eine Reihe von Identitäten, eine Sammlung von Berechtigungen, eine Historie von Entscheidungen, ein Netz von Abhängigkeiten, eine Gruppe von Menschen, die wissen, wie man ihn betreibt, und eine Institution, die jemand anderem versprochen hat, dass der Dienst weiter funktionieren wird. Die Daten sind Teil des Systems. Sie sind nicht das gesamte System. Ein sauber formatierter Export kann das Gebäude verlassen, während die Bedeutung, die Zeitabläufe und die Autorität, die ihn nützlich gemacht haben, zurückbleiben.

Deshalb sind Wechselkosten kein Finanzproblem, das erst nach der Architektur auftritt. Sie sind ein Architekturproblem mit einer Finanzrechnung. Wenn eine Organisation eine Arbeitslast nicht bewegen kann, ohne Semantik, Kontinuität, Sicherheit oder die Fähigkeit zur Entscheidungsfindung zu verlieren, besitzt sie keinen Ausstiegsweg. Sie besitzt eine Abhängigkeit und hat einen höflichen Absatz darüber geschrieben.

Der europäische Data Act behandelt den Wechsel zwischen Datenverarbeitungsdiensten als eine Frage des Wettbewerbs, der Interoperabilität und der Kontinuität. Sein Kapitel VI verlangt von Anbietern, technische, kommerzielle, vertragliche und organisatorische Hindernisse zu beseitigen. Die Europäische Kommission erklärt denselben Anspruch in einfacherer Sprache: Cloud- und Edge-Kunden sollten wechseln können, ohne Daten oder Anwendungsfunktionalität zu verlieren. Das ist eine nützliche Grundlage. Es ist kein Zaubertrick. Der Unterschied zwischen einem gesetzlichen Anspruch und einem nutzbaren Ausstieg ist die Arbeit, um die es in diesem Artikel geht.

Portabilität hat vier Bedeutungen

Menschen verwenden Portabilität oft, um zu meinen, dass Bytes eine Grenze überqueren können. Ein Datenbank-Dump existiert. Ein Objektspeicher kann kopiert werden. Ein Image einer virtuellen Maschine kann heruntergeladen werden. Der Export-Button ist sichtbar, und jemand hat einen Screenshot davon gemacht. Das ist eine Art von Portabilität, und sie ist wichtig. Sie ist auch die Art, die am leichtesten übertrieben wird.

Portable Bytes sind nur dann nützlich, wenn das empfangende System sie interpretieren kann. Ein Datensatz mit einer Kennung, einem Zeitstempel und einem Status mag vollständig erscheinen, während seine Beziehungen, Zeitzone, Sortierregel, Aufbewahrungsbedeutung und Berechtigungshistorie in einem Dienst leben, der nicht mitwandert. Ein Ereignis kann exportiert werden, während die Richtlinie, die ihm Bedeutung verliehen hat, in der alten Plattform bleibt. Ein Modell kann exportiert werden, während Tokenizer, Prompt-Version, Feature-Pipeline und Evaluierungssatz proprietär oder undokumentiert bleiben. Die Datei hat das Gebäude verlassen. Das System nicht.

Es gibt semantische Portabilität: Der empfangende Dienst kann verstehen, was die exportierten Objekte bedeuten. Es gibt operative Portabilität: Menschen können den Dienst in der neuen Umgebung ausführen, absichern, überwachen, reparieren und wiederherstellen. Es gibt institutionelle Portabilität: Die Organisation kann ihre rechtlichen, vertraglichen und öffentlichen Verpflichtungen weiterhin erfüllen, während der Wechsel stattfindet. Diese Bedeutungen überlappen sich, aber keine kann durch eine andere ersetzt werden.

Man stelle sich ein öffentliches Archiv vor, das jedes Dokument exportieren kann und dennoch nicht in der Lage ist, die Zugriffsentscheidungen zu rekonstruieren, die bestimmten, wer jedes Dokument sehen durfte. Man stelle sich eine Krankenhausplattform vor, die Patientenakten übertragen kann, aber den Alarmpfad, den ein klinisches Team nutzt, nicht reproduzieren kann. Man stelle sich einen Energiebetreiber vor, der Messwerte kopieren kann, aber die zeitliche Abstimmung zwischen Zählern, Prognosen und Einsatzentscheidungen nicht bewahren kann. Dies sind hypothetische Beispiele, bewusst gewählt. Sie beschreiben Klassen von Abhängigkeiten, nicht Vorfälle bei namentlich genannten Organisationen.

Ein ernsthafter Exit-Plan benennt, welche Art von Portabilität für jeden Teil des Dienstes erforderlich ist. Er stuft ein System nicht deshalb als portabel ein, weil ein Sales Engineer einen Download-Link erstellen kann. Die Frage ist immer: portabel für welchen Zweck, unter welcher Kontinuitätsanforderung, mit welchen Nachweisen und von wem.

Der Data Act setzt eine Untergrenze, keine Rettungsmannschaft

Kapitel VI der Verordnung (EU) 2023/2854 beginnt mit einer unmodisch praktischen Anweisung. Anbieter von Datenverarbeitungsdiensten müssen vorvertragliche, kommerzielle, technische, vertragliche und organisatorische Hindernisse beseitigen, die den Wechsel, die Übertragung exportierbarer Daten und digitaler Assets, das Erreichen funktionaler Äquivalenz, soweit die Verordnung dies verlangt, oder die gleichzeitige Nutzung mehrerer Anbieter behindern. Die Liste ist nützlich, weil sie sich weigert, so zu tun, als sei ein Dateiformat das einzige Hindernis.

Artikel 25 verlangt, dass Wechselrechte und Pflichten des Anbieters in einem schriftlichen Vertrag festgelegt werden, den der Kunde speichern und reproduzieren kann. Die übliche Struktur umfasst eine maximale Kündigungsfrist von zwei Monaten, eine verbindliche Übergangsfrist von höchstens 30 Kalendertagen nach dieser Kündigungsfrist, Unterstützung durch den bisherigen Anbieter, Kontinuität der vertraglich vereinbarten Funktionen und ein hohes Sicherheitsniveau während des gesamten Übergangs und des Abrufzeitraums. Sie verlangt außerdem eine erschöpfende Spezifikation der exportierbaren Daten und digitalen Assets, einen Abrufzeitraum von mindestens 30 Kalendertagen und die Löschung nach einem erfolgreichen Wechsel, vorbehaltlich der Bedingungen des Artikels.

Die Daten sind wichtig. Während des Übergangs vom 11. Januar 2024 bis zum 12. Januar 2027 dürfen Anbieter ermäßigte Wechselentgelte erheben, die ihre unmittelbar anfallenden Kosten nicht übersteigen. Ab dem 12. Januar 2027, so die Verordnung, müssen Wechselentgelte entfallen. Das ist eine wichtige Änderung in der Ökonomie eines Exits. Sie macht eine eng gekoppelte Anwendung nicht unabhängig und stellt auch nicht die Ingenieure, die Testumgebung oder den Ersatzdienst bereit, die die Migration benötigt.

Artikel 26 ergänzt eine Informationspflicht. Kunden sollen die Verfahren, Methoden, Formate, Einschränkungen und bekannten technischen Grenzen für den Wechsel erhalten, zusammen mit einem Verweis auf ein aktuelles Register, das Datenstrukturen, Datenformate und relevante Standards oder offene Interoperabilitätsspezifikationen beschreibt. Artikel 27 fordert alle Parteien, einschließlich des Zielanbieters, zur gutgläubigen Zusammenarbeit auf. Ein Ziel, das die Daten nicht empfangen kann, ist kein nützliches Ziel, so vernünftig der bisherige Anbieter auch sein mag.

Artikel 30 trennt die Diensttypen. Infrastrukturanbieter werden aufgefordert, funktionale Äquivalenz für gemeinsame Funktionen zu ermöglichen, wenn ein Kunde zum gleichen Diensttyp wechselt. Andere Datenverarbeitungsanbieter müssen Kunden und Zielanbietern offene Schnittstellen bereitstellen und strukturierten, gängigen, maschinenlesbaren Export unterstützen, soweit die relevanten Standards noch nicht verfügbar sind. Die Verordnung verlangt von einem Anbieter nicht, Geschäftsgeheimnisse preiszugeben, eine neue Technologie zu erfinden oder die Sicherheit zu gefährden. Die Grenze ist sinnvoll. Sie bedeutet auch, dass der Kunde vor der Unterzeichnung verstehen muss, was tatsächlich exportierbar ist.

Es gibt Grenzen und Ausnahmen. Überwiegend kundenspezifische Dienste und Nicht-Produktionstestdienste unterliegen einem besonderen Regime, und Anbieter müssen potenziellen Kunden mitteilen, welche Wechselpflichten nicht gelten. Die rechtliche Untergrenze enthält also ihre eigene Warnung: den Anwendungsbereich lesen. Ein kundenspezifischer Dienst kann genau dort liegen, wo eine Organisation ihre folgenreichste Abhängigkeit platziert hat. Eine Klausel, die für einen Katalogdienst gilt, rettet nicht automatisch eine maßgeschneiderte Vereinbarung.

The Data Act can make an exit obligation visible, testable and harder to obstruct. It cannot decide whether an organisation documented its domain semantics, retained staff who understand the workload, tested the restore path or budgeted for a parallel run. Law can require an opening. Somebody still has to build a door on the other side.

Data is the cargo, not the vehicle

The Commission’s explanation of the Data Act identifies input data, output data and metadata generated by a customer’s use of a service as central to switching, subject to intellectual-property and trade-secret boundaries. That is a useful definition, because metadata often carries the context people forget to ask for. It can include relationships, configuration, timestamps, lineage, retention state and identifiers. It can also be the first thing that disappears when an export has been designed as a marketing feature rather than a recovery path.

Imagine exporting a set of work items. The receiving system has the titles and descriptions, but not the queue semantics, escalation rules, assignment history or links to evidence. The export is technically accurate. The organisation still cannot explain why a case was waiting, who was allowed to intervene or which rule was active at the time. The missing pieces are not decorative fields. They are the behaviour of the service.

Metadata deserves the same design attention as primary content. A migration inventory should ask which identifiers are stable, which are local to the provider, which relationships are implicit, which timestamps have a defined clock, which permissions are portable, which derived artefacts are customer-owned and which are provider internals. It should record the meaning of a deletion, a hold, an archive and a replay. Otherwise the receiving team receives a pile of nouns and has to guess the verbs.

There is a further complication in AI systems. A response may depend on a retrieval index, an embedding model, a prompt, a policy version, a tool permission, a cache and a human release decision. Exporting the final text does not export the conditions under which it was produced. An evaluation set may travel while the tokenizer or normalisation rules do not. An audit event may travel while the key that verifies its signature is forgotten. The result is a record that remembers the answer and has lost the reason.

None of this means every transient intermediate must be preserved forever. Portability is not a licence to hoard. It means deciding which artefacts are necessary for the purpose of the move, preserving them with their meaning, and stating what cannot move. An honest boundary is safer than a vague promise. The worst export is the one that looks complete until somebody depends on it.

Interoperability is a conversation

A file format is a sentence. Interoperability is a conversation in which both systems agree about the subject, the verb, the timing and the consequences. Open interfaces help because they let another system speak to the service without guessing at a private dialect. They do not, by themselves, guarantee that the two systems share a vocabulary.

Die Cloud-Politik der Europäischen Kommission verknüpft die Umstellung auf offene Standards, interoperable Cloud- und Edge-Dienste und eine gemeinsame europäische Datenumgebung. Ihre Beschreibung der geplanten Leitlinien für die öffentliche Vergabe von Datenverarbeitungsdiensten ist aufschlussreich: Die Leitlinien sollen Empfehlungen und wesentliche Kriterien für Ausschreibungen bieten. Mit anderen Worten: Der öffentliche Auftraggeber wird aufgefordert, die Bedingungen festzulegen, unter denen ein Ausstieg ausgeübt werden kann, und nicht darauf zu hoffen, dass der Markt dies in seinem Namen übernimmt.

Semantische Verträge sind der Punkt, an dem Interoperabilität konkret wird. Eine Organisation sollte wissen, ob ein leerer Wert unbekannt, nicht zutreffend oder absichtlich zurückgehalten bedeutet. Sie sollte wissen, ob ein Zeitstempel den Zeitpunkt des Ereignisses, der Erfassung oder der Veröffentlichung aufzeichnet. Sie sollte wissen, ob eine Entscheidung endgültig, vorläufig oder auf Einspruch wartend ist. Sie sollte wissen, ob eine Kennung einen Umzug übersteht oder lediglich eine Adresse in der Datenbank des bisherigen Anbieters ist. Diese Fragen sind nicht glamourös. Sie sind der Unterschied zwischen einer Migration und einer Übung im erneuten Abtippen.

Auch die funktionale Gleichwertigkeit erfordert Sorgfalt. Das Datengesetz verwendet diese Idee für Infrastrukturdienste, die denselben Diensttyp und gemeinsame Merkmale abdecken. Es verspricht nicht, dass zwei Anbieter identische Konsolen, Preismodelle oder interne Architekturen haben werden. Eine Arbeitslast kann für die im Rahmen liegenden Funktionen materiell vergleichbare Ergebnisse liefern, während sie ein anderes Betriebsdesign benötigt. Das ist ein ehrlicheres Ziel, als so zu tun, als wäre jede Cloud ein Kopiergerät jeder anderen Cloud.

Interoperabilität kann mit einem kleinen Vokabular getestet werden, bevor sich eine Organisation auf eine große Abhängigkeit einlässt. Nehmen Sie einen repräsentativen Datensatz, eine Berechtigungsänderung, einen Fehler, einen geplanten Auftrag und eine Korrektur. Bewegen Sie sie durch die vorgeschlagene Schnittstelle. Fragen Sie, ob das Ziel sie validieren, abfragen, aktualisieren, prüfen und löschen kann, ohne ein privates Treffen mit dem Quellanbieter. Wenn die Antwort von einer Präsentation abhängt, ist die Schnittstelle noch keine Route. Sie ist ein Versprechen mit guter Typografie.

Runtime-Lock-in versteckt sich hinter dem Export

Viele Migrationen beginnen mit der falschen Bestandsaufnahme. Das Team listet Datenbanken, Dateien und virtuelle Maschinen auf. Es vergisst die verwaltete Warteschlange, die Wiederholungen steuert, den Identitätsanbieter, der Dienstzugangsdaten ausstellt, die Beobachtbarkeitsplattform, die den einzigen nützlichen Vorfallkontext enthält, den Geheimnisdienst, der Bereitstellungen signiert, die anbieterspezifische Netzwerkrichtlinie, die Image-Registry, den Planer, das Sicherungsformat und den Eskalationspfad für den Support. Jede Abhängigkeit mag sinnvoll sein. Zusammen bilden sie eine Laufzeit, die schwer zu reproduzieren ist.

Verwaltete Dienste schaffen Wert, indem sie Arbeit entfernen. Diese Arbeit verschwindet nicht, wenn der Vertrag endet. Sie wandert in den Ausstiegsplan. Jemand muss eine Ersatzwarteschlange wählen, Zustellsemantik übersetzen, Alarmierung neu aufbauen, Schlüssel rotieren, Identitätsverbund neu herstellen, historische Metriken wiederherstellen, die Integrität von Sicherungen erneut testen und entscheiden, welches anbieterspezifische Verhalten Teil der Annahmen der Anwendung war. Der Dienst war praktisch, weil er diese Entscheidungen für Sie getroffen hat. Gehen bedeutet, sie zurückzunehmen.

Dies ist kein Argument gegen die Nutzung verwalteter Dienste. Es ist ein Argument dafür, die Grenze zu dokumentieren. Ein Team kann bewusst eine Abhängigkeit von einer verwalteten Datenbank akzeptieren, wenn es das Exportformat, den Wiederherstellungspfad, die Kompatibilitätsgrenzen und die Fähigkeiten kennt, die für den Betrieb der Alternative erforderlich sind. Es kann auch entscheiden, dass eine bestimmte Warteschlange oder ein bestimmter Identitätsdienst zu zentral ist, um implizit zu bleiben. Die architektonische Wahl ist nicht Anbieter oder kein Anbieter. Es ist sichtbare Abhängigkeit oder nicht bepreiste Abhängigkeit.

Infrastruktur als Code kann helfen, aber nur, wenn sie mehr beschreibt als die Ressourcennamen des Quellanbieters. Ein Skript, das ein proprietäres Netzwerkobjekt auf derselben Plattform neu erstellt, ist Automatisierung, nicht Portabilität. Eine brauchbare Ausstiegsbeschreibung erfasst Absicht, Richtlinien, Datenverträge, Sicherheitsannahmen und Tests. Sie kann diese Dinge dann auf eine neue Implementierung abbilden. Diese Unterscheidung ist schützenswert, denn ein perfektes Skript für die falsche Plattform ist ein sehr effizienter Weg, um dort zu bleiben, wo man ist.

Backups offenbaren dasselbe Problem. Ein Backup, das nur von dem Dienst wiederhergestellt werden kann, der es erstellt hat, ist ein Resilienzmechanismus innerhalb der Abhängigkeit, kein Ausstiegsweg aus ihr. Das kann für eine Workload mit geringem Risiko die richtige Wahl sein. Es ist nicht die richtige Beschreibung. Menschen sollten wissen, ob ein Backup eine kurzfristige Wiederherstellungskopie, ein langfristiges Archiv, ein Migrationsartefakt oder alles drei ist. Etiketten sind billiger als Überraschungen.

Operationale Bindung ist ein Personalproblem

Die schwerste zu exportierende Abhängigkeit ist oft das Wissen einer Person. Die Konsole eines Anbieters hat einem Team beigebracht, wo es klicken muss, welche Fehlermeldungen wichtig sind, welches Wartungsfenster sicher ist und welche Support-Warteschlange vor einer Frist antwortet. Das Wissen kann real und wertvoll sein. Es kann auch im Vertrag unsichtbar sein. Wenn sich der Dienst ändert oder die Organisation umzieht, wird das Wissen zu einer Warteschlange von Fragen.

Der Cloud-Souveränitätsrahmen der Kommission umfasst operative Souveränität als die Fähigkeit europäischer Akteure, Technologie unabhängig von ausländischer Kontrolle zu betreiben, zu unterstützen und weiterzuentwickeln. Seine Kriterien beziehen sich auf Kontinuität, Kompetenzen und Resilienz gegenüber externen Abhängigkeiten. Das ist eine nützliche Korrektur der Vorstellung, dass Souveränität durch den Ort entschieden wird, der auf einer Rechnung steht. Ein System kann nicht operativ unabhängig sein, wenn niemand innerhalb der Organisation es wiederherstellen, diagnostizieren oder eine Änderung genehmigen kann.

Kompetenzen bedeuten nicht, dass jede Organisation für jeden Anbieter einen vollständigen Ersatz beschäftigen muss. Sie bedeuten, dass die Organisation genug Verständnis behält, um eine informierte Entscheidung zu treffen, einen Lieferanten zu beaufsichtigen, eine Wiederherstellung zu verifizieren und eine Antwort zu hinterfragen. Sie sollte wissen, welches Wissen dokumentiert ist, welches von einem Lieferanten gehalten wird, welches von einer Person gehalten wird und welches durch einen Test ausgeübt werden kann. Eine Abhängigkeitskarte, die Menschen auslässt, ist eine schmeichelhafte Fiktion.

Runbooks sollten daher einen Ausstiegspfad enthalten, nicht nur einen Pfad für den Dauerbetrieb. Das Runbook muss nicht jeden Befehl für jedes Ziel beschreiben. Es sollte die Invarianten, Verantwortlichen, Vorbedingungen, Nachweise und Rollback-Bedingungen benennen. Es sollte erklären, was wahr bleiben muss, während der Dienst unterwegs ist. Das macht es nützlich für eine Migration und für einen schwerwiegenden Vorfall, was eine gute Rendite für den Aufwand ist.

Operationale Portabilität umfasst auch den unglamourösen Kalender. Wer ist während der Umstellung verfügbar? Wer kann eine Risikoentscheidung genehmigen? Welcher Lieferant muss eine Frage beantworten? Welcher Regulierungsbehörde, Datenschutzbeauftragter oder Serviceverantwortlicher muss benachrichtigt werden? Welche Wartungsfenster sind verboten, weil ein öffentlicher Dienst, ein Krankenhausprozess oder eine industrielle Steuerungsschleife von ihnen abhängt? Ein System verlässt nicht im Abstrakten. Es verlässt an einem Dienstag, mit Menschen, Schichten und Verpflichtungen.

Eine Klausel ist keine Probe

Es gibt einen zuverlässigen Weg, um herauszufinden, ob eine Ausstiegsklausel funktioniert: Man versucht, sie zu nutzen, bevor es dringend ist. Das bedeutet nicht, den Produktionsdienst zum Spaß zu verschieben. Es bedeutet, die Route gegen einen repräsentativen Ausschnitt, einen Test-Mandanten, eine Wiederherstellungskopie oder eine parallele Umgebung zu üben. Die Probe sollte groß genug sein, um die fehlende Semantik aufzudecken, und klein genug, dass die Organisation lernen kann, ohne den Dienst zu gefährden.

Stellen Sie sich einen hypothetischen regionalen Archivdienst vor. Sein Vertrag listet exportierbare Datensätze auf, erlaubt einen Wechsel zu einem anderen Anbieter und verspricht Unterstützung. Bei einer Probeübung entdeckt das Team, dass der Export Dateien und Kundenkennungen umfasst, aber keine Aufbewahrungsfristen, Rollenzuordnungen oder die Reihenfolge, in der Genehmigungen erfasst wurden. Der Quellanbieter hat die wörtliche Exportspezifikation erfüllt. Der Empfängerdienst hat die Fracht erhalten. Die Organisation hat ihr Aufzeichnungssystem nicht erhalten.

Die Lehre ist nicht, dass der Anbieter den Vertrag zwangsläufig verletzt hat. Die Lehre ist, dass der Vertrag den tatsächlichen Kontinuitätsbedarf der Einrichtung nicht beschrieben hat. Eine Probeübung verwandelt ein Adjektiv in eine Frage. Portabel genug für was? Umkehrbar genug für welchen Ausfall? Sicher genug für welche Daten? Schnell genug für welche öffentliche Verpflichtung? Die Antworten gehören in die Planung vor einer Beschaffungsunterschrift, nicht in einen Streit nach einer Frist.

Eine Probeübung sollte Belege hervorbringen. Die Organisation sollte die Manifeste, Prüfsummen, Schemaversionen, Fehlerlisten, Zeitgrenzen, Genehmigungsprotokolle, Testergebnisse und ungelösten Lücken aufbewahren. Sie sollte wissen, welche Artefakte absichtlich ausgeschlossen wurden und warum. Sie sollte die menschlichen Entscheidungen festhalten, die den Umzug sicher gemacht haben. Hier beginnt eine gewöhnliche Migrationsübung einer Sicherungsmaßnahme zu ähneln. Der Papierweg wird zu einer Sache, die geprüft werden kann.

Probeübungen haben auch eine soziale Wirkung. Sie machen es akzeptabel, zu entdecken, dass der Ausstieg unvollständig ist. Ohne einen Test kann die erste Person, die sagt, dass das System nicht verlagert werden kann, wie ein Hindernis wirken. Mit einem Test hat die Lücke einen Namen, eine Reproduktion und einen Verantwortlichen. Das ist bessere Technik und etwas weniger Theater, was in jeder Saison ein gutes Geschäft ist.

Die Reihenfolge eines Ausstiegs

Eine Migration lässt sich leichter durchdenken, wenn ihre Reihenfolge explizit ist. Beginnen Sie mit der Dienstgrenze, nicht mit der Anbieterbroschüre. Benennen Sie die nutzersichtbare Fähigkeit, die Datensätze, die sie erzeugt, die Entscheidungen, die sie unterstützt, die externen Systeme, die sie aufruft, und die Verpflichtungen, die sie weiterhin erfüllen muss. Identifizieren Sie dann die Daten und digitalen Vermögenswerte, die diese Funktionen tragen, einschließlich der Metadaten und Beziehungen, die ein Empfänger benötigt.

Beschreiben Sie als Nächstes die Invarianten. Welche Kennungen müssen stabil bleiben? Welche Zustände dürfen nicht übersprungen werden? Welche Zeitstempel müssen die Reihenfolge bewahren? Welche Berechtigungen müssen gleichwertig sein, und welche können neu gestaltet werden? Welche Ausgaben dürfen neu berechnet werden, und welche müssen exakt erhalten bleiben? Welche Prüfbelege müssen überprüfbar bleiben? Eine Invariante ist ein Versprechen über Bedeutung. Sie gibt der Migration etwas Stärkeres als eine Dateizahl als Ziel.

Kartieren Sie dann die Abhängigkeiten. Schließen Sie Dienste, Schnittstellen, Anmeldedaten, Schlüssel, Netzwerke, Laufzeitbibliotheken, anbieterspezifische Funktionen, Personen, Verträge, Supportvereinbarungen und behördliche Meldungen ein. Unterscheiden Sie eine Abhängigkeit, die ersetzt werden kann, von einer, die nur überbrückt werden kann. Die Karte sollte die Quelle und das Ziel einschließen, denn ein Zieldienst kann eine neue Abhängigkeit einführen, während er eine alte entfernt. Ein Anbieterwechsel ist nicht automatisch eine Verringerung der Abhängigkeit.

Danach kommt der parallele Pfad. Exportieren Sie einen kontrollierten Ausschnitt. Laden Sie ihn in das Ziel. Führen Sie dieselben Geschäftsfragen, Berechtigungen, Aufträge, Warnungen und Wiederherstellungstests aus. Vergleichen Sie Ergebnisse und erklären Sie Unterschiede. Halten Sie die Quelle verfügbar, während der Vergleich läuft. Es geht nicht darum, zwei Systeme identisch zu machen. Es geht darum zu verstehen, wo sie sich unterscheiden und ob diese Unterschiede für den Zweck des Dienstes akzeptabel sind.

Cutover ist eine Entscheidung, kein Zeitstempel. Jemand braucht die Befugnis, sie zu genehmigen, und die Nachweise müssen für Personen lesbar sein, die nicht im Migrationsraum waren. Definieren Sie vor dem Wechsel eine Rollback-Bedingung. Definieren Sie, was ein Rollback rückgängig machen kann und was nicht. Entscheiden Sie, wie neue Schreibvorgänge behandelt werden, wie Nutzer informiert werden, wie die Quelle geschützt wird und wie das Ziel maßgeblich wird. Wenn das Team keinen Rückweg beschreiben kann, ist es nicht bereit, die Änderung als reversibel zu bezeichnen.

Schließen Sie schließlich den alten Weg bewusst ab. Rufen Sie ab, was der Vertrag verlangt. Verifizieren Sie das Ziel. Gleichen Sie ausstehende Ereignisse ab. Widerrufen Sie Zugangsdaten. Behandeln Sie Backups, Caches und abgeleitete Kopien. Fordern Sie Löschung an, wo angemessen, und bewahren Sie die Nachweise auf, die belegen, dass der alte Dienst keine exportierbaren Kundendaten mehr hält. Ein Anbieterwechsel ist nicht abgeschlossen, wenn der neue Login funktioniert. Er ist abgeschlossen, wenn die alte Autorität beendet ist und die Organisation dies nachweisen kann.

Sicherheit muss mit der Arbeitslast reisen

Der Data Act hält während des gesamten Wechselprozesses ausdrücklich ein hohes Sicherheitsniveau aufrecht. Das klingt offensichtlich, bis eine Migration als Ausnahme von den normalen Kontrollen behandelt wird. Temporäre Zugangsdaten werden in ein Notizbuch kopiert. Ein Transfer-Bucket wird für eine Stunde öffentlich gemacht. Verschlüsselungsschlüssel werden über den Kanal ausgetauscht, der verfügbar war. Alte Konten bleiben aktiv, falls jemand noch etwas prüfen möchte. Der Ausstiegsweg ist zur interessantesten Angriffsfläche der Architektur geworden.

Eine sichere Migration hat ihr eigenes Bedrohungsmodell. Wer kann einen Export anfordern? Wer kann ihn genehmigen? Welches Ziel ist legitim? Wie wird das Manifest signiert? Wie werden unvollständige Transfers erkannt? Wie weist der empfangende Dienst nach, dass ein Datensatz während der Übertragung nicht verändert wurde? Welche Protokolle werden aufbewahrt, und welche enthalten sensible Inhalte, die eine gesonderte Behandlung benötigen? Wie werden Schlüssel an der Grenze rotiert? Das sind gewöhnliche Sicherheitsfragen mit ungewöhnlichem Timing.

Sicherheit umfasst auch Kontinuität. Eine Organisation muss möglicherweise Quelle und Ziel gemeinsam betreiben, während Datensätze abgeglichen werden. Das schafft einen Zeitraum, in dem Daten sich bewegen, Identitäten Grenzen überschreiten und zwei Systeme ihren Zustand ändern können. Das Migrationsdesign sollte diesen Zeitraum begrenzt und beobachtbar machen. Wenn der Doppelbetrieb unbegrenzt wird, hat die Organisation eine dauerhafte Brücke zwischen zwei Abhängigkeiten geschaffen und sie Übergang genannt.

Das Gesundheitswesen verdeutlicht den Punkt, ohne eine dramatische Geschichte zu benötigen. ENISAs Leitfaden für Cloud-Dienste im Gesundheitswesen behandelt Incident-Management, Verschlüsselung, Portabilität und Interoperabilität als Teil der Planung eines sicheren Wechsels. Ein patientenorientierter Dienst kann Sicherheit und Kontinuität nicht als konkurrierende Dekorationen behandeln. Ein Datensatz, der sicher ankommt, nachdem der Dienst nicht mehr verfügbar war, ist für die Person, die Pflege benötigte, keine erfolgreiche Migration.

Für Systeme mit geringerem Risiko gilt dasselbe Prinzip in ruhigerer Form. Der Transfer sollte für den Zeitraum, in dem ein Rollback weiterhin möglich ist, mit geringsten Rechten erfolgen, protokolliert, getestet und reversibel sein. Die Unterstützung eines Anbieters sollte kein Grund sein, die Verifizierung der empfangenden Organisation zu lockern. Guter Glaube ist eine rechtliche Erwartung. Er ist kein Ersatz für kryptografische Prüfungen und eine Bedienperson, die weiß, was die Prüfungen bedeuten.

Löschung ist Teil des Verlassens

People often describe an exit as moving data from one provider to another. The old provider then becomes a footnote. The Data Act gives that footnote a job: after the retrieval period, the contract must guarantee full erasure of exportable data and digital assets generated directly by or relating directly to the customer when the switching process has completed successfully, subject to the stated conditions and any agreed later date.

Erasure is harder when the service has produced derivatives. Working tables may have become indexes. Indexes may have become caches. A document may have been summarised into a ticket, embedded into a search state or included in a backup. Some derivatives are customer assets. Some are provider internals. Some may be required for a legal retention period. The contract and technical design need to make the categories visible enough for a decision to be checked.

A good exit inventory therefore has two directions. It traces what must move to the destination, and it traces what must disappear from the source. The second direction protects the customer from silent retention and the provider from an impossible promise. It also exposes a familiar weakness: teams may know how to export the data they can see and have no map of the copies they created indirectly.

Erasure evidence should be proportionate and meaningful. A provider’s statement can be useful. A machine-readable record, an identified retention boundary and a verifiable completion event are better. The organisation should know what the evidence proves and what it cannot prove. There is no virtue in producing a beautifully signed certificate for a deletion process that never knew about the cache.

Leaving should reduce the old dependency, not merely move the data into a second system while the first keeps a shadow of it forever. The boundary needs an end state. Otherwise the organisation has paid for a migration and retained the original liability as a souvenir.

Multi-cloud is not a personality

Using more than one provider can reduce dependence, but it can also multiply the number of things an organisation must understand. A second provider may give the team an alternative route, or it may become a second specialist dependency connected by a private integration. The label multi-cloud says how many clouds are present. It says nothing about how many exits are real.

The Data Act recognises parallel use of several data processing services and distinguishes it from a one-off switch. The Regulation also acknowledges that ongoing data egress for parallel use can have a different cost treatment during the transition. This is a useful legal distinction. It is also an operational warning. A design that continuously moves data between providers needs an explicit contract, security model, reconciliation process and budget. It is not a free rehearsal that happens to run forever.

Multi-cloud can make sense when the boundaries are clear. A public agency may separate a workload by sensitivity or continuity requirement. A research group may use a second environment for reproducibility. A manufacturer may keep control logic near a plant while using a separate service for analysis. These are architectural choices, not badges of independence. Each needs a reason, an owner and a way to recover when one route is unavailable.

There is also a skills cost. Two platforms mean two sets of permissions, failure modes, release practices and escalation paths unless the organisation creates a genuinely common operating layer. A second platform that nobody can operate under pressure is not resilience. It is a very expensive spare key in a drawer that nobody has opened.

The useful question is not whether an organisation has two providers. It is whether it can move a defined service boundary without losing control. Sometimes the answer is a well-designed single-provider deployment with a tested export. Sometimes it is a federated arrangement. Sometimes it is an on-premises route. The architecture should earn its topology.

Sovereignty is the ability to move and stay

The Commission’s Cloud Sovereignty Framework is valuable here because it does not reduce sovereignty to a server’s postcode. It names strategic, legal and jurisdictional, data and AI, operational, supply-chain, technological, security and compliance, and environmental objectives. Its operational objective asks whether European actors can run, support and evolve a technology independently of foreign control. Its technology objective discusses openness, transparency, interoperability, auditability and avoiding lock-in to foreign proprietary systems.

That framework is an assessment approach for a public procurement context. It is not a universal score, and it does not certify that a provider can be replaced on a deadline. Its usefulness is the shape of the questions. Who can make a change? Who can keep the service alive if support is withdrawn? Which skills and components are exposed to an external dependency? Which legal claims can reach the operator? Which parts of the stack can be inspected and evolved?

Location still matters. Jurisdiction matters. Ownership matters. They answer important questions about access, authority and industrial capacity. They do not answer whether the organisation can restore the service from a portable state, whether the data model is understood or whether a replacement team can operate the workload. Sovereignty without an exit route is a flag over a locked room.

Staying matters too. A provider may be easy to leave but difficult to operate with today. Portability should not be treated as an excuse to choose a poor service or ignore security. The point is to keep the power to make a different choice. A system with a credible exit can choose to remain for good reasons. A system without one remains because the cost of movement has become a veto.

Openness is a design choice, not a licence badge

Open source can reduce dependency, but a licence alone does not make an operational boundary portable. The organisation also needs a format that can be read, a build that can be reproduced, an interface that is documented, a release process that is visible and people who can maintain the path. An abandoned open repository is open in the same way an unlocked shed is available: technically, perhaps; usefully, not always.

Open standards have a similar discipline. A standard can be public while implementations disagree about edge cases, versioning and error handling. A portable boundary needs conformance tests and a way to record which version was used. It should make the meaning of a state inspectable without requiring a private service. The standard is the common language. The test suite is how the speakers prove they understood one another.

At Dweve, this is the narrow reason we describe BitWeave’s boundary in terms of a portable semantic state rather than a hosted search endpoint. The public page describes one on-disk .bwks index format across its in-process, standalone-server and compatible WASM surfaces. That is a small engineering example, not evidence that every workload is portable and not a claim that an open component removes all contractual or operational dependency. The useful principle is simply to make the state and the boundary explicit.

The wider point survives without Dweve. When a system’s essential state can be inspected, moved and tested through a documented contract, an organisation has more choices. When the state exists only inside a provider’s runtime, the organisation has fewer. A licence can help create the first condition. It cannot create it on its own.

What procurement should ask before the signature

Procurement is often asked to compare price, features, security certifications and service levels. Exit should sit in the same conversation. It should be specific enough for a technical reviewer to test and plain enough for a legal or service owner to understand. A useful question is one that can be answered with a document, an interface call, a rehearsal or an owner. A vague promise is none of these.

Ask what can leave. Request an exhaustive category list, not a sentence saying customer data is exportable. Ask which metadata, relationships, configurations, audit records, derived artefacts and digital assets are included. Ask what is excluded as provider internals or trade secrets, and why the exclusion does not prevent the service from being rebuilt or its function from being continued.

Ask how it leaves. Request formats, schemas, interface descriptions, rate limits, ordering rules, integrity checks, encryption arrangements and a destination-neutral test export. Ask whether the destination provider can receive the data through an open interface and whether the provider will support a representative rehearsal. The answer should not depend on an emergency exception.

Ask what stays working. Define service continuity, functional equivalence and the conditions under which the source remains responsible. Ask how new writes, retries, scheduled jobs, alerts, identity changes and support requests behave during the transition. Ask who can approve the cutover and who can stop it. A contract that specifies data but not authority is incomplete for a consequential service.

Ask who can operate the replacement. Name the skills, documentation, training, tool access, support and evidence needed to run the destination. Ask whether a provider-specific certification is the only practical route to competence. Ask how the organisation will recover if the original supplier becomes unavailable during the move. These questions expose operational lock-in before it becomes a staffing emergency.

Ask how the old route closes. Define retrieval, retention, deletion, backup handling, key revocation, access removal and evidence. Ask how the organisation will prove that the export completed and that the old authority ended. The last question is often the one that turns a pleasing procurement document into a serious one.

A small exit scorecard

An organisation does not need a universal number to compare exits. It needs a short record that makes the important gaps difficult to hide. The following questions are a starting point, not a statutory test:

• Can a new team identify and interpret every asset that the service must carry?
• Can the destination validate the export without proprietary assistance?
• Can the service continue while the source and destination are reconciled?
• Can the organisation reproduce the permissions, evidence and policy state that matter?
• Can a named person stop or reverse the move under defined conditions?
• Can the required security controls operate during transfer and retrieval?
• Can the organisation run the replacement with skills it can retain or obtain?
• Can it prove what was erased, retained or intentionally excluded at the source?

The value of this list is not the list itself. It is the demand for an answer that can be checked. A provider may answer some questions with contractual terms, some with technical documentation, some with a test and some with a limitation. That is healthy. A limitation that is visible can be managed. A limitation that appears only during an urgent migration owns the timetable.

Exit changes how a system is designed

Once a team treats exit as a real property, design discussions become more precise. State needs an owner and a format. Interfaces need a version and a conformance test. Derived artefacts need a lineage and a deletion rule. Credentials need a rotation path. Provider-specific features need a reason, an alternative or an explicit acceptance of dependency. Operational knowledge needs a home outside one person’s memory.

This discipline can improve the system even when nobody ever switches. A portable state is easier to back up and restore. A documented interface is easier to test. A clear dependency map is useful during an outage. A rehearsal exposes ambiguous permissions before they become a security incident. A named rollback owner makes a release decision less ceremonial. Exit is a resilience practice wearing procurement clothing.

It can also prevent a common strategic error. Organisations sometimes try to buy sovereignty at the end by adding a second provider, a legal addendum or a dashboard that counts cloud regions. These additions may help, but they do not reverse a design that has hidden its semantics, skills and authority inside one service. The cheapest time to make an exit credible is before the dependency becomes the shortest path to every important outcome.

There is no shame in choosing a dependency. Every serious system has them. The shame is in calling a dependency optional because the contract has an export clause. Clarity lets an organisation price the choice, govern it and decide when the trade-off is no longer acceptable. It also gives a provider a fairer relationship with the customer. A service that earns renewal by being useful is stronger than one that earns it by being impossible to leave.

The system should be allowed to leave

The cost of a system that cannot leave is not only the eventual migration bill. It is the authority surrendered before the bill arrives. It is the supplier’s private vocabulary becoming the organisation’s public process. It is a runtime nobody else can operate, a record nobody else can interpret and a decision nobody can reverse without asking permission from the system that made the dependency.

European policy is pushing in the right direction. The Data Act makes switching rights, export information, cooperation, continuity, interoperability and the removal of charges part of the legal landscape. The Commission’s cloud policy puts interoperable infrastructure and procurement criteria beside competitiveness and security. ENISA has been naming lock-in and loss of governance as cloud risks for years, and its healthcare guidance connects portability to the safe continuity of a sensitive service. These sources do not describe an effortless future. They describe the work that an effortless claim tends to hide.

The practical answer is modest and demanding. Design the exit while designing the service. Describe the state before you purchase the runtime. Test the export before you need it. Keep enough operational knowledge to challenge the supplier and run the destination. Treat security, continuity, authority and erasure as part of the move. Record what cannot travel. Rehearse the route with people who will have to sign their names to the outcome.

Ein System kann jahrelang bei einem Anbieter bleiben. Das ist völlig vernünftig, solange die Wahl bewusst bleibt. Der Maßstab ist, ob die Organisation erneut wählen könnte. Wenn sie das kann, ist die Abhängigkeit beherrscht. Wenn nicht, hat die Abhängigkeit das Sagen. Software hat eine nüchterne Art, Machtverhältnisse offenzulegen. Geben Sie ihr einen Ausweg, bleibt sie Infrastruktur. Nehmen Sie den Ausweg weg, wird sie zum Vermieter.

Quellen

• Regulation (EU) 2023/2854, Data Act, Chapter VI, EUR-Lex, Amt für Veröffentlichungen der Europäischen Union.
• Data Act explained, Europäische Kommission.
• Cloud computing, Europäische Kommission.
• Cloud Sovereignty Framework: implementation guidance, Europäische Kommission, Generaldirektion Digitale Dienste.
• Cloud Computing Risk Assessment, Agentur der Europäischen Union für Cybersicherheit.
• Securing cloud services for health, Agentur der Europäischen Union für Cybersicherheit.
• BitWeave, Dweve.