EU Cloud Switching & Exit Readiness Report 2026

Executive Summary

Der EU Data Act verändert Cloud Switching von einer überwiegend vertraglichen Frage zu einem regulierten Betriebsprozess. Seit dem 12. September 2025 ist die Verordnung anwendbar. Für Anbieter von Datenverarbeitungsdiensten enthält sie Vorgaben zum Abbau von Wechselhindernissen, zur vertraglichen Transparenz und zur Unterstützung des Wechsels. Ab dem 12. Januar 2027 sollen Switching Charges einschließlich der für einen erfassten Wechsel anfallenden Data-Egress-Gebühren vollständig entfallen.

Das beseitigt nicht automatisch den Cloud-Lock-in. Datenübertragung ist nur eine Schicht. Ein realer Exit umfasst Daten und Metadaten, Schemas, Identitäten, Schlüssel, Netzwerke, Serviceabhängigkeiten, Deploymentartefakte, Observability, Betriebswissen, Verträge und einen kontrollierten Abschaltpfad. Selbst ein Anbieter mit kostenlosem Egress kann hohe Wechselkosten erzeugen, wenn proprietäre Managed Services, fehlende Exportpfade oder ungetestete Restore-Prozesse dominieren.

Dieser Report konsolidiert drei Untersuchungen:

1. einen Documentation Readiness Score für fünf große Cloudanbieter;
2. ein reproduzierbares Routine-Egress-Modell für 1, 10 und 100 TB sowie eine Matrix öffentlicher Exit-Programme;
3. zehn dokumentierte Produktabschaltungen und Service-Enden als Recovery-Fallstudien.

Die Ergebnisse sind bewusst keine Konformitätsbescheinigung. Sie zeigen, welche Informationen öffentlich auffindbar sind, welche Kostenklassen sich berechnen lassen und welche operativen Kontrollen ein Kunde selbst besitzen muss.

Zitierfähige Kernergebnisse

1. [OBSERVED] Der EU Data Act ist seit 12. September 2025 anwendbar; seine Cloud-Switching-Regeln adressieren technische, vertragliche, kommerzielle und organisatorische Hindernisse.
2. [OBSERVED] Ab 12. Januar 2027 sollen Switching Charges einschließlich entsprechender Data-Egress-Gebühren vollständig entfallen. Diese Regel ist nicht mit generell kostenlosem laufendem Internet-Egress gleichzusetzen.
3. [CALCULATED] Im offengelegten Dokumentationsscore erreicht Google Cloud 95/100, Oracle Cloud Infrastructure 88/100, Azure 84/100, AWS 82/100 und IBM Cloud 65/100. Gemessen wird öffentliche Dokumentationsreife, nicht tatsächliche Rechtskonformität.
4. [CALCULATED] In den Routine-Egress-Szenarien reichen die modellierten Transferkosten je nach Anbieter, Tariflogik und Volumen von null beziehungsweise gebündelten Beträgen bis zu mehreren Tausend Euro pro Monat. Requests, Retrieval, Storage, Support und Engineering sind separat zu berücksichtigen.
5. [OBSERVED] Mehrere Hyperscaler dokumentieren Programme oder Gutschriften für einen vollständigen geplanten Exit. Bedingungen, Fristen, Scope und Kontoschließung unterscheiden sich.
6. [INTERPRETATION] Ein gesetzliches Wechselrecht ist nur dann operativ nutzbar, wenn Export, Rehydration, Reconciliation, Security und Cutover vorher getestet wurden.
7. [INTERPRETATION] Eine lange Abschaltungsfrist beweist keine Recovery-Fähigkeit. Ohne vollständigen Export- und Importpfad verlängert sie lediglich die Zeit, in der das Risiko sichtbar ist.
8. [RECOMMENDATION] Jeder kritische Cloudservice braucht ein versioniertes Exit Record, ein getestetes Exportartefakt, Zielarchitektur, Kostenbudget, RACI und einen letzten erfolgreichen Drill.

---

1. Forschungsfrage und Scope

Wie weit reduzieren Recht, öffentliche Anbieterdokumentation und Preisprogramme die Wechselbarriere – und welche Exit-Kosten sowie Recovery-Aufgaben verbleiben beim Kunden?

Untersucht werden vier Ebenen:

Ebene	Untersuchungsgegenstand	nicht behauptet
Recht	Data-Act-nahe Anforderungen und Zeitpunkte	individuelle Rechtsberatung oder Konformitätsprüfung
Dokumentation	öffentlich auffindbare Switching-, Export- und Supportpfade	tatsächliche Qualität eines konkreten Enterprise-Projekts
Kosten	öffentliche Routine-Egress-Preise und dokumentierte Exit-Programme	vollständiger TCO eines konkreten Accounts
Recovery	öffentliche Shutdown-/Sunset-Fälle und daraus ableitbare Kontrollen	repräsentative Ausfallwahrscheinlichkeit aller Anbieter

1.1 Analyseobjekte

• fünf große Cloudanbieter im Documentation Readiness Score;
• acht Object-Storage- beziehungsweise Cloud-Egress-Modelle;
• öffentlich dokumentierte Vollausstiegs- oder Egress-Regeln;
• zehn Shutdown-/Sunset-Ereignisse zwischen 2015 und 2026;
• sieben technische und organisatorische Exit-Schichten.

1.2 Aussageklassen

• [OBSERVED]: direkt aus einer öffentlichen Quelle dokumentiert;
• [CALCULATED]: aus offengelegten Regeln und Daten berechnet;
• [SCENARIO]: modellierte Annahme, nicht beobachteter Kundenfall;
• [INTERPRETATION]: analytische Schlussfolgerung;
• [RECOMMENDATION]: operative Handlungsempfehlung.

---

2. Das gemeinsame Exit-Modell

Ein Cloud-Exit ist kein einzelner Datenexport. FW Delta Research verwendet sieben voneinander trennbare Schichten.

Schicht	zu übertragender Zustand	typische versteckte Abhängigkeit	Nachweis eines belastbaren Exits
1. Vertrag	Kündigung, Fristen, Gebühren, Support	automatische Verlängerung, Mindestabnahme	geprüfter Exit-Kalender und Kostenfreigabe
2. Daten	Nutzdaten, Dateien, Metadaten, Historie	unvollständige Exporte, Retrieval Fees	vollständiger Export plus Checksums
3. Schema und Logik	Datenmodelle, Regeln, Jobs, Policies	proprietäre Workflows und Functions	maschinenlesbare Definitionen und Mapping
4. Identität und Secrets	Rollen, Gruppen, Schlüssel, Zertifikate	Provider-IAM, nicht exportierbare Secrets	neues IAM-Modell und Rotation
5. Netzwerk	DNS, IPs, Peering, Firewalls, Egress	private Endpunkte, feste Allow-Lists	reproduzierbare Netzwerkkonfiguration
6. Betrieb	Logs, Alerts, SLOs, Runbooks, Backups	providergebundene Observability	Zielmonitoring und getesteter Restore
7. Abschaltung	Reconciliation, Read-only, Löschung	unbekannte Restdaten und offene Jobs	signiertes Cutover- und Deletion Record

2.1 Der Portability Gap

Portability Gap =
benötigter betrieblicher Zustand
- tatsächlich exportierbarer und wiederherstellbarer Zustand

Je größer diese Lücke, desto weniger relevant ist die reine Egress-Rate. Ein kostenloser Datenstrom hilft wenig, wenn Berechtigungen, Scheduler, Functions, Event-Routen oder Managed-Service-Semantik manuell rekonstruiert werden müssen.

2.2 Vier Kostenklassen

Total exit cost =
Transferkosten
+ Transformationskosten
+ Parallelbetrieb
+ Risikokosten

Transferkosten umfassen Egress, Requests, Retrieval, Medien und Netzwerk. Transformation umfasst Exportskripte, Schema-Mapping, Replatforming und Tests. Parallelbetrieb entsteht durch doppelte Infrastruktur, Datenreplikation und verlängerte Supportverträge. Risikokosten umfassen Downtime, Datenverlust, Fehlkonfiguration, Security-Gaps und entgangenen Umsatz.

---

3. Teil I - Rechtlicher Rahmen und öffentliche Provider-Readiness

2. Rechtlicher Rahmen

2.1 Anwendungsdatum

[OBSERVED] Die Verordnung (EU) 2023/2854 wurde Ende 2023 veröffentlicht und gilt seit 12. September 2025.

2.2 Wechsel zwischen Datenverarbeitungsdiensten

Kapitel VI zielt auf Hindernisse bei:

• Wechsel zu einem anderen Anbieter,
• Übertragung auf On-Premises-Infrastruktur,
• paralleler Nutzung mehrerer Anbieter,
• Portierung exportierbarer Daten und digitaler Assets.

2.3 Fristen

Der Data Act sieht grundsätzlich einen maximalen Übergangszeitraum von 30 Kalendertagen nach der einschlägigen Notice-/Initiierungsphase vor. Wenn dies technisch nicht machbar ist, kann unter den gesetzlichen Voraussetzungen eine begründete alternative Übergangsfrist von höchstens sieben Monaten relevant werden. Der Vertrag muss außerdem eine Mindestperiode für Datenabruf nach dem Übergang adressieren.

