Zmiana chmury po Data Act: czy dostawca może doliczyć opłatę za wyprowadzenie danych i kiedy switching charges mają zniknąć całkowicie?

Firma przenosi 30 TB danych z jednej chmury do drugiej. Dotychczasowy dostawca wystawia na koniec rachunek za transfer wychodzący i nazywa go „data egress fee”. Po wejściu w stosowanie Data Act taki rachunek nie zawsze jest już dopuszczalny. Od 12 września 2025 r. obowiązują unijne zasady ułatwiające zmianę dostawcy usług przetwarzania danych, a 12 stycznia 2027 r. nastąpi kolejny, znacznie ostrzejszy etap: opłaty za sam proces zmiany dostawcy mają zniknąć.

Nie oznacza to jednak, że każda migracja stanie się bezkosztowa. Data Act rozdziela kilka kategorii, które na fakturze mogą wyglądać podobnie: opłatę za zmianę dostawcy, transfer wychodzący danych, normalny abonament, karę za wcześniejsze rozwiązanie umowy i dodatkowe prace migracyjne zamówione przez klienta. Tylko część z nich zostanie wyzerowana.

To rozróżnienie jest najważniejsze przy planowaniu wyjścia z AWS, Microsoft Azure, Google Cloud albo mniejszej europejskiej chmury. Sam napis „migration fee” na fakturze niczego jeszcze nie przesądza. Liczy się, za co faktycznie pobierana jest opłata.

Do 12 stycznia 2027 r. dostawca może naliczyć opłatę, ale nie według dowolnego cennika

Data Act, czyli rozporządzenie (UE) 2023/2854, wszedł w życie 11 stycznia 2024 r., a jego zasadnicze przepisy są bezpośrednio stosowane od 12 września 2025 r. w całej Unii Europejskiej, również w Polsce.

Artykuł 29 przewiduje okres przejściowy dotyczący kosztów zmiany dostawcy. Od 11 stycznia 2024 r. do 12 stycznia 2027 r. dostawca może stosować tzw. reduced switching charges, czyli obniżone opłaty za zmianę dostawcy. Jest jednak istotny limit: opłata nie może przekraczać kosztów poniesionych przez dostawcę i bezpośrednio związanych z konkretną zmianą dostawcy.

To zasadnicza różnica w stosunku do klasycznego cennika. Dostawca nie powinien traktować migracji jak kolejnego produktu, na którym dowolnie ustala marżę. Przy ocenie faktury trzeba więc zadać dwa pytania:

• czy dana pozycja rzeczywiście wynika z procesu przejścia do innego dostawcy albo do własnej infrastruktury;

• czy jej wysokość odpowiada kosztowi bezpośrednio związanemu z tym procesem.

Do switching charges Data Act wprost zalicza data egress charges, czyli opłaty za wyprowadzenie danych przez sieć z infrastruktury dotychczasowego dostawcy do systemu innego operatora albo do infrastruktury on-premises klienta.

Jeżeli więc dostawca pobiera opłatę właśnie dlatego, że klient eksportuje swoje dane w ramach migracji, nie wystarczy argument: „taką mamy stawkę za każdy GB wychodzącego transferu”. W okresie przejściowym punktem odniesienia jest limit wynikający z rzeczywistych kosztów bezpośrednio związanych ze zmianą.

Rozporządzenie nie ustanawia przy tym unijnej stawki, np. 0,01 euro za GB, ani tabeli określającej maksymalną cenę za 1 TB. Nie ma ustawowej ceny za eksport danych. Dlatego przy większej fakturze rozsądnym pierwszym ruchem jest żądanie rozbicia naliczonej kwoty i wskazania, jakie koszty dostawca uznaje za bezpośrednio związane z migracją.

Trzeba też uważać na inną pułapkę. Nie każdy transfer wychodzący z chmury jest automatycznie „switchingiem”. Data Act definiuje zmianę dostawcy jako proces przejścia do usługi innego dostawcy albo do lokalnej infrastruktury ICT. Zwykły transfer sieciowy wykonywany podczas codziennego korzystania z usługi nie staje się bezpłatny tylko dlatego, że dane opuszczają centrum danych.

