Kalkulator kosztów migracji do chmury: trzy pozycje, których w nim nie ma

Planujesz migrację i potrzebujesz zespołu, który policzy ją uczciwie? Poznaj nasze usługi Staff Augmentation.

Zobacz też: FinOps 101: zarządzanie kosztami chmury oraz Migracja on-premise do chmury 2026: planowanie licencji

Każdy duży dostawca chmury udostępnia kalkulator całkowitego kosztu posiadania. Wprowadzacie swoją infrastrukturę, kalkulator liczy chwilę i pokazuje oszczędność. Zawsze pokazuje oszczędność. Nie dlatego, że kłamie — liczy poprawnie to, co ma policzyć — ale dlatego, że pytanie, na które odpowiada, zostało zadane przez sprzedającego.

Mechanizm jest prosty i warto go nazwać wprost. Kalkulator porównuje wasz najgorszy realistyczny wariant infrastruktury własnej — nowy sprzęt kupowany dziś, pełna redundancja, amortyzacja od zera, zapas mocy na wzrost — z najlepszym realistycznym wariantem chmury: rezerwacje trzyletnie, rabaty za zobowiązanie, idealnie dobrane rozmiary maszyn i zerowe zużycie poza godzinami pracy. Obie strony policzono poprawnie. Tylko że jedną przy założeniach pesymistycznych, a drugą przy optymistycznych. Cała przewaga wyniku bierze się z asymetrii założeń, nie z asymetrii technologii.

Teza tego przewodnika brzmi i można się z nią spierać: w polskich warunkach o wyniku rachunku migracyjnego rozstrzygają trzy pozycje, których nie zawiera żaden kalkulator dostawcy — koszt wyjścia, koszt zgodności lokalizacyjnej i ekspozycja walutowa — a nie cena mocy obliczeniowej, którą wszystkie te kalkulatory liczą z dużą precyzją. Precyzja w pozycji, która nie rozstrzyga, jest gorsza niż jej brak, bo buduje zaufanie do wyniku jako całości.

Kontrargument jest mocny i trzeba go postawić uczciwie: migracja do chmury rzadko jest decyzją kosztową. Jest decyzją o tempie, o elastyczności, o dostępie do usług, których nie zbudujecie sami, i o tym, żeby przestać zajmować się sprzętem. Liczenie kursu walutowego w takiej decyzji to mierzenie nie tego, co ważne. Odpowiedź: to jest prawda i prowadzi do wniosku ostrzejszego, nie łagodniejszego. Jeżeli decyzja nie jest kosztowa, przestańcie ją uzasadniać kalkulatorem TCO. Rachunek, który ma udowodnić z góry przyjętą tezę, i tak ją udowodni, a jego jedynym trwałym skutkiem będzie zobowiązanie do oszczędności, których za dwa lata nikt nie potwierdzi. Uczciwe „migrujemy dla tempa, koszt wyjdzie porównywalnie albo nieco wyżej” jest lepszą pozycją wobec zarządu niż optymistyczny arkusz, który się nie sprawdzi.

Dlaczego kalkulator dostawcy zawsze pokazuje oszczędność?

Cztery mechanizmy działają w tę samą stronę i wszystkie są legalne.

Asymetria założeń o wykorzystaniu. Po stronie własnej infrastruktury kalkulator zakłada, że kupujecie moc na szczyt i płacicie za nią całą dobę. Po stronie chmury zakłada, że płacicie za to, czego używacie. To jest prawdziwe w modelu, ale w praktyce wiele organizacji przenosi maszyny jeden do jednego i płaci w chmurze także za szczyt, tylko drożej.

Rabaty warunkowe traktowane jako pewne. Cennik z rezerwacją trzyletnią pojawia się w rachunku jako obowiązujący od pierwszego dnia. W rzeczywistości rezerwacje robi się po ustabilizowaniu zużycia, czyli zwykle po roku, a przez pierwszy rok płaci się stawkę podstawową. Ten jeden szczegół potrafi przesunąć trzyletni rachunek o kilkanaście procent.

Pominięcie okresu przejściowego. Migracja to od trzech do sześciu miesięcy, w których płacicie za oba środowiska. Kalkulator liczy stan docelowy, nie drogę do niego.