Die genaue Anwendung hängt vom Vertrag, Service und Sachverhalt ab.

2.4 Switching Charges

Die Europäische Kommission erläutert:

• bis 12. Januar 2027 besteht ein Übergangsregime,
• ab 12. Januar 2027 sollen Switching Charges einschließlich Data Egress, soweit sie dem Wechsel dienen, vollständig entfallen.

Drei Abgrenzungen sind entscheidend:

1. Routine-Egress: laufender Datenverkehr im Normalbetrieb
2. Switching-Egress: Datenübertragung im Rahmen eines qualifizierten Wechsels
3. Early Termination/Commitment: verbleibende Vertrags- oder Mindestabnahmeverpflichtungen

Ein Anbieter kann Switching-Egress erlassen und trotzdem Routine-Egress berechnen. Ein Gebührenverzicht beendet zudem nicht automatisch Mindestlaufzeiten oder andere vertragliche Verpflichtungen.

---

---

3. Methodik

3.1 Stichprobe

• Amazon Web Services
• Microsoft Azure
• Google Cloud
• Oracle Cloud Infrastructure
• IBM Cloud

OVHcloud und Hetzner wurden in der Recherche berücksichtigt, aber nicht gerankt. Bis zum Datenstichtag wurde keine hinreichend dedizierte, öffentlich auffindbare Data-Act-Mapping-Seite mit vergleichbarer Detailtiefe identifiziert. NR bedeutet hier nicht gerankt, nicht „nicht konform“.

3.2 Kriterien

Code	Kriterium	Gewicht
L	dedizierte rechtliche Zuordnung oder Addendum	15
P	öffentlicher Switching-Prozess	15
E	servicebezogene Exportdokumentation	15
F	Formate, APIs und Schnittstellen	15
T	Fristen, Transition und Continuity	10
C	Behandlung von Switching-/Egress-Kosten	15
D	Retrieval, Löschung und Abschluss	10
S	Support- und Eskalationspfad	5

Readiness Score = L + P + E + F + T + C + D + S

3.3 Bewertungsgegenstand

Der Score misst die Qualität der öffentlichen Nachvollziehbarkeit. Er misst keine interne operative Leistungsfähigkeit. Ein Anbieter kann einen hohen Score haben und eine komplexe Migration erfordern.

---

---

4. Gesamtergebnis

Rang	Anbieter	Dokumentationsreife / 100
1	Google Cloud	95
2	Oracle Cloud Infrastructure	88
3	Microsoft Azure	84
4	AWS	82
5	IBM Cloud	65

Vollständige Matrix

Anbieter	L /15	P /15	E /15	F /15	T /10	C /15	D /10	S /5	Gesamt
Google Cloud	15	15	15	15	10	15	5	5	95
Oracle Cloud Infrastructure	15	15	15	13	10	10	5	5	88
Microsoft Azure	15	12	15	12	10	10	5	5	84
AWS	15	10	15	12	10	10	5	5	82
IBM Cloud	10	8	10	10	5	10	7	5	65

Maschinenlesbare Fassung:

data/FDR-2026-05_cloud_switching_readiness.csv

---

---

5. Anbieteranalysen

5.1 Google Cloud – 95 Punkte

Google veröffentlicht eine ausführliche Zuordnung von Artikeln des Data Act zu Vertragsklauseln und Prozesskomponenten. Die Mapping-Seite behandelt unter anderem:

• 30-tägige Migration Period,
• Initiation Period,
• alternative Frist bei technischer Unmöglichkeit,
• exportierbare Daten und digitale Assets,
• ausgenommene interne Daten,
• Data Recovery Period,
• Löschung,
• Business Continuity,
• Sicherheitsanforderungen.

Zusätzlich bestehen allgemeine Data-Portability-Dokumentation und ein Programm zur Eliminierung bestimmter Data-Transfer-Gebühren beim vollständigen Wechsel.

[INTERPRETATION] Google erreicht den höchsten Wert nicht wegen einer behaupteten „einfachen Migration“, sondern weil die öffentliche Dokumentation Vertrag, Frist und Prozess granular verknüpft.

5.2 Oracle Cloud Infrastructure – 88 Punkte

Oracle stellt eine dedizierte EU-Data-Act-Seite und servicebezogene Hinweise zu Switching-Methoden bereit. Ein Addendum behandelt vertragliche Aspekte.

Stärken:

• dedizierte Rechts-/Vertragsdokumentation,
• konkrete servicebezogene Export- und Migrationspfade,
• Supportbezug.

Grenzen:

• der Gesamtprozess ist über mehrere Dokumente verteilt,
• „keine Switching Charges“ muss von verbleibenden Early-Termination- oder Commitment-Effekten getrennt werden,
• Retrieval-/Löschlogik ist öffentlich weniger kompakt als im Google-Mapping.

5.3 Microsoft Azure – 84 Punkte

Microsoft dokumentiert Data Export und Cloud Choice über APIs, PowerShell, Portale und maschinenlesbare Formate. Die öffentliche Bandbreitenseite beschreibt zudem ein Verfahren für kostenloses Egress bei einem vollständigen Ausstieg aus Azure.

Stärken:

• breite Exportdokumentation,
• kostenloser Exit-Egress mit Antragsprozess,
• klare administrative Tools,
• umfangreiche servicebezogene Dokumentation.

Grenzen:

• manche Konfigurationen und proprietäre Daten sind nicht identisch exportierbar,
• Data-Act-spezifische End-to-End-Dokumentation ist weniger zentralisiert,
• ein Credit-/Supportprozess ist nicht dasselbe wie automatisch gebührenfreier Routine-Egress.

5.4 AWS – 82 Punkte

AWS kündigte 2024 ein weltweites Programm an, bei dem Kunden für einen vollständigen Wechsel zusätzlichen Data Transfer Out über Support gutschreiben lassen können. Spätere Aktualisierungen verweisen für EU-Kunden auf ein Data-Act-Addendum und definierte Prozesskriterien.

Stärken:

• dokumentierter Supportpfad,
• etablierte Service-Exporttools,
• kostenlose Exit-DTO-Credits unter Bedingungen,
• umfangreiche technische Migrationsdokumentation.

Grenzen:

• der Kunde muss den Exit als solchen anmelden,
• Freigabe und Zeitfenster sind prozessgebunden,
• AWS-Servicevielfalt macht „funktionale Äquivalenz“ zu einer workload-spezifischen Frage,
• Routine-Egress und qualifizierter Exit müssen getrennt werden.

5.5 IBM Cloud – 65 Punkte

IBM weist in den Cloud Terms darauf hin, dass EU-Kunden bei einer Migration aus IBM Cloud Anspruch auf reduzierte Data-Egress-Charges nach den Data-Act-Bedingungen haben können und Support beziehungsweise den Ansprechpartner kontaktieren sollen.

Stärken:

• Data Act öffentlich erwähnt,
• Support-/Case-Pfad,
• Vertragsbezug.

Grenzen:

• weniger öffentliche End-to-End-Prozessdetails,
• weniger granularer Service- und Fristen-Mapping-Ansatz,
• Gebührenbehandlung und Exportkategorien benötigen eher individuellen Support.

[INTERPRETATION] Der niedrigere Score ist eine Aussage über öffentliche Dokumentationsdichte, nicht über die tatsächliche Rechtsposition des Kunden.

---

---

6. Was ein Cloud-Exit tatsächlich umfasst

6.1 Daten

• Objekt- und Dateispeicher
• Datenbanken
• Snapshots
• Logs
• Backups
• Secrets
• Metadaten
• IAM-Konfiguration
• Images und Artefakte

6.2 Compute

• VM-Images
• Container
• Serverless-Funktionen
• Autoscaling
• Scheduling
• Accelerator-/GPU-Abhängigkeiten

6.3 Netzwerk

• IP-Adressen
• DNS
• Load Balancer
• Firewalls
• Private Links
• Peering
• Routing
• Zertifikate

6.4 Managed Services

Hier entsteht der größte semantische Wiederaufbau:

• proprietäre Datenbanken
• Queues
• Event Bus
• AI/ML-Dienste
• Observability
• Identity
• Data Warehouses
• Serverless-Plattformen

[INTERPRETATION] Der Data Act kann vertragliche und technische Hindernisse reduzieren. Er macht aus einem proprietären Managed Service aber nicht automatisch eine identische portable Runtime.

---

---

7. Switching Readiness auf Kundenseite

7.1 Exportable Asset Register

Für jeden Service:

Feld	Beispiel
Service	Managed PostgreSQL
Daten	Tabellen, WAL, Nutzer, Extensions
Exportformat	SQL dump, logical replication
Volumen	4,2 TB
Abhängigkeiten	IAM, KMS, DNS, Monitoring
RTO/RPO	2 h / 5 min
Ziel	PostgreSQL auf anderem Provider
Validierung	Row counts, checksums, query suite
Owner	Data Platform
letzter Test	2026-06-15

7.2 Exit Runbook

