Cloud-Exit-Strategie: Einen Anbieterwechsel vorbereiten
Daten exportieren, Abhängigkeiten ersetzen und den Wechsel erproben: So planen KMU eine konkrete Cloud-Migration mit Abnahme und Rückfallweg.
Inhalt
Daten exportieren, Abhängigkeiten ersetzen und den Wechsel erproben: So planen KMU eine konkrete Cloud-Migration mit Abnahme und Rückfallweg.
Artikel teilen
Ein Anbieterwechsel braucht eine Abnahme
Ein illustratives Beispiel: Claudia, Geschäftsführerin eines technischen Dienstleisters mit 35 Mitarbeitern in Bayern, erhält einen Anruf, der ihren Tag ruiniert. Ein strategischer Großkunde fordert nachweisbare EU-Datenresidenz für alle Projektdaten — und zwar mit Wirkung zum nächsten Quartal. Bisher lagern 800 GB Kundenprojektdaten bei einem US-Hyperscaler. Claudia bittet ihren Technischen Leiter Markus, eine Schätzung für den Umzug zu erstellen. Drei Tage später liegt das Ergebnis auf dem Tisch: Die Egress-Gebühren allein übersteigen die erwarteten Einsparungen eines ganzen Jahres. Hinzu kommen vier bis sechs Monate Entwicklungszeit, weil drei produktive Workloads auf proprietäre APIs gebunden sind.
Der Ausstieg war nie eingeplant. Die Architektur ging davon aus, dass der Anbieter permanent ist. Die Bequemlichkeit von Managed Kubernetes, Managed PostgreSQL und serverlosen Funktionen maskierte eine schleichende Abhängigkeit, die jetzt — mitten in einer Kundenverhandlung — zum strategischen Problem wird.
Eurostat meldet für 2025, dass 52,74 Prozent der erfassten EU-Unternehmen bezahlte Cloud-Dienste nutzten. Die Erhebung umfasst Unternehmen ab zehn Beschäftigten in den erfassten Wirtschaftsbereichen. Das zeigt Verbreitung, aber nicht, ob ein einzelner Betrieb wechseln kann. Dafür müssen Verträge, Daten und technische Abhängigkeiten untersucht werden.
Warum Cloud-Ausstieg kein Problem für später ist
Der Irrtum beginnt mit dem Gefühl, jederzeit wechseln zu können. Doch Ausstiegskosten kristallisieren sich nicht am Tag der Kündigung, sondern in den tausend kleinen Architekturentscheidungen davor.
Die API-Sediment-Schicht
Jede Zeile Code, die an eine proprietäre API gebunden ist, bildet Sediment. Ein serverloser Funktionsdienst hier, eine verwaltete Warteschlange dort — nach zwei Jahren ist der Integrations-Stack so dicht verbacken, dass ein Re-Platforming 40 % des Codes neu schreiben lässt. Das ist keine theoretische Zahl: In der Praxis dieses technischen Dienstleisters stecken 12 SaaS-Integrationen in diesem Netz. David, der Entwickler, weiß: Ein Umzug bedeutet Monate Reverse-Engineering statt Produktivität.
Die Datenformat-Falle
Bei verwalteten Datenbanken reicht der Produktname nicht als Portabilitätsprüfung. Aurora bietet beispielsweise PostgreSQL- und MySQL-kompatible Varianten; trotzdem können Erweiterungen, Betriebsfunktionen und Integrationen vom Anbieter abhängen. Prüfen Sie Schema, SQL-Funktionen, Export und Wiederanlauf auf dem Zielsystem. Auch PostgreSQL ist keine Garantie für einen unveränderten Umzug.
Die Dokumentationslücke
Wer besitzt bei Ihnen die Zugänge, die Deployment-Prozeduren und die Netzwerkkonfiguration für einen Provider-Wechsel? In vielen KMU mit 10–100 Mitarbeitern ist dieses Wissen auf eine Person konzentriert. Wenn diese Person das Unternehmen verlässt, verschwindet der Ausstiegsschlüssel mit ihr.
Die versteckten Kosten, wenn die Tür nicht mehr aufgeht
Planen Sie Datenübertragung, Anpassungen an der Anwendung und Parallelbetrieb getrennt. Die folgenden Fragen helfen bei der Schätzung; die tatsächlichen Kosten hängen von Ihrem System und den vereinbarten Leistungen ab.
Egress-Gebühren als Ausstiegsmauer
Prüfen Sie, ob für Ihren Wechsel noch Übertragungsgebühren anfallen und welche Vertragskonditionen gelten. Der Data Act sieht ab 12. Januar 2027 die Abschaffung der erfassten Wechselgebühren vor. Eigene Entwicklungsarbeit und Parallelbetrieb bleiben gesonderte Kostenpositionen.
Re-Platforming-Kosten ohne Budgetreserve
Eine Migration muss für den konkreten Workload kalkuliert werden. Erfassen Sie Schnittstellen, Datenmenge, notwendige Anpassungen, Tests, Parallelbetrieb und Schulung. Ohne diese Annahmen sind pauschale Angaben wie 80.000 bis 120.000 Euro oder vier bis sechs Monate keine belastbare Kostenschätzung.
Verhandlungsmachtverlust und Preisdiktat
Ein glaubwürdiger Wechselpfad kann bei Vertragsgesprächen helfen. Wie groß dieser Effekt ist, hängt jedoch von Alternativen, Laufzeiten und Umstellungskosten ab. Eine pauschale Preissteigerung bei Hyperscalern oder der Verzicht aller übrigen Kunden auf Verhandlungsmacht lässt sich daraus nicht ableiten.
Der 30-Tage-Test und andere Frühwarnsignale
Der beste Ausstiegsschlüssel ist der, den Sie regelmäßig in der Hand halten. Statt auf einen Notfall zu warten, sollten KMU ihre Stack-Portabilität systematisch testen.
Der EU-Data-Act-Portabilitätscheck
Trennen Sie Kündigung, vertraglichen Wechselzeitraum und technische Durchführung. Ein interner Probelauf kann zeigen, ob ein kritischer Workload am Ziel funktioniert. Ein selbst gesetztes 30-Tage-Ziel ist dabei eine Planungsannahme; es belegt weder eine allgemeine Kündigungsfrist noch die vollständige Umsetzbarkeit einer Migration.
Das NIS2-Ausstiegsnachweise-Audit
NIS2-Anforderungen an Lieferkettensicherheit betreffen Einrichtungen im jeweiligen gesetzlichen Anwendungsbereich. Ein kleinerer Zulieferer kann zusätzlich vertragliche Nachweisanforderungen seiner Kunden erhalten. Daraus folgt keine automatische Übertragung sämtlicher NIS2-Pflichten. Klären Sie, welche Nachweise für Ihren Wechsel konkret benötigt werden.
Der interne Switching-Drill
Markus bei diesem technischen Dienstleister führt einmal jährlich einen 30-Tage-Switching-Drill durch: Ein kritischer Workload wird auf einem alternativen Ziel reprovisioned. Das Ziel ist nicht der vollständige Umzug, sondern die Reproduzierbarkeit. Wenn Terraform- oder GitOps-Pipelines den Stack in unter einer Woche auf einer neuen Umgebung aufbauen können, ist der Ausstiegsschlüssel funktionsfähig. Wenn nicht, wissen Claudia und Markus genau, wo der Stack klebt.
Die portable Architektur, die den Ausstieg ermöglicht
Portabilität ist kein Produkt, das man kauft. Sie ist eine Eigenschaft, die man einbaut. Die portable Architektur basiert auf vier Säulen, die zusammen verhindern, dass der Ausstieg zur Katastrophe wird.
Kubernetes als Abstraktionsschicht
Kubernetes vereinheitlicht Teile der Bereitstellung. Ein Umzug muss trotzdem Speicher, Netzwerk, Ingress, Identitäten, Secrets und externe Dienste berücksichtigen. Die StorageClass-Dokumentation zeigt beispielsweise anbieterspezifische Provisioner. Testen Sie einen repräsentativen Workload auf dem Ziel; erst daraus lassen sich Aufwand und Restabhängigkeiten ableiten.
Offene Datenformate und quelloffene Workloads
Offene Datenbanken und Protokolle können einen Wechsel erleichtern. Prüfen Sie trotzdem Erweiterungen, Betriebsfunktionen, Datenmengen und Schnittstellen. Ob ein selbst betriebener Dienst günstiger ist, hängt von Kapazität, Personal und Wartung ab. Eine offene Lizenz allein macht ein System weder vollständig portabel noch wirtschaftlicher.
Infrastructure as Code für reproduzierbare Umgebungen
Infrastructure as Code kann die Bereitstellung dokumentieren und wiederholbar machen. Ressourcen, Provider-Module, Secrets und Datenwiederherstellung bleiben auf dem Ziel zu prüfen. Für den illustrativen Betrieb wäre ein begrenzter Umzugstest ein geeigneter nächster Schritt. Eine bestimmte Verkürzung der Migrationszeit ist damit noch nicht gemessen.
Souveräne DACH-Hosting-Optionen als Fallback
Ein Zielanbieter muss anhand von Vertrag, technischer Eignung, Datenflüssen und Jurisdiktion geprüft werden. Der CLOUD Act betrifft bestimmte Anbieter unter US-Jurisdiktion und Daten in deren Besitz, Verwahrung oder Kontrolle; ein fehlender US-Mutterkonzern allein ist kein abschließender Ausschlusstest. Standort und Unternehmensstruktur sind deshalb Teile der Prüfung, keine pauschale Freigabe.
Von der Lock-in-Falle zur bewussten Abhängigkeit
Der Unterschied zwischen einer Falle und einer bewussten Abhängigkeit liegt in der Architektur. Hier zeigt sich der Kontrast am Beispiel dieses technischen Dienstleisters.
Vorher: Eine Architektur ohne Ausstiegsschlüssel
Drei Workloads auf einem US-Hyperscaler: Managed Kubernetes mit anbieterspezifischen Ingress-Controllern, eine Managed-PostgreSQL-Instanz mit proprietären Erweiterungen, serverlose Funktionen, die direkt an den Message-Queue-Dienst des Anbieters gekoppelt sind. 12 SaaS-Integrationen, deren Authentifizierung über den Identity-Provider des Hyperscalers läuft. Keine dokumentierte Netzwerktopologie, keine IaC-Pipelines, kein regelmäßiger Backup-Restore-Test auf alternativer Infrastruktur. Der Ausstiegsschlüssel existiert nicht.
Nachher: Ein Stack, der Anbieter nach Wert wählt
Nach einer sechsmonatigen Phase der Standardisierung läuft der gleiche Funktionsumfang auf einem Kubernetes-Cluster mit Helm-Charts und GitOps. PostgreSQL als StatefulSet mit standardisierten Backup-Jobs. n8n für Automatisierungen auf einer selbstgehosteten Instanz mit lokaler Datenausführung. Die SaaS-Integrationen nutzen OAuth2 mit portablen Credentials statt anbieterspezifischer IAM-Rollen. Ein zweiter, kleinerer Cluster bei einem DACH-Anbieter dient als aktiver Fallback. Der jährliche Switching-Drill bestätigt: Ein kritischer Workload lässt sich in unter 30 Tagen umziehen.
Das Ergebnis ist keine Ideologie. Es ist eine bewusste Abhängigkeit: Dieser technische Dienstleister nutzt weiterhin den US-Hyperscaler für spezialisierte KI-Workloads, weil er dort wirtschaftlich sinnvoll ist. Aber der Entscheid ist jetzt eine Wahl — keine Zwangslage.
Wie Planfold Souveränität in die Architektur einbaut
Bei Planfold behandeln wir Exit-Fähigkeit nicht als Notfallprozedur, sondern als kontinuierliche Architektureigenschaft. Unsere Methode folgt drei Phasen, die technisch definiert und betrieblich nachvollziehbar sind.
Plan — Lock-in-Risiko auditieren und portable Architektur entwerfen
Wir beginnen mit einem Audit des bestehenden Stacks: Welche Workloads sind auf proprietäre APIs gebunden? Welche Datenformate sind portabel, welche anbieterspezifisch? Welche Kundenverträge verlangen nachweisbare Exit-Fähigkeit oder Datenlokalisierung? Wer im Unternehmen besitzt die Zugänge, Dokumentation und Deployment-Prozeduren für einen Provider-Wechsel? Das Ergebnis ist keine theoretische Risikoliste, sondern eine priorisierte Roadmap mit konkreten Schritten.
Unfold — Souveräne Infrastruktur auf standardisierten Schichten ausrollen
Wir rollen die Zielarchitektur auf Kubernetes aus, nutzen Infrastructure as Code für reproduzierbare Deployments und setzen auf offene Datenformate. Jede neue Managed-Service-Entscheidung durchläuft eine 15-minütige Lock-in-Risiko-Einschätzung — ein Review-Gate, das Claudia und Markus bei diesem technischen Dienstleister für jede Architekturentscheidung institutionalisiert haben. Die Infrastruktur wird in einem DACH-Rechenzentrum mit dokumentierter Datenresidenz und Eigentümerschaft betrieben.
Resonate — Portabilität und Compliance fortlaufend nachweisen
Vereinbaren Sie, wann Export, Wiederherstellung und dokumentierte Abhängigkeiten erneut geprüft werden. Ein erfolgreicher Probelauf verliert an Aussagekraft, wenn sich Datenmodell, Infrastruktur oder Berechtigungen ändern. Prüfprotokolle unterstützen Kunden- und Rechtsfragen; sie erzeugen keine automatische Konformitätsbestätigung.
Ein praktischer Startpunkt für KMU
Sie brauchen kein Enterprise-Plattform-Team, um mit Portabilität zu beginnen. Sie brauchen fünf klare Architekturentscheidungen und einen 90-Tage-Plan.
Die fünf Architekturentscheidungen, die Portabilität sichern
- Containerisierung als Standard: Jeder neue Workload wird als Container ausgeliefert, nicht als anbieterspezifische Serverless-Funktion oder proprietärer Dienst. Kubernetes wird zur Zielplattform.
- Offene Datenformate: Neue Datenhaltung nutzt PostgreSQL, MySQL oder andere offene Standards. Proprietäre Datenbankdienste werden nur für bestehende Workloads beibehalten, nicht für Neuentwicklungen.
- Infrastructure as Code: Jede Umgebung wird in Code versioniert. Manuelle Konfiguration über die Weboberfläche des Anbieters wird verboten — auch für schnelle Tests.
- Entkopplung der Integrationschicht: SaaS-Integrationen nutzen standardisierte APIs und portablen Authentifizierungsmechanismus. Keine enge Kopplung an anbieterspezifische IAM-Rollen oder Message-Queues.
- Dokumentierte Ownership: Für jeden Workload gibt es eine dokumentierte Deployment-Prozedur, einen Backup-Restore-Testplan und einen benannten Verantwortlichen — unabhängig davon, wer gerade im Urlaub ist.
Der 90-Tage-Exit-Readiness-Plan
- Tag 1–30: Lock-in-Risiko-Audit. Identifizieren Sie die drei am stärksten gebundenen Workloads und schätzen Sie deren Umzugskosten. Dokumentieren Sie Egress-Gebühren der letzten 12 Monate.
- Tag 31–60: Standardisieren Sie einen Workload. Containerisieren, IaC-Pipeline aufbauen, offene Datenformate einführen. Führen Sie einen ersten Switching-Drill durch.
- Tag 61–90: Institutionalisieren Sie Review-Gates. Jede neue Managed-Service-Entscheidung durchläuft die 15-minütige Lock-in-Prüfung. Quartalsweise Egress- und Portabilitäts-Reviews werden im Kalender verankert.
Beginnen Sie mit einer repräsentativen Datenkopie und einem kritischen Ablauf. Halten Sie fest, welche Anpassungen am Ziel nötig sind, wer das Ergebnis abnimmt und wie der Rückfall auf die bisherige Umgebung funktioniert.
Planen. Entfalten. Resonanz erzeugen.