Zerowy koszt wyjścia. Rachunek kończy się na trzecim roku i milczy o tym, co jest po nim. Tymczasem właśnie tam siedzi asymetria najpoważniejsza: wejście jest tanie i szybkie, wyjście drogie i wolne — i ta asymetria jest cechą modelu biznesowego, a nie usterką.

Ta sama infrastruktura, dwa uczciwe rachunki

Weźmy czterdzieści maszyn wirtualnych, obciążenie stabilne, sprzęt czteroletni, zespół infrastrukturalny liczący dwie osoby.

Rachunek dostawcy: sprzęt trzeba wymienić, więc po stronie własnej infrastruktury pojawia się pełny nakład inwestycyjny na nowe serwery z redundancją, do tego kolokacja, wsparcie producenta i pełny koszt dwóch etatów. Po stronie chmury: rezerwacje trzyletnie od pierwszego dnia, maszyny dobrane do rzeczywistego obciążenia zamiast do obecnych rozmiarów, wyłączanie środowisk nieprodukcyjnych poza godzinami pracy. Wynik: oszczędność rzędu trzydziestu procent w horyzoncie trzyletnim.

Rachunek uczciwy: sprzęt można eksploatować jeszcze dwa lata z przedłużonym wsparciem, więc nakład inwestycyjny przesuwa się poza horyzont porównania. Zespół infrastrukturalny i tak zostaje, bo zajmuje się także siecią, stacjami roboczymi i systemami, które nie migrują — do rachunku wchodzi więc różnica, a nie całość. Po stronie chmury: pierwszy rok bez rezerwacji, sześć miesięcy równoległego działania obu środowisk, dobranie rozmiarów maszyn wymaga pracy, której nikt nie wycenił, a jedna trzecia obciążeń i tak nie da się wyłączyć poza godzinami, bo obsługuje zadania nocne. Wynik: koszt porównywalny, z przewagą chmury pojawiającą się dopiero w roku trzecim.

Oba rachunki są policzone poprawnie i różnią się wyłącznie założeniami. Różnica wynosi trzydzieści punktów procentowych — czyli więcej niż jakakolwiek optymalizacja techniczna, którą można było wykonać po podjęciu decyzji.

Wniosek dla praktyki jest prosty i niewygodny: zanim policzycie cokolwiek, spiszcie założenia obu stron na jednej kartce i pokażcie je komuś, kto nie ma interesu w wyniku. Ta jedna kartka rozstrzyga rachunek w większym stopniu niż arkusz, który po niej powstanie.

Wniosek praktyczny nie brzmi „nie używajcie kalkulatorów”. Brzmi: użyjcie go do policzenia jednej pozycji, którą liczy dobrze — kosztu mocy obliczeniowej i składowania przy zadanym profilu — a resztę rachunku zbudujcie sami.

Które trzy pozycje decydują, a nie ma ich w żadnym kalkulatorze?

Koszt wyjścia. Nie dlatego, że planujecie wyjść, tylko dlatego, że jego wysokość określa waszą pozycję negocjacyjną przy każdej kolejnej rozmowie o cenniku. Dostawca, który wie, że wyjście kosztuje was osiemnaście miesięcy pracy, ma inną motywację do ustępstw niż dostawca, który wie, że kosztuje trzy.

Koszt zgodności lokalizacyjnej. W sektorach regulowanych, a w Polsce jest to zbiór znacznie szerszy niż same banki, przetwarzanie w chmurze pociąga wymagania dotyczące lokalizacji danych, łańcucha powierzenia, uprawnień kontrolnych i planów wyjścia. Każde z nich przekłada się na konkretną pracę i na ograniczenie wyboru usług — a ograniczenie wyboru usług zmienia cenę.

Ekspozycja walutowa. Cennik w walucie obcej wobec przychodu w złotych, w horyzoncie trzyletnim.

Wspólna cecha tych trzech: żadnej nie da się policzyć bez wiedzy o waszej organizacji, więc żaden zewnętrzny kalkulator nie ma jak ich uwzględnić. To nie jest zarzut wobec kalkulatorów — to jest powód, żeby nie traktować ich wyniku jako rachunku.

Jak policzyć koszt wyjścia, zanim jeszcze wejdziecie?

Ćwiczenie zajmuje pół dnia i jest najlepiej wydanym czasem w całym procesie decyzyjnym.

