Usługi migracji do chmury: co naprawdę robi partner migracyjny, jak się rozlicza i jak go wybrać?

CTO firmy logistycznej dostaje trzy oferty na migrację 80 aplikacji z serwerowni kolokacyjnej, której umowa wygasa za 14 miesięcy. Pierwsza to cena stała 1,7 mln zł. Druga — time & materials z szacunkiem 3 mln zł. Trzecia opiewa na 4,4 mln zł i zawiera rok „usług zarządzanych”. Zarząd zadaje oczywiste pytanie: dlaczego ta sama migracja kosztuje u jednego dostawcy prawie trzy razy więcej niż u drugiego?

Odpowiedź brzmi: to nie są trzy ceny tej samej rzeczy. Pierwsza oferta obejmuje przeniesienie maszyn wirtualnych bez zmian i zostawia klientowi landing zone, bezpieczeństwo i aktualizacje baz danych. Druga zakłada, że partner przeniesie jedną trzecią portfela na usługi zarządzane. Trzecia zawiera rok utrzymania, którego dwie pozostałe nie uwzględniają. Usługi migracji do chmury nie są towarem, a słowo „migracja” ukrywa bardzo różne zakresy.

Ma to znaczenie, bo migracje psują się drogo. Badanie McKinsey przeprowadzone wśród prawie 450 CIO i liderów IT pokazało, że nieefektywna koordynacja migracji kosztuje przeciętną firmę o 14% więcej, niż planowała, a 38% firm doświadczyło opóźnień migracji dłuższych niż kwartał. Poniżej pokazujemy, co partner migracyjny powinien robić w każdej fazie, jak cztery modele rozliczeń wypadają na przykładzie liczbowym, jak dostawcy chmury dofinansowują pracę partnerów w 2026 roku i jak rozpoznać słabą ofertę przed podpisaniem umowy.

Co naprawdę obejmują usługi migracji do chmury?

Kompletne zlecenie migracji do chmury obejmuje sześć obszarów. Większość ofert pokrywa część z nich, a budżety pękają właśnie w lukach:

1. Ocena stanu obecnego (assessment) — inwentaryzacja serwerów, aplikacji i zależności, uzasadnienie biznesowe i model całkowitego kosztu posiadania.
2. Strategia migracji — decyzja dla każdego obciążenia: wycofać, zostawić, przenieść bez zmian czy zmienić po drodze.
3. Landing zone — środowisko docelowe: struktura kont, sieć, tożsamość, bazowe zabezpieczenia, logowanie i polityki.
4. Fale migracji — przenoszenie obciążeń w grupach, testy, przełączenie i okres wzmożonego wsparcia.
5. Optymalizacja i FinOps — dopasowanie rozmiarów, zobowiązania zakupowe, alokacja kosztów i nadzór po uruchomieniu.
6. Utrzymanie — opcjonalne bieżące zarządzanie, monitoring i obsługa incydentów.

Dobry partner wnosi też elementy łączące: zarządzanie programem, zarządzanie zmianą w zespołach klienta, akceptację bezpieczeństwa i zgodności oraz transfer wiedzy, żeby klient nie był od niego zależny po zakończeniu projektu.

Praktyczny test każdej oferty jest prosty: przypisz każdą pozycję oferty do jednego z tych sześciu obszarów i zaznacz, czego brakuje. Tania oferta obejmująca dwa obszary nie jest tańsza od drogiej obejmującej pięć — przerzuca pozostałe trzy na Twój zespół, zwykle bez budżetu.

Ten artykuł dotyczy partnera: co dostarcza, jak się rozlicza i jak go wybrać. Stronę operacyjną — co robić w którym tygodniu i o jakich polskich wymaganiach prawnych pamiętać — opisaliśmy w checkliście migracji do chmury krok po kroku. Rachunek biznesowy znajdziesz w artykule o kalkulatorze kosztów migracji do chmury.

Co dzieje się w fazie oceny stanu obecnego i co powinna dostarczyć?

Ocena stanu obecnego to najtańsza faza i ta o największej dźwigni. W naszym przykładzie liczbowym odpowiada za ok. 5% budżetu partnera, a decyduje o pozostałych 95%.

Porządna ocena dostarcza pięciu produktów:

• Inwentaryzacji z zależnościami. Nie tylko listy serwerów z CMDB, ale wykrytych przepływów sieciowych między aplikacjami. Narzędzia takie jak AWS Application Discovery Service, Azure Migrate czy Google Cloud Migration Center zbierają je automatycznie. Zależności decydują, które aplikacje muszą migrować razem — a więc jak układają się fale.
• Klasyfikacji każdego obciążenia według strategii. Każda aplikacja dostaje jedną ze strategii 7R z uzasadnieniem (o tym w kolejnej sekcji).
• Docelowego modelu kosztów. Prognozowanych miesięcznych wydatków w chmurze dla każdego obciążenia, łącznie z przechowywaniem danych, transferem wychodzącym i licencjami — nie tylko mocą obliczeniową.
• Przeglądu licencji. Licencje Microsoftu, Oracle i innych producentów działają inaczej w każdej chmurze. Błąd potrafi zjeść całą oszczędność — pułapki opisaliśmy w artykule o planowaniu licencji przy migracji on-premise do chmury.
• Planu fal i rejestru ryzyk. Które grupy migrują kiedy, co może pójść źle i kto podejmuje decyzje.

Zapytaj partnera, ile potrwa ocena i co dokładnie dostaniesz na jej końcu. Dla portfela ok. 80 aplikacji realne są cztery do sześciu tygodni. „Ocena” wykonana w tydzień na podstawie wysłanego przez Ciebie arkusza to prezentacja sprzedażowa.

Jeszcze jedno: ocena musi mieć prawo zakończyć się wnioskiem, że część obciążeń nie powinna migrować. Partner opłacany wyłącznie za przeniesione serwery ma motywację, żeby przenieść wszystko. Partner, któremu płacisz za ocenę jako osobny produkt, może powiedzieć, że stary system do wymiany za 18 miesięcy powinien zostać na miejscu.

Jak partner wybiera strategię 7R dla każdego obciążenia?

AWS Prescriptive Guidance opisuje siedem strategii migracji, znanych jako 7R. Pozostali dostawcy używają podobnych list pod innymi nazwami, więc warto je znać niezależnie od docelowej chmury:

Strategia	Co oznacza	Typowe zastosowanie
Retire	Wycofanie aplikacji	Systemy nieużywane lub zdublowane
Retain	Pozostawienie na razie na miejscu	Systemy do wymiany, ograniczenia regulacyjne
Rehost	Przeniesienie bez zmian („lift and shift”)	Większość portfela w migracji z twardym terminem
Relocate	Przeniesienie na poziomie hiperwizora, np. VMware do usługi VMware w chmurze	Duże środowiska VMware z datą wyjścia
Replatform	Przeniesienie z niewielkimi zmianami, np. na zarządzaną bazę danych	Bazy danych, middleware, standardowe serwery aplikacyjne
Repurchase	Zastąpienie produktem SaaS	CRM, HR, narzędzia do współpracy
Refactor	Przebudowa pod usługi natywne dla chmury	Systemy kluczowe, w których skalowalność lub tempo zmian uzasadnia koszt

Wytyczne AWS mówią wprost o czymś, co oferty często pomijają: przy dużych migracjach zalecane są głównie rehost, replatform, relocate i retire, a modernizacja — po przeniesieniu. Przebudowa w trakcie migracji to najbardziej złożona strategia, a łączenie jej z migracją pod twardy termin to sposób na kwartalne opóźnienia.

Udział poszczególnych strategii wpływa na koszt bardziej niż cokolwiek innego. W naszym przykładzie przebudowa 10% aplikacji pochłania prawie połowę całej pracy migracyjnej. Gdy dwie oferty różnią się dwukrotnie, pierwsze pytanie brzmi: ile aplikacji każdy partner założył do przebudowy lub zmiany platformy? Często cała różnica leży właśnie tam.

Dobry partner pokazuje strategię dla każdej aplikacji z uzasadnieniem i szacunkiem pracochłonności oraz pozwala przesuwać aplikacje między kategoriami, żeby zobaczyć wpływ na koszt i harmonogram. Słaby podaje jeden podział procentowy dla całego portfela.

Dlaczego landing zone powstaje przed pierwszym przeniesionym serwerem?

Landing zone to fundament środowiska docelowego: struktura kont lub subskrypcji, topologia sieci i połączenie z biurami oraz serwerowniami, zarządzanie tożsamością i dostępem, bazowe zabezpieczenia, logowanie i monitoring oraz polityki, które nie pozwalają zespołom tworzyć zasobów poza regułami. Zwykle buduje się ją jako infrastrukturę jako kod, żeby dało się ją przeglądać, wersjonować i odtwarzać.

