Dlaczego firmy przechodzą z on‑premise na SaaS i gdzie zaczynają się prawne schody
Motywacje biznesowe: od „posiadania” do „korzystania”
Przejście z licencji on‑premise na model SaaS zwykle nie zaczyna się od działu prawnego, tylko od biznesu i IT. Zarząd widzi, że konkurencja wdraża nowe rozwiązania w tygodnie, a nie w miesiące. IT ma dość utrzymywania przestarzałych serwerów. Finansom podoba się perspektywa zamiany dużych wydatków inwestycyjnych (CAPEX) na przewidywalne opłaty operacyjne (OPEX). Na poziomie slajdów w prezentacji wszystko wygląda logicznie.
Model SaaS obiecuje kilka kluczowych korzyści:
elastyczność – szybkie dodawanie i odejmowanie użytkowników, skalowanie mocy i funkcji;
brak konieczności utrzymywania infrastruktury – serwery, bazy danych, kopie zapasowe i aktualizacje spadają na dostawcę;
szybsze wdrożenia – konfiguracja w przeglądarce zamiast instalacji na setkach stacji;
stały dostęp do nowych funkcji – zamiast drogich i rzadkich projektów upgrade’u.
To wszystko jest prawdą, ale pod jednym warunkiem: migracja z licencji on‑premise do SaaS jest przeprowadzona świadomie, z kontrolą nad umowami, zakresem praw do użytkowania i kosztami. W przeciwnym wypadku firma szybko wchodzi w strefę szarej odpowiedzialności i rosnących wydatków, których nikt nie planował.
Konsekwencje dla licencjonowania i zgodności
W świecie on‑premise organizacja kupuje najczęściej licencję wieczystą, czyli prawo do korzystania z konkretnej wersji oprogramowania bez ograniczenia w czasie. Płaci osobno za utrzymanie (maintenance), upgrade’y czy wsparcie. W modelu SaaS firma opłaca prawo do korzystania z usługi w określonym okresie – najczęściej rocznym lub miesięcznym. Relacja zmienia się z „kupuję produkt” na „korzystam z usługi” i to ma bardzo konkretne skutki:
Po pierwsze, znikają proste granice techniczne. Przy on‑premise licencja jest związana z liczbą instalacji, rdzeni procesora, serwerów. W SaaS granicą jest zazwyczaj liczba użytkowników, rodzaj planu, ilość danych, liczba transakcji. Łatwo zgubić kontrolę, kiedy biznes samodzielnie zamawia dodatkowe subskrypcje kartą firmową.
Po drugie, odpowiedzialność za zgodność się przesuwa, ale nie znika. Dostawca SaaS odpowiada za infrastrukturę, zabezpieczenia fizyczne, często również za część konfiguracji bezpieczeństwa. Natomiast to nadal organizacja pozostaje administratorem danych w rozumieniu RODO, odpowiada za poprawne nadanie uprawnień, polityki retencji danych i zgodność wykorzystania z umową licencyjną.
Gdzie najczęściej dochodzi do konfliktu z prawnikami i finansami
Praktyka pokazuje, że napięcie wokół przejścia z on‑premise na SaaS pojawia się zwykle w trzech miejscach:
brak jasnych kryteriów opłacalności – biznes widzi „niską miesięczną opłatę”, finanse widzą „roczną umowę z automatycznym przedłużeniem i rosnącą liczbą kont”;
rozmycie odpowiedzialności – IT zakłada, że skoro to chmura, to dostawca zadba o wszystko, dział prawny zakłada, że ktoś przeczytał umowę, a nikt faktycznie nie ma całościowego obrazu ryzyk;
ignorowanie istniejących zobowiązań licencyjnych – organizacja przechodzi na SaaS, ale nie zamyka poprawnie licencji on‑premise, narażając się na audyt lub płacąc de facto dwa razy.
Konsekwencje bywają dotkliwe. Jedna z firm produkcyjnych wdrożyła system SaaS do zarządzania dokumentacją, ale „profilaktycznie” zostawiła działające środowisko on‑premise, na wypadek gdyby chmura się „nie sprawdziła”. Projekt się powiódł, jednak nikt nie odłączył starych licencji. Przez dwa lata firma płaciła za utrzymanie obu rozwiązań, bo rezygnacja z maintenance była obciążona dodatkowymi warunkami, o których pamiętał tylko stary integrator.
Przyspieszona migracja a ryzyko audytu
Drugi przykład to organizacja usługowa, która po zmianie właścicielskiej została zmuszona do szybkiego przejścia na wspólną chmurową platformę grupy. Zespół projektowy zignorował zapisy o audycie licencji w umowach on‑premise, zakładając, że „przecież i tak to wyłączymy”. Producent wykorzystał moment migracji, by uruchomić audyt końcowy, w trakcie którego wykazano kilka nieprawidłowości w licencjach testowych i szkoleniowych. Koszt porozumienia ugodowego praktycznie skasował korzyści z pierwszego roku migracji.
W obu scenariuszach źródłem problemu nie był SaaS sam w sobie, ale brak uporządkowanego podejścia: analizy stanu licencji, przeglądu umów i spójnej strategii przełączenia z on‑premise na model usługowy.
Źródło: Pexels | Autor: RDNE Stock project
Różnice między licencją on‑premise a SaaS – jak zmienia się ryzyko i odpowiedzialność
Wieczysta vs czasowa: inne myślenie o prawie do korzystania
Licencja on‑premise w klasycznej formie to prawo do korzystania z określonej wersji oprogramowania, zazwyczaj bez ograniczenia w czasie. Można ją utrzymywać przez lata, nawet po zakończeniu wsparcia producenta. W modelu SaaS prawo do korzystania jest ściśle związane z okresem opłaconej subskrypcji. Po jej wygaśnięciu organizacja traci dostęp do usługi, a często także do danych w wygodnym formacie.
To fundamentalna zmiana z punktu widzenia ryzyka:
w on‑premise zagrożeniem jest brak aktualizacji i wsparcia, ale system wciąż działa;
w SaaS zagrożeniem jest utrata lub ograniczenie dostępu w razie sporu, opóźnienia w płatnościach lub zmian warunków przez dostawcę.
Decyzja o migracji powinna uwzględniać, jak krytyczne procesy są obsługiwane przez dane narzędzie i jakie mechanizmy awaryjne (np. eksport danych, system zapasowy) są realnie dostępne.
Instalacja lokalna vs usługa – zmiana zakresu kontroli
Przy oprogramowaniu on‑premise organizacja ma fizyczną kontrolę nad serwerami, bazami danych oraz konfiguracją środowiska. Może dostosować zabezpieczenia do własnych standardów, ale też sama bierze na siebie pełną odpowiedzialność za ich właściwe wdrożenie i utrzymanie.
W SaaS dostawca zapewnia infrastrukturę, storage, kopie zapasowe, monitoring i znaczną część zabezpieczeń. Firma-klient konfiguruje głównie warstwę aplikacyjną: role, uprawnienia, procesy biznesowe. Ryzyko techniczne (np. awarii dysku, pożaru w serwerowni) w dużej mierze przenosi się na dostawcę, ale w zamian organizacja traci możliwość ingerencji w wiele aspektów środowiska.
Ta zmiana bywa złudnie uspokajająca. Łatwo uznać, że skoro dostawca deklaruje certyfikaty ISO czy zgodność z SOC 2, to „wszystko jest załatwione”. Tymczasem większość incydentów bezpieczeństwa w usługach SaaS wynika z błędnej konfiguracji po stronie klienta – nadmiernie szerokich uprawnień, braku kontroli nad kontami uprzywilejowanymi, niewygaszonych kont po odejściu pracownika.
Prawa do użytkowania: funkcje, użytkownicy, terytorium
Modele licencjonowania w SaaS opierają się zazwyczaj na kilku parametrach:
rodzaj planu (np. Basic, Pro, Enterprise) – różne poziomy funkcji i limitów;
liczba użytkowników – najczęściej liczona jako konta imienne lub równoczesne sesje;
limity ilościowe – miejsce na dane, liczba transakcji, API calls;
terytorium – prawo do korzystania w danym kraju lub globalnie;
ograniczenia branżowe – np. zakaz wykorzystania w sektorach wysokiego ryzyka czy w krytycznej infrastrukturze bez dodatkowych umów.
Przy on‑premise wiele z tych ograniczeń jest albo nieobecnych, albo ma charakter czysto teoretyczny (np. zakaz użycia poza określonym regionem, którego nikt praktycznie nie jest w stanie zweryfikować). W SaaS ślad użycia jest z natury bardziej mierzalny. Dostawca widzi, ilu użytkowników aktywnie korzysta z usługi, z jakich krajów następuje logowanie, jak intensywnie wykorzystywane są API. To zwiększa szansę na szybkie wykrycie naruszeń licencji.
Rozkład odpowiedzialności: dostawca vs klient
Przy przejściu z on‑premise na SaaS kluczowe jest zdefiniowanie, kto za co odpowiada. Uproszczony podział wygląda zwykle tak:
dostawca SaaS – infrastruktura (serwery, storage, sieć), podstawowe zabezpieczenia techniczne, kopie zapasowe, ochrona przed atakami na poziomie platformy, zgodność z określonymi normami (np. ISO 27001);
klient – konfiguracja aplikacji, polityki haseł, zarządzanie użytkownikami i uprawnieniami, integracje z innymi systemami, treść danych, przestrzeganie przepisów branżowych.
Teoretycznie granice te są zapisane w umowie SaaS i dokumentach towarzyszących (SLA, DPA, polityki bezpieczeństwa). Praktycznie jednak często nikt w organizacji nie łączy tych zapisów z procesami wewnętrznymi. Dział compliance zakłada, że IT wdroży odpowiednie procedury. IT zakłada, że to użytkownicy będą odpowiedzialni za świadome korzystanie z danych. W efekcie powstaje luka, w której „wszyscy są odpowiedzialni”, czyli nikt konkretny.
SaaS z elementami on‑prem: hybrydy, agent lokalny, connectory
Coraz więcej rozwiązań określanych jako SaaS wymaga instalacji dodatków w lokalnym środowisku – agentów, gatewayów, connectorów integracyjnych. Z licencyjnego punktu widzenia sytuacja robi się wtedy mniej oczywista.
Przykładowo:
aplikacja do backupu SaaS, która wymaga lokalnego agenta na serwerach plików;
system bezpieczeństwa działający w chmurze, ale z lokalnym komponentem monitorującym ruch sieciowy;
platforma integracyjna, gdzie core działa w chmurze, ale integracje on‑premise wymagają dedykowanych konektorów.
W takich przypadkach część zasad licencjonowania nadal obowiązuje w klasycznej formie. Agent może być licencjonowany per host, per instancja, per rdzeń. Connector może być ograniczony co do liczby obsługiwanych systemów źródłowych. Przeoczenie tych zapisów prowadzi do typowego błędu: założenia, że skoro to „chmurowe”, to problem licencji serwerowych znika. Nie zawsze tak jest – i to trzeba bardzo precyzyjnie zweryfikować w dokumentacji.
Audyt licencyjny przed migracją – co trzeba wiedzieć, zanim wyłączy się serwery
Dlaczego audyt przed migracją do SaaS jest koniecznością, a nie „fanaberią”
Audyt licencyjny przed przejściem z on‑premise na SaaS pełni trzy funkcje:
bilans licencji – rzetelne ustalenie, z czego organizacja realnie korzysta i jakie ma do tego prawo;
identyfikacja ryzyka kar i dopłat – wykrycie ewentualnych nieprawidłowości, zanim zrobi to producent w formalnym audycie;
podstawa do negocjacji – twarde dane, na których można oprzeć rozmowy o przejściu na SaaS, programach konwersji licencji czy rabatach.
Bez takiego audytu migracja przypomina przeprowadzkę bez otwierania szaf: wszystko jest „mniej więcej” jasne, ale przy pierwszej kontroli okazuje się, że są tam rzeczy, za które trzeba dopłacić, lub których w ogóle nie wolno było mieć.
Jak zebrać dane: praktyczna inwentaryzacja
Skuteczny audyt licencyjny przed migracją do SaaS wymaga zebrania danych z kilku źródeł:
inwentaryzacja oprogramowania – listy instalacji z systemów zarządzania zasobami IT (SAM, CMDB), skanów sieci, ręcznych przeglądów w małych oddziałach;
inwentaryzacja umów – wszystkie kontrakty licencyjne, aneksy, warunki programów wolumenowych, ew. porozumienia ugodowe z przeszłości;
historia utrzymania i upgrade’ów – informacje o tym, kiedy i do jakich wersji oprogramowanie było aktualizowane w ramach maintenance.
Ważny element to identyfikacja praw nabytych w ramach maintenance. U wielu producentów opłacanie utrzymania przez określony czas daje prawo do korzystania z nowszych wersji oprogramowania, nawet po zakończeniu maintenance. Z drugiej strony istnieją przypadki, gdzie prawo do korzystania z danej wersji jest ściśle związane z aktywnym utrzymaniem. Bez zrozumienia tych niuansów łatwo zaniżyć lub zawyżyć realny stan licencji.
Typowe niespodzianki podczas audytu
Nawet w dobrze zarządzonych firmach audyt przed migracją ujawnia zwykle kilka powtarzalnych „niespodzianek”:
instalacje testowe bez licencji – środowiska stworzone „na chwilę” przez zespół projektowy, które zostały i działają w tle latami;
Shadow IT i „dzikie” subskrypcje w działach biznesowych
Podczas audytu przedmigracyjnego na światło dzienne wychodzi zwykle jeszcze jeden problem: narzędzia SaaS kupowane poza IT. Marketing, sprzedaż czy HR zamawiają samodzielnie małe subskrypcje na kartę służbową lub prywatną, omijając centralne procedury. Z perspektywy licencyjnej i prawnej to tykająca bomba.
Najczęstsze ryzyka są dość powtarzalne:
brak centralnej kontroli nad danymi – dane klientów czy pracowników trafiają do usług bez zweryfikowanych warunków przetwarzania;
naruszenie polityk bezpieczeństwa – integracje typu „kliknij, aby podłączyć konto firmowe” bez oceny skutków dla bezpieczeństwa;
sprzeczne lub dublujące się umowy – kilka działów kupuje to samo narzędzie, każdy na innych warunkach, co utrudnia renegocjacje i zgodność.
Przed przejściem na „oficjalne” rozwiązania SaaS trzeba zmapować te rozproszone subskrypcje. Nie chodzi tylko o cięcie kosztów, ale o to, by wiedzieć, gdzie faktycznie znajdują się dane i jakie zobowiązania już zaciągnięto w imieniu organizacji.
Licencje „uśpione”, OEM i prawa wynikające z bundli
Kolejna stała niespodzianka audytu to licencje, które formalnie istnieją, ale nikt nie wie, co się z nimi dzieje. Chodzi zwłaszcza o:
licencje OEM – kupione razem ze sprzętem (np. serwer, router, macierz), często z własnymi, specyficznymi ograniczeniami;
bundlowane komponenty – funkcje „w pakiecie” z głównym produktem, które w SaaS bywają już dodatkowo płatne;
licencje niewykorzystane – zakupione w nadmiarze w przeszłości, porzucone po zmianie projektu.
W kontekście migracji do SaaS te licencje mogą stać siękartą przetargową w negocjacjach. Część producentów oferuje konwersję (tzw. license migration lub trade-in), ale zwykle wymaga to wykazania, jakie prawa faktycznie przysługują organizacji. Bez rzetelnej dokumentacji atut ten przepada.
Nieudokumentowane modyfikacje i dodatki
W systemach on‑premise często pojawiają się wtyczki, moduły lub „tymczasowe” rozszerzenia pisane przez integratorów. Po kilku latach mało kto pamięta, czy prace te były objęte licencją bazową, czy wymagały dodatkowych praw:
rozszerzenia ingerujące w kod źródłowy standardowego produktu;
niestandardowe integracje do systemów trzecich na podstawie licencji developerskich;
komponenty open source dołączone bez analizy zgodności licencji.
Przed migracją do SaaS trzeba ustalić, czy takie modyfikacje można w ogóle przenieść (np. do modelu PaaS rozszerzającego SaaS), czy też są one „uwięzione” w on‑premise i wymagają zastąpienia funkcjonalnie. To często punkt zapalny między działem biznesowym (przyzwyczajonym do customizacji) a dostawcą chmury (oferującym standardowy produkt).
Mapowanie licencji on‑premise na plany SaaS
Kiedy wiadomo już, co faktycznie jest używane i jakie licencje posiada organizacja, zaczyna się mniej efektowna, ale krytyczna praca: mapowanie starego świata na nowy. Największy błąd to proste przeliczenie „użytkownik on‑premise = użytkownik w SaaS”. Zazwyczaj struktura wygląda inaczej.
Praktyczne kroki mapowania:
segmentacja użytkowników – osobno analizuje się „power userów”, zwykłych użytkowników biznesowych i użytkowników sporadycznych;
porównanie funkcji – nie każdy moduł on‑premise ma odpowiednik w SaaS, część jest zintegrowana, część sprzedawana oddzielnie;
weryfikacja limitów – modele SaaS często wprowadzają ograniczenia, których wcześniej nie było (API, storage, transakcje).
Efektem powinna być konkretna matryca: jaki profil użytkownika on‑premise odpowiada któremu planowi lub roli w SaaS, z jakimi parametrami (liczba API calls, wolumen danych, funkcje premium). Bez takiej matrycy wiarygodne planowanie budżetu jest czystą fikcją.
Scenariusze przejścia: big bang, migracja etapowa i model równoległy
Sposób przeprowadzenia migracji ma bezpośredni wpływ na kwestie licencyjne i kosztowe. Zwykle rozważa się trzy podstawowe scenariusze:
big bang – szybkie wyłączenie systemu on‑premise i przejście całości użytkowników na SaaS w jednym momencie;
migracja etapowa – stopniowe przenoszenie modułów, procesów lub jednostek organizacyjnych;
model równoległy (co‑existence) – utrzymywanie przez pewien czas środowiska hybrydowego.
Każdy z nich generuje inne wymagania licencyjne. Przy big bang główne ryzyko to niedoszacowanie planów SaaS na start (blokada procesów biznesowych), przy migracji etapowej i równoległej – podwójne koszty, bo przez pewien czas płaci się i za on‑premise, i za SaaS.
Przy planowaniu trzeba jasno ustalić:
jak długo system on‑premise będzie utrzymywany po formalnym „go‑live” SaaS;
czy w tym czasie obowiązuje pełna licencja produkcyjna, czy można zejść na niższy poziom (np. read‑only, archiwum);
czy producent dopuszcza tymczasowy okres nakładania się licencji na preferencyjnych warunkach.
Niektórzy dostawcy przewidują wprost w programach migracyjnych okres „dual use”, ale nie jest to norma. Zostawienie tego w szarej strefie kończy się później sporami przy audytach.
Źródło: Pexels | Autor: Markus Winkler
Analiza umów on‑premise – kiedy wolno przejść na SaaS, a kiedy najpierw trzeba posprzątać
Kluczowe klauzule, które blokują lub utrudniają migrację
Umowy licencyjne on‑premise bywają bardziej konserwatywne niż SaaS. Z punktu widzenia migracji do chmury najistotniejsze są:
zakazy hostingu zewnętrznego – postanowienia zabraniające instalacji oprogramowania u podmiotów trzecich (np. u integratora, w data center strony trzeciej);
ograniczenia outsourcingu – zgoda na korzystanie wyłącznie przez określony podmiot, bez prawa dostępu dla outsourcerów procesów biznesowych;
brak praw do kopii zapasowych poza siedzibą – szczególnie w starszych kontraktach lub w sektorach regulowanych.
Na pierwszy rzut oka takie klauzule dotyczą tylko środowiska on‑premise. Problem zaczyna się, gdy w trakcie migracji do SaaS część komponentów pozostaje lokalna, ale ma być utrzymywana przez zewnętrznego dostawcę lub w nowej infrastrukturze. Bez zgody producenta może to formalnie naruszać warunki licencyjne.
Maintenance, upgrade’y i przerwy w utrzymaniu
Wielu producentów uzależnia prawo do migracji (np. do nowszej linii produktowej w SaaS) od ciągłości utrzymania (maintenance). Typowy schemat:
aktywne maintenance pozwala przejść na określony plan SaaS na preferencyjnych warunkach (czasem z kredytem za niewykorzystane lata);
przerwa w maintenance powyżej określonego okresu wymaga opłaty wyrównawczej lub traktowana jest jak nowy zakup;
czasem istnieją „okna migracyjne” – możliwość przejścia na SaaS tylko w trakcie trwania umowy utrzymaniowej.
Jeżeli w przeszłości zrezygnowano z maintenance, trzeba policzyć, co będzie tańsze: powrót do utrzymania i migracja w ramach programu konwersji czy zakup licencji SaaS „od zera”. Producenci chętnie prezentują tylko korzystniejszy dla siebie wariant.
Klauzule audytowe i obowiązki sprawozdawcze przy wygaszaniu systemów
Starsze umowy on‑premise często zawierają klauzule audytowe bez precyzyjnego trybu ich wykonywania. Przy wygaszaniu systemów i przechodzeniu na SaaS pojawia się pokusa, by „nie ruszać” tego tematu. To krótkowzroczne podejście.
Rozsądna praktyka to:
udokumentowanie stanu licencji na dzień migracji, z potwierdzeniem od producenta lub integratora;
uzgodnienie, czy i w jakim zakresie producent ma prawo audytować środowisko po wyłączeniu systemów;
ewentualne zawarcie aneksu „zamykanego” – potwierdzającego rozliczenie licencji on‑premise i zasady dalszej współpracy w SaaS.
Bez takiego zamknięcia temat potrafi wrócić po latach, gdy producent w ramach globalnej akcji audytowej stwierdzi, że „kiedyś mieliście nasze oprogramowanie, prosimy o dane historyczne”. Im starsze logi i dokumenty, tym trudniej obronić się przed nadinterpretacją.
Prawa do danych i formatów eksportu po wyłączeniu systemu
Umowy on‑premise rzadko wprost regulują format i zakres eksportu danych przy wyłączeniu systemu. W praktyce przyjmuje się, że skoro system stoi na serwerach organizacji, dostęp do danych jest „gwarantowany”. Przy migracji na SaaS staje się jasne, że to założenie było kruche.
Warto przeanalizować, czy:
oprogramowanie on‑premise umożliwia kompletny eksport danych w formacie, który da się później odczytać bez zakupu nowych licencji;
nie ma ograniczeń co do instalacji narzędzi do odczytu archiwalnych baz danych (np. osobne licencje na „viewer”, ograniczenia co do liczby użytkowników);
wyłączenie maintenance nie blokuje dostępu do narzędzi migracyjnych lub konwerterów formatów.
Tego typu niuanse wychodzą zwykle dopiero, gdy system ma zostać fizycznie wyłączony, a dane muszą pozostać dostępne choćby na potrzeby sporów sądowych lub kontroli regulatora.
Powiązane licencje osób trzecich i „łańcuch” zobowiązań
Duże systemy on‑premise często korzystają z komponentów innych producentów: baz danych, silników raportowych, bibliotek szyfrujących. Te licencje bywają zaszyte w umowach z głównym dostawcą (np. w modelu OEM) lub kupowane oddzielnie.
Przed migracją trzeba ustalić:
czy licencje osób trzecich wygasają automatycznie wraz z głównym systemem, czy wymagają odrębnego wypowiedzenia;
czy istnieją minimalne okresy korzystania, po których wcześniejsze zakończenie generuje kary;
jakie prawa do archiwizacji danych dają te licencje – nie zawsze pokrywają się z prawami z umowy głównej.
Brak analizy „łańcucha” licencji prowadzi do sytuacji, w której główny system jest już w SaaS, ale organizacja wciąż płaci za zbędne komponenty on‑premise tylko dlatego, że nikt nie sprawdził ich statusu.
Jak czytać umowy SaaS: licencje, SLA, DPA, jurysdykcja
Licencja w modelu SaaS: dostęp, nie własność
Podstawowa zmiana to przejście z licencji wieczystej na uprawnienie do korzystania z usługi w określonym czasie. Z punktu widzenia umowy kluczowe są odpowiedzi na kilka praktycznych pytań:
czy klient ma prawo korzystać z usługi wyłącznie na własne potrzeby, czy dopuszczalne są modele typu BPO (świadczenie usług na rzecz własnych klientów);
czy istnieją ograniczenia co do podmiotów powiązanych – spółki zależne, oddziały zagraniczne, joint venture;
jak rozumiany jest „user” – konto imienne, urządzenie, równoczesna sesja, a może „aktywny użytkownik w ostatnich 30 dniach”.
Te definicje decydują, czy budżet będzie stabilny, czy też co kwartał pojawią się dodatkowe faktury za „nieuprawnione” użycie. Marketingowe materiały producenta są tu zwykle zbyt ogólne – liczy się tylko to, co zapisano w umowie i załączonych warunkach licencyjnych.
SLA: dostępność, wydajność i procedury eskalacji
SLA jest często prezentowane jako główne zabezpieczenie klienta. W praktyce większość SLA chroni w pierwszej kolejności dostawcę, a nie użytkownika. Analiza powinna dotyczyć nie tylko wskaźników, ale i mechanizmów.
Najważniejsze elementy SLA:
definicja „dostępności” – czy obejmuje tylko rdzeń aplikacji, czy także integracje, kolejki zadań, moduły raportowe;
wyłączenia odpowiedzialności – prace serwisowe, awarie po stronie operatorów telekomunikacyjnych, ataki DDoS, błędna konfiguracja klienta;
formy rekompensaty – kredyty na przyszłe usługi, rabaty, prawo do rozwiązania umowy po serii incydentów.
Najczęściej zadawane pytania (FAQ)
Na co zwrócić uwagę przy przejściu z licencji on‑premise na SaaS, żeby nie złamać umowy licencyjnej?
Minimalny zestaw to: przegląd wszystkich aktywnych umów on‑premise, identyfikacja okresów wypowiedzenia, klauzul audytowych i zasad rezygnacji z maintenance. Bez tego łatwo zostawić „przy życiu” stare licencje albo wejść w konflikt z producentem przy zamykaniu środowiska.
Trzeba też sprawdzić, czy nowa usługa SaaS nie zmienia sposobu liczenia uprawnień (np. z per serwer na per użytkownik) i czy dane wykorzystanie mieści się w przeznaczeniu określonym w umowie. W praktyce oznacza to wspólną analizę IT, działu prawnego i finansów, a nie jednostronną decyzję jednego działu.
Czy przy migracji na SaaS muszę rezygnować z posiadanych licencji on‑premise?
Z reguły nie ma obowiązku automatycznej rezygnacji z licencji wieczystych – można je dalej zachować, choć często bez sensu jest opłacanie utrzymania, jeśli narzędzie nie jest używane w produkcji. Pułapka polega na tym, że rezygnacja z maintenance bywa obwarowana warunkami (np. zakaz ponownego zakupu na preferencyjnych zasadach, okresy wypowiedzenia, opłaty wyrównawcze).
Dlatego przed migracją trzeba ustalić: czy środowisko on‑premise będzie wyłączone całkowicie, pozostanie jako awaryjne czy testowe, oraz jak to wpływa na licencje. Sam fakt posiadania licencji wieczystej nie oznacza, że można dowolnie trzymać „uśpione” środowiska bez ryzyka audytu.
Jak ograniczyć ryzyko audytu licencyjnego podczas przejścia na SaaS?
Najczęstszy błąd to założenie, że „skoro i tak idziemy do chmury, to audyt nas nie dotyczy”. Tymczasem migracja jest idealnym momentem dla producenta, żeby zweryfikować zgodność historyczną i licencje testowe czy szkoleniowe. W praktyce trzeba spokojnie przeczytać klauzule audytowe i sprawdzić, czy zamknięcie środowiska nie wymaga formalnego potwierdzenia lub raportu końcowego.
Dodatkowo opłaca się utrzymać przez pewien czas przejrzysty inwentarz: ile instancji on‑premise działa, kto ma dostęp, jakie moduły są faktycznie używane. Im większy chaos w danych, tym łatwiej audytorowi wykazać nieprawidłowości i tym trudniej się z nimi spierać.
Jak policzyć, czy przejście z on‑premise na SaaS naprawdę się opłaca?
Samo porównanie „abonament miesięczny vs rata amortyzacji” jest zbyt uproszczone. Trzeba zsumować: istniejące koszty utrzymania on‑premise (sprzęt, prąd, wsparcie, maintenance, praca zespołu), koszty migracji (wdrożenie, integracje, szkolenia, ewentualne kary umowne) oraz koszty stałe SaaS (licencje, nadlimity, płatne dodatki).
Osobny temat to automatyczne przedłużenia i rozrost liczby kont. Modele SaaS są z definicji elastyczne, ale w praktyce oznacza to także ryzyko „pełzającego” wzrostu kosztów. Bez centralnego nadzoru nad subskrypcjami (np. zakaz zakupu kartą firmową poza procesem) kalkulacja z arkusza szybko przestaje być aktualna.
Kto odpowiada za RODO i bezpieczeństwo danych po przejściu na SaaS – my czy dostawca?
Dostawca zwykle jest procesorem danych i odpowiada za infrastrukturę, zabezpieczenia fizyczne, kopie zapasowe, część środków organizacyjnych. Natomiast administrator danych pozostaje ten sam – organizacja korzystająca z usługi. To oznacza odpowiedzialność za dobór dostawcy, konfigurację uprawnień, retencję danych, podstawy prawne przetwarzania i obsługę praw osób, których dane dotyczą.
Większość realnych incydentów w SaaS wynika nie z naruszenia po stronie dostawcy, tylko z błędów po stronie klienta: zbyt szerokich ról, kont nieusuwanych po odejściu pracownika, otwartych integracji. Certyfikaty typu ISO czy SOC 2 po stronie dostawcy zmniejszają ryzyko techniczne, ale nie zastąpią własnych procedur i kontroli dostępu.
Jak uniknąć podwójnego płacenia za system on‑premise i jego następcę w SaaS?
Najpierw trzeba jasno zdefiniować datę „przełączenia” produkcji na SaaS i proces wygaszania starego środowiska – technicznie i kontraktowo. Bez tego łatwo skończyć w sytuacji, w której płatności za maintenance on‑premise idą z przyzwyczajenia, a nikt formalnie nie wypowiedział umowy lub nie dotrzymał terminu wypowiedzenia.
Pomaga prosty, ale konkretny plan: lista umów, odpowiedzialny właściciel po stronie biznesu/IT, decyzja „produkcyjnie / testowo / wyłączamy”, daty graniczne oraz potwierdzenie od dostawców (lub integratorów), że uznają zamknięcie utrzymania. Bez takiej listy zawsze ktoś założy, że „ktoś inny już to ogarnął”.
Czy SaaS daje większą czy mniejszą kontrolę nad licencjami niż on‑premise?
Technicznie producent SaaS ma więcej danych o faktycznym wykorzystaniu usługi: liczbie użytkowników, lokalizacjach logowań, intensywności korzystania z API. To ułatwia mu egzekwowanie warunków licencji i wykrywanie nadużyć. Z punktu widzenia klienta oznacza to mniej „szarej strefy” i mniejsze pole do nieformalnych obejść.
Z drugiej strony dobrze skonfigurowana platforma SaaS potrafi dać lepszy wgląd w to, kto i jak korzysta z systemu, niż rozproszone instalacje on‑premise. Kluczowe jest jedno: scentralizowana administracja (np. SSO, centralne zarządzanie kontami) i jasne zasady zamawiania nowych subskrypcji. Bez tego elastyczność SaaS szybko zamienia się w zbiór niespójnych, drogich „wysp” licencyjnych.