Pozycja pierwsza — transfer danych na zewnątrz. Weźcie planowany rozmiar danych w środowisku docelowym po trzech latach, nie dzisiejszy, i pomnóżcie przez stawkę za transfer wychodzący z cennika dostawcy. Stawki mieszczą się zwykle w przedziale kilku centów za gigabajt i przy dużych zbiorach dają kwoty, które zaskakują. Ta pozycja jest łatwa do policzenia i najmniejsza z trzech.

Pozycja druga — odwrócenie zależności od usług zarządzanych. Tu siedzi główny koszt. Im więcej korzystacie z usług specyficznych dla dostawcy — zarządzanych baz danych o autorskim interfejsie, funkcji bezserwerowych, usług kolejkowania, gotowych komponentów uczenia maszynowego — tym więcej pracy wymaga przeniesienie gdziekolwiek indziej. Oszacujcie ją w osobodniach dla każdej używanej usługi i zsumujcie.

Pozycja trzecia — równoległe działanie przy wyjściu. Symetryczna do kosztu wejścia i zwykle o połowę dłuższa, bo wyjście robi się przy mniejszym zaangażowaniu organizacji.

Do tego rachunku warto dołożyć kontekst prawny, który zmienia się na waszą korzyść: rozporządzenie 2023/2854 w sprawie danych, stosowane od 12 września 2025 roku, wprowadza obowiązki ułatwiające zmianę dostawcy usług przetwarzania danych oraz harmonogram wycofywania opłat pobieranych za samo przełączenie. Nie usuwa to kosztu pracy inżynierskiej, który i tak dominuje w tym rachunku, ale usuwa część barier umownych — i jest wartym zadania pytaniem do dostawcy, czy jego usługi mieszczą się w zakresie tych przepisów.

Trzy pytania do dostawcy, które ustawiają koszt wyjścia

Wszystkie trzy warto zadać na etapie ofertowym, bo wtedy odpowiedzi są konkretne, a później przestają być.

„W jakim formacie otrzymamy dane, jeśli zdecydujemy się odejść, w jakim terminie i za jaką kwotę?” Odpowiedź musi zawierać liczbę. Sformułowanie „według cennika obowiązującego w dniu żądania” jest odpowiedzią odmowną wyrażoną uprzejmie.

„Które z proponowanych usług mają odpowiedniki u innych dostawców lub w wersji otwartej, a które nie?” Dostawcy zwykle odpowiadają na to uczciwie, bo pytanie brzmi technicznie. Odpowiedź jest gotową mapą waszej przyszłej zależności.

„Czy usługi objęte ofertą mieszczą się w zakresie przepisów o przełączaniu usług przetwarzania danych?” Pytanie techniczne w formie, prawne w treści. Reakcja mówi wam, czy rozmawiacie z kimś, kto zna własny produkt od strony umownej.

Odpowiedzi warto zapisać w załączniku do umowy. Nie dlatego, że planujecie z niego skorzystać, tylko dlatego, że dokument, który istnieje, zmienia zachowanie drugiej strony przy każdej kolejnej rozmowie o cenniku — a to jest realna wartość tego ćwiczenia, znacznie większa niż sam koszt ewentualnego wyjścia.

Praktyczna zasada projektowa wynikająca z tego rachunku: dla każdej usługi zarządzanej, którą chcecie wykorzystać, zapytajcie z góry, ile kosztowałoby jej zastąpienie. Odpowiedź „bardzo dużo” nie jest powodem do rezygnacji — bywa, że korzyść jest tego warta — ale musi być decyzją świadomą i zapisaną, a nie odkryciem po trzech latach.

Ile kosztuje zgodność lokalizacyjna w polskich realiach?

Ta pozycja jest zerowa dla części organizacji i dominująca dla innych, więc pierwszym krokiem jest ustalenie, do której grupy należycie.

Podmioty sektora finansowego działają w ramach wymogów dotyczących korzystania z usług przetwarzania w chmurze obliczeniowej, w tym obowiązków wynikających z rozporządzenia o operacyjnej odporności cyfrowej sektora finansowego, stosowanego od 17 stycznia 2025 roku. Praktyczne skutki architektoniczne i kosztowe obejmują: rejestr umów z zewnętrznymi dostawcami usług teleinformatycznych, wymagania dotyczące uprawnień kontrolnych i dostępu do informacji, obowiązki zgłoszeniowe przy poważnych incydentach, wymagania dotyczące strategii wyjścia oraz testowanie odporności. To jest praca, którą ktoś musi wykonać, i jest ona kosztem migracji, choć nie pojawia się w żadnym kalkulatorze.