Pominięcie jej albo zrobienie jej w pośpiechu to najdroższy skrót w migracji do chmury. Obciążenia przeniesione do prowizorycznego środowiska trzeba przenieść drugi raz, gdy bezpieczeństwo lub sieć zostaną w końcu zrobione porządnie — migracja jest wtedy opłacana dwukrotnie.

Landing zone to też miejsce, w którym odpowiedzialność najczęściej ginie między stronami. Kto odpowiada za integrację tożsamości z Twoim katalogiem? Kto zatwierdza reguły zapory? Kto przechowuje poświadczenia konta głównego? Oferta powinna jawnie określać, co buduje partner, co buduje Twój zespół i kto będzie tym zarządzał później. „Landing zone w cenie” bez takiego podziału oznacza, że luki odkryjesz podczas pierwszej fali.

Trzej najwięksi dostawcy publikują architektury referencyjne — AWS Landing Zone Accelerator i Control Tower, strefy docelowe w Cloud Adoption Framework Microsoftu oraz blueprinty fundamentów Google Cloud. Partner powinien zaczynać od nich, a nie wymyślać własny projekt, i wyjaśniać, gdzie i dlaczego od nich odchodzi. Jeśli nie wybrałeś jeszcze dostawcy, porównanie znajdziesz w przewodniku AWS vs Azure vs GCP.

Jak przebiegają fale migracji i przełączenie?

Fale migracji grupują aplikacje, które muszą przenieść się razem z powodu zależności, wspólnych baz danych albo kalendarza biznesowego. Typowy program zaczyna od fali pilotażowej z kilkoma aplikacjami niskiego ryzyka, żeby sprawdzić narzędzia, procedury i landing zone, a potem przyspiesza.

Dla każdej fali dojrzały partner dostarcza:

• Procedurę przełączenia (runbook) — kroki z właścicielami, czasami i kryteriami wycofania.
• Replikację i synchronizację — narzędzia takie jak AWS Application Migration Service (obecnie pod marką AWS Transform MGN), Azure Migrate czy Google Cloud Migrate to VMs replikują serwery na bieżąco, więc przełączenie trwa minuty lub godziny, a nie dni. AWS daje 2160 bezpłatnych godzin replikacji na każdy serwer źródłowy, czyli 90 dni ciągłej replikacji; po tym czasie replikacja jest płatna za godzinę.
• Testy — funkcjonalne, wydajnościowe i bezpieczeństwa w środowisku docelowym przed przełączeniem.
• Przełączenie i wzmożone wsparcie — samo przełączenie, zwykle w oknie serwisowym, a po nim tydzień lub dwa podwyższonej gotowości.

Szczególnej uwagi wymagają bazy danych. Przeniesienie dużej bazy z minimalnym przestojem wymaga ciągłej replikacji, a okno na ostateczne przełączenie wyznaczają wolumen i tempo zmian danych, a nie optymizm. Zapytaj partnera, jak planuje przełączenia baz danych i co zrobił, gdy ostatnio musiał przełączenie wycofać.

Jak może wyglądać harmonogram dla portfela z naszego przykładu? Po odjęciu aplikacji wycofywanych i pozostawionych na miejscu do przeniesienia zostaje 60. Rozsądny układ to fala pilotażowa z trzema–pięcioma aplikacjami niskiego ryzyka, potem fale po osiem–dwanaście aplikacji co dwa–trzy tygodnie, a na końcu osobne fale dla systemów krytycznych i największych baz danych, planowane pod kalendarz biznesowy — nie w okresie zamknięcia roku ani szczytu sprzedaży. Przebudowywane aplikacje idą własnym torem, bo ich harmonogram wyznacza praca programistów, a nie narzędzia replikacji.

Tempo fal wpływa na koszt. Fale prowadzone równolegle skracają program, ale wymagają więcej ludzi naraz. Partner, który proponuje jedno przełączenie „big bang” dla 80 aplikacji, jest albo bardzo pewny siebie, albo nie przejrzał Twoich zależności.

Co dzieje się po uruchomieniu: optymalizacja, FinOps i utrzymanie?

