Dual-Vendor-Entflechtung: Hyperscaler-Silos ohne Betriebsunterbrechung entkoppeln

Die strategische Ausrichtung vieler europäischer IT-Landschaften glich im vergangenen Jahrzehnt einer riskanten Wette auf eine einzige Karte. Im Bestreben, operative Komplexität zu reduzieren und kurzfristige Mengenrabatte auszuschöpfen, verlagerten Vorstände nahezu ihr gesamtes digitales Anwendungsportfolio zu einem einzigen marktbeherrschenden Public-Cloud-Anbieter. Was in frühen Strategiepapieren als effiziente Konsolidierung erschien, entpuppt sich in der heutigen Betriebspraxis als schwerwiegendes strukturelles Klumpenrisiko.

Einseitige Preisanpassungen, kurzfristig geänderte Lizenzmetriken und geopolitische Rechtsunsicherheiten schränken die kaufmännische und technische Handlungsfähigkeit europäischer Unternehmen spürbar ein. Gleichzeitig verschärfen europäische Regulierungen wie der Digital Operational Resilience Act (DORA) und die NIS-2-Richtlinie den Handlungsdruck auf die Geschäftsleitung. Aufsichtsbehörden verlangen heute den belastbaren Nachweis, dass der Ausfall oder die Sperrung eines einzelnen Cloud-Providers nicht zum Stillstand geschäftskritischer Wertschöpfungsketten führt.

Wer seine gesamte Unternehmensarchitektur exklusiv auf proprietäre Dienste von Amazon Web Services (AWS) oder Microsoft Azure zuschneidet, verliert nicht nur jede Hebelwirkung am Verhandlungstisch, sondern riskiert auch empfindliche Beanstandungen in der Wirtschaftsprüfung. Dieser Leitfaden analysiert die technischen Bindungsmechanismen moderner Hyperscaler-Silos und zeigt Schritt für Schritt, wie CIOs und Chefarchitekten eine belastbare Dual-Vendor-Entflechtung im laufenden Betrieb umsetzen.

Die Architektur der Abhängigkeit: Warum proprietäre PaaS-Dienste den Cloud-Austritt blockieren

In der Frühphase der Cloud-Migration nutzten Unternehmen überwiegend standardisierte virtuelle Maschinen und einfachen Blockspeicher (IaaS). Solche Workloads ließen sich mit überschaubarem Aufwand zwischen verschiedenen Rechenzentren verschieben. Die eigentliche Abhängigkeit entsteht erst auf der darüberliegenden Plattform-Schicht (PaaS) sowie bei serverlosen Architekturen, die von den Hyperscalern gezielt mit hohen Wechselhürden versehen wurden.

Im AWS-Ökosystem manifestiert sich diese Bindung vor allem durch Dienste wie Amazon DynamoDB, AWS Lambda, Amazon Aurora sowie proprietäre Ereignisbusse wie SQS und EventBridge. Sobald Entwicklungsteams ihre Geschäftslogik direkt in Hunderte isolierte Lambda-Funktionen gießen und diese eng mit DynamoDB-Tabellen, spezifischen IAM-Rollen und CloudFormation-Templates verknüpfen, ist der Programmcode außerhalb der AWS-Rechenzentren nicht mehr lauffähig.

Ein ganz ähnliches Bild zeigt sich in stark Microsoft-zentrierten Umgebungen. Dort führt die tiefe Kopplung von Applikationen an Azure Cosmos DB, Azure Service Bus und vor allem an proprietäre Identitäts- und Berechtigungsstrukturen rund um Microsoft Entra ID zu einer faktischen Immobilität. Jede Datenbankabfrage und jeder API-Aufruf setzt herstellerspezifische SDKs und Token-Formate voraus, die sich nicht ohne monatelange Neuprogrammierung auf einen Zweitanbieter übertragen lassen.

Praxistaugliche Dual-Vendor-Architekturen verzichten deshalb bewusst auf synchrone Schreibzugriffe über Providergrenzen hinweg. Stattdessen setzen sie auf eine klare Trennung: Ein primärer Cloud-Stack trägt die produktive Schreiblast auf Basis quelloffener Standards, während ein zweiter, unabhängiger Infrastruktur-Provider über asynchrone Datenreplikation im Warm-Standby-Modus (Pilot Light) jederzeit innerhalb weniger Minuten die volle Produktionslast übernehmen kann.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Sovereignty by Design im Enterprise-Einsatz, zu Betriebsrat Mitbestimmung im Enterprise-Einsatz sowie zu HR-Tech im Enterprise-Einsatz.