1. Scope einfrieren.
2. Zielumgebung bereitstellen.
3. Datenklassifikation und Rechtsgrundlage prüfen.
4. Voll- und Delta-Transfer planen.
5. Secrets und Keys rotieren.
6. Performance testen.
7. Business Continuity prüfen.
8. Cutover.
9. Validierung.
10. Retrieval-Zeit nutzen.
11. Löschung bestätigen.
12. Vertrag und Billing schließen.

7.3 Exit Budget

Auch bei null Switching Charges bleiben:

• Engineering
• Zielinfrastruktur
• Parallelbetrieb
• Tests
• Downtime-Risiko
• Datenbereinigung
• Anwendungskonvertierung
• Schulung
• externe Beratung

Gebührenfreiheit beseitigt eine Rechnungskomponente, nicht das Migrationsprojekt.

---

---

8. Procurement-Anforderungen ab 2026

[RECOMMENDATION] Neue Cloud-Verträge sollten mindestens adressieren:

• exportierbare Kategorien,
• ausgeschlossene interne Daten,
• Formate und APIs,
• Notice-/Initiierungsprozess,
• maximale Transition,
• technische Unmöglichkeit und Verlängerung,
• Continuity und Security,
• Retrieval-Zeit,
• Löschbestätigung,
• Switching Charges,
• Routine-Egress,
• Commitments und Early Termination,
• Support-SLA,
• Testexport,
• Subprocessor-/Marketplace-Abhängigkeiten.

Vertrags- und Architekturtest

Der beste Zeitpunkt für den ersten Exit-Test ist vor dem Go-live, nicht vor der Kündigung.

---

---

9. Warum Egress allein kein Lock-in-Maß ist

Ein Speicheranbieter kann null Egress-Gebühren verlangen und dennoch hohe Wechselkosten erzeugen, wenn:

• APIs proprietär sind,
• Datenmodelle nicht portabel sind,
• Export langsam ist,
• Abhängigkeiten und Identitäten fehlen,
• Managed Services neu implementiert werden müssen.

Umgekehrt kann ein Anbieter Egress berechnen, aber standardisierte Formate und sehr gute Exportwerkzeuge bieten.

[INTERPRETATION] Lock-in ist multidimensional:

Datenmenge
× Egresspreis
+ semantischer Wiederaufbau
+ Betriebsunterbrechung
+ Vertragsbindung
+ Organisationsaufwand

---

4. Teil II - Routine-Egress, Exit-Programme und Kostenmodell

2. Begriffe, die nicht vermischt werden dürfen

2.1 Routine-Egress

Wiederkehrende Übertragung aus dem Cloud-Service zu Internet-Zielen, beispielsweise:

• Downloads durch Endkunden,
• Datenausleitung an Partner,
• CDN-Origin-Traffic,
• regelmäßige Replikation in eine andere Umgebung,
• Analytics- oder Backup-Exports,
• API-Antworten mit hohem Datenvolumen.

Dieser Verkehr ist Teil des normalen Betriebs. Ein Anbieter kann ihn nach Volumen abrechnen, in einem Tarif bündeln, an Storage-Nutzung koppeln oder mit null ausweisen.

2.2 Planned Exit

Ein geplanter vollständiger oder weitgehender Anbieterwechsel. Dafür können gesonderte Bedingungen gelten:

• Support-Antrag,
• Exit Notice,
• definierter Migrationszeitraum,
• Credit statt sofortiger Nullpreis,
• Liste erfasster Services,
• Abschluss- oder Kündigungsprozess,
• Ausschluss mehrfacher oder normaler Transfers.

Ein Exit-Programm ist deshalb keine Flat Rate für gewöhnlichen Traffic.

2.3 Switching Charges nach EU Data Act

Der EU Data Act adressiert Hindernisse beim Wechsel zwischen Data Processing Services. Die Europäische Kommission beschreibt, dass Switching Charges einschließlich Gebühren für Data Egress ab 12. Januar 2027 vollständig entfallen sollen. Bis dahin bestand eine Übergangsphase, in der kostenbasierte Gebühren möglich waren.

[CRITICAL] Der konkrete Scope ist rechtlich und vertraglich zu prüfen. Der Report behandelt keine Einzelfallfrage und behauptet nicht, dass ab 12. Januar 2027 sämtlicher Internet-Egress unabhängig vom Anlass, Vertrag, Kundenstandort und Dienst kostenlos ist.

2.4 Data Retrieval

Retrieval ist die technische oder tarifliche Wiederbereitstellung von Daten aus einer Storage-Klasse. Ein Anbieter kann Egress mit null ausweisen und gleichzeitig Retrieval berechnen. Bei Archiv- oder Infrequent-Access-Klassen ist das für Exit-Kosten entscheidend.

---

---

3. Methodik

3.1 Stichprobe

Die Stichprobe umfasst acht Anbieter:

• AWS
• Microsoft Azure
• Google Cloud
• Cloudflare R2
• Backblaze B2
• Wasabi
• OVHcloud
• Hetzner Object Storage

Für AWS, Azure und Google Cloud wurde ein numerisches Routine-Egress-Modell erstellt. Die fünf weiteren Anbieter wurden wegen abweichender Bündel-, Nullpreis- oder Fair-Use-Modelle in einer Policy-Matrix analysiert, statt sie durch falsche Gleichsetzung in dieselbe Preisreihe zu zwingen.

3.2 Einheit

Das Nutzungsvolumen wird als dezimales TB definiert:

1 TB = 1.000 GB = 10^12 Byte

Provider-spezifische Abrechnungseinheiten bleiben erhalten:

• Azure veröffentlicht für die betrachtete Tabelle ausdrücklich 1 TB = 1.000 GB.
• AWS-Beispiele verwenden für TB-Grenzen 1 TB = 1.024 GB; die Modellgrenzen wurden entsprechend angesetzt.
• Google Cloud berechnet die betrachtete Cloud-Storage-Übertragung pro GiB und staffelt in TiB. Dezimale TB wurden deshalb in GiB umgerechnet.

Diese Trennung verhindert, dass gleich beschriftete „TB“ stillschweigend als identische Billing-Einheit behandelt werden.

3.3 Szenario

Modelliert wird:

• Quelle in Europa beziehungsweise europäische Referenzregion,
• Übertragung ins öffentliche Internet,
• normales Zielgebiet ohne höhere Sondertarife,
• ein Abrechnungsmonat,
• 1, 10 oder 100 dezimale TB,
• öffentliche Pay-as-you-go-Listenpreise,
• keine Individualrabatte oder Commitments.

3.4 Ausschlüsse

Nicht enthalten sind:

• Storage-Kapazität,
• PUT/GET/List- oder sonstige API-Operationen,
• Retrieval- und Early-Deletion-Gebühren,
• Compute und Datenbankexporte,
• Inter-Region- oder Inter-Zone-Traffic,
• CDN und private Interconnects,
• Premium Routing oder Beschleunigung,
• Support,
• Umsatzsteuer,
• Vertragsstrafen und Restlaufzeiten,
• Engineering und Doppelbetrieb,
• Downtime und Opportunitätskosten.

3.5 Währung

EUR-Kosten = USD-Kosten / 1,1367

Verwendet wurde der EZB-Referenzkurs vom 28. Juli 2026. Die Umrechnung ist eine Vergleichsnormalisierung und kein Rechnungsbetrag.

---

---

4. Routine-Egress: öffentliche Listenpreise

Monatliches Volumen	AWS	Microsoft Azure	Google Cloud
1 TB	71,26 €	68,88 €	98,32 €
10 TB	783,85 €	757,72 €	983,19 €
100 TB	6.872,70 €	6.759,04 €	9.102,62 €

Maschinenlesbare Eingaben, Einheiten, USD-Werte, EUR-Werte und Quellen:

data/FDR-2026-05_egress_costs.csv

4.1 AWS

[OBSERVED] AWS weist für Data Transfer Out aus Regionen ins Internet die ersten 100 GB pro Monat als kostenlos aus. Ein offizielles S3-Beispiel nennt für Europe (Ireland) 0,09 US-Dollar pro GB. Öffentliche AWS-DTO-Beispiele dokumentieren danach Staffelwerte von 0,09 US-Dollar für die ersten 10 TB, 0,085 US-Dollar für die nächsten 40 TB und 0,07 US-Dollar für die nächste Stufe.

[CALCULATED] Im normalisierten Modell ergeben sich:

• 1 TB: 71,26 Euro
• 10 TB: 783,85 Euro
• 100 TB: 6.872,70 Euro

Die Rechnung ist ein repräsentatives Listenpreis-Modell für den betrachteten Datenpfad, kein vollständiger AWS-Rechnungsrechner. Service, Region und Transferpfad können abweichen.

4.2 Microsoft Azure

[OBSERVED] Azure veröffentlicht für Internet Egress über das Microsoft Premium Global Network aus Europa und Nordamerika:

• erste 100 GB pro Monat kostenlos,
• nächste 10 TB: 0,087 US-Dollar pro GB,
• nächste 40 TB: 0,083 US-Dollar pro GB,
• nächste 100 TB: 0,07 US-Dollar pro GB,
• nächste 350 TB: 0,05 US-Dollar pro GB.

[CALCULATED] Daraus folgen:

• 1 TB: 68,88 Euro
• 10 TB: 757,72 Euro
• 100 TB: 6.759,04 Euro

4.3 Google Cloud

