Cloud-Lock-in: Warum der Data Act jetzt einen Wechselplan erzwingt

Cloud-Lock-in war lange ein technisches Ärgernis: Egress-Kosten, proprietäre APIs, schwer exportierbare Daten und Infrastruktur, die nur bei einem Anbieter wirklich funktioniert. Seit dem EU Data Act ist das Thema aber nicht mehr nur Architektur-Philosophie, sondern Teil der operativen Compliance.

Für kleine Unternehmen, Agenturen und SaaS-Teams ist die wichtigste Frage nicht: „Müssen wir morgen alles migrieren?“ Die bessere Frage ist: Könnten wir sauber erklären, wie wir wechseln würden, wenn ein Kunde, ein Risiko oder ein Anbieterproblem uns dazu zwingt?

Was der Data Act bei Cloud-Wechseln anstößt

Der Data Act gilt grundsätzlich seit dem 12. September 2025. Er enthält unter anderem Regeln für sogenannte Datenverarbeitungsdienste, also Cloud- und Hosting-nahe Services. Anbieter sollen Hindernisse abbauen, die Kund:innen am Wechsel zu einem anderen Anbieter, zu On-Premises-Infrastruktur oder an einer Multi-Cloud-Nutzung hindern.

Besonders praktisch ist der Blick auf Wechselkosten: Bis zum 12. Januar 2027 dürfen Anbieter unter bestimmten Bedingungen noch reduzierte Switching Charges verlangen. Ab dem 12. Januar 2027 sollen für den Wechselprozess keine solchen Wechselentgelte mehr erhoben werden. Das betrifft nicht normale Servicegebühren, aber gerade Datenexport- und Wechselkosten werden damit politisch und regulatorisch deutlich weniger akzeptiert.

Für Website-Betreiber klingt das erst einmal nach „Big Cloud“. In der Praxis hängen aber auch kleine Projekte an dieser Kette: Hosting, Datenbank, Object Storage, E-Mail-Versand, Analytics, Auth, KI-APIs, Backups und Monitoring.

Warum das für Entwicklerteams jetzt relevant ist

Ein Wechselplan ist kein 80-Seiten-Roman mit Compliance-Parfüm. Er ist eine technische Sicherheitsleine. Wenn ein Anbieter Preise erhöht, ein Dienst ausfällt, Datenschutzanforderungen steigen oder ein Kunde eine andere Infrastruktur verlangt, entscheidet die bestehende Architektur darüber, ob der Wechsel ein Sprint wird — oder ein Staffelfinale mit brennendem Serverraum.

Typische Lock-in-Stellen sind:

• Datenbanken: proprietäre Funktionen, unklare Exportpfade, fehlende Migrationsstrategie.
• Dateien und Medien: Object Storage ohne saubere Pfadstruktur, keine Lifecycle-Regeln, keine Exporttests.
• Serverless- und Edge-Funktionen: stark an Anbieter-Runtime, Secrets und Deployments gekoppelt.
• Auth und Nutzerkonten: User-IDs, Sessions, Rollen und MFA lassen sich oft schwer übertragen.
• Analytics und Logs: personenbezogene oder sicherheitsrelevante Daten liegen verteilt in Tools.
• KI-Integrationen: Prompts, Modellnamen, Regionen, Logging und Anbieterbedingungen ändern sich schnell.

Wer hier erst nachdenkt, wenn der Anbieterwechsel bereits nötig ist, zahlt doppelt: technisch und organisatorisch.

Der pragmatische Wechselplan

Für kleine Teams reicht ein kompaktes Dokument im Projekt, zum Beispiel docs/vendor-exit-plan.md. Darin sollten keine Wunschträume stehen, sondern prüfbare Fakten:

1. Kritische Anbieter: Welche Dienste sind für Betrieb, Zahlung, Kommunikation, Analyse oder KI-Funktionen notwendig?
2. Datenarten: Welche personenbezogenen Daten, Kundendaten, Dateien, Logs und Konfigurationen liegen wo?
3. Exportweg: Gibt es API-, SQL-, CSV-, JSON- oder Backup-Exports? Wurden sie getestet?
4. Wiederherstellung: Kann ein Export in einer anderen Umgebung wirklich wieder eingespielt werden?
5. Abhängigkeiten im Code: Sind Anbieter-SDKs gekapselt oder quer durch die App verteilt?
6. Verträge und AVV: Wo stehen Auftragsverarbeitung, Region, Unterauftragnehmer und Kündigungsfristen?
7. Kosten und Fristen: Welche Gebühren, Kündigungsfristen und Datenaufbewahrungsfristen gelten aktuell?

Das ist kein Luxus. Das ist das technische Gegenstück zu „Wo sind die Schlüssel, wenn das Haus brennt?“

Architektur: Kleine Entscheidungen, großer Unterschied

Ein Projekt muss nicht komplett cloud-agnostisch gebaut werden. Das wäre für viele kleine Teams zu teuer und zu langsam. Aber bestimmte Entscheidungen machen spätere Wechsel deutlich weniger schmerzhaft:

• Anbieter-SDKs hinter kleine interne Adapter legen.
• Datenmodelle in eigenen Typen halten statt Provider-Objekte überall durchzureichen.
• Backups nicht nur erstellen, sondern testweise wiederherstellen.
• Secrets, Domains, DNS und Webhooks dokumentieren.
• Logs mit Lösch- und Zugriffskonzept behandeln.
• Für wichtige Dienste mindestens eine realistische Alternative notieren.

Gerade bei Websites und kleineren SaaS-Projekten reicht oft schon eine saubere Trennung zwischen Produktlogik und Anbieterintegration. Niemand muss Multi-Cloud cosplayen. Aber niemand sollte sein Geschäftsmodell an einen einzigen Button im fremden Dashboard ketten.

Datenschutz: Export ist nicht automatisch erlaubt

Portabilität und Wechselbarkeit lösen nicht automatisch alle Datenschutzfragen. Wenn personenbezogene Daten exportiert oder zu einem neuen Anbieter übertragen werden, bleiben DSGVO-Themen bestehen: Rechtsgrundlage, Auftragsverarbeitung, Informationspflichten, Zugriffsschutz, Löschung und Datenminimierung.

Besonders heikel sind Logs, Supportdaten und KI-Prompts. Diese Daten sehen oft technisch aus, enthalten aber schnell Namen, E-Mail-Adressen, Vertragsinhalte, Gesundheitsdaten, Zahlungsinformationen oder interne Kundennotizen. Wer einen Wechselplan schreibt, sollte deshalb nicht nur fragen „Können wir exportieren?“, sondern auch: Was dürfen wir exportieren, wer darf es sehen und wann muss es gelöscht werden?

Fazit

Der Data Act macht Cloud-Wechselbarkeit sichtbarer und relevanter. Gleichzeitig schaut die EU auch politisch stärker auf Cloud- und KI-Märkte, Wettbewerb und digitale Souveränität. Für kleine Softwareteams ist daraus keine Panik abzuleiten, aber eine klare Aufgabe: Anbieterabhängigkeiten müssen sichtbar werden.

Ein guter Wechselplan ist kurz, technisch und ehrlich. Er zeigt, wo Daten liegen, wie sie exportiert werden, welche Anbieter kritisch sind und welche Teile der Architektur beim Wechsel weh tun würden. Das schützt vor Lock-in, verbessert Datenschutzdokumentation und macht Projekte wartbarer.

Oder weniger trocken gesagt: Wer den Exit kennt, ist nicht gefangen. Und Software, die nicht gefangen ist, schläft nachts besser.

Quellen

• Regulation (EU) 2023/2854, Data Act
• Reuters: EU rules reining in Big Tech will now target cloud services and AI, regulators say
• Reuters: EU Commission awards 180 million euro cloud contract to four European providers

Hinweis: Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung.