Data Act und Cloud-Wechsel: Warum Websites einen Exit-Plan brauchen
Der EU Data Act rückt den Wechsel von Cloud- und Datenverarbeitungsdiensten stärker in den Fokus. Für Website-Teams ist das ein guter Anlass, Hosting, Backups, Exporte und Vendor-Lock-in praktisch zu prüfen.
Viele Websites hängen stärker an einzelnen Anbietern, als es im Alltag sichtbar ist. Hosting, Datenbank, CMS, Newsletter, Analytics, Suche, Medien, Formulare, Zahlungsanbieter und Automationen wirken wie einzelne Bausteine. In der Praxis entsteht daraus schnell ein Lock-in: Niemand weiß genau, welche Daten wo liegen, wie ein Export funktioniert und wie lange ein Wechsel wirklich dauern würde.
Der EU Data Act lenkt den Blick unter anderem auf den Wechsel von Datenverarbeitungsdiensten und Cloud-Anbietern. Für normale Website-Betreiber ist daraus vor allem eine praktische Frage abzuleiten: Könnten wir unsere Website, Daten und Prozesse in angemessener Zeit zu einem anderen Anbieter bewegen?
Der Unterschied zwischen Backup und Exit
Ein Backup ist gut. Ein Exit-Plan ist mehr. Ein Backup sagt: Wir können etwas wiederherstellen. Ein Exit-Plan sagt: Wir können den Anbieter wechseln, ohne Website, Daten, Domains und Geschäftsprozesse zu verlieren.
Das ist ein anderer Test. Bei einem echten Wechsel zählen nicht nur Dateien. Relevant sind auch Datenbankschema, Uploads, DNS, E-Mail, Cronjobs, Redirects, API-Schlüssel, Webhooks, Zahlungsreferenzen, Logs, Consent-Einstellungen und Dokumentation.
Typische Lock-in-Stellen
Website-Projekte stolpern oft an sehr banalen Stellen:
- Domain und DNS liegen bei einer Agentur statt beim Unternehmen.
- CMS-Backups enthalten keine Medien oder keine Datenbank.
- Page-Builder-Inhalte lassen sich nicht sauber exportieren.
- Tracking- und Consent-Konfigurationen sind nicht dokumentiert.
- Formulare senden an alte Postfächer oder versteckte Webhooks.
- Zahlungsanbieter, Mitgliederbereich und E-Mail-Automation sind eng gekoppelt.
- Niemand kennt die Zugangsdaten für Hosting, CDN oder Search Console.
Das Problem zeigt sich meistens erst unter Druck: Provider kündigt, Preise steigen, Agenturwechsel, Sicherheitsvorfall, schlechtes Hosting oder ein Relaunch, der plötzlich alte Abhängigkeiten offenlegt.
Praktischer Website-Exit-Check
Ein kleiner Exit-Check sollte diese Fragen beantworten:
- Besitz: Gehören Domain, Hosting, Repository und Accounts wirklich dem Unternehmen?
- Export: Können Inhalte, Nutzer, Bestellungen, Dateien und Einstellungen exportiert werden?
- Wiederherstellung: Wurde ein Restore wirklich getestet?
- DNS und E-Mail: Sind MX, SPF, DKIM, DMARC und Weiterleitungen dokumentiert?
- Integrationen: Welche Webhooks, API-Keys und Drittanbieter hängen an der Website?
- Datenflüsse: Welche personenbezogenen Daten laufen durch welche Dienste?
- Zeitplan: Wie lange dauert ein realistischer Wechsel?
Die Antwort muss nicht perfekt sein. Aber wenn niemand sie geben kann, ist das ein Wartungsrisiko.
Was Teams sofort verbessern können
Für kleine Teams reichen oft einfache Maßnahmen:
- Zugangsliste mit Owner, Zweck und Wiederherstellungsweg pflegen.
- Monatlich automatisierte Backups plus gelegentliche Restore-Tests.
- Repository, Deployment und Umgebungsvariablen dokumentieren.
- Kritische Konfigurationen exportieren oder screenshotten.
- Verträge und Kündigungsfristen sammeln.
- Mindestens einmal pro Jahr einen Anbieterwechsel theoretisch durchspielen.
Das klingt trocken, spart aber im Ernstfall Tage.
Fazit
Der Data Act ist für Website-Teams ein guter Anlass, Cloud- und Dienstleisterabhängigkeiten sichtbar zu machen. Ein Exit-Plan bedeutet nicht, dass man morgen wechseln muss. Er bedeutet, dass man könnte. Genau das ist der Unterschied zwischen Kontrolle und Hoffnung.
Quellen
- Regulation (EU) 2023/2854 Data Act
- European Commission: Data Act
- European Commission: Switching cloud providers and data processing services
Hinweis: Dieser Beitrag ist eine technische Einordnung und keine Rechtsberatung.