Poza sektorem finansowym analogiczne wymagania rozszerzają przepisy o cyberbezpieczeństwie wdrażające dyrektywę NIS2 — obejmują one znacznie szerszy katalog podmiotów, w tym część produkcji, energetyki, transportu, gospodarki odpadami i usług cyfrowych. Kluczowy dla rachunku migracyjnego jest tam obszar zarządzania ryzykiem łańcucha dostaw.

Dla wszystkich organizacji przetwarzających dane osobowe pozostaje warstwa wynikająca z RODO: umowa powierzenia, lista podprzetwarzających, lokalizacja przetwarzania, tryb informowania o zmianach oraz zasady przekazywania danych poza Europejski Obszar Gospodarczy.

Praktyczny sposób wyceny tej pozycji, sprawdzający się bez angażowania kancelarii na etapie decyzji: policzcie osobodni prawnika i architekta potrzebne do przygotowania dokumentacji i uzgodnień, a osobno wskażcie usługi, z których nie będziecie mogli skorzystać z powodu ograniczeń lokalizacyjnych. Ta druga część bywa istotniejsza kosztowo, bo zawężenie do regionów europejskich i do usług dostępnych w tych regionach potrafi wykluczyć właśnie te komponenty, którymi uzasadniano migrację.

Dlaczego rachunek w dolarach mierzy co innego, niż myślicie?

To jest pozycja, którą pomija się najczęściej i której pominięcie jest najtrudniejsze do obrony przed dyrektorem finansowym, gdy już zostanie zauważone.

Struktura problemu: przychody w złotych, koszt w walucie obcej, horyzont trzy lata, brak zabezpieczenia. Zmienność kursowa w takim horyzoncie bywa dwucyfrowa i jest tego samego rzędu wielkości, co oszczędność deklarowana w typowym rachunku migracyjnym, mieszcząca się zwykle w przedziale kilkunastu do trzydziestu procent. Oznacza to, że wynik porównania może się odwrócić bez jakiejkolwiek zmiany w technologii, w cenniku dostawcy ani w waszym zużyciu.

Trzy sposoby postępowania, w kolejności od najprostszego.

Pokażcie wariant pesymistyczny obok bazowego. Minimum, jakie należy zrobić. Ten sam arkusz, dwie kolumny, jawnie podane założenie kursowe. Koszt tej operacji to piętnaście minut, a buduje wiarygodność całego rachunku bardziej niż jakakolwiek inna pojedyncza czynność.

Sprawdźcie, czy rozliczenie w złotych jest dostępne. Część dostawców i część partnerów odsprzedających oferuje rozliczenie w walucie lokalnej. Przenosi to ryzyko na sprzedającego, więc zwykle kosztuje w marży — ale koszt jest wtedy jawny i wyceniony, a nie ukryty.

Włączcie dyrektora finansowego wcześnie. Zabezpieczenie ekspozycji walutowej to jego dziedzina i ma do tego narzędzia. Problemem nie jest ryzyko walutowe, tylko to, że zostało ukryte w rachunku przedstawianym jako techniczny i trafiło do organizacji bez wiedzy osoby, która nim zarządza.

Warto zauważyć, że ten sam mechanizm dotyczy każdej długoterminowej umowy na usługi rozliczane w walucie obcej, nie tylko chmury. Migracja jest po prostu największą taką pozycją, jaką większość organizacji zaciąga.

Co z EBITDA — dlaczego chmura psuje wskaźnik, który sprzęt poprawiał?

To jest efekt, który regularnie zaskakuje zespoły techniczne, a dla zarządu bywa argumentem rozstrzygającym.

Zakup serwerów jest nakładem inwestycyjnym: powiększa aktywa i obciąża wynik przez odpisy amortyzacyjne rozłożone na lata, wyłączone z wyniku operacyjnego przed amortyzacją. Opłata za chmurę jest kosztem operacyjnym bieżącego okresu i obciąża ten wynik w całości, natychmiast.