Migracja kończy się na przełączeniu. Wartość zaczyna się po nim. Raport Flexera State of the Cloud 2026 szacuje, że 29% wydatków na IaaS i PaaS jest marnowanych — po raz pierwszy od pięciu lat ten odsetek wzrósł — a 85% respondentów wskazuje zarządzanie wydatkami na chmurę jako jedno z głównych wyzwań. Obciążenia przeniesione bez zmian są zwykle przewymiarowane, bo dobierano je pod szczyty w serwerowni z zapasem.

Skalę tego zjawiska łatwo przeliczyć. Jeśli po migracji portfela z naszego przykładu miesięczny rachunek za chmurę wyniesie 150 tys. zł, a marnotrawstwo będzie na średnim poziomie z raportu Flexery, firma traci ok. 522 tys. zł rocznie — więcej niż kosztowały razem ocena stanu obecnego i landing zone. Dlatego o wartości partnera w dużej mierze decyduje to, co robi po przełączeniu, a nie tylko to, jak sprawnie przenosi serwery. Warto też zapytać, kto po stronie partnera odpowiada za optymalizację i czy ta osoba zna Twoje obciążenia z fazy oceny, czy przejmuje je dopiero po migracji.

Faza optymalizacji u partnera powinna obejmować:

• Dopasowanie rozmiarów — korektę wielkości instancji do rzeczywistego wykorzystania po kilku tygodniach danych produkcyjnych.
• Zobowiązania zakupowe — savings plans, instancje zarezerwowane lub rabaty za zobowiązanie, gdy znany jest poziom bazowy. Kupione przed migracją utrwalają złe rozmiary.
• Alokację kosztów — tagowanie i raportowanie, żeby jednostki biznesowe widziały, co zużywają.
• Nadzór — budżety, alerty i polityki, które nie pozwalają marnotrawstwu wrócić.

To dyscyplina FinOps. Jest procesem ciągłym, a nie projektem — jak ją zorganizować wewnętrznie, opisaliśmy w przewodniku FinOps 101.

Usługi zarządzane — partner utrzymujący środowisko po migracji — są opcjonalne. Mają sens, gdy nie masz zespołu operacyjnego chmury albo potrzebujesz dyżurów 24/7. To także miejsce, w którym powstaje uzależnienie od dostawcy. Jeśli je kupujesz, wymagaj udokumentowanej infrastruktury jako kod w Twoich repozytoriach, procedur, których jesteś właścicielem, i klauzuli rozwiązania umowy z okresem przekazania.

Jakie modele rozliczeń stosują firmy migracyjne?

Partnerzy migracyjni stosują cztery główne modele rozliczeń, często łącząc je w jednym programie:

Cena stała za fazę. Stała opłata za ocenę, osobna za landing zone i ceny stałe za każdą falę, gdy zakres fali jest znany. Działa dobrze, gdy każda faza ma jasny produkt. Partner wycenia niepewność jako narzut na ryzyko — z naszego doświadczenia zwykle 15–25% ponad szacunek pracochłonności — i zabezpiecza się zleceniami zmian. Jak pisaliśmy w artykule o tym, kto naprawdę płaci za przeniesienie ryzyka w modelu fixed price, cena stała nie usuwa ryzyka, tylko przenosi jego koszt do ceny.

Time & materials (T&M). Płacisz za przepracowane godziny według uzgodnionych stawek. To najbardziej przejrzysty model, dobry dla faz o wysokiej niepewności, takich jak przebudowa. Wymaga aktywnego zarządzania po Twojej stronie: backlogu, priorytetów i regularnego porównywania zużycia budżetu z postępem.

Body leasing (staff augmentation). Partner dostarcza architektów chmury i inżynierów DevOps, którzy dołączają do Twojego zespołu i pracują pod Twoim kierownictwem. Ty odpowiadasz za plan i decyzje, partner dostarcza przepustowość i wiedzę. Model sprawdza się w organizacjach z silnym liderem wewnętrznym, którym brakuje rąk do pracy, a nie gotowego projektu. Zobacz, jak działa nasz body leasing.

Rozliczenie za efekt. Część wynagrodzenia zależy od wyników — liczby przeniesionych aplikacji, opuszczenia serwerowni w terminie albo osiągniętej redukcji kosztów chmury. Wyrównuje motywacje, ale wymaga precyzyjnych, mierzalnych definicji efektu uzgodnionych z góry. Rzadziej stosuje się go do całych migracji, częściej do zleceń optymalizacyjnych, w których oszczędności łatwo zmierzyć.

Porównując oferty, sprawdź też, co dokładnie kryje się za stawką. Oferta T&M ze stawką niższą o 20% może okazać się droższa, jeśli partner planuje więcej godzin, obsadza zespół mniej doświadczonymi osobami albo dolicza osobno zarządzanie projektem, licencje narzędzi i dyżury podczas przełączeń. Proś o rozbicie godzin na role i fazy oraz o listę pozycji rozliczanych poza stawką. Dopiero wtedy stawki da się porównać.

W praktyce najodporniejsze połączenie dla średniej migracji to: cena stała za ocenę, cena stała lub T&M za landing zone, cena stała za falę dla rehost i replatform oraz T&M lub body leasing dla przebudowy.

Ile kosztuje projekt migracji do chmury na przykładzie liczbowym?

Żeby modele dało się porównać, pokazujemy jawny przykład. To nie jest oferta, tylko przejrzysty model, który możesz dopasować do własnych liczb.

Założenia: 80 aplikacji, ok. 200 maszyn wirtualnych, jedna serwerownia, program na 12 miesięcy. Podział strategii: retire 10%, retain 15%, rehost 40%, replatform 20%, repurchase 5%, refactor 10%. Pracochłonność partnera na aplikację: retire 2 osobodni, retain 1, rehost 6, replatform 15, repurchase 12, refactor 60. Ocena 60 osobodni, landing zone 90, wzmożone wsparcie 10% ponad fale migracji, zarządzanie programem 12% ponad całość. Stawka uśredniona: 60% pracy seniorów DevOps i 40% architektów chmury, po środkach przedziałów z naszego benchmarku stawek body leasingu na 2026 rok (240 i 300 zł/h), czyli 264 zł za godzinę.

Składnik	Osobodni	Koszt (T&M)
Ocena stanu obecnego	67	141 926 zł
Landing zone	101	212 890 zł
Fale migracji ze wsparciem	1217	2 570 760 zł
Razem	1385	2 925 576 zł
Cena stała z narzutem 15%	—	3 364 413 zł
Cena stała z narzutem 25%	—	3 656 970 zł

Wyróżniają się trzy wnioski:

1. Przebudowa dominuje. Osiem aplikacji do przebudowy — 10% portfela — odpowiada za 49% pracy migracyjnej (480 z 988 osobodni). Przesunięcie trzech z nich do kategorii „najpierw replatform, przebudowa później” obniża całkowity koszt o ok. 350 tys. zł.
2. Ocena i landing zone są tanie w stosunku do swojego wpływu. Razem to ok. 12% budżetu, a decydują o koszcie wszystkiego innego.
3. Narzut ceny stałej to cena niepewności. Dopłata 440–730 tys. zł za cenę stałą ma sens tylko wtedy, gdy zakres jest dobrze rozpoznany — czyli po ocenie, a nie przed nią.

Liczy się też miejsce dostarczania. Te same ok. 11 tys. godzin po stawkach firm doradczych z Europy Zachodniej czy USA kosztowałyby wielokrotność tej kwoty — dlatego zagraniczni klienci często łączą lokalnego lidera z zespołem nearshore z Polski. Aktualne przedziały dla ról znajdziesz w naszym cenniku.

Jak programy AWS, Microsoftu i Google obniżają rachunek za partnera?

Wszyscy trzej najwięksi dostawcy współfinansują migracje, bo przeniesione obciążenie to lata zużycia. Środki zwykle płyną przez certyfikowanego partnera, więc jego status u dostawcy bezpośrednio wpływa na Twój koszt.

AWS Migration Acceleration Program (MAP). Składa się z trzech faz: Assess, Mobilize oraz Migrate & Modernize. Faza Assess obejmuje ocenę gotowości do migracji (Migration Readiness Assessment) w wymiarach AWS Cloud Adoption Framework oraz model TCO. Mobilize zamyka luki kompetencyjne, buduje landing zone i tworzy szczegółowy plan migracji. Migrate & Modernize to samo przenoszenie obciążeń. Finansowanie i kredyty zależą od prognozowanych wydatków w AWS i są naliczane według kamieni milowych i zużycia; przeniesione zasoby muszą być otagowane, a kredytów nie przyznaje się wstecz. Przewodniki partnerów publikowane w 2026 roku opisują kredyty w fazie Migrate & Modernize zwykle na poziomie 15–25% prognozowanych wydatków pierwszego roku — traktuj to orientacyjnie i potwierdź u opiekuna konta AWS.

