Wyjście z SaaS i migracja danych – co powinno regulować porozumienie?

Od Mallbutiken · Informacje zweryfikowane 1 października 2026 r. · Czas czytania: ok. 8 minut

Dobre wyjście z usługi SaaS zaczyna się w momencie podpisywania umowy – a nie wtedy, gdy wypowiedzenie zostało już wysłane. Umowa powinna umożliwiać rezygnację z usługi bez sprawiania, że dane, metadane, integracje czy dostęp do systemu staną się narzędziem przetargowym. Dlatego od samego początku należy uregulować formaty eksportu, okres eksportu, wsparcie migracyjne, koszty, dostęp po wypowiedzeniu oraz potwierdzone usunięcie danych.

Dlaczego warunki wyjścia powinny znaleźć się w oryginalnej umowie SaaS

Gdy usługa chmurowa staje się częścią codziennej pracy, zależność od niej szybko rośnie. Dane klienta łączą się z kontami użytkowników, uprawnieniami, historią, przepływami pracy, integracjami, raportami i konfiguracją. Jeśli kwestia eksportu pozostanie nieuregulowana, zmiana dostawcy może okazać się znacznie droższa i wolniejsza, niż przewidywano.

Wyjście z usługi należy zatem traktować jako element architektury usługi oraz jej warunków handlowych. Najpierw przeczytaj Umowy SaaS – 12 kwestii do uregulowania, aby uzyskać pełny obraz, oraz przewodnik po SLA dotyczący dostępności i poziomów usług.

1. Zdefiniuj dokładnie, jakie dane klient może eksportować

„Klient jest właścicielem swoich danych” to za mało, jeśli nie można ich uzyskać w użytecznej formie. Należy określić, jakie kategorie wchodzą w skład eksportu:

• główne rejestry i dokumenty,
• historia i dane transakcyjne,
• komentarze i załączniki,
• logi audytowe lub inna istotna historia dzienników,
• informacje o użytkownikach i uprawnieniach, tam gdzie jest to istotne,
• konfiguracje, taksonomie i pola niestandardowe,
• relacje między rekordami i inne zależności.

Należy również ustalić, czy eksport może być dokonywany na bieżąco w trakcie obowiązywania umowy, czy tylko w momencie wypowiedzenia. Ciągły eksport ogranicza uzależnienie od dostawcy (vendor lock-in) i może poprawić gotowość operacyjną.

2. Format, metadane i API – to decyduje o użyteczności eksportu

Plik ZIP z tysiącami rozłącznych dokumentów może technicznie być eksportem, ale może być trudny do zmigrowania. Dlatego należy uregulować kwestie formatu czytelnego maszynowo, kodowania znaków, formatu dat, kluczy/identyfikatorów, relacji, metadanych oraz dokumentacji struktury danych.

3. Określ okres wyjścia i dalszy dostęp

Umowa powinna określać, jak długo usługa będzie dostępna po wypowiedzeniu i na jakich warunkach. Jeśli dostęp zostanie zablokowany w dniu wygaśnięcia umowy, klient może być zmuszony do przeprowadzenia całej migracji z wyprzedzeniem.

Należy zatem ustalić, na przykład:

• kiedy można zażądać końcowego eksportu,
• ile czasu ma dostawca na jego dostarczenie,
• jak długo pozostaje dostęp (do odczytu lub pełny),
• czy eksport może zostać powtórzony w razie błędów,
• co się dzieje, jeśli migracja opóźni się z winy dostawcy.

4. Wsparcie migracyjne i koszty

Sformułowania typu „dostawca będzie udzielał niezbędnego wsparcia” mogą prowadzić do sporów, gdy przyjdzie co do czego. Należy zdefiniować, jaka pomoc jest w cenie, a za jaką pobierane są osobne opłaty. Może to dotyczyć zadań eksportowych, warsztatów technicznych, mapowania danych, wsparcia API lub rozwiązywania problemów podczas weryfikacji.

Jeśli wsparcie jest rozliczane na bieżąco, umowa powinna określać zasady wyceny lub stawkę godzinową, ewentualny limit kosztów oraz sposób składania zamówień. Klient musi mieć możliwość oszacowania kosztów wyjścia przed podjęciem decyzji o zmianie dostawcy.

5. Usuwanie, kopie zapasowe i RODO

Kiedy dostawca SaaS występuje w roli podmiotu przetwarzającego dane osobowe, umowa powierzenia przetwarzania danych powinna regulować, jak dane osobowe są traktowane po ustaniu zlecenia. Zgodnie z art. 28 ust. 3 lit. g RODO, podmiot przetwarzający powinien, zgodnie z wyborem administratora, usunąć lub zwrócić dane osobowe oraz usunąć istniejące kopie, chyba że prawo wymaga dalszego przechowywania danych.

Urząd Ochrony Danych (IMY) podkreśla również, że usuwanie powinno odbywać się w sposób bezpieczny. W praktyce umowa powinna zatem obejmować:

• dane pierwotne,
• kopie i pamięć podręczną (cache),
• kopie zapasowe i standardowe wycofywanie z cyklu tworzenia kopii,
• wymogi prawne, które mogą wymagać dalszego przechowywania,
• certyfikat usunięcia danych lub inne potwierdzenie, tam gdzie jest to istotne.

Zobacz również przewodnik po umowach powierzenia przetwarzania danych.

6. Kontrolowane zamykanie uprawnień i integracji

Proces wyjścia obejmuje również klucze API, połączenia SSO, konta serwisowe, webhooks i uprawnienia administratora. Należy utworzyć listę czynności (checklistę), aby ani dostawca, ani klient nie pozostawili zbędnego aktywnego dostępu po migracji.

Należy ustalić, kto odpowiada za cofnięcie kluczy, eksport logów audytowych, zamykanie integracji i weryfikację, czy stare połączenia już nie działają.

7. Przetestuj wyjście, zanim stanie się pilne

Klauzula eksportowa ma ograniczoną wartość, jeśli nikt nie wie, czy eksport faktycznie działa. W przypadku usług krytycznych dla biznesu klient może regularnie testować mniejszy eksport lub przeprowadzać ćwiczenia typu „table-top” dotyczące zmiany dostawcy.

Sprawdź, czy format pliku jest czytelny, czy relacje są zachowane i czy czas eksportu odpowiada potrzebom operacyjnym. Wynik można powiązać z analizą wpływu na biznes (BIA) i planem ciągłości działania, jeśli usługa SaaS jest kluczowa.

Lista kontrolna wyjścia z SaaS

• Jakie kategorie danych powinny być możliwe do wyeksportowania?
• Czy formaty, metadane i relacje są zdefiniowane?
• Czy dostępny jest eksport przez API i czy istnieją udokumentowane ograniczenia?
• Jak szybko dostarczany jest końcowy eksport?
• Jak długo klient ma dostęp do usługi po wypowiedzeniu?
• Czy wsparcie migracyjne jest w cenie i ile kosztuje?
• Czy klient może zweryfikować kompletność eksportu?
• Kiedy usuwane są dane produkcyjne?
• Jak zarządzane są kopie zapasowe i inne kopie?
• Czy dostawca może dostarczyć potwierdzenie usunięcia danych?
• Jak zamykane są klucze API, integracje i konta?
• Czy zdolność do wyjścia z usługi została przetestowana przed wystąpieniem potrzeby?