To istotne choćby przy architekturach multi-cloud, replikacji danych albo regularnym przesyłaniu dużych wolumenów do systemów zewnętrznych. Trzeba ustalić, czy transfer jest częścią formalnego procesu wyjścia, czy zwyczajnym elementem świadczonej usługi.

Od 12 stycznia 2027 r. switching charge wynosi zero, ale migracja nadal ma swoją procedurę

Data graniczna jest konkretna: 12 stycznia 2027 r.

Od tego dnia dostawca objęty art. 29 Data Act nie może obciążać klienta opłatą za proces zmiany dostawcy. Zakaz obejmuje również opłaty za wychodzący ruch danych stanowiący element takiego procesu.

W praktyce firma planująca dużą migrację na przełomie 2026 i 2027 r. powinna więc zwrócić uwagę nie tylko na dzień wypowiedzenia umowy, ale także na moment, w którym wykonywany będzie płatny eksport danych. Przy transferze liczonym w dziesiątkach lub setkach terabajtów różnica może być finansowo istotna.

Nie można jednak sprowadzać Data Act wyłącznie do faktury. Rozporządzenie narzuca również zasady samego procesu zmiany dostawcy.

Umowa powinna przewidywać m.in.:

• maksymalny okres wypowiedzenia wynoszący dwa miesiące przed rozpoczęciem procesu zmiany;

• zasadniczo maksymalnie 30 dni kalendarzowych okresu przejściowego na przeprowadzenie switchingu;

• co najmniej 30 dni kalendarzowych na pobranie danych po zakończeniu uzgodnionego okresu przejściowego;

• wskazanie kategorii danych i aktywów cyfrowych możliwych do przeniesienia;

• informacje dotyczące procedur, metod, formatów oraz znanych ograniczeń technicznych migracji;

• obowiązek wspierania klienta w realizacji jego strategii wyjścia.

Jeżeli zakończenie migracji w standardowych 30 dniach jest technicznie niewykonalne, dostawca musi poinformować klienta o tym w ciągu 14 dni roboczych od otrzymania żądania zmiany, uzasadnić problem i wskazać alternatywny okres przejściowy. Ten alternatywny okres nie może przekroczyć siedmiu miesięcy.

Klient ma ponadto możliwość jednorazowego przedłużenia okresu przejściowego, jeżeli potrzebuje więcej czasu.

To ma znaczenie szczególnie przy złożonych środowiskach. Przeniesienie kilku maszyn wirtualnych i storage’u jest czymś innym niż migracja środowiska opartego na zarządzanych bazach danych, funkcjach serverless, kolejce zdarzeń, własnych mechanizmach IAM oraz usługach analitycznych charakterystycznych dla jednego hyperscalera. Data Act ogranicza vendor lock-in, ale nie usuwa różnic technologicznych między chmurami.

W modelu IaaS dostawca źródłowy powinien podjąć rozsądne działania umożliwiające uzyskanie po migracji równoważności funkcjonalnej dla wspólnych funkcji. Nie oznacza to obowiązku przebudowania całej aplikacji klienta pod architekturę konkurenta.

W przypadku innych usług, w tym wielu rozwiązań PaaS i SaaS, istotne stają się otwarte interfejsy oraz możliwość eksportu danych. Jeśli dla danego rodzaju usługi nie obowiązuje odpowiednia wspólna specyfikacja albo norma interoperacyjności, na żądanie klienta dane eksportowalne powinny być udostępnione w uporządkowanym, powszechnie używanym i nadającym się do odczytu maszynowego formacie.

Największa niedogodność pozostaje po stronie klienta: bezpłatne wyprowadzenie danych nie oznacza automatycznej kompatybilności aplikacji. Migracja 100 TB może kosztować po stronie starego dostawcy zero euro za switching, a równocześnie wymagać setek godzin pracy administratorów, DevOpsów, programistów i integratora.

Co dostawca nadal może naliczać po 12 stycznia 2027 r.

Najczęstszy błąd będzie polegał na założeniu, że od 12 stycznia 2027 r. dostawca starej chmury nie może wystawić już żadnej faktury związanej z odejściem klienta. To nieprawda.