Zustandsdaten entkoppeln: PostgreSQL, Apache Kafka und Ceph RGW als offenes Fundament

Der kritische Pfad jeder Cloud-Entflechtung verläuft nicht über die zustandslosen Applikationsserver, sondern über die Datenhaltung (Data Gravity). Solange Terabytes an Transaktions-, Dokumenten- und Objektdaten in proprietären Cloud-Speichern gefangen sind, bleibt jede Container-Portabilität wirkungslos. Eine tragfähige Dual-Vendor-Strategie beginnt daher zwingend mit der Standardisierung der Daten- und Messaging-Schicht.

Relationale Datenhaltung und Change Data Capture (CDC)

Anstelle proprietärer Cloud-Datenbanken wie Amazon Aurora oder Azure SQL mit herstellerspezifischen Erweiterungen etablieren souveräne Architekturteams natives PostgreSQL als universellen Datenbankstandard. Durch den Einsatz Kubernetes-nativer Operatoren wie CloudNativePG oder Patroni lässt sich ein hochverfügbares PostgreSQL-Cluster samt automatischem Failover, Point-in-Time-Recovery und Streaming-Replikation sowohl auf einem US-Hyperscaler als auch auf europäischen Sovereign-Cloud-Plattformen exakt identisch betreiben.

Um bestehende Datenbestände im laufenden Betrieb ohne Ausfallzeit aus einem Hyperscaler-Silo herauszulösen, hat sich das Strangler-Fig-Muster in Verbindung mit Change Data Capture (CDC) bewährt. Hierbei liest Debezium fortlaufend das Transaktionsprotokoll (Write-Ahead-Log) der Quelldatenbank aus und streamt jede Datenänderung in Echtzeit über Apache Kafka in die PostgreSQL-Zielinstanz beim Zweitprovider.

„Wahre Cloud-Portabilität entscheidet sich nicht im Container-Image, sondern in der Datenbankschicht: Erst wer seine Zustandsdaten aus proprietären PaaS-Fesseln befreit und über offene Replikationspfade synchronisiert, besitzt am Verhandlungstisch eine reale Ausstiegsoption.“

Auf der Objektspeicherebene bildet die S3-API zwar den De-facto-Industriestandard, doch binden Funktionen wie AWS-spezifische KMS-Verschlüsselung oder proprietäre Lifecycle-Regeln viele Unternehmen dennoch an das Original. Durch den Aufbau eines S3-kompatiblen Object Storage auf Basis von Ceph RGW (RADOS Gateway) im Zweitrechenzentrum lassen sich Backup-Archive, Data-Lake-Bestände und Anwendungsdaten über offene Replikationsmechanismen herstellerneutral spiegeln.

Abstraktionsschichten mit OpenTofu, Crossplane und Envoy

Damit Infrastruktur-Teams nicht zwei völlig unterschiedliche Werkzeugketten für zwei Provider pflegen müssen, wird die Bereitstellung konsequent abstrahiert. Auf der Ebene von Infrastructure-as-Code (IaC) ersetzt das unter der Linux Foundation betreute OpenTofu proprietäre Werkzeuge wie AWS CloudFormation oder Azure Bicep. Mit modular aufgebauten OpenTofu-Skripten werden Netzwerk-Topologien, Sicherheitsgruppen und Speicher-Volumes deklarativ verwaltet.

Noch einen Schritt weiter geht Crossplane als universelle Steuerungsebene (Universal Control Plane) auf Basis von Kubernetes. Plattform-Teams definieren in Crossplane eigene, unternehmensweite Composite Resource Definitions (XRDs), etwa für eine standardisierte Applikationsdatenbank oder einen Message-Broker. Entwickler fordern diese Ressource über ein einfaches YAML-Manifest an, während Crossplane im Hintergrund entscheidet, ob die Ressource auf dem primären Hyperscaler oder auf einer europäischen Sovereign-Cloud-Stack-Umgebung (SCS) provisioniert wird.