Skutek: przejście z własnej infrastruktury na chmurę pogarsza wskaźnik EBITDA nawet wtedy, gdy całkowity koszt gotówkowy jest identyczny lub niższy. Dla spółki, której zarząd jest rozliczany z tego wskaźnika albo która ma kowenanty kredytowe na nim oparte, jest to konsekwencja poważna i całkowicie niewidoczna w kalkulatorze TCO. Kwalifikacja konkretnych umów zależy od przyjętych zasad rachunkowości i rozstrzyga ją dział finansowy — ale kierunek efektu jest systematyczny.

Praktyczny wniosek: pokażcie rachunek w dwóch ujęciach. Gotówkowym, który odpowiada na pytanie, ile pieniędzy wypłynie z firmy, i wynikowym, który odpowiada na pytanie, jak zmienią się wskaźniki. Te dwa ujęcia potrafią prowadzić do przeciwnych rekomendacji i lepiej, żeby ta rozbieżność wyszła na spotkaniu decyzyjnym niż w pierwszym raporcie kwartalnym po migracji.

Jak zbudować rachunek, który wytrzyma pytania dyrektora finansowego?

Poniższa tabela jest strukturą takiego rachunku. Wartość ma nie w liczbach, których nie znam, tylko w trzech ostatnich kolumnach: skąd bierze się liczba, jaki jest typowy błąd i kto za nią odpowiada. Rachunek, w którym każda pozycja ma nazwane źródło i nazwanego właściciela, przechodzi przez spotkanie zarządu; rachunek bez tego nie przechodzi, choćby suma była taka sama.

Pozycja	Źródło liczby	Typowy błąd	Właściciel
Moc obliczeniowa i składowanie	Kalkulator dostawcy przy realnym profilu zużycia	Przyjęcie rabatów za rezerwację od pierwszego dnia	Architekt
Transfer danych na zewnątrz	Zmierzony ruch wychodzący razy stawka z cennika	Pominięcie ruchu między regionami i strefami	Architekt
Refaktoryzacja aplikacji	Wycena per aplikacja, w przedziale, nie punktowa	Założenie, że przeniesienie bez zmian wystarczy	Lider techniczny
Okres równoległego działania	Długość migracji razy koszt obu środowisk	Przyjęcie trzech miesięcy zamiast realnych sześciu	Kierownik projektu
Licencje	Przegląd umów pod kątem przenoszalności	Założenie, że dotychczasowe warunki obowiązują w chmurze	Zakupy
Kompetencje zespołu	Szkolenia plus różnica stawek plus czas nauki	Wpisanie zera, bo „zespół się nauczy”	Dyrektor techniczny
Zgodność i dokumentacja	Osobodni prawnika i architekta plus lista wykluczonych usług	Pominięcie, bo pozycja nie jest techniczna	Ryzyko lub dział prawny
Koszt wyjścia	Trzy pozycje z osobnej sekcji tego tekstu	Pominięcie w całości	Architekt i zakupy
Ekspozycja walutowa	Wariant pesymistyczny obok bazowego	Rachunek prowadzony wyłącznie w walucie obcej	Dyrektor finansowy
Wpływ na wynik i wskaźniki	Ujęcie wynikowe obok gotówkowego	Prezentacja wyłącznie ujęcia gotówkowego	Dyrektor finansowy

Dwie zasady dotyczące sposobu prezentacji. Po pierwsze, podawajcie przedziały, nie liczby punktowe — rachunek z jedną liczbą przy pozycji „refaktoryzacja” jest rachunkiem, o którym wszyscy przy stole wiedzą, że został zmyślony. Po drugie, wskażcie jawnie trzy pozycje o największej niepewności i powiedzcie, kiedy się wyjaśnią. To zamienia rozmowę o wiarygodności rachunku w rozmowę o harmonogramie weryfikacji, a tę drugą da się prowadzić.

Jak wycenić refaktoryzację, skoro to największa niewiadoma?

Refaktoryzacja aplikacji jest pozycją o największym rozrzucie w całym rachunku i jednocześnie tą, którą najczęściej wpisuje się jako zero, zakładając przeniesienie bez zmian.

Przeniesienie bez zmian działa i jest uzasadnione — dla obciążeń stabilnych, o przewidywalnym zużyciu, gdzie celem migracji jest wyjście z serwerowni, a nie oszczędność. Nie działa jako sposób na obniżenie kosztu, ponieważ aplikacja zaprojektowana pod stały serwer pracujący całą dobę będzie w chmurze kosztować tyle, co stały serwer pracujący całą dobę, powiększony o marżę dostawcy.