[OBSERVED] Google Cloud Storage berechnet General Network Usage zu weltweiten Zielen außerhalb Asiens und Australiens mit:

• 0 bis 10 TiB: 0,12 US-Dollar pro GiB,
• 10 bis 150 TiB: 0,11 US-Dollar pro GiB,
• darüber: 0,08 US-Dollar pro GiB.

[CALCULATED] Nach Umrechnung der dezimalen Nutzungsvolumina in GiB:

• 1 TB: 98,32 Euro
• 10 TB: 983,19 Euro
• 100 TB: 9.102,62 Euro

[CRITICAL] Zielregionen wie Australien oder China besitzen andere Preise. Der Vergleich darf nicht auf diese Pfade übertragen werden.

---

---

5. Was die Zahlen bedeuten – und was nicht

5.1 Wiederkehrung macht die Position strategisch

[CALCULATED] Bei jeden Monat konstanten 10 TB entstehen in zwölf Monaten:

Anbieter	Jahreswert nur Routine-Egress
AWS	9.406,18 €
Microsoft Azure	9.092,64 €
Google Cloud	11.798,23 €

Der Unterschied zwischen Azure und Google Cloud beträgt in diesem eng definierten Modell rund 2.705,59 Euro pro Jahr. Daraus folgt nicht, dass Azure insgesamt günstiger ist. Ein niedrigerer Netzwerkpreis kann durch höhere Kosten an anderer Stelle überkompensiert werden.

5.2 Mengenrabatte lösen die absolute Kostenposition nicht auf

Bei 100 TB sinkt der effektive Eurobetrag pro TB durch Staffeln. Die Gesamtrechnung bleibt dennoch im vierstelligen Monatsbereich. Besonders bei Medien, Telemetrie, Backups, AI-Datensätzen und Cross-Cloud-Architekturen kann Egress daher eine Architekturvariable statt einer Nebenkostenposition werden.

5.3 Ein öffentlicher Preis ist nicht der reale Vertrag

Enterprise-Verträge können enthalten:

• rabattierte Datenübertragung,
• private Commitments,
• Credits,
• Spend-basierte Nachlässe,
• CDN-Bündel,
• individuelle Regionenpreise,
• Mindestabnahmen oder Kündigungsfolgen.

Der Listenpreis ist deshalb eine reproduzierbare Baseline, nicht zwangsläufig der Rechnungsbetrag.

---

---

6. Anbieter mit null, bedingt null oder gebündeltem Egress

Anbieter	öffentliche Routine-Regel	wichtige Gegenposition
Cloudflare R2	Egress für Standard und Infrequent Access mit 0 ausgewiesen	Storage und Operationen; IA-Retrieval 0,01 USD/GB; 30 Tage Mindestdauer
OVHcloud Object Storage	keine Ingress-/Egress- oder API-Gebühren auf der betrachteten Seite	Retrieval beziehungsweise Restored Data je Storage-Klasse möglich
Backblaze B2	bis zum Dreifachen des durchschnittlichen Monats-Storage kostenlos	darüber 0,01 USD/GB; Freimenge hängt vom Byte-Hour-Storage ab
Wasabi Pay as You Go	kein Egresspreis, solange monatlicher Egress höchstens dem Active Storage entspricht	1-TB-Mindestcommitment und 90 Tage Mindesthaltedauer
Hetzner Object Storage	1 TB Egress und 1 TB Storage im Basistarif enthalten	Überschreitung Pay as you go; aktuellen dynamischen Overage-Wert vor Live-Schaltung prüfen

Vollständige Policy-Matrix:

data/FDR-2026-05_exit_policy_matrix.csv

6.1 Warum null nicht gleich kostenlos ist

Beispiel Cloudflare R2:

Egress = 0
Gesamtkosten = Storage + Class-A-Operationen + Class-B-Operationen + ggf. Retrieval

Beispiel Wasabi:

kostenfreier Egress gilt nur innerhalb der veröffentlichten Storage-Egress-Relation
+ Mindestcommitment
+ Mindesthaltedauer

Beispiel Backblaze:

kostenfreier Egress = bis 3 × durchschnittlicher Monats-Storage
Overage = 0,01 USD/GB

[INTERPRETATION] Ein fairer Vergleich braucht mindestens zwei Achsen:

1. Kosten pro gespeichertem TB-Monat
2. Kosten pro übertragenem TB bei realem Read-/Exit-Verhältnis

Ein reiner Egress-Nullwert bevorzugt Anbieter mit höherem Storage- oder Retrievalpreis; ein reiner Storage-Vergleich bevorzugt Anbieter mit teurem Zugriff.

---

---

7. Hyperscaler-Exit-Programme

7.1 AWS

[OBSERVED] AWS dokumentiert, dass Kunden bei einem Wechsel zu einem anderen Anbieter oder On-Premises Support kontaktieren können, um Credits für Data Transfer Out zu erhalten. Die Prüfung erfolgt auf Account-Ebene. Laut Aktualisierung haben berechtigte Kunden grundsätzlich 90 Tage für den Wechsel und sollen Support informieren, falls mehr Zeit benötigt wird.

7.2 Microsoft Azure

[OBSERVED] Azure beschreibt kostenfreien Egress für Kunden, die ihre Daten vollständig aus Azure herausnehmen, um zu einem anderen Cloud-Anbieter oder in ein eigenes Rechenzentrum zu wechseln. Für Volumen oberhalb der normalen 100-GB-Freimenge ist ein Credit-Prozess vorgesehen.

7.3 Google Cloud

[OBSERVED] Das Google Cloud Exit Program erfasst Kunden, die alle Workloads und Daten migrieren und anschließend ihr Google-Cloud-Vertragsverhältnis beenden. Der Prozess umfasst eine Exit Notice, einen definierten Startprozess und eine Completion Notice; nicht jeder Service und nicht jeder normale Transfer fällt automatisch darunter.

7.4 Konsequenz für Kostenmodelle

Ein belastbares Modell enthält zwei Zeilen:

Routine-Egress nach normalem Betriebspreis
Planned-Exit-Egress nach beantragter/vertraglich bestätigter Behandlung

Erst nach schriftlicher Bestätigung darf der Exit-Egress im Projektbudget mit null angesetzt werden. Ein öffentliches Programm ersetzt keine Account-Prüfung.

---

---

8. EU Data Act: Was sich am 12. Januar 2027 ändert

[OBSERVED] Der Data Act gilt seit 12. September 2025. Die Kommission beschreibt für Cloud Switching:

• Vertrags- und Transparenzanforderungen,
• technische Unterstützung und Beseitigung von Hindernissen,
• offene Schnittstellen beziehungsweise exportierbare Formate für bestimmte Services,
• funktionale Äquivalenz als Ziel bei bestimmten IaaS-Wechseln,
• vollständige Entfernung von Switching Charges einschließlich Data Egress ab 12. Januar 2027.

Keine pauschale Null-Egress-Verordnung

Der zentrale Satz lautet nicht:

Jeder Datentransfer aus der Cloud ist kostenlos.

Sondern sinngemäß:

Gebühren für die zum erfassten Wechsel notwendigen Vorgänge und Data Egress sollen entfallen.

Daraus folgen Prüfungsfragen:

• Ist der Kunde und Vertrag im räumlichen/persönlichen Scope?
• Handelt es sich um einen Wechsel oder normalen Dauerbetrieb?
• Welche Services und Daten sind erfasst?
• Welche Exit-/Notice-Prozesse gelten?
• Welche Leistungen sind zwingend notwendig?
• Welche Drittanbieter- und Marketplace-Kosten bleiben bestehen?
• Welche Restlaufzeiten oder Commitments sind keine Switching Charge?

[RECOMMENDATION] Ab 2027 sollte Procurement nicht einfach die Egress-Zeile streichen, sondern im Vertrag eine separate Switching-Cost-Schedule mit nullfähigen, verbleibenden und ungeklärten Positionen verlangen.

---

---

9. Die tatsächliche Gleichung des Cloud-Exit

Total Exit Cost
= Netzwerk- und Switching-Gebühren
+ Retrieval und API-Operationen
+ Transferwerkzeuge und temporäre Infrastruktur
+ Doppelbetrieb
+ Datenmodell- und Formattransformation
+ Re-Platforming von Managed Services
+ IAM-, Secret- und Key-Migration
+ Netzwerk-, DNS- und Zertifikatswechsel
+ Tests, Reconciliation und Audit-Evidence
+ Downtime und Performance-Risiko
+ Restlaufzeiten und Commitments
+ interne und externe Engineering-Zeit

9.1 Semantischer Exit

Daten als Bytes exportieren zu können, bedeutet nicht, ein System portiert zu haben. Beispiele:

• proprietäre Warehouse-Funktionen,
• Cloud-spezifische IAM-Rollen,
• Event-Bus-Semantik,
• Managed-Kubernetes-Erweiterungen,
• Serverless Trigger,
• Monitoring- und Alerting-Historie,
• Schlüsselmaterial und HSM-Integration,
• Datenbankextensions,
• ML-Feature-Stores und Vektorindizes.

9.2 Zeit ist ein Kostenfaktor

