Der EU Data Act gilt seit dem 12. September 2025. Für Cloud- und andere Datenverarbeitungsdienste verändert sich am 12. Januar 2027 ein wichtiger Kostenpunkt: Anbieter dürfen für den Wechselprozess keine Wechselentgelte mehr verlangen. Bis dahin dürfen reduzierte Wechselentgelte höchstens die unmittelbar mit dem Wechsel verbundenen Kosten des Anbieters abdecken.
Kostenlos wird ein Cloud-Exit 2027 dadurch trotzdem nicht. Standard-Serviceentgelte, die Folgen einer vorzeitigen Vertragsbeendigung, die eigene Migrationsarbeit, der Parallelbetrieb, neue Architektur und der Zielanbieter bleiben eigene Kostenblöcke. FinOps und Procurement sollten sie schon jetzt auseinanderhalten, statt alles unter „Egress Fee“ abzulegen.
Was 2027 tatsächlich wegfällt
Artikel 29 der Verordnung (EU) 2023/2854 regelt die schrittweise Abschaffung von Wechselentgelten. Gemeint sind Entgelte, die der Quellanbieter für den Wechselprozess auferlegt. Der Text unterscheidet sie ausdrücklich von Standard-Serviceentgelten und Sanktionen wegen vorzeitiger Kündigung.
| Kostenblock | Behandlung ab 12. Januar 2027 | Prüfnachweis |
|---|---|---|
| Wechselentgelt des Quellanbieters | Darf für den Wechselprozess nicht mehr erhoben werden | Vertrag, Preisliste und Abschlussrechnung |
| Reguläre Nutzung während der Transition | Bleibt ein Standard-Serviceentgelt | Nutzungsdaten und Laufzeitplan |
| Vorzeitige Vertragsbeendigung | Wird nicht automatisch durch Artikel 29 beseitigt | Kündigungs- und Commitment-Klauseln |
| Interne Migration | Bleibt beim Kunden | Projektplan, Arbeitsaufwand und Dienstleisterangebote |
| Zielplattform und Re-Architektur | Bleiben Teil des Business Case | Zielarchitektur und Zielpreise |
| Parallelbetrieb | Bleibt reale Doppelnutzung | Cutover-Plan und technische Abhängigkeiten |
An dieser Trennung hängt der größte Teil der FinOps-Arbeit. Fehlt sie, lässt sich hinterher weder prüfen, ob ein Entgelt richtig eingeordnet wurde, noch, ob sich die Migration so gerechnet hat wie geplant.
Den Vertrag vor der Rechnung prüfen
Der Data Act regelt für Datenverarbeitungsdienste Vertragsbedingungen, Wechselunterstützung und Informationspflichten. Ob und wie das für einen konkreten Vertrag gilt, müssen Juristen beantworten. Die Kostenarbeit kann darauf aber nicht warten, deshalb brauchen FinOps und Procurement schon vorher eine saubere Bestandsaufnahme.
Pro Vertrag gehören mindestens folgende Felder in das Review:
- betroffener Service und Vertragspartner;
- Vertragsende, Kündigungsfrist und maximale Übergangsfrist;
- Standard-Serviceentgelte während der Transition;
- ausgewiesene Wechselentgelte und deren Berechnungsgrundlage;
- Commitments, Mindestabnahmen und vorzeitige Beendigung;
- exportierbare Daten und digitale Assets;
- zugesagte Unterstützung und Zuständigkeit;
- Link auf die aktuelle Anbieterinformation und Prüfdatum.
Eine interne Kostenstellenbezeichnung reicht nicht, um etwas als Wechselentgelt einzustufen. Strittige Positionen sollten Legal oder Procurement gegen Vertrag und Verordnung prüfen.
Einen Exit als eigenes Kostenszenario modellieren
Belastbar wird ein Exit-Business-Case, wenn er drei Szenarien über denselben Funktionsumfang und denselben Zeitraum vergleicht:
- Weiterbetrieb: bestehende Architektur, Commitments und erwartete Nutzung.
- Wechsel: Quellbetrieb, Parallelphase, Migration, Zielbetrieb und Restverpflichtungen.
- Neu verhandeln: Weiterbetrieb mit neuen Konditionen oder geänderter Architektur.
Halten Sie Einmalkosten und Run Rate auseinander. Das Ziel kann im Betrieb günstiger sein und sich wegen Migration und übrig gebliebener Commitments trotzdem erst nach einer Weile rechnen. Auch der umgekehrte Fall kommt vor: Ein Team nimmt eine höhere Run Rate für weniger Risiko oder bessere Portabilität in Kauf. Das ist legitim, solange es als Entscheidung dokumentiert und nicht als Einsparung verkauft wird.
| Modellfeld | Inhalt |
|---|---|
| Bewertungszeitraum | Ein gemeinsamer Zeitraum für alle Szenarien |
| Quellkosten | Nutzung, Support und reguläre Gebühren bis zum Ende |
| Wechselkosten | Nur Kosten, die unmittelbar dem Wechselprozess zugeordnet werden |
| Kundenprojekt | Engineering, Datenvalidierung, Tests, Security und Projektsteuerung |
| Parallelbetrieb | Doppelte Nutzung samt Support und Lizenzen |
| Rest-Commitments | Nicht mehr genutzte Mindestabnahmen oder Rabatte mit Laufzeit |
| Zielkosten | Nutzung, Support, Betrieb und neue Commitments |
| Risikopuffer | Benannte Unsicherheiten mit Owner, nicht pauschale Prozentzahl |
Messpunkte vor dem Cutover festlegen
Ohne Baseline wird nach der Migration jede Kostenänderung zur Diskussion. Schließen Sie vor dem Start mindestens einen vollständigen Abrechnungszeitraum ab und sichern Sie:
- Nutzungsmengen und Kostendefinition je Service;
- tatsächliche, amortisierte und effektive Kosten, soweit relevant;
- genutzte Rabatte und offene Commitments;
- Datenvolumen und Datenflüsse, die exportiert werden müssen;
- Betriebsaufwand, der im Ziel entfällt oder neu entsteht;
- Leistungs- und Verfügbarkeitsanforderungen für den Vergleich.
Legen Sie außerdem fest, wann der Wechsel als abgeschlossen gilt. Artikel 25 sieht grundsätzlich einen maximalen Übergangszeitraum von 30 Kalendertagen vor, erlaubt aber unter bestimmten Umständen eine alternative Frist. Diese rechtliche Frist ist etwas anderes als die Parallelphase, die Engineering für einen sicheren Cutover braucht, und beides wird leicht verwechselt. Legen Sie die zwei Zeitachsen mit Legal und Engineering nebeneinander.
Die Abschlussrechnung kontrollieren
Nach dem Cutover reicht es nicht, wenn Finance nur die erste Rechnung des neuen Anbieters prüft. Stimmen Sie vier Dinge ab:
- Letzte Quellrechnung gegen Nutzung und Vertragsende.
- Ausgewiesene Wechselentgelte gegen Vertrag und geltenden Stichtag.
- Rest-Commitments gegen die vor dem Wechsel dokumentierte Exposure-Liste.
- Erste Zielrechnung gegen die freigegebene Zielarchitektur und Preisliste.
Jede Abweichung bekommt einen Owner und eine Klasse: Menge, Preis, Architektur, Timing, einmalige Migration oder ungeklärt. So bleibt der Wechsel im Monatsreport als Wechsel erkennbar und verschwimmt nicht mit normalen Kostenbewegungen.
Was Teams 2026 erledigen sollten
- Verträge und Provider-Informationen inventarisieren.
- Wechselentgelte von regulärer Nutzung und Kündigungskosten trennen.
- Commitments mit Laufzeit über Januar 2027 sichtbar machen.
- Exportierbare Daten, Formate, Schnittstellen und Abhängigkeiten testen.
- Einen repräsentativen Exit für einen begrenzten Scope proben.
- Baseline, Cutover-Kriterien und Abschlussabstimmung definieren.
- Legal für Rechtsauslegung und Procurement für strittige Entgelte benennen.
Das alles ist kein Plädoyer für einen schnellen Anbieterwechsel. Am Ende steht ein Exit-Modell, das auch jemand anderes prüfen kann, mit Preis, Vertrag und technischer Umsetzung sauber getrennt.
Ein Wechsel in eine getrennte souveräne Partition wirft dieselben Vergleichsfragen auf; siehe AWS European Sovereign Cloud: die Kostenfragen vor einer Migration. Vor und nach der Umstellung halten Kostenberichte, gruppiert nach Konto und Service, beide Zeiträume vergleichbar.
Quellen und Prüfgrenze
Primärquelle ist die Verordnung (EU) 2023/2854, insbesondere Kapitel VI und Artikel 29, geprüft am 6. September 2026. Dieser Beitrag beschreibt eine Kosten- und Nachweisstruktur und ist keine Rechtsberatung. Anwendbarkeit, Vertragsauslegung und Streitfragen gehören zu qualifizierter rechtlicher Prüfung.