Für die serverlose Ausführung von ereignisgesteuertem Programmcode tritt Knative auf Kubernetes-Basis an die Stelle von AWS Lambda oder Azure Functions. Kombiniert mit Envoy als herstellerunabhängigem API-Gateway und BGP-Anycast-Routing an der Netzwerkkante lässt sich der produktive Nutzerverkehr in fein dosierten Canary-Schritten (ein Prozent, fünf Prozent, 25 Prozent bis hin zu 100 Prozent) ohne Unterbrechung zwischen beiden Providern verschieben.

Architekturvergleich: Monolithischer Single-Vendor-Stack versus Dual-Vendor-Entflechtung

Für die Investitionsentscheidung im Vorstand und IT-Architekturboard ist entscheidend, wie sich eine entkoppelte Dual-Vendor-Architektur im Vergleich zum klassischen Single-Cloud-Monopol und zu unkoordinierten Multi-Cloud-Inseln verhält. Denn ein bloßes Nebeneinander mehrerer Cloud-Anbieter ohne verbindende Abstraktionsschicht verdoppelt lediglich den Betriebsaufwand, ohne die Abhängigkeit für die einzelne Applikation zu senken.

Die folgende Bloomberg-Radar-Matrix bewertet die fünf zentralen Architekturdimensionen zwischen proprietärer Hyperscaler-Bindung und einer standardisierten Dual-Vendor-Plattform:

Der direkte Architekturvergleich zeigt deutlich, wo der strategische Mehrwert entsteht: Nicht im gleichzeitigen Betrieb beliebiger Cloud-Dienste, sondern in der bewussten Beschränkung auf offene Schnittstellen der Cloud Native Computing Foundation (CNCF). Sobald Datenbanken, Identitätsdienste (etwa über Keycloak und OpenID Connect) sowie Container-Laufzeiten vom darunterliegenden IaaS-Anbieter abgekoppelt sind, schrumpft der Hyperscaler zum austauschbaren Ressourcenlieferanten.

Sektorale Einsatzfelder und 5-Jahres-Wirtschaftlichkeit unter dem EU Data Act

In der europäischen Wirtschaft treiben derzeit vier Leitbranchen die Dual-Vendor-Entflechtung mit besonderem Nachdruck voran. In der Kreditwirtschaft und im Zahlungsverkehr verlangen die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) und die Europäische Bankenaufsichtsbehörde (EBA) belastbare Multi-Provider-Konzepte für Kernbankensysteme, die auf einer souveränen IT-Infrastruktur und Cloud-Exit-Architektur aufbauen.

Parallel dazu entkoppeln Automobilhersteller und Tier-1-Zulieferer ihre vernetzten Fahrzeug-Telemetriedaten sowie ihre Forschungs- und Entwicklungsplattformen, um kritisches geistiges Eigentum vor extraterritorialen Datenzugriffen nach dem US CLOUD Act zu schützen. Auch Betreiber kritischer Infrastrukturen (KRITIS) im Energiesektor und große E-Commerce-Handelskonzerne verteilen ihre Kundenportale auf zwei unabhängige Plattformen, um sowohl bei transatlantischen Störungen als auch in Spitzenlastzeiten wie dem Weihnachtsgeschäft handlungsfähig zu bleiben.

EU Data Act (Art. 23 bis 29) und die Abschaffung der Egress-Gebühren bis Januar 2027

Ein entscheidender wirtschaftlicher Wendepunkt für jede Dual-Vendor-Kalkulation ist die europäische Datenverordnung, Verordnung (EU) 2023/2854 (EU Data Act). Bislang nutzten Hyperscaler hohe Datenausgangsgebühren (Egress Fees), um den Datenabzug zu einem Zweitanbieter oder das Zurückholen von Daten ins eigene Rechenzentrum kaufmännisch unattraktiv zu machen. Die Artikel 23 bis 29 des EU Data Act schieben dieser Praxis einen gesetzlichen Riegel vor.

Bereits seit Inkrafttreten der Übergangsregeln dürfen Cloud-Provider Wechselgebühren nur noch in Höhe der unmittelbaren technischen Selbstkosten weitergeben. Ab dem 12. Januar 2027 gilt gemäß Artikel 25 des EU Data Act ein vollständiges Verbot jeglicher Wechselentgelte und Egress-Gebühren beim Anbieterwechsel. Ergänzend verpflichtet Artikel 26 die Anbieter offener Plattformdienste dazu, kostenfreie Schnittstellen und Exportwerkzeuge bereitzustellen, um die funktionale Äquivalenz in der Zielumgebung sicherzustellen.