Standardowa opłata za korzystanie z usługi nie jest switching charge. Jeżeli podczas okresu przejściowego środowisko nadal działa, umowa pozostaje aktywna i klient korzysta z zasobów, normalne opłaty za usługę mogą być naliczane aż do zakończenia umowy.

To prowadzi do bardzo praktycznego kosztu, którego Data Act nie likwiduje: przez pewien czas firma może płacić równocześnie za stare i nowe środowisko. Przy migracji systemu produkcyjnego jest to często rozsądniejsze niż gwałtowne wyłączenie starej infrastruktury, ale trzeba uwzględnić taki okres podwójnych kosztów w budżecie.

Drugą kategorią jest kara lub rekompensata za wcześniejsze rozwiązanie umowy zawartej na czas określony. Definicja switching charge w Data Act wprost oddziela ją od opłaty za zmianę dostawcy. Samo wyzerowanie switching charges nie unieważnia więc automatycznie zobowiązania wynikającego np. z przedterminowego zerwania kontraktu terminowego. Rozporządzenie zakłada możliwość stosowania proporcjonalnych konsekwencji wcześniejszego rozwiązania takich umów.

Trzecia kategoria to usługi dodatkowe zamówione przez klienta. Jeżeli dostawca wykonuje prace wykraczające poza obowiązki, które Data Act nakłada na niego przy switchingu, może żądać za nie zapłaty, jeżeli klient je zamówił i zaakceptował wcześniej cenę.

Przykład: obowiązkowe udostępnienie danych albo wymaganej dokumentacji nie powinno zostać przemianowane na „premium migration support” tylko po to, aby pojawiła się nowa faktura. Inaczej wygląda sytuacja, gdy klient zamawia dodatkowych inżynierów na nocne okno migracyjne, indywidualne testy, przygotowanie niestandardowych skryptów czy pomoc wykraczającą poza zakres obowiązkowej obsługi.

Dostawca nie powinien też przerzucać na klienta kosztu swojego podwykonawcy tylko dlatego, że sam zdecydował się zlecić część swoich obowiązkowych prac migracyjnych na zewnątrz.

Jest jeszcze ważny wyjątek, o którym łatwo zapomnieć. Art. 29 nie obejmuje wszystkich usług bez wyjątku. Obowiązek likwidacji switching charges nie ma zastosowania do usług, których większość głównych funkcji została zbudowana na zamówienie dla konkretnego klienta albo których wszystkie komponenty opracowano dla niego indywidualnie, jeżeli jednocześnie usługa nie jest oferowana na szeroką skalę w katalogu dostawcy.

Jeszcze dalej idzie wyjątek dotyczący usług świadczonych przez ograniczony czas jako nieprodukcyjna wersja przeznaczona do testowania i oceny. W takim przypadku obowiązki całego rozdziału Data Act dotyczącego zmiany dostawcy zasadniczo nie mają zastosowania. Dostawca powinien jednak przed zawarciem umowy poinformować klienta, które obowiązki zostały wyłączone.

Dlatego przed zakwestionowaniem pozycji na fakturze trzeba wykonać cztery sprawdzenia:

• ustalić, czy kupiona usługa jest usługą przetwarzania danych objętą Data Act;

• sprawdzić, czy nie zachodzi wyjątek dla rozwiązania tworzonego indywidualnie albo środowiska testowego;

• oddzielić switching charge od abonamentu, wcześniejszego rozwiązania kontraktu i dodatkowo zamówionych usług;

• przy migracji wykonywanej przed 12 stycznia 2027 r. sprawdzić, czy naliczona kwota nie przekracza kosztów dostawcy bezpośrednio związanych z konkretnym switchingiem.

Dopiero po tej analizie wiadomo, czy pozycja „egress”, „migration”, „exit fee” albo „transition support” jest prawidłowa. Nazwa użyta w cenniku nie rozstrzyga sprawy. Liczy się charakter świadczenia i moment naliczenia opłaty.

FAQ: opłaty za zmianę chmury po Data Act