Bei großen Datenmengen können Bandbreite, API-Limits und Exportfenster die Migration verlängern. Längerer Doppelbetrieb erzeugt Compute-, Storage-, Lizenz- und Personalkosten – selbst wenn die reine Egress-Gebühr null ist.

9.3 Die billigste Übertragung kann der teuerste Umbau sein

Ein standardisiertes S3-kompatibles Archiv kann trotz Egress-Gebühr einfach migrierbar sein. Ein egress-freier proprietärer Managed Service kann hohe Re-Platforming-Kosten erzeugen. Exit-Risiko muss daher getrennt nach Bytes, Semantik und Betrieb bewertet werden.

---

---

10. Exit-Budget für Entscheider

10.1 Pflichtfelder pro Service

Feld	Frage
Datenvolumen	Wie viele TB müssen vollständig, inkrementell und wiederholt übertragen werden?
Routine oder Exit	Ist der Transfer normaler Betrieb oder qualifizierter Anbieterwechsel?
Storage-Klasse	Fallen Retrieval oder Mindesthaltedauern an?
Format	Ist das Exportformat offen, vollständig und dokumentiert?
Bandbreite	Welche realistische Netto-Transferrate steht zur Verfügung?
Konsistenz	Wie werden Änderungen während der Migration synchronisiert?
Abhängigkeiten	Welche IAM-, Netzwerk-, Event-, Key- und Managed-Service-Abhängigkeiten bestehen?
Doppelbetrieb	Wie lange müssen Quelle und Ziel parallel laufen?
Vertrag	Welche Notice-, Credit-, Commitment- und Löschbedingungen gelten?
Evidence	Wie werden Vollständigkeit, Integrität und Löschung nachgewiesen?

10.2 Drei Budgettöpfe

A. Routine Data Movement
B. Planned Switching Project
C. Emergency Exit / Provider Failure

Der Notfall-Exit braucht eine eigene Annahme. Ein Credit-Prozess, der Supportkontakt und Vorlauf erfordert, ist kein Ersatz für ein Szenario, in dem der Anbieter oder Account kurzfristig nicht verfügbar ist.

10.3 Kontrollkennzahlen

Routine Egress Rate
= monatlicher externer Transfer / durchschnittlich gespeicherte Daten

Exit Throughput
= erfolgreich validierte Datenmenge / Migrationstag

Semantic Portability Coverage
= portierbare kritische Funktionen / kritische Funktionen gesamt

Exit Cost at Risk
= ungeklärte Gebühren + Restlaufzeiten + geschätzter Re-Platforming-Aufwand

---

---

11. Architekturmaßnahmen, die Kosten und Risiko gleichzeitig senken

Daten

• offene Formate und dokumentierte Schemas,
• regelmäßige externe Snapshots,
• Checksums und Reconciliation,
• getrennte Hot-, Warm- und Archive-Strategie,
• unabhängige Schlüssel- und Secret-Verwaltung, soweit sinnvoll.

Anwendung

• Cloud-spezifische Adapter an klaren Grenzen,
• Infrastructure as Code,
• reproduzierbare Builds,
• keine Geschäftslogik ausschließlich in proprietären Low-Code-Flows,
• Export-/Importpfade als Produktfunktion.

Betrieb

• Restore- und Exit-Drills,
• gemessene Netto-Bandbreite,
• dokumentierte API-Limits,
• Runbooks und Verantwortlichkeiten,
• Monitoring außerhalb des primären Providers,
• getestet funktionierende DNS- und Zertifikatsumschaltung.

Vertrag

• Exit-Notice- und Credit-Prozess,
• Service-Liste und Gebührenmatrix,
• Retrieval und API-Kosten,
• Lösch- und Übergangsfrist,
• Unterstützung und Datenformate,
• Behandlung von Subprozessoren und Marketplace-Produkten,
• Pflichten nach Data Act ab 2027.

---

5. Teil III - Shutdown Notice und Recovery-Evidenz

2. Ereignistypen

Geplanter Sunset

Der Anbieter kündigt ein Enddatum mit Vorlauf an und beschreibt Export oder Ersatz.

Produktkonsolidierung

Funktionalität wird in ein anderes Produkt, einen Partner oder eine Plattform verlagert.

Support End-of-Life

Entwicklung oder Support endet, während lokale Artefakte teilweise weiterverwendet werden können.

Read-only Tail

Produktive Nutzung endet, Daten bleiben für einen definierten Zeitraum lesbar oder exportierbar.

Incident-driven Shutdown

Ein Dienst wird aus Sicherheits-, Missbrauchs- oder Betriebsgründen zunächst offline genommen; die formale Einstellung folgt später.

[INTERPRETATION] Diese Typen dürfen nicht in einer einzigen Notice-Kennzahl vermischt werden. Ein negativer Wert bei Firefox Send zeigt ein anderes Risikomuster als 731 Tage Vorlauf bei Adobe Muse.

---

---

3. Methodik

3.1 Stichprobe

Die Fälle wurden ausgewählt, weil offizielle Ankündigungen oder Supportunterlagen öffentlich verfügbar waren und unterschiedliche Shutdown-Typen abbilden.

Die Stichprobe ist:

• nicht zufällig,
• nicht repräsentativ,
• über verschiedene Kategorien verteilt,
• auf öffentlich rekonstruierbare Ereignisse begrenzt.

3.2 Kennzahlen

Notice Days
= primäres Service-Enddatum
- öffentliches Ankündigungsdatum

Post-End Export Days
= Read-only-/Export-Enddatum
- primäres Service-Enddatum

Wenn kein belastbares Ankündigungsdatum aus der geprüften Primärquelle hervorging, wird kein Notice-Wert geschätzt.

3.3 Qualitative Felder

Je Ereignis wurden erfasst:

• Exportpfad,
• Migrationspfad,
• benannter Ersatz,
• Refund/Credit,
• Datenlöschungs- oder Retention-Hinweis.

Werte:

1,0 = klar dokumentiert
0,5 = teilweise, eingeschränkt oder vertragsspezifisch
0,0 = nicht hinreichend in der geprüften Primärquelle dokumentiert

---

---

4. Ereignismatrix

Ereignis	Anbieter	Ankündigung	Service-Ende	Notice-Tage	Post-End-Fenster
Universal Analytics Standard	Google	16.03.2022	01.07.2023	472	366
Stadia	Google	29.09.2022	18.01.2023	111	0
Google Optimize / Optimize 360	Google	20.01.2023	30.09.2023	253	0
Jamboard app and devices	Google	28.09.2023	01.10.2024	369	91
Hipchat Cloud and Stride	Atlassian	26.07.2018	15.02.2019	204	28
Adobe Muse development/support	Adobe	26.03.2018	26.03.2020	731	365
Workplace from Meta	Meta	14.05.2024	31.08.2025	474	273
Firefox Send	Mozilla	17.09.2020	07.07.2020	-72	0
Firefox Notes sync service	Mozilla	17.09.2020	01.11.2020	45	0
Firebase Dynamic Links	Google	nicht belastbar dokumentiert	25.08.2025	n. v.	0

Statistische Einordnung

• [CALCULATED] Positive, exakt datierte geplante Notices: n = 8
• [CALCULATED] Median: 311 Tage
• [CALCULATED] Minimum: 45 Tage
• [CALCULATED] Maximum: 731 Tage
• [CALCULATED] Exakt datierte Ereignisse inklusive Firefox Send: n = 9
• [CALCULATED] Median inklusive negativer incident-getriebener Timeline: 253 Tage
• [CALCULATED] Fälle mit positivem Post-End-Fenster: 5 von 10
• [CALCULATED] Median Post-End über alle Fälle inklusive Null: 14 Tage

[CRITICAL] Diese Kennzahlen dürfen nicht auf den gesamten SaaS-Markt hochgerechnet werden.

---

---

5. Fallstudien

Universal Analytics Standard

[OBSERVED] Google kündigte am 16. März 2022 an, dass Standard-Universal-Analytics-Properties ab 1. Juli 2023 keine neuen Daten mehr verarbeiten. Der rekonstruierte Vorlauf beträgt 472 Tage. Der Zugriff beziehungsweise Export historischer Daten blieb bis 1. Juli 2024 vorgesehen.

[INTERPRETATION] Das ist ein Beispiel für einen langen Übergang mit benanntem Nachfolger. Trotzdem war die Migration kein reiner Export: Eventmodell, Attribution, Reporting und Implementierung änderten sich.

Stadia

[OBSERVED] Die Einstellung wurde am 29. September 2022 für den 18. Januar 2023 angekündigt, entsprechend 111 Tagen. Google kündigte Rückerstattungen für relevante Käufe an.

[INTERPRETATION] Refund reduziert finanziellen Verlust, portiert aber keine Nutzerbibliothek oder den Dienstzustand in eine alternative Plattform.

Google Optimize / Optimize 360

[OBSERVED] Der Service endete am 30. September 2023. Die historische Ankündigung wird in der Matrix auf 20. Januar 2023 datiert; dieser Wert muss vor Veröffentlichung anhand eines archivierten Primärbelegs nochmals bestätigt werden.

[CRITICAL] Wenn das ursprüngliche Ankündigungsdatum nicht in der aktuellen Supportseite erhalten ist, muss die Live-Version entweder einen Web-Archive-Beleg angeben oder den Notice-Wert als nicht verifizierbar entfernen.