Für die Fünfjahres-TCO-Betrachtung (Total Cost of Ownership) verändert diese Gesetzeslage die Amortisationsrechnung grundlegend. Während der initiale Aufbau einer Crossplane- und OpenTofu-Abstraktionsschicht für ein mittelgroßes Enterprise-Portfolio einmalige Plattform-Engineering-Kosten von rund 180.000 bis 250.000 Euro erfordert, sinken die laufenden Datenübertragungskosten durch den EU Data Act und dedizierte Interconnects an Knotenpunkten wie dem DE-CIX drastisch.

Der größte finanzielle Hebel entsteht jedoch unmittelbar bei der nächsten Vertragsverlängerung mit dem Primär-Hyperscaler. Unternehmen, die im Rahmen ihrer BATNA-Verhandlungsmacht im Enterprise-Agreement-Renewal technisch demonstrieren können, dass 30 Prozent ihrer containerisierten Workloads binnen weniger Wochen auf einen europäischen Zweitprovider umziehen können, erzielen regelmäßig Rabattverbesserungen von 20 bis 35 Prozent. Bei einem jährlichen Cloud-Spend von zwei Millionen Euro amortisiert sich die Entflechtungsarchitektur damit bereits nach 14 bis 18 Monaten.

Make-or-Buy im Platform Engineering und regulatorische Pflichten unter DORA

Der Aufbau einer herstellerneutralen Abstraktionsschicht ist keine reine Software-Entscheidung, sondern eine Frage der organisatorischen Betriebsreife. Je nach Größe des internen Platform-Engineering-Teams und der Kritikalität der verarbeiteten Daten wählen europäische CIOs zwischen drei klar abgegrenzten Bereitstellungsmodellen für ihre Dual-Vendor-Landschaft.

Erstens (Sovereign-Hybrid-Split): Unternehmen betreiben elastische, öffentlich zugängliche Frontend-Dienste und globale Content-Delivery-Workloads weiterhin auf einem großen US-Hyperscaler, verlagern jedoch sämtliche zustandsbehafteten Kerndatenbanken, Schlüsselverwaltungssysteme (KMS) und personenbezogenen Kundendaten dauerhaft auf einen BSI-C5-testierten europäischen Cloud-Provider oder in eigene Colocation-Racks. Eine detaillierte Gegenüberstellung der Betriebskosten liefert unser 5-Jahres-TCO-Vergleich zwischen Eigenbetrieb und Hyperscalern.

Zweitens (Föderierter SCS-Verbund): Regulierte Branchen, öffentliche Auftraggeber und Unternehmensgruppen bündeln ihre Infrastruktur auf einer standardisierten Community Cloud nach den offenen Spezifikationen des Sovereign Cloud Stack (SCS). Da mehrere unabhängige europäische Rechenzentrumsbetreiber exakt denselben OpenStack-, Ceph- und Kubernetes-Unterbau bereitstellen, genießen Unternehmen volle Dual-Vendor-Redundanz ohne jeglichen Übersetzungsaufwand zwischen proprietären Cloud-APIs.

Drittens (Multi-Cloud-Abstraktion): Global agierende Industrie- und Handelskonzerne, die auf weltweite Rechenzentrumsregionen zweier großer Hyperscaler angewiesen sind, etablieren ein zentrales Internal Developer Platform (IDP) Team. Dieses Team kapselt beide Cloud-Anbieter vollständig hinter Crossplane, OpenTofu und Managed-Kubernetes-Clustern ab und untersagt den Applikationsteams per Architektur-Richtlinie die direkte Einbindung herstellerspezifischer PaaS-Datenbanken oder proprietärer Serverless-Dienste.

Unabhängig vom gewählten Pfad erfüllt diese Architektur präzise die gesetzlichen Vorgaben der Artikel 28 bis 30 der DORA-Verordnung (Verordnung (EU) 2022/2554). Artikel 28 verpflichtet Unternehmen zur strengen Begrenzung von IKT-Konzentrationsrisiken sowie zum Vorhalten dokumentierter, technisch getesteter Ausstiegsstrategien, während Artikel 30 vertragliche Unterstützungs- und Übergangspflichten des Cloud-Anbieters im Kündigungs- oder Störungsfall zwingend vorschreibt.

Der 4-Phasen-Umsetzungsfahrplan: Ohne Betriebsunterbrechung aus dem Cloud-Silo

Eine erfolgreiche Dual-Vendor-Entflechtung erfolgt niemals als riskante Big-Bang-Abschaltung an einem einzigen Wochenende. Stattdessen hat sich in der Unternehmenspraxis ein phasenweiser Umbau über sechs bis zwölf Monate bewährt, der bestehende PaaS-Abhängigkeiten schrittweise ablöst und jede Phase durch messbare Meilensteine absichert.

Phase 1 (Monat 1 bis 2): Abhängigkeits-Audit, PaaS-Klassifizierung und Architektur-Stopp

Zu Beginn inventarisiert das Architektur-Team sämtliche genutzten Cloud-Dienste, IAM-Verflechtungen, Datenflüsse und monatlichen Egress-Volumina. Jede Applikation wird nach ihrem Lock-in-Schweregrad klassifiziert: Zustandslose Container-Workloads bilden die erste Migrationswelle, während eng gekoppelte DynamoDB-, Cosmos-DB- oder Lambda-Anwendungen für das gezielte Refactoring eingeplant werden. Gleichzeitig verhängt der CIO einen verbindlichen Architektur-Stopp für die Neueinführung proprietärer PaaS-Dienste ohne offenes Open-Source-Äquivalent.

Phase 2 (Monat 3 bis 5): Aufbau der universellen Control Plane mit OpenTofu und Crossplane

In der zweiten Phase errichtet das Platform-Engineering-Team die herstellerneutrale Steuerungsebene. Sowohl beim Primär-Hyperscaler als auch beim ausgewählten europäischen Zweitprovider werden standardisierte CNCF-Kubernetes-Cluster bereitgestellt und über GitOps-Pipelines (ArgoCD oder Flux) synchronisiert. Parallel dazu ersetzt ein zentrales Identitätsmanagement auf Basis von OpenID Connect (Keycloak) die direkte Applikationsbindung an proprietäre Cloud-IAM-Verzeichnisse, während OpenTofu und Crossplane die Bereitstellung von Netzwerk-, Zertifikats- und Speicherressourcen vereinheitlichen.

Phase 3 (Monat 6 bis 8): Entkopplung der Datenhaltung und asynchrone CDC-Replikation

Nun folgt der Kernschritt zur Auflösung der Data Gravity. Proprietäre Datenbankdienste werden schrittweise auf hochverfügbare PostgreSQL-Cluster (CloudNativePG) und S3-kompatible Ceph-RGW-Objektspeicher umgestellt. Über Debezium und Apache Kafka richtet das Datenbankteam eine kontinuierliche Change-Data-Capture-Pipeline ein, die alle Transaktionen nahezu in Echtzeit vom Primär-Provider in die Standby-Datenbank des Zweitanbieters spiegelt und dort automatisiert auf Prüfsummen- und Schema-Konsistenz validiert.

Phase 4 (Monat 9 bis 12): Canary-Traffic-Shifting, DORA-Exit-Test und Vertrags-Neuverhandlung

In der Abschlussphase wird das globale Routing über Envoy-Gateways und BGP-Anycast scharfgeschaltet. Im Rahmen eines angekündigten Chaos-Engineering- und DORA-Resilienztests leitet das Betriebsteam schrittweise fünf, 25 und schließlich 100 Prozent des produktiven Datenverkehrs ausgewählter Kernapplikationen auf den Zweitprovider um. Das erfolgreiche Umschaltprotokoll dient einerseits als revisionssicherer Nachweis gegenüber der Aufsichtsbehörde und bildet andererseits die unmittelbare Verhandlungsgrundlage für die Senkung der Committed-Spend-Volumina beim Primär-Hyperscaler.

Fünf Kontrollfragen für Vorstand und IT-Leitung vor der Dual-Vendor-Entflechtung

1. Welcher Anteil unseres Cloud-Budgets fließt in proprietäre PaaS-Dienste ohne offenes Äquivalent?