Czy od 12 stycznia 2027 r. eksport danych z chmury będzie zawsze bezpłatny?
Nie. Zakaz dotyczy switching charges, w tym data egress charges związanych z procesem zmiany dostawcy lub przejścia do infrastruktury lokalnej. Nie oznacza automatycznego zniesienia wszystkich opłat za każdy wychodzący transfer danych wykonywany podczas normalnego korzystania z chmury.

Czy dostawca może pobrać opłatę za migrację jeszcze w 2026 r.?
Tak, ale w przypadku usługi objętej art. 29 jest to opłata ograniczona do kosztów dostawcy bezpośrednio związanych z danym procesem zmiany. Nie jest to otwarta zgoda na dowolną marżę migracyjną.

Czy Data Act obejmuje tylko nowe umowy zawarte po 12 września 2025 r.?
Nie w przypadku zasad zmiany dostawcy z rozdziału VI. Dla tych regulacji nie ustanowiono analogicznego generalnego wyłączenia starych umów. Dostawca nie może więc założyć, że sam fakt podpisania kontraktu kilka lat wcześniej wyłącza obowiązki dotyczące switchingu.

Czy od 2027 r. znika kara za wcześniejsze zakończenie trzyletniego kontraktu?
Nie. Kara lub proporcjonalna rekompensata za wcześniejsze rozwiązanie umowy jest odrębną kategorią od switching charge. Trzeba ją oceniać osobno na podstawie umowy oraz właściwego prawa.

Czy dostawca może pobierać pieniądze za pomoc swoich specjalistów podczas migracji?
Za wykonanie obowiązków, które Data Act nakłada na dostawcę w ramach switchingu, po 12 stycznia 2027 r. nie powinien powstawać switching charge. Odpłatne mogą natomiast pozostać dodatkowe prace wykraczające poza te obowiązki, zamówione przez klienta za wcześniej zaakceptowaną cenę.

Ile może trwać zmiana dostawcy?
Umowa może przewidywać maksymalnie dwumiesięczny okres wypowiedzenia rozpoczynający proces zmiany. Następnie standardowy maksymalny okres przejściowy wynosi 30 dni kalendarzowych. Gdy 30 dni jest technicznie niewykonalne, dostawca musi powiadomić klienta w ciągu 14 dni roboczych i może wskazać uzasadniony okres alternatywny nieprzekraczający siedmiu miesięcy.

Czy po migracji można od razu usunąć konto u starego dostawcy?
Nie należy robić tego automatycznie. Data Act przewiduje co najmniej 30-dniowy okres umożliwiający pobranie danych po zakończeniu uzgodnionego okresu przejściowego. W praktyce przed usunięciem starego środowiska trzeba potwierdzić kompletność danych, integralność backupów, działanie aplikacji oraz brak zależności od starego API, IAM, DNS czy usług zarządzanych.

Czy Data Act gwarantuje, że aplikacja będzie działała identycznie po przejściu z jednej chmury do drugiej?
Nie. Przepisy ułatwiają przenoszenie danych i ograniczają bariery techniczne oraz kontraktowe, ale nie usuwają różnic między usługami AWS, Azure, Google Cloud czy innych dostawców. Im więcej aplikacja wykorzystuje usług charakterystycznych dla jednego ekosystemu, tym większa część rzeczywistego kosztu migracji może przypadać na przebudowę po stronie klienta.

Pierwszy krok przed migracją jest więc prosty: nie zaczynaj od negocjowania ceny za transfer. Najpierw weź umowę i aktualny cennik, oznacz każdą pozycję jako standardową usługę, wcześniejsze rozwiązanie kontraktu, dodatkową usługę albo switching charge i sprawdź, kiedy dokładnie nastąpi eksport danych. Jeżeli transfer przypada po 12 stycznia 2027 r. i jest elementem objętej Data Act zmiany dostawcy, pierwszym błędem do usunięcia z kalkulacji jest założenie, że stary dostawca może nadal doliczyć zwykłą opłatę egress tylko dlatego, że wcześniej znajdowała się w jego cenniku.

Więcej informacji na: https://takieprawo.pl