Jamboard

[OBSERVED] Google kündigte die nächste Phase am 28. September 2023 an. Der App-Betrieb ging am 1. Oktober 2024 in eine Endphase über; ein zusätzliches Read-only-/Exportfenster lief bis 31. Dezember 2024.

[RECOMMENDATION] Whiteboard-Inhalte sollten nicht nur als statische Bilder, sondern mit Ownership, Kontext und Zielzuordnung migriert werden.

Hipchat Cloud und Stride

[OBSERVED] Atlassian kündigte die Partnerschaft mit Slack am 26. Juli 2018 an; die Services endeten am 15. Februar 2019. Export blieb in der Matrix bis 15. März 2019 möglich.

[INTERPRETATION] Ein benannter Partnerpfad kann Migration erleichtern, erzeugt aber eine neue Anbieterabhängigkeit.

Adobe Muse

[OBSERVED] Adobe stellte die Entwicklung am 26. März 2018 ein und unterstützte das Produkt bis 26. März 2020. Für bestimmte gehostete Business-Catalyst-Sites reichte der betrachtete Übergang bis 26. März 2021.

[INTERPRETATION] Lokale Designartefakte und gehostete Runtime besitzen unterschiedliche End-of-Life-Uhren.

Workplace from Meta

[OBSERVED] Meta ergänzte seine Workplace-Kommunikation am 14. Mai 2024. Reguläre Nutzung lief in der Matrix bis 31. August 2025; eine Read-/Download-Phase bis 328. Juli 2026.

[RECOMMENDATION] Bei Collaboration-Systemen müssen Messages, Files, Gruppen, Integrationen, Identität, Compliance-Archive und Kommunikationskultur getrennt migriert werden.

Firefox Send

[OBSERVED] Mozilla nahm Firefox Send bereits im Juli 2020 offline und bestätigte am 17. September 2020 die dauerhafte Einstellung.

[INTERPRETATION] Dies ist das wichtigste Gegenbeispiel zur Annahme eines garantierten Vorlaufs. Sicherheits- oder Missbrauchsereignisse können den normalen Sunset-Prozess überspringen.

Firefox Notes

[OBSERVED] Mozilla kündigte das Ende des Sync-Service am 17. September 2020 für Anfang November an. Der modellierte Vorlauf beträgt 45 Tage.

[LIMITATION] Ein einfacher Notizdienst besitzt eine andere Migrationskomplexität als CRM, Analytics oder Messaging. Die Notice-Zahl allein sagt nichts über Angemessenheit.

Firebase Dynamic Links

[OBSERVED] Google dokumentiert das Ende des Dienstes am 25. August 2025 sowie Export- und Migrationshinweise.

[LIMITATION] Das erste belastbare Ankündigungsdatum war in der geprüften aktuellen Primärseite nicht ausreichend erhalten. Der Report berechnet deshalb keinen Notice-Wert, statt ein Datum aus Sekundärquellen zu schätzen.

---

---

6. Was eine lange Notice nicht löst

Discovery

Ankündigungen können in:

• Blogposts,
• Admin-Bannern,
• Supportartikeln,
• Account-E-Mails,
• Changelogs,
• Vertragsmitteilungen

erscheinen. Ohne Owner und Monitoring kann der interne Start Monate später erfolgen.

Inventory

Teams wissen häufig nicht:

• welche Prozesse betroffen sind,
• welche Datenvolumina existieren,
• welche Integrationen laufen,
• welche Benutzer oder Kunden abhängig sind,
• welche Exporte plan- oder genehmigungsabhängig sind.

Replacement Fit

Ein benannter Nachfolger kann:

• anderes Datenmodell,
• andere Preise,
• andere APIs,
• andere Compliance,
• geringere Funktionalität

haben.

Parallelbetrieb

Migration benötigt oft:

• Dual Write,
• Delta Sync,
• Read-only Freeze,
• Identitätsmapping,
• Kundenkommunikation,
• Rollback.

---

---

7. Shutdown Readiness Record

service: "..."
business_criticality: "high"
owner: "..."
vendor_status_sources:
  - "official-blog"
  - "admin-notices"
  - "legal-updates"
last_full_export: "YYYY-MM-DD"
export_frequency_days: 30
restore_last_tested: "YYYY-MM-DD"
portable_state:
  data: true
  files: true
  logic: partial
  permissions: partial
  audit: false
replacement_candidates:
  - "..."
maximum_tolerable_notice_days: 30
degraded_mode: "..."
customer_communication_template: "..."

[RECOMMENDATION] Der Record sollte Bestandteil des Servicekatalogs und nicht nur des Procurement-Ordners sein.

---

---

8. Recovery-Strategien nach Zustand

Daten

• regelmäßige Exporte,
• offene Formate,
• Hashes und Manifest,
• unabhängige Backups,
• dokumentierte Retention.

Logik

• Workflows als Code oder maschinenlesbares Format,
• Business Rules außerhalb proprietärer UI dokumentieren,
• Tests und Beispieldaten.

Identität

• eigene Domain,
• unabhängiger Identity Provider,
• Gruppen- und Rollenexport,
• Break-Glass-Zugriff.

Integrationen

• API Inventory,
• Webhooks,
• Credentials im eigenen Secret Store,
• Adaptergrenzen,
• Fallback.

Kommunikation

• Stakeholder,
• Kunden,
• regulatorische Stellen,
• Supportskripte,
• Statuspage.

---

---

9. Trigger für einen vorgezogenen Exit Drill

• Übernahme oder strategische Partnerschaft,
• Lizenz- oder Preisänderung,
• sinkende Releasefrequenz,
• abnehmender Support,
• neue Exportrestriktionen,
• Produktkonsolidierung,
• Abkündigung angrenzender Features,
• hoher Personalabgang beim Anbieter,
• regulatorische Änderung,
• wiederholte Incidents.

[CRITICAL] Diese Signale beweisen keine bevorstehende Abschaltung. Sie rechtfertigen eine Aktualisierung des Exit-Plans.

---

---

10. Verbindung zum EU Data Act

Der EU Data Act stärkt Portabilität und Switching bei erfassten Data Processing Services. Er eliminiert jedoch nicht alle Shutdown-Risiken:

• nicht jedes Produkt fällt gleich in den Scope,
• Anwendungslogik bleibt möglicherweise proprietär,
• Incident-getriebene Abschaltungen können schnell erfolgen,
• Zielsystem und interne Migration bleiben Kundenaufgaben,
• Exportrechte ersetzen keinen getesteten Restore.

[INTERPRETATION] Regulierung kann den Wechselkanal verbessern. Business Continuity muss trotzdem architektonisch vorbereitet sein.

---

6. Synthese: Was das Recht löst – und was Architektur lösen muss

6.1 Vom Anspruch zur Betriebsfähigkeit

Ein gesetzlicher Anspruch reduziert asymmetrische Vertragsmacht. Er ersetzt jedoch keine Ausführungskompetenz. Der Kunde muss weiterhin wissen:

• welcher Zustand existiert;
• welcher davon geschäftskritisch ist;
• in welchem Format er exportiert werden kann;
• welche Konsistenzgrenzen gelten;
• welche Zielplattform den Zustand akzeptiert;
• wie lange Parallelbetrieb notwendig ist;
• welcher Cutover- und Rollback-Punkt zulässig ist;
• wie Löschung und Vertragsende nachgewiesen werden.

Die entscheidende Metrik ist daher nicht „Kann ich kündigen?“, sondern:

Time to verified independent operation

Sie misst die Zeit vom aktivierten Exit-Plan bis zu einem nachweislich funktionsfähigen Zielsystem, das ohne produktive Abhängigkeit vom bisherigen Anbieter läuft.

6.2 Routine-Egress, Vollausstieg und Data-Act-Switching

Diese drei Fälle dürfen weder redaktionell noch im Rechner vermischt werden.

Fall	typische Situation	Preislogik	notwendige Prüfung
Routine-Egress	laufende Auslieferung an Nutzer oder Systeme	normale öffentliche Rate/Freimenge	Region, Destination, Tier, Einheit
Vollausstiegsprogramm	Kunde verlagert alle Daten/Workloads und schließt Account oder Vertrag	Gutschrift, Waiver oder Antrag	Eligibility, Frist, Scope, Account Closure
Data-Act-Switching	gesetzlich erfasster Wechsel eines Datenverarbeitungsdienstes	Übergangs- und spätere Gebührenregeln	Anwendungsbereich, Vertrag, notwendige Leistungen

Eine Headline wie „Ab 2027 ist Cloud-Egress kostenlos“ wäre falsch. Präzise ist: Für erfasste Switching Charges einschließlich entsprechender Data-Egress-Gebühren sieht der Data Act ab 12. Januar 2027 die vollständige Abschaffung vor. Laufender Datentransfer außerhalb eines Wechselprozesses kann weiter bepreist sein.

6.3 Exit Readiness als kontrolliertes System

Ein belastbares Programm benötigt mindestens folgende Artefakte:

1. Service- und Dateninventar;
2. Abhängigkeitsgraph;
3. Data Classification und Retention Map;
4. Export- und Importverfahren;
5. Checksums und Reconciliation-Regeln;
6. Zielarchitektur und Kapazitätsannahmen;
7. IAM- und Secret-Rotationsplan;
8. Netzwerk- und DNS-Cutover;
9. Observability- und Incident-Plan;
10. Vertrags-, Gebühren- und Supportkalender;
11. RACI und Eskalationskontakte;
12. letzter Drill mit Findings und Remediation.

6.4 Warum Multi-Cloud nicht automatisch Exit Readiness ist

Multi-Cloud kann Abhängigkeiten reduzieren oder verdoppeln. Zwei Provider bedeuten nicht automatisch Portabilität, wenn:

• jede Anwendung unterschiedliche proprietäre Services nutzt;
• Datenmodelle auseinanderlaufen;
• Identitäten getrennt gepflegt werden;
• nur eine Seite produktiv getestet wird;
• Kosten und Betriebswissen fragmentieren;
• failover lediglich auf Folien existiert.

Echte Portabilität zeigt sich in reproduzierbaren Artefakten und getesteten Übergängen, nicht in der Zahl der Cloudverträge.

---

7. 180-Tage-Exit-Programm

Tage 0–30: Scope und Beweisführung

• Sponsor und Exit Owner benennen;
• kritische Services nach Umsatz-, Regulierungs- und Betriebswirkung priorisieren;
• Daten, Schemas, Identitäten, Secrets und Netzwerkpfade inventarisieren;
• Verträge, Renewal Dates und Exit-Programme erfassen;
• erste Exportartefakte ziehen und hash-basiert dokumentieren;
• Ziel-RTO, RPO und maximalen Parallelbetrieb festlegen.

Gate 1: Für jeden Tier-1-Service existieren Owner, Datenklasse, Exportweg und Zielhypothese.

Tage 31–60: Export und Rehydration

• vollständige Exporte in isolierter Umgebung erzeugen;
• Metadaten, Attachments, Auditdaten und Relationen prüfen;
• Zielsystem aufbauen;
• Mapping- und Transformationsregeln versionieren;
• Restore beziehungsweise Import ausführen;
• Mengen, Checksums und fachliche Stichproben vergleichen.

Gate 2: Mindestens ein repräsentativer Zustand wurde außerhalb des Quellsystems wiederhergestellt.

Tage 61–90: Funktions- und Sicherheitsparität

• IAM, Rollen und Least Privilege implementieren;
• Secrets rotieren;
• Integrationen und Eventpfade testen;
• Monitoring, Alerting, Backup und Incident Runbooks aktivieren;
• Performance-, Last- und Failure-Tests durchführen;
• offene Paritätslücken priorisieren.

Gate 3: Zielsystem erfüllt definierte Minimal-SLOs und Security Controls.

Tage 91–120: Parallelbetrieb

• Change Data Capture oder kontrollierte Synchronisation aktivieren;
• fachliche Reconciliation automatisieren;
• Nutzergruppen oder Traffic schrittweise verlagern;
• Kosten beider Umgebungen täglich beobachten;
• Rollback-Bedingungen und Entscheidungsrechte testen.

Gate 4: Abweichungen sind messbar, erklärbar und innerhalb des Fehlerbudgets.

Tage 121–150: Cutover

• Change Freeze oder definierte Write-Ownership setzen;
• finalen Delta-Transfer durchführen;
• DNS, Routing, Queues und Integrationen umstellen;
• Business Acceptance einholen;
• alten Service read-only setzen, sofern möglich;
• Hypercare und Executive Reporting aktivieren.

Gate 5: Produktiver Betrieb ist unabhängig; Rollback bleibt zeitlich begrenzt verfügbar.

Tage 151–180: Closure

• letzte Daten- und Finanzreconciliation;
• Exportartefakte und Evidence Vault sichern;
• Konten, Schlüssel, Peering und Supportverträge abbauen;
• Lösch- und Beendigungsnachweise einholen;
• Lessons Learned, Ist-Kosten und Restabhängigkeiten dokumentieren;
• nächsten Exit Drill terminieren.

Gate 6: Keine unbeabsichtigte produktive Abhängigkeit und keine ungeklärte Restdatenklasse verbleiben.

---

8. Exit Readiness Scorecard für Kunden

Dimension	Gewicht	0 Punkte	volle Punktzahl
Inventar und Ownership	10	unbekannte Services/Owner	vollständiges, aktuelles Inventar
Datenexport	15	kein getesteter Voll-Export	automatisiert, vollständig, verifiziert
Rehydration	15	Export nie importiert	wiederholbarer Restore im Ziel
Logik und Konfiguration	10	nur GUI/implizit	versioniert und portabel dokumentiert
IAM und Secrets	10	providergebunden, ungeklärt	Zielrollen und Rotation getestet
Netzwerk und Integrationen	10	keine Dependency Map	reproduzierbare Pfade und Cutover
Observability und Betrieb	10	Monitoring endet am Provider	SLOs, Alerts, Backups und Runbooks im Ziel
Vertrag und Gebühren	10	Renewal/Exit unbekannt	Fristen, Waiver, Support und Budget bestätigt
Drill und Evidence	10	kein Test	aktueller Drill mit Findings-Closure

Die Scorecard ist eine interne Steuerungshilfe, kein Rechts- oder Zertifizierungsstandard. Eine hohe Punktzahl hat nur Wert, wenn Belege hinterlegt sind.

---

9. Beschaffungsanforderungen für Neuverträge

Mindestens schriftlich klären:

1. vollständige Liste exportierbarer Daten- und Metadatenklassen;
2. Formate, APIs, Rate Limits und maximale Exportdauer;
3. Behandlung von Logs, Auditdaten, Attachments und Backups;
4. Portabilität von Policies, Functions, Workflows und Konfiguration;
5. Supportpflichten während Übergangs- und Parallelbetrieb;
6. Routine-Egress, Exit-Waiver und sonstige Switching Charges;
7. Data-Retrieval- und Mindestaufbewahrungskosten;
8. Zugriff nach Kündigung und Read-only-Frist;
9. Löschzeitpunkt, Backup-Retention und Nachweis;
10. technische Ansprechpartner und Eskalation;
11. Möglichkeit eines jährlichen Exit Drills;
12. Mitwirkung bei Sicherheits- und Reconciliation-Tests.

Ein allgemeiner Satz wie „Daten können jederzeit exportiert werden“ ist nicht ausreichend. Vertrag und technische Anlage sollten Objektklassen, Formate, Fristen und Verantwortungen benennen.

---

10. Visualisierungsspezifikation

Chart 1 - Provider Documentation Readiness

• Datei: data/FDR-2026-05_cloud_switching_readiness.csv
• Darstellung: horizontale Balken, 0–100;
• Untertitel: „Öffentliche Dokumentationsreife, keine Konformitätsbewertung“;
• Tooltip: acht Subscores.

Chart 2 - Routine-Egress bei 1, 10 und 100 TB

• Datei: data/FDR-2026-05_egress_costs.csv;
• separate Panels je Volumen oder logarithmische Skala;
• Null-/gebündelte Angebote mit Fußnote zu Retrieval, Operations und Mindestbedingungen;
• keine Vermischung von USD und EUR.

Chart 3 - Exit Policy Taxonomy

• Datei: data/FDR-2026-05_exit_policy_matrix.csv;
• Kategorien: metered, waiver, conditional zero, bundled;
• Anbieterlogos optional, aber textliche Bedingungen müssen zugänglich bleiben.

Chart 4 - Shutdown Notice und Recovery Window

• Datei: data/FDR-2026-05_shutdown_events.csv;
• Timeline von Ankündigung bis Service-Ende und optionaler Read-only-/Exportphase;
• Ereignistyp farblich oder per Symbol unterscheiden;
• geplante Sunsets nicht mit Sicherheitsabschaltungen aggregieren.

Chart 5 - Sieben Exit-Schichten

• Architekturdiagramm;
• je Schicht Artefakt, Owner und Testnachweis;
• keine dekorative Cloudgrafik ohne Informationsgehalt.

---

11. Reproduzierbarkeit

Dateien

• data/FDR-2026-05_cloud_switching_readiness.csv
• data/FDR-2026-05_egress_costs.csv
• data/FDR-2026-05_exit_policy_matrix.csv
• data/FDR-2026-05_shutdown_events.csv

Rechenregeln

1. Dezimale TB und providerseitige GB/GiB/TiB-Grenzen nicht stillschweigend vermischen.
2. Währung und Referenzkurs mit Datum ausweisen.
3. Freimengen vor Staffeln anwenden.
4. Requests, Retrieval, Storage, Support, Taxes und Engineering separat halten.
5. Routine-Egress nicht durch ein Vollausstiegsprogramm ersetzen.
6. Documentation Scores nur neu berechnen, wenn Quellen und Rubrik archiviert sind.
7. Shutdown-Notice als Kalendertage zwischen dokumentiertem Announcement und Enddatum berechnen.
8. unbekannte Werte als not documented, nicht als Null behandeln.

---

12. Grenzen