Praktyczna metoda wyceny, wykonalna w tydzień dla portfela kilkudziesięciu aplikacji. Podzielcie je na cztery grupy. Grupa pierwsza — przenoszalne bez zmian, o stabilnym zużyciu. Koszt refaktoryzacji zero, oszczędność zero, decyzja o przeniesieniu z innych powodów niż koszt. Grupa druga — wymagające drobnych zmian: konfiguracja, sposób przechowywania stanu, logowanie. Wycena w dniach, ryzyko niskie. Grupa trzecia — wymagające przebudowy, żeby korzystać z elastyczności. To tu leży cała potencjalna oszczędność i całe ryzyko wyceny; stosujcie przedziały i mnożnik znany z projektów przebudowy. Grupa czwarta — nieprzenoszalne w rozsądnym koszcie: systemy z zależnościami sprzętowymi, licencjami nieprzenoszalnymi albo wymaganiami, których dostawca nie spełnia. Ta grupa determinuje, czy w ogóle mówimy o pełnej migracji, czy o modelu mieszanym.

Najczęstszy błąd polega na wycenie całego portfela przez pryzmat grupy pierwszej, bo jest najliczniejsza i najlepiej znana. Oszczędność deklarowana w rachunku pochodzi natomiast prawie w całości z grupy trzeciej, czyli tej najdroższej i najbardziej niepewnej.

Przy grupie trzeciej warto zastosować ten sam mnożnik, który stosuje się do każdej przebudowy systemów starszych niż pięć lat: rzeczywisty czas mieści się zwykle w przedziale od półtora do trzech razy wobec pierwotnej wyceny, ponieważ wycena obejmuje to, co zespół o systemie wie, a przebudowa napotyka to, czego nie wie. Podanie tego przedziału wprost w rachunku jest lepsze niż podanie liczby punktowej z zastrzeżeniem w przypisie — przedział przenosi niepewność do liczby, przypis pozwala ją zignorować.

Jest też pytanie, które przy grupie czwartej pada zbyt późno: czy te systemy da się wygasić zamiast migrować. W portfelach, które mieliśmy okazję przeglądać, część aplikacji zakwalifikowanych jako „nieprzenoszalne” okazywała się aplikacjami, z których korzysta kilkanaście osób w sposób dający się zastąpić czymś innym. Sprawdzenie tego kosztuje dwie rozmowy i bywa najtańszą pozycją oszczędnościową w całym projekcie — a jednocześnie taką, której żaden kalkulator nie zasugeruje, bo kalkulatory liczą przeniesienie, nie rezygnację.

Kiedy chmura naprawdę jest tańsza?

Cztery sytuacje, w których odpowiedź jest twierdząca i nie wymaga naciągania rachunku.

Obciążenie zmienne z wyraźnymi szczytami. Sprzedaż sezonowa, kampanie, przetwarzanie okresowe. Płacenie za szczyt przez cały rok jest w tym profilu głównym kosztem i chmura ten koszt usuwa.

Szybki, niepewny wzrost. Kiedy nie wiadomo, czy za rok będzie dwa razy więcej użytkowników, czy dziesięć razy, kupowanie sprzętu jest zakładem. Chmura wycenia tę niepewność i cena tej opcji bywa niższa niż koszt złego zakładu.

Brak własnych kompetencji infrastrukturalnych i brak planu ich budowy. Utrzymanie własnej infrastruktury wymaga ludzi, których trzeba znaleźć, opłacić i zastąpić, gdy odejdą. Dla małych i średnich organizacji to jest realny koszt, często wyższy niż różnica w cenie sprzętu.

Moment odnowienia sprzętu. Rachunek wygląda zupełnie inaczej, gdy alternatywą jest zakup nowych serwerów, niż gdy alternatywą jest dalsze użytkowanie sprzętu zamortyzowanego. To jest zresztą najczęstszy powód, dla którego dwa uczciwe rachunki dla podobnych firm dają przeciwne wyniki.

Kiedy zostać na własnej infrastrukturze?

Uczciwość wymaga wymienienia również tych przypadków, bo w polskich realiach występują częściej, niż wynikałoby z materiałów branżowych.

