Ein Cloud-Umzug ist planbar, wenn Sie wissen, womit Sie es zu tun haben. Markieren Sie die Dienste, die Sie nutzen, und sehen Sie, was direkt umziehen kann, was Anpassungen braucht und was tief verankert ist.
2Welche Dienste nutzen Sie?
Wir haben eine typische Konfiguration vorausgewählt. Passen Sie sie an Ihre Umgebung an und sehen Sie, wo jeder Dienst landet.
Ihr Portabilitätsprofil
Kategorie 1: Direkt umziehbar
Weit verbreitete, offene Technologie. Zieht mit erprobten Verfahren und kaum Unterbrechung um.
Kategorie 2: Umziehbar mit Anpassung
Europäische Entsprechungen gibt es. Einige Anpassungen sind nötig, der Aufwand bleibt aber kalkulierbar.
Kategorie 3: Tief verankert
Eng mit einem Anbieter verwachsen. Braucht eine bewusste Entscheidung: ersetzen, neu bauen oder vorerst belassen.
Kein Ausschlusskriterium. Jeder dieser Dienste lässt sich ersetzen oder neu bauen. Wir planen den Umzug mit Ihnen Schritt für Schritt, damit nichts davon Sie am Anbieterwechsel hindert.
Eine Orientierung auf Basis typischer Umgebungen. Den tatsächlichen Aufwand bestimmt Ihre Konfiguration, die Cloud-Analyse bewertet jeden Dienst einzeln. Zuordnungen zuletzt geprüft am 20. Oktober 2026. Wir erhalten von keinem der genannten Anbieter Provisionen.
| Dienst | Kategorie | Europäische Option | Was sich ändert |
|---|---|---|---|
| Amazon Web Services | |||
| Amazon EC2 | 1 Direkt umziehbar | Compute-Instanzen (STACKIT, IONOS, Open Telekom Cloud, Exoscale) | Images und Konfigurationen ziehen mit Standardwerkzeugen um. Ein guter Anlass, die Größen neu zu dimensionieren. |
| Amazon EKS | 1 Direkt umziehbar | Managed Kubernetes (STACKIT SKE, Open Telekom Cloud CCE, Exoscale SKS) | Manifeste und Helm-Charts laufen weitgehend unverändert weiter. Anbieterspezifische Add-ons wie Load Balancer oder Identitätsanbindungen werden ausgetauscht. |
| Amazon ECS und Fargate | 2 Umziehbar mit Anpassung | Managed Kubernetes | Die Container bleiben gleich. Aus Task-Definitionen werden Kubernetes-Deployments. |
| AWS Lambda | 2 Umziehbar mit Anpassung | Funktionen auf Kubernetes (Knative, OpenFaaS) oder einfache Container | Der Code zieht leicht um. Den größten Aufwand machen die Trigger und Integrationen drumherum. |
| AWS Elastic Beanstalk | 2 Umziehbar mit Anpassung | Container auf Managed Kubernetes | Jede Anwendung wird einmal containerisiert, die Plattform-Konfiguration neu aufgebaut. |
| Amazon S3 | 1 Direkt umziehbar | S3-kompatibler Objektspeicher (STACKIT, IONOS, Open Telekom Cloud, Hetzner) | Gleiche Schnittstelle, Ihre Anwendungen ändern sich kaum. Den einmaligen Datentransfer planen wir vorab ein. |
| Amazon EBS und EFS | 1 Direkt umziehbar | Block- und Dateispeicher beim Zielanbieter | Zieht gemeinsam mit den Servern um, die darauf zugreifen. |
| Amazon RDS (PostgreSQL, MySQL, MariaDB) | 1 Direkt umziehbar | Managed PostgreSQL, MySQL oder MariaDB (STACKIT, IONOS, Exoscale) | Standard-Engines mit bewährten Migrationswerkzeugen. Per Replikation bleibt das Umschaltfenster kurz. |
| Amazon Aurora | 2 Umziehbar mit Anpassung | Managed PostgreSQL oder MySQL | Engine-kompatibel, aber Aurora-eigene Funktionen wie Serverless oder Global Database brauchen einen Ersatzplan. |
| Amazon ElastiCache | 1 Direkt umziehbar | Managed Valkey oder Redis (Exoscale, OVHcloud) | Gleiches Protokoll, meist genügt eine Konfigurationsänderung. |
| Amazon DocumentDB | 2 Umziehbar mit Anpassung | Managed MongoDB (STACKIT, IONOS, OVHcloud) | MongoDB-kompatible Schnittstelle, im Detail aber abweichend. Abfragen und Indizes werden geprüft. |
| Amazon DynamoDB | 3 Tief verankert | Neues Datenmodell für PostgreSQL, MongoDB oder Vergleichbares | Proprietär bei AWS. Meist der aufwendigste Teil des Umzugs, dafür fällt eine der größten Abhängigkeiten weg. |
| Amazon SQS und SNS | 2 Umziehbar mit Anpassung | RabbitMQ, Apache Kafka oder NATS | Die Messaging-Muster lassen sich gut übertragen. Client-Code und Berechtigungen ändern sich. |
| Amazon EventBridge | 2 Umziehbar mit Anpassung | Event-Bus auf Basis von Apache Kafka oder NATS | Event-Regeln und Routing werden neu aufgebaut. |
| Amazon Kinesis | 2 Umziehbar mit Anpassung | Apache Kafka | Kafka ist der offene Standard für Streaming. Producer und Consumer werden angepasst. |
| Amazon API Gateway | 2 Umziehbar mit Anpassung | Offenes API-Gateway (Kong, Traefik) oder Kubernetes Ingress | Die Routen ziehen mit um, Authorizer und Nutzungspläne werden neu aufgebaut. |
| AWS Step Functions | 3 Tief verankert | Workflow-Engine wie Temporal oder Argo Workflows | Die Zustandsautomaten sind in einer AWS-eigenen Sprache beschrieben und werden neu gebaut. Entscheidung je Workflow. |
| AWS AppSync | 3 Tief verankert | GraphQL-Server wie Hasura oder Apollo | Die Resolver hängen an AWS-Diensten und werden neu geschrieben. |
| Amazon Cognito | 2 Umziehbar mit Anpassung | Anbieterunabhängige Identitätsplattform (Keycloak, Zitadel) | Beide Systeme laufen parallel. Cognito gibt keine Passwort-Hashes heraus, deshalb wechseln Nutzer schrittweise bei der nächsten Anmeldung. |
| AWS IAM | 2 Umziehbar mit Anpassung | Zugriffsverwaltung der Zielplattform, als Code verwaltet | Berechtigungen werden für die neue Plattform neu formuliert, idealerweise als Code mit Terraform. |
| AWS KMS und Secrets Manager | 2 Umziehbar mit Anpassung | KMS des Zielanbieters oder OpenBao, mit Schlüsseln allein unter Ihrer Kontrolle | Secrets ziehen leicht um. KMS-Schlüssel lassen sich nicht exportieren, die Daten werden daher mit neuen Schlüsseln verschlüsselt. |
| Amazon Redshift | 2 Umziehbar mit Anpassung | ClickHouse oder ein Data Warehouse auf PostgreSQL-Basis | Das meiste SQL lässt sich übernehmen, die Ladestrecken werden angepasst. |
| AWS Glue und Amazon Athena | 2 Umziehbar mit Anpassung | Apache Spark und Trino | Offene Engines. Jobs und Datenkatalog werden darauf neu aufgesetzt. |
| Amazon SageMaker | 2 Umziehbar mit Anpassung | Offene MLOps-Werkzeuge (MLflow, Kubeflow) auf europäischen GPUs | Die Modelle bleiben meist gleich. Training, Deployment und Monitoring werden darum herum neu aufgebaut. |
| Amazon Bedrock | 2 Umziehbar mit Anpassung | Souveräne KI-Plattform mit offenen oder europäischen Modellen | Prompts und Anwendungslogik bleiben, nur der Modell-Endpunkt ändert sich. |
| Amazon CloudFront | 1 Direkt umziehbar | Europäisches CDN | Cache- und Routing-Regeln werden neu angelegt. Die Umstellung selbst ist eine DNS-Änderung. |
| Amazon Route 53 | 1 Direkt umziehbar | DNS bei einem europäischen Anbieter | Zonen lassen sich als Standard-Zonendateien exportieren. Das Routing per Health Check braucht einen Ersatz. |
| Microsoft Azure | |||
| Azure Virtual Machines | 1 Direkt umziehbar | Compute-Instanzen (STACKIT, IONOS, Open Telekom Cloud, plusserver) | Images und Konfigurationen ziehen mit Standardwerkzeugen um. Ein guter Anlass, die Größen neu zu dimensionieren. |
| Azure Kubernetes Service (AKS) | 1 Direkt umziehbar | Managed Kubernetes (STACKIT SKE, Open Telekom Cloud CCE, plusserver) | Manifeste und Helm-Charts laufen weitgehend unverändert weiter. Anbieterspezifische Add-ons wie Load Balancer oder Identitätsanbindungen werden ausgetauscht. |
| Azure Container Apps | 2 Umziehbar mit Anpassung | Managed Kubernetes mit KEDA und Dapr | Basiert auf offenen Komponenten, die auf jedem Kubernetes laufen. Die App-Konfiguration wird neu geschrieben. |
| Azure App Service | 2 Umziehbar mit Anpassung | Container auf Managed Kubernetes oder Managed Hosting wie Mittwald | Jede Anwendung wird einmal containerisiert, Deployment-Slots und Einstellungen werden neu aufgebaut. |
| Azure Functions | 2 Umziehbar mit Anpassung | Funktionen auf Kubernetes (Knative, KEDA) oder einfache Container | Der Code zieht leicht um. Den größten Aufwand machen Trigger, Bindings und Durable Functions. |
| Azure Blob Storage | 2 Umziehbar mit Anpassung | S3-kompatibler Objektspeicher (STACKIT, IONOS, Open Telekom Cloud) | Die Daten selbst ziehen einfach um. Code, der die Blob-API nutzt, wechselt auf die S3-API, meist eine überschaubare Änderung. |
| Azure Managed Disks und Azure Files | 1 Direkt umziehbar | Block- und Dateispeicher beim Zielanbieter | Zieht gemeinsam mit den Servern um, die darauf zugreifen. |
| Azure SQL Database | 1 Direkt umziehbar | Managed SQL Server (STACKIT, IONOS) oder PostgreSQL | Managed SQL Server gibt es auch in Europa, die Lizenzierung sollte geprüft werden. Der Wechsel zu PostgreSQL ist größer, aber verbreitet. |
| Azure Database for PostgreSQL und MySQL | 1 Direkt umziehbar | Managed PostgreSQL oder MySQL (STACKIT, IONOS, Open Telekom Cloud) | Standard-Engines mit bewährten Migrationswerkzeugen. Per Replikation bleibt das Umschaltfenster kurz. |
| Azure Cache for Redis | 1 Direkt umziehbar | Managed Valkey oder Redis (Exoscale, OVHcloud) | Gleiches Protokoll, meist genügt eine Konfigurationsänderung. |
| Azure Cosmos DB | 3 Tief verankert | Neues Datenmodell für PostgreSQL, MongoDB oder Vergleichbares | Bei anderen Anbietern gibt es keine direkte Entsprechung. Meist der aufwendigste Teil des Umzugs, dafür fällt eine der größten Abhängigkeiten weg. |
| Azure Service Bus | 2 Umziehbar mit Anpassung | RabbitMQ oder ein anderer AMQP-Broker | Service Bus spricht AMQP, die Messaging-Muster lassen sich daher gut übertragen. Der Client-Code ändert sich. |
| Azure Event Hubs | 2 Umziehbar mit Anpassung | Apache Kafka | Event Hubs bietet bereits einen Kafka-kompatiblen Endpunkt, das erleichtert den Wechsel. |
| Azure Event Grid | 2 Umziehbar mit Anpassung | Event-Bus auf Basis von Apache Kafka oder NATS | Abonnements und Routing werden neu aufgebaut. |
| Azure Logic Apps | 3 Tief verankert | Workflow-Engine (Temporal) oder Automatisierungstool (n8n) | Low-Code-Workflows hängen an Azure-Konnektoren und werden neu gebaut. Entscheidung je Workflow. |
| Azure Notification Hubs | 2 Umziehbar mit Anpassung | Eigener Push-Server in Europa (etwa Gorush) mit Anbindung an Apple und Google | Notification Hubs leitet Nachrichten nur an die Push-Dienste von Apple und Google weiter. Das übernimmt ein offener Push-Server in Europa, die Geräteregistrierungen ziehen mit. |
| Azure API Management | 2 Umziehbar mit Anpassung | Offenes API-Gateway (Kong, Traefik) oder Kubernetes Ingress | Die Routen ziehen mit um, Richtlinien werden neu geschrieben. |
| Microsoft Entra ID | 3 Tief verankert | Bleibt oft, wo es ist. Sonst Keycloak oder Zitadel | Anwendungen melden sich über offene Standards (OpenID Connect, SAML) an, Entra ID funktioniert also unabhängig davon, wo sie laufen. Ein Wechsel ist eine eigene Entscheidung. |
| Azure Key Vault | 2 Umziehbar mit Anpassung | KMS des Zielanbieters oder OpenBao, mit Schlüsseln allein unter Ihrer Kontrolle | Secrets ziehen leicht um. Schlüssel werden neu erzeugt und die Daten damit neu verschlüsselt. |
| Azure Synapse Analytics | 2 Umziehbar mit Anpassung | ClickHouse oder Apache Spark | Das meiste SQL lässt sich übernehmen, die Pipelines werden angepasst. |
| Azure OpenAI | 2 Umziehbar mit Anpassung | Souveräne KI-Plattform mit offenen oder europäischen Modellen | Prompts und Anwendungslogik bleiben, nur der Modell-Endpunkt ändert sich. |
| Azure Machine Learning | 2 Umziehbar mit Anpassung | Offene MLOps-Werkzeuge (MLflow, Kubeflow) auf europäischen GPUs | Die Modelle bleiben meist gleich. Training, Deployment und Monitoring werden darum herum neu aufgebaut. |
| Azure AI Services (Vision, Speech, Language) | 2 Umziehbar mit Anpassung | Offene Modelle, in Europa gehostet | Jede Schnittstelle wird einzeln ersetzt und die Qualität je Anwendungsfall getestet. |
| Azure Front Door und Azure CDN | 1 Direkt umziehbar | Europäisches CDN | Cache- und Routing-Regeln werden neu angelegt. Die Umstellung selbst ist eine DNS-Änderung. |
| Azure DNS | 1 Direkt umziehbar | DNS bei einem europäischen Anbieter | Zonen lassen sich als Standard-Zonendateien exportieren. |
| Google Cloud | |||
| Compute Engine | 1 Direkt umziehbar | Compute-Instanzen (STACKIT, Exoscale, gridscale) | Images und Konfigurationen ziehen mit Standardwerkzeugen um. Ein guter Anlass, die Größen neu zu dimensionieren. |
| Google Kubernetes Engine (GKE) | 1 Direkt umziehbar | Managed Kubernetes (STACKIT SKE, Exoscale SKS, gridscale) | Manifeste und Helm-Charts laufen weitgehend unverändert weiter. Anbieterspezifische Add-ons wie Load Balancer oder Identitätsanbindungen werden ausgetauscht. |
| Cloud Run | 1 Direkt umziehbar | Container auf Managed Kubernetes mit Knative | Cloud Run basiert auf Knative, die Container laufen also unverändert weiter. Die Integrationen drumherum werden angepasst. |
| App Engine | 2 Umziehbar mit Anpassung | Container auf Managed Kubernetes | Jede Anwendung wird einmal containerisiert, App-Engine-Dienste und Einstellungen werden ersetzt. |
| Cloud Functions | 2 Umziehbar mit Anpassung | Funktionen auf Kubernetes (Knative) oder einfache Container | Der Code zieht leicht um. Den größten Aufwand machen die Trigger und Integrationen drumherum. |
| Cloud Storage | 1 Direkt umziehbar | S3-kompatibler Objektspeicher (STACKIT, Open Telekom Cloud, plusserver) | Cloud Storage bietet eine S3-kompatible Schnittstelle, die Daten ziehen also mit Standardwerkzeugen um. Anwendungen mit Google-Client-Bibliotheken wechseln die Bibliothek. |
| Persistent Disk und Filestore | 1 Direkt umziehbar | Block- und Dateispeicher beim Zielanbieter | Zieht gemeinsam mit den Servern um, die darauf zugreifen. |
| Cloud SQL | 1 Direkt umziehbar | Managed PostgreSQL, MySQL oder SQL Server (STACKIT, IONOS, Open Telekom Cloud) | Standard-Engines mit bewährten Migrationswerkzeugen. Per Replikation bleibt das Umschaltfenster kurz. |
| Memorystore | 1 Direkt umziehbar | Managed Valkey oder Redis (Exoscale, OVHcloud) | Gleiches Protokoll, meist genügt eine Konfigurationsänderung. |
| Firestore und Realtime Database | 3 Tief verankert | Offene Dokument- oder relationale Datenbank (MongoDB, PostgreSQL) | Echtzeit-Synchronisation und Sicherheitsregeln werden mit offenen Bausteinen neu gebaut. Den Aufwand schätzen wir ein, bevor etwas umzieht. |
| Bigtable | 2 Umziehbar mit Anpassung | Apache HBase oder ein Cassandra-kompatibler Speicher | Bigtable unterstützt die HBase-Schnittstelle, das erleichtert den Umzug. Schemas und Zugriffsmuster werden geprüft. |
| Spanner | 3 Tief verankert | PostgreSQL oder eine verteilte SQL-Datenbank | Globale Konsistenz ist eine Google-eigene Funktion. Klären Sie zuerst, ob Sie sie wirklich brauchen. |
| Pub/Sub | 2 Umziehbar mit Anpassung | Apache Kafka oder NATS | Die Messaging-Muster lassen sich gut übertragen. Der Client-Code ändert sich. |
| Cloud Tasks und Workflows | 2 Umziehbar mit Anpassung | Job-Queue oder Workflow-Engine (Temporal, Argo Workflows) | Die Workflows werden in der neuen Engine abgebildet. |
| Apigee | 2 Umziehbar mit Anpassung | Offenes API-Gateway (Kong, Traefik) oder Kubernetes Ingress | Die Routen ziehen mit um, Richtlinien werden neu geschrieben. |
| Firebase Cloud Messaging (Push-Benachrichtigungen) | 2 Umziehbar mit Anpassung | Eigener Push-Server in Europa (etwa Gorush) mit Anbindung an FCM und Apple | Auf den meisten Android-Geräten laufen Push-Nachrichten immer über Google, egal wo Ihr Backend steht. Umziehen kann der sendende Teil, und die Nachrichten lassen sich frei von personenbezogenen Daten halten. |
| Firebase Authentication und Identity Platform | 2 Umziehbar mit Anpassung | Anbieterunabhängige Identitätsplattform (Keycloak, Zitadel) | Nutzer lassen sich samt Passwort-Hashes exportieren, niemand muss ein neues Passwort vergeben. |
| Cloud IAM | 2 Umziehbar mit Anpassung | Zugriffsverwaltung der Zielplattform, als Code verwaltet | Berechtigungen werden für die neue Plattform neu formuliert, idealerweise als Code mit Terraform. |
| Secret Manager und Cloud KMS | 2 Umziehbar mit Anpassung | KMS des Zielanbieters oder OpenBao, mit Schlüsseln allein unter Ihrer Kontrolle | Secrets ziehen leicht um. Schlüssel werden neu erzeugt und die Daten damit neu verschlüsselt. |
| BigQuery | 2 Umziehbar mit Anpassung | ClickHouse bei einem europäischen Anbieter | Meist ein eigenes Migrationsprojekt. Spezialfunktionen, auf die Ihre Berichte angewiesen sind, prüfen wir vorab. |
| Dataflow | 2 Umziehbar mit Anpassung | Apache Beam auf Flink oder Spark | Dataflow nutzt Apache Beam, das auch auf offenen Engines läuft. Die Pipelines lassen sich weitgehend übernehmen. |
| Dataproc | 1 Direkt umziehbar | Apache Spark auf Managed Kubernetes | Open-Source-Jobs für Spark und Hadoop ziehen mit wenig Aufwand um. |
| Vertex AI | 2 Umziehbar mit Anpassung | Offene MLOps-Werkzeuge (MLflow, Kubeflow) auf europäischen GPUs | Die Modelle bleiben meist gleich. Training, Deployment und Monitoring werden darum herum neu aufgebaut. |
| Gemini API | 2 Umziehbar mit Anpassung | Souveräne KI-Plattform mit offenen oder europäischen Modellen | Prompts und Anwendungslogik bleiben, nur der Modell-Endpunkt ändert sich. |
| Firebase Hosting | 1 Direkt umziehbar | Statisches Hosting oder CDN bei einem europäischen Anbieter | Statische Websites ziehen unverändert um. |
| Cloud CDN und Cloud DNS | 1 Direkt umziehbar | Europäisches CDN und DNS | Cache-Regeln werden neu angelegt und Zonen als Standarddateien exportiert. Die Umstellung ist eine DNS-Änderung. |
Die ehrliche Konsequenz: Nicht alles muss umziehen, und nicht alles sollte. Ein guter Umzugsplan beginnt mit der Unterscheidung, was leicht geht, was sich lohnt und was bleiben kann.
Amazon Web Services
Typische Bindungspunkte, passende Zielanbieter und was der Wechsel bei den Datenverkehrskosten verändert.
Microsoft Azure
Datenbanken, Kubernetes, Rechenleistung und KI-Dienste ziehen zu deutschen und europäischen Anbietern, auch Azure-eigene Bausteine wie Cosmos DB oder Azure Functions.
Google Cloud
Warum hier meist die Daten- und KI-Plattformen im Mittelpunkt stehen und wie sie souverän weiterlaufen.
Moderne europäische Cloud-Anbieter liefern hohe Verfügbarkeit, alle relevanten Cloud-Services und häufig niedrigere Gesamtkosten. Für viele Unternehmen sind sie heute eine echte Alternative zu den großen Hyperscalern. Im Vergleich unten stellen Sie zwei beliebige Anbieter direkt gegenüber.
| Kriterium | ExoscaleSchweizEntwicklerfreundlich, stark in der DACH-Region | HetznerDeutschlandAm günstigsten, viel Eigenregie | IONOS CloudDeutschlandBreitestes Portfolio unter deutschem Recht | MittwaldDeutschlandManaged Hosting statt Infrastruktur-Cloud | Open Telekom CloudDeutschlandTelekom-Format bei Größe und Verträgen | OVHcloudFrankreichGrößte Präsenz in Europa | plusserverDeutschlandAuditfeste Compliance-Nachweise | STACKITDeutschlandSouveränität auf Konzernniveau |
|---|---|---|---|---|---|---|---|---|
| Eigentümer | A1 Digital, Teil der A1 Telekom Austria Group | Hetzner Online GmbH, unabhängiges Unternehmen | IONOS SE, Teil von United Internet | Mittwald CM Service, eigentümergeführt, Espelkamp | T-Systems International, Teil der Deutschen Telekom | OVH Groupe, börsennotiert an der Euronext Paris, gegründet in Roubaix | plusserver GmbH, Köln | Schwarz Digits, Teil der Schwarz Gruppe (Lidl, Kaufland) |
| Regionen in Europa | Schweiz, Österreich, Deutschland, Bulgarien, Kroatien | Deutschland (Falkenstein, Nürnberg), Finnland (Helsinki) | Deutschland, Großbritannien, Frankreich, Spanien | Ausschließlich Deutschland | Deutschland (Twin-Core in Biere und Magdeburg), Niederlande, Schweiz | Frankreich, Deutschland, Italien, Polen, Großbritannien, dazu Local Zones in ganz Europa | Vier Rechenzentren in der DACH-Region | Sieben europäische Rechenzentren, Schwerpunkt Deutschland |
| Zertifizierungen | ISO 27001 / 27017 / 27018, SOC 2, BSI C5, CSA STAR | ISO 27001, BSI C5, DSGVO | ISO 27001, BSI C5, DSGVO, kein Weiterverkauf von Daten | ISO 27001 | BSI C5:2020 Typ 2, ISO 27001 / 27017 / 27018 | ISO 27001 / 27017 / 27018 / 27701, SecNumCloud für ausgewählte Private-Cloud-Angebote | ISO 27001 und 9001, BSI C5 Typ 2, ISAE 3402 Typ 2, PCI DSS, IT-Grundschutz | BSI C5, ISO 27001, TÜV SÜD, DSGVO |
| Leistungsumfang |
|
|
|
|
|
|
|
|
| Preismodell | Planbare Festpreise, in allen Regionen gleich | Feste Monatspreise, viel Traffic inklusive, günstigster der acht Anbieter | Nutzungsbasiert mit Savings Plans, deutlich unter den Listenpreisen der Hyperscaler | Hosting-Tarife statt nutzungsbasierter Abrechnung | Pay-as-you-go mit Rabattmodellen und Kapazitätsreservierungen | Stündlich oder monatlich mit Savings Plans, Netzwerk-Traffic inklusive | Preise für Managed Services, Kubernetes ab rund 67 € im Monat | Enterprise-Verträge auf Angebotsbasis statt Self-Service |
| Support | Direkt durch Engineers, aus Europa | Ticket und E-Mail rund um die Uhr, ohne festen Ansprechpartner | Telefon und Ticket, technischer Support rund um die Uhr | Deutschsprachig, auf die Abläufe von Agenturen zugeschnitten | Europäische Teams rund um die Uhr, auf Deutsch und Englisch, kostenlose Beratung | Vier Stufen, bis zu 24/7 mit einer Stunde Reaktionszeit und Technical Account Manager | Managed-Service-Teams aus Deutschland | Enterprise-Support auf Deutsch |
| Ideal für | Produktteams, die in Kubernetes zu Hause sind und eine EU-Zone in der Nähe suchen | Kostengetriebene Workloads und Teams, die ihre Plattform selbst betreiben | Teams, die ein breites Portfolio wie bei einem Hyperscaler suchen, unter deutschem Recht | Agenturen und Freelancer mit Kundenwebsites, kein Ersatz für einen Hyperscaler | Konzerne, die einen Vertrag mit der Telekom und einen großen Servicekatalog wollen | Teams, die Hyperscaler-Breite, GPUs und die meisten Standorte in Europa brauchen | Gesundheitswesen, öffentlicher Sektor und Finanzbranche mit Prüfpflichten | Regulierte Workloads, bei denen Souveränität Chefsache ist |
Wir sind an keinen dieser Anbieter gebunden und erhalten keine Provisionen. Die Empfehlung folgt Ihrem Workload, nicht unserer Partnerliste.
Wer ein neues Haus baut, kopiert nicht den Grundriss des alten. Organisch gewachsene Cloud-Umgebungen tragen Ballast: überdimensionierte Ressourcen, vergessene Dienste, Doppelstrukturen. Der Umzug ist der eine Moment, in dem das Aufräumen nicht extra kostet. Deshalb migrieren wir nicht eins zu eins, sondern nehmen mit, was sich bewährt hat, und korrigieren, was seit Jahren stört.
PHASE 1
2 bis 6 Wochen, je nach Umfang
Ergebnis — Zielarchitektur, Umzugsreihenfolge und aufgebaute Zielumgebung, während alles Bestehende normal weiterläuft.
PHASE 2
3 bis 12 Monate, je nach Umgebung
Ergebnis — System für System zieht um: erst parallel betrieben und geprüft, dann umgeschaltet. Kein Stichtag, an dem alles auf einmal passieren muss, keine Betriebsunterbrechung.
PHASE 3
Laufend, nach Ihrem Modell
Ergebnis — Ihr Team übernimmt mit Dokumentation und Schulung, oder wir betreiben weiter mit klaren Service-Zusagen. Beides ist von Anfang an so angelegt, dass Sie die Wahl behalten.
Diese Großunternehmen vertrauen uns
Erhalten Sie innerhalb von 24 Stunden eine erste Einschätzung zu Aufwand, Architektur und Umsetzungsmöglichkeiten.
Keine Sorge, die von Ihnen angegebenen Daten werden nur für geschäftliche Zwecke gespeichert. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie.
Möchten Sie lieber direkt mit unserem Experten sprechen? Bringen Sie die Frage mit, die Ihnen Ihr Auditor, Ihr größter Kunde oder Ihre Cloud-Rechnung stellt. Sie erhalten eine ehrliche erste Einschätzung, auch wenn sie lautet: Bei Ihnen ist das derzeit kein dringendes Thema.
Miki
Senior Consultant
[email protected]
Die meisten Antworten finden Sie in unseren FAQ zur digitalen Souveränität, kurz und ohne Umschweife.
Das hängt von Umfang und Kategorie-Mix ab, deshalb nennen wir keine Pauschale. Nach der Cloud-Analyse erhalten Sie einen Festpreisrahmen je Umzugswelle. In die Wirtschaftlichkeitsrechnung gehören auch die dauerhaft niedrigeren laufenden Kosten, die den Einmalaufwand in vielen Fällen innerhalb überschaubarer Zeit ausgleichen.
Ja. Zertifizierte Rechenzentren, zugesicherte Verfügbarkeiten und redundante Standorte sind bei den etablierten Anbietern Standard, auf ihnen laufen Handelskonzerne, Banken und Behörden produktiv. Der relevante Unterschied ist nicht die Betriebsqualität, sondern Portfolio-Breite und Rechtsraum. Beides klären wir vorab in der Analyse.
Nein, und oft ist das auch nicht sinnvoll. Häufig ziehen die Systeme um, bei denen Datenhoheit und Kosten am meisten bringen, während Unkritisches bleibt, wo es ist. Das Ergebnis ist eine bewusste Aufteilung statt einer Alles-oder-nichts-Entscheidung.
Ein einzelnes Backend-System liegt erfahrungsgemäß bei drei bis sechs Monaten, größere Umgebungen mit mehreren Systemen bei sechs bis zwölf Monaten oder darüber. Die Cloud-Analyse liefert vorab einen belastbaren Rahmen für Ihren konkreten Fall.
Nein. Wir bauen die Zielumgebung parallel auf und schalten System für System um, erst nachdem es dort geprüft läuft. Ihre Anwendungen und Ihre Kunden merken vom Umzug im Normalfall nichts.
Wir nutzen ein bewährtes und in der Industrie häufig angewandtes vierdimensionales Modell als Bewertungsraster bei jedem Souveränitäts-Check.
Erfahren Sie, warum sie für Unternehmen immer wichtiger wird und welche Rolle Cloud, Daten und KI dabei spielen.
Wie abhängig ist Ihr Unternehmen von Cloud-Anbietern und Software-Herstellern? Der Selbsttest für CTOs zeigt Ihren Reifegrad bei digitaler Souveränität.