1. Öffentliche Dokumentation kann hinter internen Anbieterprozessen zurückbleiben.
2. Enterprise-Verträge können bessere oder schlechtere Bedingungen enthalten.
3. Der Documentation Score misst Auffindbarkeit und Vollständigkeit, nicht Rechtskonformität.
4. Egresspreise sind region-, service-, destination- und volumenabhängig.
5. Wechselprogramme können Eligibility- und Closure-Bedingungen enthalten.
6. Die betrachteten Shutdown-Fälle sind eine kuratierte Stichprobe, keine Grundgesamtheit.
7. Ein erfolgreicher Export beweist keine funktionale Wiederherstellung.
8. Der Report bewertet keine Cloud-Security, Performance oder Gesamtproduktqualität.
9. Rechtliche Einordnung kann sich durch Guidance, Rechtsprechung und Vertragsgestaltung konkretisieren.
10. Alle volatilen Preise und Programme müssen vor Live-Publikation erneut geprüft werden.

---

13. Zulässige und unzulässige Aussagen

Zulässig:

„FW Delta bewertet die öffentlich dokumentierte Switching Readiness von fünf Anbietern; der Score ist keine Konformitätsprüfung.“

Unzulässig:

„Google Cloud ist zu 95 Prozent Data-Act-konform.“

Zulässig:

„Der Data Act sieht ab 12. Januar 2027 die Abschaffung erfasster Switching Charges einschließlich entsprechender Data-Egress-Gebühren vor.“

Unzulässig:

„Ab 2027 ist jeder Cloud-Datentransfer kostenlos.“

Zulässig:

„Routine-Egress und vollständiger Exit folgen unterschiedlichen Preis- und Prozessregeln.“

Unzulässig:

„Ein Zero-Egress-Anbieter verursacht keine Exit-Kosten.“

---

14. Versionshistorie

• 1.0 · Juli 2026 · Data-Act-Dokumentationsscore, Egresskosten, Exit-Programme, Shutdown-Fälle und 180-Tage-Betriebsmodell konsolidiert.
• Live-Version offen · Recht, Preise, Programme und Anbieterunterlagen vor Veröffentlichung erneut prüfen.

15. Quellen

1. Verordnung (EU) 2023/2854, Data Act, https://eur-lex.europa.eu/eli/reg/2023/2854/oj/eng.
2. Europäische Kommission, „Data Act explained“, https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained, abgerufen im Juli 2026.
3. Europäische Kommission, „Frequently Asked Questions – Data Act“, https://digital-strategy.ec.europa.eu/en/faqs/data-act-questions-and-answers, abgerufen im Juli 2026.
4. Google Cloud, „EU Data Act – Google Cloud Mapping“, https://cloud.google.com/security/compliance/eudataact, abgerufen im Juli 2026.
5. Google Cloud, „Data Portability“, https://cloud.google.com/terms/data-portability, abgerufen im Juli 2026.
6. Google Cloud Blog, „Eliminating data transfer fees when migrating off Google Cloud“, https://cloud.google.com/blog/products/networking/eliminating-data-transfer-fees-when-migrating-off-google-cloud, abgerufen im Juli 2026.
7. Microsoft Learn, „Exporting Customer Data and Enabling Cloud Choice“, https://learn.microsoft.com/en-us/compliance/assurance/assurance-exporting-customer-data, abgerufen im Juli 2026.
8. Microsoft Azure, „Bandwidth pricing“, https://azure.microsoft.com/en-us/pricing/details/bandwidth/, abgerufen im Juli 2026.
9. Microsoft Learn, „Data transfer fees – EU Data Act“, https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/data-transfer-fees, abgerufen im Juli 2026.
10. AWS News Blog, „Free data transfer out to internet when moving out of AWS“, https://aws.amazon.com/blogs/aws/free-data-transfer-out-to-internet-when-moving-out-of-aws/, aktualisiert 30.09.2025, abgerufen im Juli 2026.
11. AWS, „Data transfer“, https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer, abgerufen im Juli 2026.
12. AWS, „Service Terms“, https://aws.amazon.com/service-terms/, abgerufen im Juli 2026.
13. Oracle Cloud Infrastructure, „EU Data Act“, https://docs.oracle.com/en-us/iaas/Content/General/Reference/eu-data-act.htm, abgerufen im Juli 2026.
14. Oracle, „EU Data Act Addendum“, https://www.oracle.com/contracts/docs/eu-data-act-addendum.pdf, abgerufen im Juli 2026.
15. IBM Cloud Docs, „IBM Cloud Terms of Use – EU Data Act“, https://cloud.ibm.com/docs/overview?topic=overview-terms, abgerufen im Juli 2026.
16. IBM, „Data Processing Addendum“, https://www.ibm.com/support/customer/csol/terms/?id=i126-6614, abgerufen im Juli 2026.
17. AWS, „Amazon S3 Pricing“, https://aws.amazon.com/s3/pricing/, abgerufen im Juli 2026.
18. AWS, „AWS VPN Pricing“, https://aws.amazon.com/vpn/pricing/, abgerufen im Juli 2026.
19. Google Cloud, „Cloud Storage pricing“, https://cloud.google.com/storage/pricing, abgerufen im Juli 2026.
20. Cloudflare, „R2 pricing“, zuletzt aktualisiert 28.05.2026, https://developers.cloudflare.com/r2/pricing/, abgerufen im Juli 2026.
21. Backblaze, „S3-Compatible Cloud Storage with 3x Free Egress“, https://www.backblaze.com/cloud-storage/solutions/developers, abgerufen im Juli 2026.
22. Wasabi, „Hot Cloud Storage Pricing“, https://wasabi.com/pricing, abgerufen im Juli 2026.
23. Wasabi, „Product Terms“, https://wasabi.com/product-terms, abgerufen im Juli 2026.
24. OVHcloud, „S3-compatible object storage with no egress fees“, https://www.ovhcloud.com/en/public-cloud/object-storage/, abgerufen im Juli 2026.
25. Hetzner, „Object Storage“, https://www.hetzner.com/storage/object-storage/, abgerufen im Juli 2026.
26. Europäische Zentralbank, „Euro foreign exchange reference rates“, Referenzkurse vom 28.07.2026, https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html, abgerufen im Juli 2026.
27. Google, Prepare for the future with Google Analytics 4, https://blog.google/products/marketingplatform/analytics/prepare-for-future-with-google-analytics-4/, veröffentlicht am 16.03.2022; abgerufen im Juli 2026.
28. Google, A message about Stadia and our long-term streaming strategy, https://blog.google/products-and-platforms/products/stadia/message-on-stadia-streaming-strategy/, veröffentlicht am 29.09.2022; abgerufen im Juli 2026.
29. Google Analytics Help, Google Optimize sunset, https://support.google.com/analytics/answer/12979939?hl=en, abgerufen im Juli 2026.
30. Google Workspace Updates, The next phase of digital whiteboarding, https://workspaceupdates.googleblog.com/2023/09/the-next-phase-of-digital-whiteboarding-for-google-workspace.html, veröffentlicht am 28.09.2023; abgerufen im Juli 2026.
31. Atlassian, New partnership with Slack, https://www.atlassian.com/blog/development/new-atlassian-slack-partnership, veröffentlicht am 26.07.2018; abgerufen im Juli 2026.
32. Atlassian, Slack partnership FAQ, https://www.atlassian.com/partnerships/slack/faq, abgerufen im Juli 2026.
33. Adobe, End of service for Adobe Muse, https://helpx.adobe.com/uk/muse/kb/adobe-muse-end-of-service.html, abgerufen im Juli 2026.
34. Meta, Shaping the Future of Work with Workplace, https://about.fb.com/news/2021/10/workplace-fifth-birthday/, mit Update vom 14.05.2024; abgerufen im Juli 2026.
35. Mozilla, Update on Firefox Send and Firefox Notes, https://blog.mozilla.org/en/uncategorized/update-on-firefox-send-and-firefox-notes/, veröffentlicht am 17.09.2020; abgerufen im Juli 2026.
36. Firebase, Dynamic Links Deprecation FAQ, https://firebase.google.com/support/dynamic-links-faq, abgerufen im Juli 2026.
37. Google Takeout, https://takeout.google.com/, abgerufen im Juli 2026.
38. Google Analytics Help, Universal Analytics data processing and deletion, https://support.google.com/analytics/answer/11583528, abgerufen im Juli 2026.
39. Verordnung (EU) 2023/2854 des Europäischen Parlaments und des Rates vom 13. Dezember 2023 über harmonisierte Vorschriften für einen fairen Datenzugang und eine faire Datennutzung, EUR-Lex, https://eur-lex.europa.eu/eli/reg/2023/2854/oj, abgerufen im Juli 2026.

---

Disclosure und Haftungsausschluss

FW Delta entwickelt und betreibt eigene Infrastruktur, Automatisierung und Migrationsarchitekturen und kann wirtschaftlich von entsprechenden Projekten profitieren. Deshalb werden öffentliche Beobachtungen, Berechnungen, Szenarien und Empfehlungen getrennt gekennzeichnet.

Dieser Report ist keine Rechts-, Steuer- oder Vertragsberatung. Für einen konkreten Wechsel sind Anwendungsbereich des Data Act, Vertrag, Datenklassen, Sicherheitsanforderungen und tatsächliche Anbieterbedingungen individuell zu prüfen.