Obciążenie stabilne przy wysokim wykorzystaniu. Systemy pracujące równo przez całą dobę, przy wykorzystaniu powyżej mniej więcej dwóch trzecich dostępnej mocy, na sprzęcie już zamortyzowanym. Nie ma tu czego optymalizować przez elastyczność, bo elastyczność nie jest potrzebna.

Wymagania lokalizacyjne wykluczające usługi, które uzasadniały migrację. Jeśli po zastosowaniu wszystkich ograniczeń zostaje wam w chmurze to samo, co macie u siebie, tylko drożej, rachunek jest rozstrzygnięty.

Duże, stałe wolumeny transferu wychodzącego. Rozwiązania intensywnie wysyłające dane na zewnątrz mają w chmurze strukturę kosztów, która rzadko wypada korzystnie.

Brak zdolności organizacji do zarządzania kosztem zmiennym. To jest przyczyna niedoceniana. Chmura zamienia koszt stały na zmienny, a koszt zmienny bez właściciela i bez dyscypliny rośnie. Organizacja bez procesu kontroli zużycia zwykle płaci w chmurze więcej, niż zakładała, i nie jest to wina cennika.

Model mieszany, w którym obciążenia stabilne zostają u siebie, a zmienne i nowe idą do chmury, bywa w polskich warunkach rozwiązaniem najbardziej racjonalnym — i najrzadziej rekomendowanym, ponieważ nie ma dostawcy, który zarabiałby na nim w całości.

Warto jednak od razu nazwać koszt tego modelu, bo bywa przemilczany po drugiej stronie sporu. Utrzymywanie dwóch środowisk oznacza dwa zestawy kompetencji, dwa modele bezpieczeństwa, dwa procesy wdrożeniowe i połączenie sieciowe między nimi, które samo w sobie jest pozycją kosztową i punktem awarii. Organizacje, które wybierają model mieszany dla uniknięcia decyzji, zwykle płacą za oba warianty i nie mają korzyści z żadnego. Model mieszany jest dobrym wyborem wtedy, gdy podział przebiega wzdłuż wyraźnej granicy — na przykład systemy transakcyjne u siebie, analityka i środowiska nieprodukcyjne w chmurze — i złym wyborem wtedy, gdy jest po prostu stanem, w którym migracja się zatrzymała.

Jak rozłożyć migrację, żeby rachunek dało się zweryfikować w trakcie?

Największą wadą rachunku migracyjnego jest to, że jego trafność sprawdza się dopiero po zakończeniu, czyli po wydaniu całości. Da się to zmienić przez kolejność.

Etap pierwszy — jedna aplikacja z grupy trzeciej, nie z pierwszej. Kontrintuicyjne i ważne. Migrując najpierw rzecz najłatwiejszą, potwierdzacie założenia dotyczące pozycji, która i tak była pewna. Migrując coś z grupy wymagającej przebudowy, weryfikujecie największą niewiadomą rachunku wtedy, kiedy jeszcze można się wycofać.

Etap drugi — pomiar rzeczywistego kosztu przez pełny cykl. Minimum kwartał, żeby objąć zamknięcie okresu, szczyt i przynajmniej jedno wydanie. Porównajcie z założeniem i skorygujcie rachunek dla całości.

Etap trzeci — decyzja o kontynuacji na podstawie zmierzonych, nie zakładanych liczb. Ten etap trzeba zaplanować jako moment decyzyjny z prawem do zatrzymania. Bez tego migracja staje się procesem, który kończy się dlatego, że się zaczął.

Etap czwarty — reszta portfela, grupami, z rezerwacjami dopiero po ustabilizowaniu zużycia.

Ten porządek ma jeszcze jedną zaletę: zespół uczy się na obciążeniu trudnym, kiedy stawka jest jeszcze niska. Migracja zaczynana od rzeczy prostych buduje fałszywą pewność siebie, która kosztuje przy trzeciej aplikacji.

Co dokładnie mierzyć w etapie drugim

Kwartał pomiaru ma sens tylko wtedy, gdy z góry wiadomo, które liczby porównujecie z rachunkiem. Cztery wystarczą.

Koszt jednostkowy zamiast kosztu całkowitego. Rachunek miesięczny sam w sobie nic nie mówi, bo obciążenie się zmienia. Podzielcie go przez jednostkę biznesową — transakcję, zamówienie, użytkownika aktywnego — i porównajcie z tą samą wielkością liczoną dla środowiska własnego. Dopiero to jest porównanie.