Fordern Sie vom Cloud-Center-of-Excellence eine präzise Aufschlüsselung der monatlichen Rechnung nach reinem IaaS-Compute und proprietären Plattformdiensten wie DynamoDB, Aurora, Cosmos DB oder nativen Serverless-Funktionen. Übersteigt der PaaS-Anteil 25 Prozent der Gesamtkosten, besteht eine akute technische Ausstiegsbarriere, die durch Architektur-Leitplanken begrenzt werden muss.

2. Wie hoch sind die realen Datenausgangsgebühren (Egress) bis zum Stichtag des EU Data Act im Januar 2027?

Lassen Sie vor dem Aufbau kontinuierlicher Replikationsstrecken kalkulieren, welches Datenvolumen täglich zwischen Primär- und Sekundär-Provider synchronisiert wird. Nutzen Sie die Übergangsregelungen der Artikel 23 bis 29 des EU Data Act aktiv in Ihren Vertragsgesprächen, um schon vor dem vollständigen Egress-Verbot im Januar 2027 die Streichung von Datentransferaufschlägen durchzusetzen.

3. Können sich unsere Applikationen auch bei einem Ausfall von Microsoft Entra ID oder AWS IAM authentifizieren?

Eine Dual-Vendor-Architektur ist wertlos, wenn im Störungsfall zwar der Zweitprovider läuft, die Benutzeranmeldung und die Service-to-Service-Kommunikation jedoch weiterhin an den ausgefallenen Identitätsdienst des Primär-Hyperscalers gekoppelt sind. Prüfen Sie, ob ein unabhängiger, föderierter Identity-Provider auf OpenID-Connect- und SAML-Basis als primäre Authentifizierungsinstanz vor beide Clouds geschaltet ist.

4. Haben wir unsere DORA-Ausstiegsstrategie in den letzten zwölf Monaten technisch unter Realbedingungen getestet?

Aufsichtsbehörden akzeptieren unter DORA Artikel 28 keine theoretischen Konzepte mehr, die lediglich beschreiben, wie man im Krisenfall migrieren würde. Stellen Sie sicher, dass mindestens einmal jährlich ein dokumentierter Live-Umschalttest (Failover-Drill) einer geschäftskritischen Applikation auf den Zweitprovider inklusive gemessener Recovery Time Objective (RTO) und Recovery Point Objective (RPO) stattfindet.

5. Wie verknüpfen wir den technischen Entflechtungsfortschritt zeitlich mit dem nächsten Enterprise-Agreement-Renewal?

Synchronisieren Sie den Projektplan von Phase 3 und Phase 4 zwingend mit den Kündigungs- und Verlängerungsfristen Ihrer bestehenden Hyperscaler-Rahmenverträge. Nur wenn der Einkauf sechs Monate vor Vertragsende belegen kann, dass ein produktionsreifer Zweitstack bereits erste Lasten trägt, lässt sich die Entflechtung in substanzielle Rabatte und flexible Abnahmeverpflichtungen ummünzen.

Strategisches Fazit: Handlungsautonomie durch herstellerneutrale Entkopplung

Die systematische Entflechtung monolithischer Hyperscaler-Silos ist weit mehr als eine technische Vorsichtsmaßnahme gegen seltene Großstörungen. In einem Cloud-Markt, der von wenigen außereuropäischen Oligopolisten dominiert wird, entscheidet die Architektur über die kaufmännische Souveränität des gesamten Unternehmens. Wer seine Applikationslandschaft unreflektiert mit proprietären PaaS-Datenbanken und herstellerspezifischen Steuerungs-APIs verschmilzt, gibt die Kontrolle über seine langfristige Kostenstruktur aus der Hand.

Unternehmen, die ihre Datenhaltung hingegen konsequent auf offene Industriestandards wie PostgreSQL, Apache Kafka und Ceph RGW stützen und ihre Infrastruktur deklarativ über OpenTofu, Crossplane und Kubernetes abstrahieren, kehren dieses Machtverhältnis um. Sie erfüllen die strengen Resilienzanforderungen von DORA, NIS-2 und BSI C5 aus dem regulären Betrieb heraus, profitieren unmittelbar vom Wegfall der Wechselgebühren unter dem EU Data Act und sichern sich dauerhafte Entscheidungsfreiheit über ihre digitale Wertschöpfung.

Häufig gestellte Fragen (FAQ) zur Dual-Vendor-Entflechtung