Dyrektor techniczny średniej firmy logistycznej ma na biurku trzy oferty na przeniesienie czterdziestu aplikacji z własnej serwerowni do chmury publicznej. Pierwsza opiewa na 780 tysięcy złotych w modelu fixed price. Druga na 1,1 miliona, rozliczana czasem pracy, z „szacunkiem niewiążącym”. Trzecia na 1,4 miliona, z długim załącznikiem technicznym, którego nikt w zarządzie nie przeczytał. Prezes pyta o oczywiste: dlaczego nie bierzemy najtańszej?
Odpowiedź leży nie w kwotach, tylko w tym, co każdy z dostawców obiecał. Pierwsza oferta kończy się w chwili, gdy maszyny wirtualne uruchomią się w chmurze. Druga nie mówi, kiedy się kończy. Trzecia zawiera testy wydajności, przetestowane odtwarzanie z kopii, sześć tygodni wsparcia po przełączeniu i przekazanie kodu infrastruktury do repozytorium klienta. To trzy różne usługi, sprzedawane pod tą samą nazwą.
Ten artykuł jest dla osoby, która właśnie stoi przed takim wyborem. O tym, co w ogóle robi partner migracyjny, jakie stosuje modele rozliczeń i jak programy dostawców chmury współfinansują jego pracę, pisaliśmy w przewodniku po usługach migracji do chmury i wyborze partnera. Tutaj idziemy krok dalej: co wpisać w zakres prac, jak zdefiniować odbiór, jak powiązać płatności z postępem i które zapisy w umowie chronią cenę oraz Twoją niezależność. Teza jest prosta: o koszcie migracji decyduje mniej stawka partnera, a bardziej precyzja zlecenia.
Dlaczego trzy oferty na tę samą migrację różnią się o połowę?
Bo słowo „migracja” nie ma jednej definicji. Dla jednego dostawcy oznacza przeniesienie maszyn wirtualnych narzędziem do replikacji i potwierdzenie, że system odpowiada. Dla drugiego obejmuje projekt strefy docelowej, zmianę bazy danych na usługę zarządzaną, testy wydajności i optymalizację kosztów po uruchomieniu. Obie firmy uczciwie wyceniają to, co rozumieją pod tym słowem. Problem polega na tym, że zamawiający porównuje kwoty, a nie zakresy.
Różnice biorą się zwykle z pięciu miejsc. Pierwsze to strategia dla poszczególnych obciążeń: przeniesienie bez zmian (rehost) kosztuje ułamek tego, co przebudowa aplikacji, a oferty często milcząco zakładają różne strategie. Drugie to strefa docelowa: konta, sieć, tożsamość, bazowe zabezpieczenia i logowanie, które jedni wliczają, a inni zakładają, że już istnieją. Trzecie to dane: wolumen, sposób synchronizacji i okno przełączenia. Czwarte to testy, czyli kto je przygotowuje, kto wykonuje i kto podpisuje wynik. Piąte to okres po przełączeniu: czy partner zostaje, gdy pierwsze nocne zadanie wsadowe zawiedzie, czy znika następnego dnia.
Do tego dochodzi rezerwa na ryzyko. Dostawca, który podaje stałą cenę bez rzetelnej inwentaryzacji, musi skądś wziąć margines na niespodzianki. Albo dolicza go do ceny, albo zawęża zakres i dopisuje listę założeń, których naruszenie otwiera drogę do zleceń zmian. W pierwszym wariancie przepłacasz za ryzyko, które może się nie zmaterializować. W drugim płacisz mniej na starcie i więcej w trakcie.
Wniosek praktyczny: zanim porównasz ceny, sprowadź oferty do wspólnego mianownika. Najprościej zrobić to, przygotowując własny zakres prac i prosząc wszystkich oferentów o wycenę tego samego dokumentu. Jeśli nie masz jeszcze danych, żeby taki dokument napisać, to znak, że pierwszym zleceniem powinna być ocena stanu obecnego, a nie migracja.
Co musi zawierać zakres prac, żeby oferty dało się porównać?
Zakres prac (statement of work, SOW) jest najważniejszym załącznikiem umowy migracyjnej. To on, a nie preambuła czy ogólne warunki, rozstrzyga spory w trzecim miesiącu projektu. Dobry zakres prac ma dziesięć elementów.
Lista obciążeń jako załącznik. Każda aplikacja, baza danych i usługa objęta migracją, z właścicielem biznesowym, środowiskami (produkcja, test, rozwój), wolumenem danych i zależnościami. Lista powinna być zamknięta: to, czego na niej nie ma, nie jest w zakresie.
Strategia dla każdego obciążenia. Przy każdej pozycji zapisana decyzja: przeniesienie bez zmian, zmiana platformy, przebudowa, zastąpienie usługą SaaS, pozostawienie albo wycofanie. Jeśli decyzji jeszcze nie ma, wpisz, kto i kiedy ją podejmie.
Strefa docelowa. Struktura kont lub subskrypcji, sieć i łączność z lokalizacjami firmy, zarządzanie tożsamością, bazowe polityki bezpieczeństwa, centralne logowanie, standard tagowania kosztów. Jeśli strefa już istnieje, zapisz, że partner pracuje na niej i nie zmienia jej bez zgody.
Przenoszenie danych. Metoda (replikacja ciągła, eksport i import, transfer fizyczny), maksymalne dopuszczalne okno przestoju dla każdej aplikacji, sposób weryfikacji kompletności danych. Hasło migracja danych w naszym słowniku opisuje typowe podejścia.
Plan testów. Rodzaje testów (funkcjonalne, integracyjne, wydajnościowe, odtwarzania), kto przygotowuje scenariusze, kto je wykonuje i kto podpisuje wynik.
Przełączenie i wycofanie. Procedura dla każdej fali, z kryteriami decyzji „idziemy” lub „wracamy” (o tym niżej).
Okres wzmożonego wsparcia. Ile tygodni partner pozostaje w gotowości po przełączeniu, w jakich godzinach i z jakim czasem reakcji.
Dokumentacja i przekazanie wiedzy. Jakie dokumenty powstaną (architektura, instrukcje operacyjne, procedury awaryjne), w jakim formacie i ile godzin warsztatów przekazania przewidziano dla Twojego zespołu.
Wyłączenia. Jawna lista rzeczy, których partner nie robi: na przykład modernizacji kodu aplikacji, licencji oprogramowania firm trzecich, utrzymania po okresie wsparcia.
Założenia. Lista warunków, na których partner opiera cenę: dostępność osób po Twojej stronie, terminy udostępnienia środowisk, liczba okien serwisowych. To ta lista najczęściej staje się źródłem zleceń zmian, więc czytaj ją uważniej niż samą cenę.
Kiedy wszyscy oferenci wyceniają ten sam dokument, różnice w cenie zaczynają coś mówić. Nadal mogą wynikać ze stawek, doświadczenia czy marży, ale przestają wynikać z tego, że każdy wycenił inną usługę.
Kto odpowiada za co i dlaczego macierz odpowiedzialności rozstrzyga spory?
Migracja do chmury jest pracą wspólną. Partner nie przetestuje reguł biznesowych aplikacji, której nie zna, nie wyznaczy okna przestoju dla działu sprzedaży i nie zdobędzie zgody właściciela systemu kadrowego na przełączenie w czwartek wieczorem. Te rzeczy musi zrobić zamawiający. Gdy umowa tego nie zapisuje, każde opóźnienie po Twojej stronie staje się podstawą do przesunięcia terminów i dodatkowej faktury, a każde opóźnienie po stronie partnera łatwo przypisać „brakowi dostępu”.
Dlatego do umowy warto dołączyć macierz odpowiedzialności w formacie RACI: kto wykonuje, kto zatwierdza, kogo się konsultuje, kogo informuje. Dla każdej czynności z zakresu prac jedna osoba odpowiedzialna. Typowe pozycje po stronie zamawiającego to: udostępnienie dostępów i kont w określonym terminie, wskazanie właścicieli aplikacji, przygotowanie danych testowych, wykonanie testów akceptacyjnych przez użytkowników, zatwierdzenie okien serwisowych, decyzja „idziemy” lub „wracamy” przy przełączeniu, zakup lub przeniesienie licencji.
Osobną warstwą jest model współdzielonej odpowiedzialności dostawcy chmury. AWS, Microsoft i Google odpowiadają za bezpieczeństwo samej chmury, czyli infrastrukturę fizyczną i warstwę wirtualizacji, a klient odpowiada za to, co w chmurze uruchamia: konfigurację, tożsamość, dane i aplikacje. Partner migracyjny wchodzi w tę drugą połowę. Macierz powinna więc jasno rozdzielać, które elementy konfiguracji partner tworzy i przekazuje, a które Ty potem utrzymujesz.
Szczególną uwagę poświęć licencjom. Przeniesienie systemu z licencją przypisaną do fizycznego serwera do współdzielonej infrastruktury chmurowej bywa niezgodne z warunkami licencji albo znacznie droższe. To temat na osobną analizę, którą opisaliśmy w artykule o planowaniu licencji przy migracji on-premise do chmury. W macierzy wystarczy zapisać, kto odpowiada za weryfikację zgodności licencyjnej każdego obciążenia przed jego przeniesieniem.
Jak zapisać kryteria odbioru każdej fali migracji?
Odbiór jest miejscem, w którym większość umów migracyjnych jest najsłabsza. Zapis „odbiór nastąpi po pomyślnym przeniesieniu systemów” nie znaczy nic, bo „pomyślnie” nie jest zdefiniowane. W praktyce kończy się to podpisaniem protokołu, gdy serwery odpowiadają na zapytania, a wszystkie problemy wykryte w kolejnych tygodniach stają się Twoje.
Odbiór warto robić per fala, a nie raz na końcu projektu. Fala to grupa obciążeń przenoszonych razem, bo od siebie zależą. Każda fala ma własną listę kryteriów, a dopiero jej zaliczenie otwiera kolejną falę i kolejną płatność. Kryteria powinny być mierzalne i sprawdzalne bez dyskusji. Oto zestaw, od którego można zacząć:
- Funkcjonalność. Scenariusze testowe przygotowane przez właściciela aplikacji wykonane i zaliczone, z protokołem podpisanym przez tę osobę.
- Wydajność. Czasy odpowiedzi kluczowych operacji i czas zadań wsadowych nie gorsze niż zmierzone przed migracją, z określoną tolerancją. To wymaga pomiaru bazowego przed przeniesieniem, więc wpisz go do zakresu prac.
- Odtwarzanie. Kopia zapasowa wykonana w nowym środowisku i faktycznie odtworzona w teście, a nie tylko skonfigurowana. Zapisz docelowe RPO i RTO, czyli dopuszczalną utratę danych i czas przywrócenia.
- Monitoring i alerty. Metryki, logi i powiadomienia działają i trafiają do zespołu, który będzie utrzymywał system.
- Bezpieczeństwo. Konfiguracja zgodna z bazowymi politykami strefy docelowej, bez publicznie dostępnych zasobów, których nie powinno być, z uprawnieniami według zasady najmniejszych przywilejów.
- Koszty. Wszystkie zasoby oznaczone tagami zgodnie ze standardem, tak aby rachunek dało się przypisać do aplikacji i właściciela.
- Dokumentacja. Instrukcja operacyjna dla fali przekazana i przejrzana przez Twój zespół.
Ostatnie dwa punkty wydają się formalnością, ale mają duże znaczenie finansowe. Według raportu Flexera 2025 State of the Cloud, opublikowanego w marcu 2025 roku na podstawie ankiety wśród ponad 750 specjalistów i menedżerów, 84% respondentów uznało zarządzanie wydatkami na chmurę za największe wyzwanie, a budżety chmurowe były już przekroczone średnio o 17%. Zasoby bez tagów to zasoby, których kosztu nie da się przypisać, a więc trudno go kontrolować. O tym, jak zbudować tę kontrolę po migracji, piszemy w artykule FinOps 101.
W umowie zapisz też procedurę odbioru: ile dni roboczych masz na weryfikację, jak zgłaszasz usterki, jak klasyfikuje się ich wagę i które z nich blokują odbiór. Dobrą praktyką jest rozróżnienie usterek blokujących od drobnych, które partner usuwa w ustalonym terminie po odbiorze.
Co powinno się znaleźć w planie przełączenia i wycofania?
Przełączenie to moment, w którym ruch użytkowników trafia do nowego środowiska. To najbardziej ryzykowna godzina całego projektu, a w wielu ofertach opisana jednym zdaniem. Plan przełączenia powinien być osobnym dokumentem dla każdej fali, przygotowanym przez partnera i zatwierdzonym przez Ciebie przed jej rozpoczęciem.
Plan przełączenia zawiera listę kroków z czasem trwania i osobą odpowiedzialną, warunki wstępne (na przykład zakończona synchronizacja danych, zamrożenie zmian w systemie źródłowym), punkty kontrolne i kryteria decyzji na każdym z nich. Najważniejszy jest punkt bez powrotu: moment, po którym wycofanie staje się droższe niż naprawa w nowym środowisku. Do tego punktu decyzja „wracamy” musi być możliwa i przećwiczona.
Plan wycofania odpowiada na pytanie, co robimy, gdy coś pójdzie źle. Jak długo system źródłowy pozostaje w gotowości, w jaki sposób dane zmienione w nowym środowisku wrócą do starego, ile trwa powrót i kto podejmuje decyzję. Strona ARDURA o architektach cloud opisuje sześciofazową metodykę migracji, w której pełna realizacja odbywa się z planami wycofania. Niezależnie od tego, kogo wybierzesz, wymagaj, żeby plan wycofania istniał na piśmie i był testowany przynajmniej na jednej fali pilotażowej z mniej krytycznymi obciążeniami.
W umowie zapisz, że decyzję „idziemy” lub „wracamy” podejmuje wskazana osoba po Twojej stronie, na podstawie kryteriów z planu. Partner rekomenduje, Ty decydujesz. Zapisz też, kto ponosi koszt powtórnego podejścia, jeśli przełączenie zostanie wycofane z przyczyn leżących po stronie partnera. Bez tego zapisu każde nieudane przełączenie to dodatkowe dni robocze na Twoim rachunku.
Dobrze jest także przewidzieć zamrożenie zmian. Na kilka dni przed przełączeniem i kilka dni po nim zespoły rozwojowe nie wdrażają nowych wersji aplikacji, które są przenoszone. Takie zamrożenie wymaga uzgodnienia wewnątrz firmy, więc wpisz je do harmonogramu i macierzy odpowiedzialności, a nie odkrywaj go w tygodniu migracji.
Jak chronić cenę przed zmianami zakresu?
Zmiany zakresu w migracji są nieuniknione. Inwentaryzacja nigdy nie jest kompletna, bo zawsze znajdzie się zapomniane zadanie cykliczne, nieudokumentowana integracja albo serwer, który „nie jest używany”, dopóki ktoś go nie wyłączy. Celem umowy nie jest wykluczenie zmian, tylko sprawienie, żeby były przewidywalne i wyceniane według z góry znanych zasad.
Pierwszym narzędziem jest podział na dwa etapy. Ocena stanu obecnego, inwentaryzacja z zależnościami i plan migracji to osobne, krótkie zlecenie o stałej cenie. Jego wynikiem jest zakres prac dla drugiego etapu, czyli samej migracji. Taki podział zmniejsza rezerwę na ryzyko w cenie drugiego etapu i daje Ci dokument, z którym możesz pójść do innego wykonawcy, jeśli pierwszy nie przekona Cię do dalszej współpracy. Upewnij się, że umowa na ocenę przenosi na Ciebie prawa do jej wyników.
Drugim narzędziem jest cennik jednostkowy. Zamiast jednej kwoty za całość poproś o cenę za typ obciążenia, na przykład: aplikacja webowa przenoszona bez zmian, baza danych przenoszona do usługi zarządzanej, aplikacja wymagająca zmiany platformy. Do tego stawki dzienne dla ról na prace poza cennikiem. Gdy w trakcie projektu znajdzie się dziesięć dodatkowych serwerów, ich wycena jest arytmetyką, a nie negocjacją.
Trzecim narzędziem jest procedura zlecenia zmiany. Każda zmiana zakresu wymaga pisemnego wniosku z opisem, wyceną i wpływem na harmonogram, zatwierdzonego przez wskazaną osobę po Twojej stronie przed rozpoczęciem pracy. Prace wykonane bez zatwierdzonego wniosku nie są płatne. Brzmi formalnie, ale chroni obie strony przed sporem o to, co było „oczywiście w zakresie”.
Czwartym narzędziem jest limit. W modelu time and materials zapisz miesięczny lub całkowity limit godzin, którego przekroczenie wymaga Twojej zgody, i obowiązek raportowania zużycia co tydzień, z prognozą do końca. Porównanie modeli rozliczeń i tego, jak rozkładają ryzyko między stronami, znajdziesz w artykule o abonamencie zespołu, time and materials i fixed price.
Jak powiązać płatności z postępem, a nie z kalendarzem?
Najczęstszy harmonogram płatności w ofertach migracyjnych to raty miesięczne albo zaliczka plus raty. Taki układ płaci za upływ czasu, a nie za wynik. Jeśli projekt się opóźnia, Ty nadal płacisz, a partner nie ma finansowej motywacji, żeby przyspieszyć.
Lepiej powiązać płatności z kamieniami milowymi, które da się obiektywnie sprawdzić. Przykładowy układ: płatność za zakończoną ocenę stanu obecnego po odbiorze raportu i planu, płatność za strefę docelową po jej odbiorze według kryteriów bezpieczeństwa i tagowania, płatność za każdą falę po jej odbiorze według kryteriów opisanych wyżej, płatność końcowa po zakończeniu okresu wzmożonego wsparcia i przekazaniu dokumentacji.
Warto rozważyć zatrzymanie części wynagrodzenia. Kilka lub kilkanaście procent wartości każdej fali wypłaca się dopiero po zakończeniu okresu wsparcia całego projektu. To zabezpiecza sytuację, w której problemy ujawniają się po kilku tygodniach, na przykład przy pierwszym zamknięciu miesiąca w systemie finansowym. Wysokość takiej kwoty jest przedmiotem negocjacji i zależy od ryzyka projektu; ważne, żeby zasady jej wypłaty były zapisane jednoznacznie.
W modelu time and materials kamienie milowe też mają sens, choć nie jako warunek płatności za przepracowane godziny. Mogą wyznaczać punkty przeglądu, w których porównujesz zużycie budżetu z postępem i decydujesz o kontynuacji. Jeśli po przeniesieniu dwóch z sześciu fal zużyto 60% budżetu, wiesz o problemie na tyle wcześnie, żeby coś z nim zrobić.
Jakie klauzule chronią przed uzależnieniem od partnera i od chmury?
Uzależnienie ma dwa wymiary. Pierwszym jest partner migracyjny: jeśli tylko on wie, jak zbudowano środowisko, i tylko on ma do niego pełny dostęp, każda zmiana wymaga jego udziału, a zmiana wykonawcy staje się projektem samym w sobie. Drugim jest dostawca chmury: jeśli architektura opiera się na usługach specyficznych dla jednej platformy, przeniesienie gdzie indziej jest kosztowne. Pierwszy rodzaj uzależnienia jest prawie zawsze niepotrzebny. Drugi bywa świadomym wyborem, ale powinien być wyborem, a nie przypadkiem.
Przeciw uzależnieniu od partnera działają cztery zapisy. Konta, subskrypcje i projekty chmurowe należą do Twojej organizacji od pierwszego dnia, a partner dostaje dostęp przez role, które możesz odebrać. Kod infrastruktury (Terraform, CloudFormation, Bicep) trafia do Twojego repozytorium na bieżąco, a nie na koniec projektu. Prawa do dokumentacji, skryptów i konfiguracji przechodzą na Ciebie z chwilą zapłaty za dany etap. Umowa opisuje obowiązki partnera przy jej zakończeniu: przekazanie haseł i kluczy, usunięcie własnych dostępów, określona liczba godzin wsparcia przy przejęciu przez nowy zespół.
Przeciw niekontrolowanemu uzależnieniu od chmury działa świadoma decyzja architektoniczna zapisana w planie migracji, z uzasadnieniem, oraz plan wyjścia. Tu pomaga prawo unijne. Data Act, czyli rozporządzenie (UE) 2023/2854, stosuje się od 12 września 2025 roku. Zgodnie z jego art. 25 umowa z dostawcą usług przetwarzania danych musi przewidywać maksymalny okres wypowiedzenia na rozpoczęcie zmiany dostawcy nie dłuższy niż dwa miesiące, a sama zmiana powinna nastąpić bez zbędnej zwłoki i co do zasady w okresie przejściowym nie dłuższym niż 30 dni kalendarzowych. Jeśli to technicznie niewykonalne, dostawca może zaproponować dłuższy okres, nie dłuższy niż siedem miesięcy. Art. 29 stanowi, że od 12 stycznia 2027 roku dostawcy nie mogą pobierać opłat za zmianę dostawcy. Pełny tekst jest dostępny w EUR-Lex.
Przepisy te dotyczą Twojej umowy z dostawcą chmury, a nie z partnerem migracyjnym, ale zmieniają rachunek wyjścia. Koszt przeniesienia danych przestaje być główną barierą, a coraz większą rolę odgrywa to, ile usług specyficznych dla platformy wbudowano w aplikacje. Dlatego warto wymagać, żeby plan migracji dla każdego obciążenia wskazywał zależności od usług danej chmury. O tym, jak ten koszt wyjścia policzyć jeszcze przed wejściem, pisaliśmy w artykule o kalkulatorze kosztów migracji do chmury.
Co zmienia regulacja DORA, jeśli działasz w sektorze finansowym?
Jeśli Twoja firma jest podmiotem finansowym w rozumieniu rozporządzenia DORA (UE 2022/2554), umowa migracyjna i umowa z dostawcą chmury podlegają dodatkowym wymogom. DORA stosuje się od 17 stycznia 2025 roku. Jej art. 30 określa minimalną treść umów z zewnętrznymi dostawcami usług ICT, w tym jasny opis świadczonych funkcji i usług oraz prawa wypowiedzenia i minimalne okresy wypowiedzenia. Dla usług wspierających funkcje krytyczne lub istotne wymagania są szersze i obejmują m.in. precyzyjne cele jakościowe, prawa dostępu i audytu oraz strategie wyjścia z odpowiednim okresem przejściowym.
W praktyce oznacza to, że dział prawny i zespół zarządzania ryzykiem powinni zobaczyć projekt umowy przed negocjacjami, a nie po nich. Partner migracyjny pracujący dla sektora finansowego powinien znać te wymagania i bez oporu przyjmować klauzule o audycie, podwykonawcach i wyjściu. Jeśli traktuje je jako egzotyczne żądania, to informacja o jego doświadczeniu.
Nawet jeśli DORA Cię nie obejmuje, jej struktura jest dobrym wzorem. Opis usług, lokalizacje przetwarzania danych, prawo audytu, zasady korzystania z podwykonawców i plan wyjścia to rzeczy, które warto mieć w każdej umowie dotyczącej infrastruktury krytycznej dla działania firmy. Regulacja sektorowa jedynie wymusza to, co rozsądny zamawiający i tak powinien chcieć zapisać.
Jak porównać oferty migracyjne, patrząc na zapisy, a nie na kwoty?
Poniższa tabela zbiera kryteria z poprzednich sekcji w jedną listę kontrolną. Przejdź ją dla każdej oferty przed porównaniem cen. Oferta, która przegrywa w kilku wierszach, może być tańsza na papierze i droższa w realizacji.
| Obszar | Co sprawdzić w ofercie lub projekcie umowy | Sygnał, że jest dobrze | Sygnał ostrzegawczy |
|---|---|---|---|
| Zakres | Zamknięta lista obciążeń ze strategią dla każdego | Załącznik z listą i decyzjami 7R | „Migracja środowiska” bez listy |
| Założenia i wyłączenia | Jawna lista warunków ceny i rzeczy poza zakresem | Krótka, konkretna lista | Brak listy albo kilkadziesiąt ogólnych zastrzeżeń |
| Odpowiedzialność | Macierz RACI dla wszystkich czynności | Jedna osoba odpowiedzialna za każdą czynność | Obowiązki klienta opisane ogólnie |
| Odbiór | Mierzalne kryteria per fala | Wydajność, odtwarzanie, monitoring, tagi | „Pomyślne przeniesienie systemów” |
| Przełączenie | Plan przełączenia i wycofania per fala | Punkt bez powrotu, decyzja po stronie klienta | Jedno zdanie o „oknie serwisowym” |
| Zmiany | Cennik jednostkowy i procedura zleceń zmian | Ceny za typ obciążenia, stawki ról | Każda zmiana wyceniana indywidualnie |
| Płatności | Powiązanie z odbiorem etapów | Płatność za odebraną falę, zatrzymana część | Raty miesięczne niezależne od postępu |
| Własność | Konta, kod infrastruktury, dokumentacja | Wszystko w organizacji klienta od dnia 1 | Środowisko budowane na kontach partnera |
| Wsparcie po przełączeniu | Długość, godziny, czas reakcji | Określone tygodnie i SLA reakcji | „Wsparcie w razie potrzeby” |
| Przekazanie wiedzy | Dokumenty i warsztaty dla zespołu | Lista dokumentów i liczba godzin | Dokumentacja „na koniec projektu” |
| Koszty chmury | Optymalizacja i tagowanie | Standard tagów, przegląd kosztów po fali | Brak słowa o rachunku po migracji |
| Wyjście | Obowiązki przy zakończeniu umowy | Przekazanie dostępów, godziny wsparcia | Brak zapisów o zakończeniu |
Tabela nie zastępuje rozmowy technicznej z ludźmi, którzy będą realizować projekt, ale pozwala zadać właściwe pytania. Dobry partner na większość z nich ma gotowe odpowiedzi, bo sam chce pracować w przewidywalnych warunkach.
Jakie zapisy w umowie powinny zatrzymać podpis?
Część problemów widać dopiero w projekcie umowy, a nie w ofercie. Oto zapisy, przy których warto się zatrzymać i negocjować.
Odpowiedzialność ograniczona symbolicznie. Limit odpowiedzialności partnera równy jednemu miesięcznemu wynagrodzeniu przy projekcie, którego nieudane przełączenie może zatrzymać sprzedaż na kilka dni, nie odpowiada ryzyku. Limit jest normalnym elementem umów IT, ale jego wysokość powinna mieć związek ze skalą możliwej szkody.
Wykonanie „z należytą starannością” bez kryteriów odbioru. Zobowiązanie starannego działania jest właściwe dla doradztwa, ale migracja ma mierzalny wynik. Jeśli umowa nie zawiera kryteriów odbioru, partner odpowiada za wysiłek, a nie za rezultat.
Środowisko na kontach partnera. Jeśli partner proponuje, że „na początek” zbuduje środowisko w swojej organizacji chmurowej i przeniesie je później, przenosiny mogą okazać się osobnym projektem. Wymagaj, żeby od pierwszego dnia pracował w Twojej.
Zakup zobowiązań chmurowych przez partnera. Instancje zarezerwowane albo plany oszczędnościowe kupione przed migracją i dopasowaniem rozmiarów utrwalają złe decyzje na rok lub trzy lata. Decyzja o zobowiązaniach należy do Ciebie i powinna zapaść po ustabilizowaniu obciążeń.
Nieujawnieni podwykonawcy. Masz prawo wiedzieć, kto ma dostęp do Twojego środowiska. Umowa powinna wymagać zgody na podwykonawców albo przynajmniej ich listy.
Automatyczne przedłużenie wsparcia. Okres wsparcia po przełączeniu, który bez wypowiedzenia zamienia się w umowę utrzymaniową na rok, to sprzedaż ukryta w umowie migracyjnej. Utrzymanie może mieć sens, ale powinno być osobną decyzją.
Brak zapisów o danych po zakończeniu. Jeśli partner miał dostęp do kopii danych na swoich nośnikach lub kontach, umowa powinna określać, kiedy i jak je usunie oraz jak to potwierdzi.
Kiedy zamiast zlecenia „pod klucz” lepiej wzmocnić własny zespół?
Zlecenie migracji w całości partnerowi ma sens, gdy w firmie brakuje kompetencji chmurowych, a projekt jest duży i jednorazowy. Ma też koszt ukryty: po zakończeniu projektu wiedza o środowisku zostaje głównie u partnera, a Twój zespół dostaje dokumentację i kilka warsztatów. Jeśli chmura ma stać się podstawową platformą firmy na lata, to Twój zespół będzie ją utrzymywał, rozwijał i optymalizował.
Alternatywą jest model, w którym migrację prowadzi Twój zespół, wzmocniony doświadczonymi architektami i inżynierami chmurowymi pracującymi w nim na co dzień. Odpowiedzialność za wynik zostaje wtedy po Twojej stronie, ale wiedza też. Ten model dobrze sprawdza się, gdy masz już kilka osób z doświadczeniem infrastrukturalnym i brakuje Ci głównie projektanta architektury docelowej oraz kogoś, kto przeprowadził podobne migracje.
W ARDURA Consulting architekci cloud pracują w tym modelu. Według naszego cennika stawki specjalistów chmurowych wynoszą od 1600 do 3600 zł netto za dzień, zależnie od poziomu doświadczenia i specjalizacji. Standardowy czas wdrożenia architekta w zespół to dwa tygodnie, a w pilnych przypadkach 48–72 godziny. Obowiązuje dwutygodniowa gwarancja satysfakcji z bezpłatną wymianą, jeśli specjalista nie spełni oczekiwań. Przy migracjach dużą rolę odgrywają też inżynierowie DevOps, którzy budują automatyzację wdrożeń i infrastrukturę jako kod.
Możliwy jest też wariant mieszany: ocena stanu obecnego i plan migracji jako zlecenie zewnętrzne o stałej cenie, a realizacja przez Twój zespół ze wsparciem zewnętrznych specjalistów. Wybór zależy od tego, czy bardziej zależy Ci na przeniesieniu odpowiedzialności, czy na zbudowaniu własnych kompetencji. Ogólne porównanie tych dwóch logik znajdziesz na stronie staff augmentation a outsourcing.
Jakie są kluczowe wnioski przed podpisaniem umowy migracyjnej?
Migracja do chmury jest projektem, w którym łatwo kupić coś innego, niż się sądzi. Oferty różnią się nie tyle stawkami, co definicją usługi, a ta różnica wychodzi na jaw dopiero przy pierwszym nieudanym przełączeniu albo pierwszym rachunku za chmurę.
Zapamiętaj sześć rzeczy. Po pierwsze, przygotuj własny zakres prac z zamkniętą listą obciążeń i poproś wszystkich oferentów o wycenę tego samego dokumentu. Jeśli nie masz danych, żeby go napisać, zacznij od osobnego zlecenia na ocenę stanu obecnego. Po drugie, dołącz macierz odpowiedzialności, w której obowiązki po Twojej stronie są tak samo konkretne jak po stronie partnera. Po trzecie, zdefiniuj mierzalne kryteria odbioru dla każdej fali: funkcjonalność, wydajność, odtwarzanie, monitoring, bezpieczeństwo, tagi kosztowe i dokumentację. Po czwarte, wymagaj planu przełączenia i wycofania z punktem bez powrotu i decyzją po Twojej stronie. Po piąte, chroń cenę cennikiem jednostkowym, procedurą zleceń zmian i płatnościami za odebrane etapy, a nie za upływ czasu. Po szóste, zadbaj, żeby konta, kod infrastruktury i dokumentacja należały do Ciebie od pierwszego dnia, a plan wyjścia uwzględniał prawa wynikające z Data Act.
Jeśli zastanawiasz się, czy przeprowadzić migrację własnym zespołem wzmocnionym doświadczonymi specjalistami, czy zlecić ją w całości, zobacz, jak pracują nasi architekci cloud albo umów rozmowę. Powiemy, jakich ról potrzebujesz na którym etapie i ile będą kosztować.