Udział kosztu, którego nikt nie planował. Transfer między strefami, obrazy dysków po nieusuniętych środowiskach testowych, kopie zapasowe o retencji ustawionej domyślnie. W pierwszym kwartale ta pozycja bywa dwucyfrowym udziałem rachunku i jest najlepszym miernikiem dojrzałości procesu kontroli kosztu.

Rzeczywisty czas refaktoryzacji wobec wyceny. Jedna liczba, która pozwala skorygować całą pozycję dla pozostałych aplikacji z grupy trzeciej. To jest główny powód, dla którego etap pierwszy zaczyna się od aplikacji trudnej.

Liczba incydentów wynikających z nowego środowiska. Nie do rachunku kosztowego, tylko do decyzji o tempie. Wysoka wartość oznacza, że kolejne grupy trzeba migrować wolniej, a nie że migracja była błędem.

Wynik pomiaru zapiszcie obok pierwotnych założeń, w tym samym arkuszu. Rachunek migracyjny, który po kwartale został skorygowany zmierzonymi liczbami i pokazany zarządowi razem z pierwotną wersją, buduje wiarygodność na wszystkie kolejne rozmowy o budżecie technologicznym — nawet, a właściwie zwłaszcza wtedy, gdy korekta jest niekorzystna.

Jakich błędów unikać?

Traktowanie kalkulatora dostawcy jako rachunku. Jest wyceną jednej pozycji, i to tej, która nie rozstrzyga.

Rachunek wyłącznie w walucie obcej. Ukrywa ekspozycję, której nikt nie zarządza.

Pominięcie kosztu wyjścia. Kosztuje nie w momencie wyjścia, tylko przy każdej rozmowie o cenniku przez cały okres współpracy.

Wpisanie zera przy kompetencjach. Zespół rzeczywiście się nauczy, ale w czasie, który jest kosztem, a część ludzi po zdobyciu tych kompetencji dostanie lepsze oferty.

Przeniesienie bez zmian z oczekiwaniem oszczędności. Dwie rzeczy, których nie da się mieć naraz.

Brak procesu kontroli kosztu po migracji. Koszt zmienny bez właściciela rośnie. Warto zaplanować ten proces przed migracją, a nie po pierwszym zaskakującym rachunku — szerzej piszemy o tym w tekście o zarządzaniu kosztami chmury.

Prezentacja wyłącznie ujęcia gotówkowego. Zaskoczenie efektem wynikowym w pierwszym raporcie kwartalnym po migracji jest kosztowne politycznie.

Jak ARDURA Consulting liczy migrację?

Zaczynamy od podziału portfela aplikacji na cztery grupy i od wyceny kosztu wyjścia — czyli od dwóch rzeczy, których nie ma w kalkulatorach, a które w naszym doświadczeniu rozstrzygają o wyniku częściej niż cena mocy obliczeniowej. Rachunek budujemy w strukturze z tabeli powyżej: z nazwanym źródłem i właścicielem przy każdej pozycji, w przedziałach, w dwóch ujęciach i z jawnie pokazanym wariantem kursowym.

Zdarza się, że wynik takiej analizy brzmi „model mieszany” albo „na razie zostajemy”. Jest to wynik pełnoprawny i tańszy dla klienta niż migracja przeprowadzona na podstawie rachunku, który miał z góry ustaloną tezę.

Kiedy decyzja o migracji zapada, udostępniamy inżynierów w modelu Staff Augmentation i Time & Materials — architektów chmurowych i specjalistów od automatyzacji wdrożeń na czas migracji, z możliwością zmniejszenia zespołu po ustabilizowaniu środowiska. Pomagamy też ustawić proces kontroli kosztu, bez którego oszczędność z rachunku nie utrzymuje się dłużej niż dwa kwartały.

Najtańszy krok, który możecie wykonać w tym tygodniu bez niczyjej pomocy: weźcie rachunek migracyjny, który już macie, i dopiszcie do niego trzy wiersze — koszt wyjścia, koszt zgodności i wariant kursowy pesymistyczny. Jeżeli po ich dopisaniu wynik się nie zmienia, macie mocną decyzję. Jeżeli się zmienia, właśnie oszczędziliście sobie trudnej rozmowy za dwa lata.

Skontaktuj się z nami, jeśli chcecie przejść przez ten rachunek na własnym portfelu aplikacji.