Microsoft: od Azure Migrate & Modernize do Frontier Accelerate for Azure. W 2025 roku Microsoft połączył Azure Migrate & Modernize, Azure Innovate i nowy Cloud Accelerate Factory w jeden program — Azure Accelerate. Cloud Accelerate Factory oferuje bezpłatne wsparcie wdrożeniowe ekspertów Microsoftu dla ponad 30 usług Azure. W 2026 roku, w ramach ram partnerskich na rok fiskalny 2027, Microsoft zmienił nazwę programu na Frontier Accelerate for Azure. Nazwa zmieniła się dwa razy w dwa lata; istotne jest to, że finansowanie, oceny i wsparcie wdrożeniowe nadal płyną przez kwalifikowanych partnerów.

Google Cloud Rapid Migration and Modernization Program (RaMP). Zaczyna się od bezpłatnej oceny migracji. Obciążenia kwalifikują się od prognozowanych wydatków 60 tys. USD rocznie, a bazowe środki na usługi wynoszą 20% prognozowanych rocznych przychodów Google z obciążenia — do 2 mln USD na obciążenie — na pokrycie kosztów partnera lub Google Professional Services. Do tego dochodzą kredyty zależne od zużycia, wypłacane kwartalnie od wzrostu otagowanych obciążeń.

Trzy praktyczne uwagi. Po pierwsze, zapytaj każdego partnera, do których programów ma kwalifikacje i ile środków spodziewa się dla Ciebie pozyskać — a potem sprawdź to u dostawcy. Po drugie, finansowanie nie jest darmowe: wiąże się z zobowiązaniami co do prognozowanego zużycia, więc docelowy model kosztów musi być realistyczny. Po trzecie, programy co roku zmieniają nazwy i zasady, jak pokazuje historia Microsoftu; każda kwota w ofercie powinna mieć datę i źródło.

Kiedy nie potrzebujesz partnera do pełnej migracji?

Nie każda migracja wymaga partnera prowadzącego cały program. W trzech sytuacjach lżejszy model działa lepiej i kosztuje mniej.

Masz już silny zespół chmurowy. Jeśli od lat utrzymujesz obciążenia produkcyjne w docelowej chmurze, masz działającą landing zone i doświadczony zespół platformowy, brakuje zwykle przepustowości, a nie wiedzy. Kilku inżynierów pod Twoim kierownictwem — body leasing — kosztuje mniej niż zarządzanie programem i narzut na ryzyko partnera za decyzje, które Twój zespół podejmie sam.

Migracja jest mała lub jednorodna. Dziesięć maszyn wirtualnych ze standardowymi aplikacjami webowymi albo jedna baza danych przenoszona do usługi zarządzanej to zadanie dla zespołu wewnętrznego z kilkudniowym przeglądem eksperckim, a nie wielofazowy program. Narzędzia AWS, Microsoftu i Google dojrzały na tyle, że proste przeniesienie bez zmian jest dobrze udokumentowane.

Trudność nie leży w migracji. Czasem prawdziwym problemem jest aplikacja do przepisania albo platforma danych do przeprojektowania, a „migracja do chmury” to etykieta na projekcie modernizacyjnym. Wtedy potrzebujesz partnera od wytwarzania oprogramowania, który rozumie architekturę chmurową, a nie „fabryki migracji” zoptymalizowanej pod szybkie przenoszenie serwerów.

Jest też rozwiązanie pośrednie, które sprawdza się w wielu średnich firmach: partner dostarcza ocenę i landing zone jako pakiety w cenie stałej — fazy, w których doświadczenie specjalistów znaczy najwięcej, a błędy są najdroższe — a Twój zespół, wzmocniony kilkoma inżynierami z zewnątrz, realizuje fale. Zachowujesz kontrolę, budujesz kompetencje wewnętrzne i płacisz wysokie stawki tylko tam, gdzie dają najwięcej. W naszym przykładzie ocena i landing zone to ok. 355 tys. zł, czyli ok. 12% budżetu — a właśnie te dwa pakiety najczęściej decydują o tym, czy fale realizowane przez zespół wewnętrzny pójdą sprawnie.

Pytanie, które warto sobie zadać: kto po migracji będzie utrzymywał i zmieniał to środowisko? Jeśli Twój zespół — najważniejszym zadaniem partnera jest przygotowanie tego zespołu i model współpracy powinien to odzwierciedlać od pierwszego dnia. Jeśli partner — usługi zarządzane, warunki wyjścia i dokumentacja stają się sednem umowy, a nie załącznikiem.

Jak wybrać partnera do migracji do chmury?

Certyfikaty i odznaki partnerskie to filtr, a nie decyzja. Ma je niemal każdy poważny kandydat. Partnerów różni sposób pracy. Najważniejszych jest sześć kryteriów:

1. Imienny zespół. Kto dokładnie poprowadzi program i zaprojektuje architekturę? Poproś o CV i porozmawiaj z głównym architektem. Oferta obsadzona „starszym architektem chmury” to obietnica, a nie zespół.
2. Porównywalne referencje. Migracje o podobnej skali, technologii (np. Oracle, SAP, mainframe, VMware) i kontekście regulacyjnym. Zadzwoń do referencji i zapytaj, co poszło źle.
3. Ocena przed zobowiązaniem. Partner, który nalega na płatną ocenę przed wyceną całej migracji, uczciwie traktuje niepewność.
4. Jasny podział odpowiedzialności. Szczególnie za bezpieczeństwo, tożsamość, sieć i utrzymanie po uruchomieniu. Poproś o macierz RACI.
5. Transfer wiedzy i wyjście. Jak Twój zespół nauczy się utrzymywać środowisko? Co dzieje się na koniec umowy? Infrastruktura jako kod w Twoich repozytoriach to warunek bez negocjacji.
6. Model rozliczeń dopasowany do niepewności. Cena stała tam, gdzie zakres jest znany, T&M lub body leasing tam, gdzie nie jest.

Zapytanie ofertowe możesz ustrukturyzować tak, żeby odpowiedzi dało się porównać. Poproś każdego kandydata o:

• listę aplikacji z przypisaną strategią 7R i pracochłonnością — albo o wycenę samej oceny, jeśli jej jeszcze nie ma,
• rozbicie ceny na fazy i role, z pozycjami rozliczanymi poza stawką,
• opis landing zone z podziałem odpowiedzialności,
• plan fal z pierwszą falą pilotażową,
• nazwę programu dofinansowania i oczekiwaną kwotę,
• skład zespołu z CV i dostępnością,
• plan transferu wiedzy i warunki zakończenia współpracy.

Pytanie, które warto zadać każdemu kandydatowi: „Opowiedzcie o migracji, która poszła źle, i o tym, co potem zmieniliście”. Partner bez odpowiedzi ma mało doświadczenia albo nie mówi prawdy. Najlepsze odpowiedzi dotyczą konkretnego wycofanego przełączenia, przeoczonej zależności albo błędnego modelu kosztów — i procesu, który się po tym zmienił.

Na koniec pomyśl o modelu działania po migracji. Jeśli środowisko ma należeć do Twojego zespołu, potrzebujesz partnera, który buduje kompetencje równolegle z realizacją — na przykład wprowadzając architektów chmury i inżynierów DevOps do Twojego zespołu, zamiast pracować w czarnej skrzynce.

Na jakie sygnały ostrzegawcze uważać w ofercie migracji?

Niektóre wzorce w ofertach niezawodnie zapowiadają kłopoty:

• Cena stała za całą migrację przed jakąkolwiek oceną. Albo narzut na ryzyko jest zawyżony, albo partner planuje odzyskać koszty w zleceniach zmian. W obu przypadkach płacisz Ty.
• Jeden podział procentowy strategii dla całego portfela. „70% rehost, 30% replatform” bez listy aplikacji oznacza, że nikt nie przyjrzał się aplikacjom.
• Brak wzmianki o landing zone albo „landing zone w cenie” bez szczegółów. Fundament to najczęstsze źródło pracy wykonywanej dwa razy.
• Obiecane oszczędności bez modelu kosztów. „30% niższy koszt infrastruktury” bez liczb dla każdego obciążenia, licencji i transferu to marketing. Wynik McKinsey — średnio 14% przekroczenia budżetu migracji — powinien budzić sceptycyzm wobec każdej okrągłej obietnicy.
• Zakup zobowiązań przed migracją. Partner, który zaleca trzyletnie rezerwacje, zanim obciążenia zaczną działać i zostaną dopasowane, optymalizuje pod dostawcę chmury, a nie pod Ciebie.
• Usługi zarządzane dołączone domyślnie. Utrzymanie może mieć wartość, ale powinno być osobną decyzją z własną ceną i warunkami wyjścia.
• Brak planu wycofania. Każda procedura przełączenia potrzebuje jawnych kryteriów wycofania i przetestowanej procedury powrotu.
• Własne narzędzia partnera, których nie możesz zatrzymać. Jeśli środowiskiem da się zarządzać tylko narzędziami partnera, kupujesz uzależnienie.

Żaden z tych sygnałów osobno nie dyskwalifikuje partnera, ale dwa lub trzy razem powinny prowadzić do znacznie trudniejszej rozmowy przed podpisaniem umowy.

Jaką listą kontrolną porównać partnerów migracyjnych?

Poniższa tabela zamienia artykuł w narzędzie oceny. Oceń każdego partnera od 0 do 2 punktów w każdym wierszu; partner z wynikiem poniżej 12 na 20 punktów potrzebuje mocnego argumentu, żeby zostać na krótkiej liście.

Kryterium	0 punktów	1 punkt	2 punkty
Pokrycie zakresu	1–2 z sześciu obszarów	3–4 obszary	Wszystkie sześć, luki nazwane wprost
Ocena stanu obecnego	Brak lub z arkusza	Krótka, narzędziowa	4–6 tygodni, zależności, TCO, licencje, plan fal
Strategia dla obciążeń	Procenty dla portfela	Dla każdej aplikacji, bez uzasadnienia	Dla każdej aplikacji z uzasadnieniem i pracochłonnością
Landing zone	Brak wzmianki	„W cenie”	Architektura referencyjna, IaC, RACI
Model rozliczeń	Cena stała przed oceną	Jeden model dla wszystkiego	Model dopasowany do niepewności fazy
Dofinansowanie dostawcy	Brak wzmianki	Ogólna wzmianka	Nazwany program, oczekiwana kwota, warunki
Zespół	Tylko role	Imienny lider	Imienny zespół, rozmowa z głównym architektem
Referencje	Ogólne logotypy	Podobna skala lub technologia	Podobna skala, technologia i regulacje, kontakt możliwy
Transfer wiedzy i wyjście	Pominięte	Obiecana dokumentacja	IaC w Twoich repozytoriach, procedury, okres przekazania
Wartość po migracji	Pominięta	Wspomniana optymalizacja	Dopasowanie rozmiarów, zobowiązania, nadzór FinOps

Najważniejsze wnioski:

1. Porównuj zakresy przed cenami. Oferty różniące się trzykrotnie zwykle opisują różne projekty.
2. Płać za ocenę osobno. To ok. 5% budżetu, a decyduje o reszcie.
3. Pilnuj udziału przebudowy. W naszym przykładzie 10% aplikacji generuje połowę pracy migracyjnej.
4. Ustalaj cenę stałą tylko tam, gdzie zakres jest znany. Cena stała przed oceną to narzut na ryzyko albo przyszłe zlecenie zmiany.
5. Korzystaj z dofinansowania dostawców, ale je weryfikuj. Nazwy i zasady programów zmieniają się co roku.
6. Planuj to, co po uruchomieniu. Przy 29% marnowanych wydatków na chmurę to optymalizacja rozstrzyga o uzasadnieniu biznesowym.

W ARDURA Consulting wspieramy migracje do chmury dla klientów w Polsce, Europie, na Bliskim Wschodzie i w USA, opierając się na ponad 10 latach doświadczenia w wytwarzaniu oprogramowania i budowaniu zespołów IT. Pracujemy w modelu dopasowanym do fazy: ocena w cenie stałej, zespół dedykowany do landing zone i fal albo architekci chmury i inżynierowie DevOps, którzy dołączają do Twojego zespołu i budują jego kompetencje. Zaczynamy od pokazania naszych założeń — tak jak w przykładzie powyżej.

Jeśli porównujesz oferty migracji do chmury albo przygotowujesz zapytanie ofertowe, porozmawiaj z naszym zespołem. Przejrzymy Twój zakres, pomożemy zbudować porównywalny model i uczciwie powiemy, które części możesz zrealizować samodzielnie.