Prawie każdy plan migracji do chmury, który widziałem, był poprawny. Fazy w dobrej kolejności, zadania rozpisane, właściciele przypisani, terminy realistyczne. I mimo to znaczna część tych projektów kończyła się z opóźnieniem, którego nikt nie potrafił wyjaśnić przez wskazanie pominiętego kroku — bo żadnego kroku nie pominięto.
Nazywam się Bartosz Ciepierski, kieruję ARDURA Consulting i przez lata pracy przy programach transformacyjnych doszedłem do wniosku, że szukamy przyczyny w złym miejscu. Migracje nie przewracają się na kroku, który ktoś pominął. Przewracają się na kroku, który ktoś uznał za zamknięty, choć nie miał kryterium wyjścia — a kiedy okazuje się, że nie był zamknięty, nie ma już drogi powrotu, bo trzy kolejne fazy zbudowano na tym założeniu.
Stąd teza tego tekstu, z którą kompetentny czytelnik ma pełne prawo się nie zgodzić: checklista migracji, której nie da się przeczytać od tyłu, nie jest checklistą — jest listą życzeń. Krok, którego odwrotu nikt nigdy nie przećwiczył, nie jest wykonany. Jest wykonany warunkowo, na kredyt zaciągnięty pod przyszłe szczęście.
Ten artykuł jest checklistą wykonawczą zbudowaną według tej zasady. Nie zajmuje się natomiast rzeczami, które mamy opisane osobno i celowo tu nie powtarzam: czy w ogóle iść do chmury i jak dobrać model — od cloud-first do strategic hybrid; ile to kosztuje i których pozycji nie ma w kalkulatorach — kalkulator kosztów migracji do chmury; jak zmienia się architektura przy przejściu z monolitu — migracja z monolitu do mikroserwisów; oraz sama warstwa licencyjna — planowanie aspektu licencyjnego. Tutaj jest o wykonaniu i o jednym pytaniu zadawanym przy każdym kroku: skąd wiecie, że ten krok się skończył, i co robicie, jeśli okaże się, że jednak nie.
Dlaczego migracje nie przewracają się na pominiętym kroku?
Bo pominięcie kroku jest widoczne. Jeżeli nikt nie zrobił inwentaryzacji, wszyscy o tym wiedzą i ktoś w końcu zapyta. Ryzyko, które da się zobaczyć, jest ryzykiem zarządzonym.
Znacznie groźniejszy jest krok wykonany częściowo i uznany za zamknięty. Inwentaryzacja objęła serwery, ale nie objęła zadań uruchamianych z harmonogramu na stacji roboczej w dziale księgowości. Analiza zależności objęła aplikacje, ale nie objęła reguł zapory, o których wiedziała jedna osoba. Test wydajności przeszedł, ale na kopii danych o jednej dziesiątej wielkości produkcyjnej. Każdy z tych kroków ma w raporcie status „zamknięty” i każdy z nich jest miną.
Mechanizm szkody jest zawsze taki sam i warto go opisać dokładnie, bo z niego wynika cała reszta tego tekstu. Fazy migracji nie są niezależne — każda kolejna przyjmuje wyniki poprzedniej jako założenie i buduje na nim. Wykryty w czwartej fazie błąd pierwszej nie kosztuje tyle, ile poprawka pierwszej fazy. Kosztuje tyle, ile poprawka pierwszej plus unieważnienie decyzji podjętych w drugiej, trzeciej i czwartej. To jest krzywa wykładnicza, a nie liniowa, i to ona odpowiada za większość spektakularnych przekroczeń budżetu.
Wniosek praktyczny jest odwrotny do intuicji zarządczej. Presja terminu każe zamykać fazy szybciej. Matematyka kosztu błędu każe zamykać je dowodliwie — a to zwykle znaczy wolniej na początku i znacznie szybciej w drugiej połowie.
Jest jeszcze jeden powód, dla którego akurat migracje są na to podatne bardziej niż inne projekty: w migracji nie budujecie nowego systemu, tylko przenosicie istniejący, więc kryterium sukcesu brzmi „ma działać tak samo”. A „tak samo” jest jednym z najtrudniejszych kryteriów do sprawdzenia, jakie można sobie postawić — wymaga wiedzy, jak system zachowywał się przed przeniesieniem, w wymiarach, których nikt nie mierzył, bo działały. Zespół budujący nowy produkt odkrywa braki natychmiast, bo funkcja albo jest, albo jej nie ma. Zespół migrujący odkrywa je wtedy, gdy ktoś pierwszy raz od przełączenia potrzebuje raportu generowanego raz na kwartał. To jest ta sama asymetria, która sprawia, że w migracjach dowód znaczy więcej niż deklaracja: deklaracja odnosi się do tego, co pamiętamy, a pamiętamy tylko to, o czym myśleliśmy.
Co znaczy „krok zamknięty” i dlaczego to najtrudniejsze zdanie w całym planie?
Proponuję definicję operacyjną, której da się użyć w piątkowym przeglądzie statusu. Krok jest zamknięty, jeżeli spełnia trzy warunki naraz:
- Ma kryterium wyjścia zapisane przed rozpoczęciem — zdanie sprawdzalne przez kogoś, kto nie wykonywał tego kroku, dające odpowiedź tak albo nie, bez interpretacji.
- Ma przećwiczoną drogę powrotu — nie opisaną, tylko wykonaną co najmniej raz na środowisku, na którym wykonanie czegokolwiek jest wiarygodne.
- Ma imiennego właściciela decyzji — jedną osobę, nie zespół i nie komitet, która stwierdza spełnienie kryterium i bierze za to odpowiedzialność.
Trzeci warunek bywa najtrudniejszy, choć wygląda najprościej. Dopóki kryterium nie jest przypisane imiennie, jego ocena jest zbiorowa, a ocena zbiorowa w praktyce zawsze wypada „chyba tak” — bo nikt osobno nie ponosi konsekwencji błędu.
Drugi warunek jest najczęściej naruszany. Plan odwrotu zapisany w dokumencie i nigdy nieprzećwiczony to nie jest plan odwrotu, to jest akapit. Rzeczy, które w takich akapitach nie działają, są zawsze te same: kopia zapasowa, której nikt nie odtwarzał; wpis w systemie nazw z długim czasem życia, przez co powrót trwa godziny, a nie minuty; dane zapisane w środowisku docelowym w trakcie testu, których nie da się scalić wstecz; klucze i sekrety wymienione w jedną stronę.
Pierwszy warunek jest najłatwiejszy do naprawienia i daje największy zwrot. Różnica między „inwentaryzacja zakończona” a „inwentaryzacja zakończona, jeżeli każdy adres sieciowy widoczny w ruchu przez ostatnie trzydzieści dni jest przypisany do zinwentaryzowanego zasobu” jest różnicą między raportem a faktem.
Jak w praktyce czytać checklistę od tyłu?
Ćwiczenie zajmuje jedno popołudnie, robi się je raz, przed rozpoczęciem, i zwykle zmienia plan.
Weźcie swój plan migracji i przejdźcie go od ostatniego kroku do pierwszego, zadając przy każdym jedno pytanie: jeżeli za tydzień po wykonaniu tego kroku okaże się, że był błędny, co konkretnie robimy? Nie „czy da się cofnąć”, bo odpowiedź zawsze brzmi „da się”. Co konkretnie: kto wykonuje, na podstawie jakiej procedury, ile to trwa, co tracimy.
Odpowiedzi układają się w trzy kategorie i to ich rozkład jest właściwym wynikiem ćwiczenia.
Kroki odwracalne — powrót zajmuje minuty do godzin, nie tracimy danych, procedura była wykonana. Tu należą przełączenia ruchu przez system nazw z krótkim czasem życia, wdrożenia równoległe z możliwością przełączenia z powrotem, uruchomienie środowiska docelowego obok źródłowego.
Kroki odwracalne kosztownie — powrót jest możliwy, ale trwa dni i wymaga decyzji zarządczej. Migracja bazy danych z jednokierunkową replikacją, zmiana modelu licencjonowania, wyłączenie sprzętu.
Kroki nieodwracalne — wyłączenie i zwrot sprzętu dzierżawionego, rozwiązanie umowy z serwerownią, usunięcie danych ze źródła, zwolnienie zespołu utrzymującego środowisko własne.
Zasada porządkująca cały plan brzmi: wszystkie kroki nieodwracalne przesuwamy tak późno, jak to możliwe, i grupujemy za jedną bramą decyzyjną z imiennym właścicielem. Typowy plan ma je rozsypane po całym harmonogramie, zwykle dlatego, że każdy z nich osobno oszczędza pieniądze i ktoś słusznie chciał je oszczędzić wcześnie. Rozsypane, zabierają odwracalność całemu projektowi znacznie wcześniej, niż ktokolwiek zauważy.
Co musi zawierać inwentaryzacja, żeby nie trzeba jej było robić drugi raz?
Faza pierwsza, cztery do ośmiu tygodni, i jedyna, której jakość przewiduje wynik całości.
Zasoby obliczeniowe. Każdy serwer fizyczny i wirtualny: procesory, pamięć, dysk, system operacyjny wraz z wersją, lokalizacja, właściciel biznesowy. Wersja systemu jest tu istotna nie dla porządku — systemy poza wsparciem producenta zmieniają zarówno koszt licencji w chmurze, jak i dopuszczalność ich przeniesienia.
Aplikacje i przypisanie. Które aplikacje działają na których zasobach. Brzmi trywialnie, w organizacji z piętnastoletnią historią bywa najtrudniejszym elementem całej fazy.
Zależności. Tu potrzebny jest pomiar, nie ankieta. Ankieta zwraca zależności, o których ludzie pamiętają; pomiar ruchu sieciowego zwraca wszystkie. Miesiąc zbierania danych o połączeniach ujawnia integracje, o których nie wie nikt z żyjących pracowników — i to właśnie one wywracają okna serwisowe.
Dane. Wolumen, przyrost, klasyfikacja. Klasyfikacja jest tu warstwą prawną, nie porządkową: to od niej zależy, czy dane obejmuje reżim wymagający zawiadomienia nadzorcy, czy dopuszczalny jest transfer poza Europejski Obszar Gospodarczy i jakie środki techniczne są wymagane.
Licencje. Osobna pozycja i najczęstsze źródło negatywnych niespodzianek. Reguły licencjonowania w środowisku wirtualizowanym u dostawcy chmury bywają zasadniczo inne niż na sprzęcie własnym, a rachunek potrafi się zmienić o rząd wielkości. Ten temat rozpisaliśmy osobno w tekście o licencjonowaniu w chmurze i warto go przejść przed, a nie po wyborze strategii.
Kryterium wyjścia dla tej fazy: każdy adres sieciowy występujący w ruchu z ostatnich trzydziestu dni jest przypisany do zinwentaryzowanego zasobu, a każdy zasób ma imiennego właściciela biznesowego. Bez tego zdania faza się nie kończy — kończy się termin.
Jak wybrać strategię per obciążenie, skoro sześć „R” to jeszcze nie decyzja?
Klasyczna taksonomia — przenieść bez zmian, przenieść z drobną zmianą platformy, kupić gotowe, przebudować, wygasić, zostawić — jest dobrym słownikiem i złym narzędziem decyzyjnym, bo nie mówi, jak przypisać obciążenie do kategorii.
Proponuję zamiast tego trzy pytania zadawane po kolei, z których każde odcina część możliwości.
Czy ten system w ogóle jest potrzebny za dwa lata? Jeżeli nie — wygaście. Migracja jest jedyną okazją w cyklu życia organizacji, kiedy wyłączenie systemu nie wymaga politycznej kampanii, bo alternatywą jest wydanie pieniędzy na jego przeniesienie. Typowo dziesięć do dwudziestu procent inwentarza da się w tym momencie zamknąć, a każdy wyłączony system to koszt, który znika z rachunku migracji i z rachunku utrzymania naraz.
Czy istnieje gotowa usługa, która robi to samo? Jeżeli tak, i nie jest to wasz wyróżnik konkurencyjny — kupcie. Utrzymywanie własnego serwera pocztowego, własnego systemu zgłoszeń czy własnego repozytorium kodu rzadko wygrywa rachunek.
Czy po przebudowie ten system zacznie robić coś, czego dziś nie robi? To jest pytanie rozstrzygające między przeniesieniem bez zmian a przebudową i sformułowanie ma znaczenie. „Będzie nowocześniejszy” nie jest odpowiedzią. „Będzie skalował się automatycznie w szczycie sprzedażowym, którego dziś nie obsługujemy” — jest.
Domyślną odpowiedzią, gdy żadne z trzech pytań nie daje wyraźnego wskazania, jest przeniesienie bez zmian. Nie dlatego, że jest najlepsze, tylko dlatego, że jest odwracalne — a zgodnie z tezą tego tekstu odwracalność jest walutą, którą płacimy za wszystkie późniejsze pomyłki.
Warto zauważyć, że kolejność tych pytań też nie jest przypadkowa. Zaczynamy od wygaszenia, bo to jedyna decyzja, która usuwa pracę z projektu zamiast ją dodawać — a zadana na końcu nie zostanie zadana wcale, bo do tego czasu system będzie już miał przypisaną strategię, przydzielone zasoby i obrońcę. Pytanie o gotową usługę jest drugie z tego samego powodu. Przebudowa jest ostatnia, bo jest najdroższa i najmniej odwracalna, więc powinna być decyzją podjętą po odrzuceniu wszystkich tańszych możliwości, a nie domyślną ambicją zespołu, który chce zbudować coś nowego.
Kryterium wyjścia dla tej fazy: każde obciążenie ma przypisaną strategię z jednozdaniowym uzasadnieniem odwołującym się do jednego z trzech pytań, zatwierdzoną przez imiennego właściciela.
Gdzie w polskim porządku prawnym leży brama, której nie przeskoczycie?
To jest warstwa, której w anglojęzycznych checklistach migracyjnych nie ma, bo dotyczy porządku prawnego, w którym te checklisty nie powstawały. W polskiej organizacji potrafi ona zdecydować o harmonogramie mocniej niż cała warstwa techniczna.
Ochrona danych osobowych. Jeżeli migrowane systemy przetwarzają dane osobowe, dostawca chmury jest podmiotem przetwarzającym i wymagana jest umowa powierzenia spełniająca wymogi artykułu 28 RODO, wraz z warunkami dalszego powierzenia — dostawcy chmury korzystają z własnych podwykonawców i lista ta bywa długa. Osobno trzeba rozstrzygnąć transfer poza Europejski Obszar Gospodarczy: po wyroku w sprawie Schrems II z 16 lipca 2020 roku samo powołanie się na standardowe klauzule nie wystarcza bez oceny skutków, a decyzja o adekwatności dla ram ochrony danych między Unią a Stanami Zjednoczonymi z 10 lipca 2023 roku zmieniła sytuację, ale jej nie zamknęła. Praktyczna konsekwencja: ta analiza trwa tygodnie i musi zacząć się w fazie pierwszej, a nie przed przełączeniem.
Sektor finansowy. Komunikat Komisji Nadzoru Finansowego dotyczący przetwarzania informacji w chmurze obliczeniowej nakłada tryb, którego elementy trzeba wpisać do harmonogramu jako kamienie milowe z datami: klasyfikacja informacji, ocena ryzyka, rejestr usług chmurowych, wymagania umowne, plan wyjścia oraz zawiadomienie nadzorcy co najmniej czternaście dni przed rozpoczęciem przetwarzania informacji prawnie chronionych. Do tego od 17 stycznia 2025 roku stosuje się rozporządzenie DORA, z rejestrem informacji o umowach z dostawcami usług teleinformatycznych i wymogiem strategii wyjścia dla funkcji krytycznych.
Cyberbezpieczeństwo. Dyrektywa NIS2, wdrażana w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa, traktuje bezpieczeństwo łańcucha dostaw jako obowiązkowy środek zarządzania ryzykiem. Dostawca chmury jest częścią tego łańcucha.
Sektor publiczny i zamówienia. Jeżeli migracja jest realizowana w reżimie zamówień publicznych, dochodzi warstwa, która działa dokładnie odwrotnie niż zwinne planowanie: zakres i kryteria muszą być opisane przed wyborem wykonawcy, a każda istotna zmiana zakresu w trakcie jest problemem formalnym, nie tylko projektowym. To dodatkowy argument za tym, żeby kryteria wyjścia dla faz były zapisane w dokumentacji postępowania — jeżeli nie ma ich tam, nie będzie podstawy, żeby ich później wymagać.
Zwróćcie uwagę na coś, co przy pierwszym czytaniu wygląda na przypadek, a przypadkiem nie jest: regulator w dwóch niezależnych miejscach wymaga planu wyjścia. To dokładnie ten sam wymóg, który teza tego tekstu formułuje z powodów czysto inżynierskich. Odwracalność nie jest tu luksusem dobrze prowadzonego projektu — jest obowiązkiem, który i tak trzeba udokumentować.
Co akt o danych zmienia w waszym planie wyjścia?
Przez lata argument „wyjście z chmury jest za drogie” był prawdziwy głównie z jednego powodu: opłaty za wyprowadzenie danych rosły liniowo z ich objętością, więc im dłużej byliście u dostawcy, tym droższe stawało się odejście. To jest klasyczny mechanizm przetrzymania i wpływał na negocjacje przy każdym przedłużeniu umowy.
Rozporządzenie o danych, stosowane od 12 września 2025 roku, adresuje to wprost. Wprowadza obowiązki dostawców usług przetwarzania danych związane ze zmianą dostawcy: ramy czasowe przejścia zapisane w umowie, obowiązek współpracy przy przenoszeniu danych i zasobów cyfrowych oraz stopniowe wycofywanie opłat za samą zmianę dostawcy, z ich całkowitym zniesieniem od 12 stycznia 2027 roku.
Trzy praktyczne wnioski dla checklisty.
Po pierwsze, koszt wyjścia przestaje być argumentem za nierobieniem planu wyjścia. Pozycja, którą wcześniej wpisywało się jako zaporową, przestaje nią być — a to znaczy, że odwracalność stała się tańsza, niż była, gdy pisano większość poradników migracyjnych krążących po sieci.
Po drugie, przetrzymanie nie znika, tylko zmienia miejsce. Opłata za dane spada, ale koszt przepisania tego, co zbudowaliście na usługach zarządzanych konkretnego dostawcy, zostaje wasz w całości. Decyzja o użyciu usługi zarządzanej zamiast rozwiązania przenośnego jest więc realną decyzją o odwracalności — i tak trzeba ją zapisać, z uzasadnieniem, a nie podejmować mimochodem na poziomie zespołu wdrożeniowego.
Po trzecie, to jest moment na przejrzenie umowy. Jeżeli podpisujecie kontrakt chmurowy w trakcie migracji, warunki wyjścia są elementem, o który należy zapytać wprost i który należy zapisać. Warto to zrobić przy podpisywaniu, bo później rozmawia się z pozycji strony, która już przeniosła dane.
Który region wybrać i dlaczego to nie jest decyzja techniczna?
Kolejność kryteriów jest tu sztywna i odwrócenie jej jest częstym błędem.
Najpierw wymogi prawne i umowne. Jeżeli umowa z klientem, interpretacja regulatora albo warunki przetargu ograniczają lokalizację przetwarzania, decyzja jest już podjęta. Sprawdźcie to przed rozmową techniczną, a nie po niej — argument o opóźnieniach sieciowych nie przekona nikogo, kto ma w umowie zapis o lokalizacji.
Potem opóźnienie sieciowe. Ma znaczenie dla aplikacji rozmownych, wymieniających z bazą danych setki zapytań na jedno żądanie użytkownika; kilkanaście milisekund na przeskok mnoży się przez liczbę przeskoków i staje widoczne. Dla przetwarzania wsadowego jest bez znaczenia. Warto zmierzyć, zamiast zakładać — a przy okazji migracji zwykle opłaca się zmniejszyć rozmowność, bo to poprawia wynik niezależnie od wybranego regionu.
Na końcu dostępność usług. Regiony nie są równoważne. Nowsze usługi zarządzane pojawiają się najpierw w największych regionach, a projekt oparty na usłudze niedostępnej w wybranym regionie odkrywa to w połowie wdrożenia. Sprawdzenie polega na wypisaniu listy usług z projektu architektury i potwierdzeniu każdej pozycji w tabeli dostępności regionalnej dostawcy — pół godziny pracy, która oszczędza tygodnie.
Warto odnotować, że argument „i tak wszystko stoi we Frankfurcie” jest już nieaktualny: dwaj z trzech największych dostawców mają regiony w Warszawie, a oferta regionów w Europie Środkowej rozrosła się w ostatnich latach. Samo porównanie dostawców pod kątem wyboru rozpisaliśmy osobno w przewodniku po wyborze dostawcy chmury.
Jak zaplanować przeniesienie danych, żeby okno serwisowe nie było zgadywaniem?
Policzmy, bo to jest rachunek, którego prawie nikt nie wykonuje przed obiecaniem daty.
Pięćdziesiąt terabajtów to około czterysta dziesięć tysięcy gigabitów. Łącze gigabitowe wykorzystane realistycznie w siedemdziesięciu procentach daje około siedmiuset megabitów na sekundę użytecznych, czyli niecałe siedem dni ciągłego transferu. Przez cały ten czas nikt inny nie może korzystać z tego pasma, nic nie może się przerwać, a dane w źródle nie mogą się zmieniać — czyli warunki, których nie da się spełnić w działającej firmie.
Stąd trzy elementy planu, które muszą istnieć zawsze.
Transfer początkowy. Powyżej kilkudziesięciu terabajtów sensowne stają się urządzenia transferowe dostarczane fizycznie przez dostawcę chmury; przy stałej wymianie — łącze dedykowane, którego uruchomienie samo w sobie trwa tygodnie i musi być zamówione w fazie pierwszej.
Synchronizacja przyrostowa. Dane zmieniają się w trakcie transferu początkowego. Plan musi obejmować mechanizm dogrywania różnicy i pomiar, jak szybko ta różnica maleje — jeśli przyrost jest szybszy niż tempo dogrywania, migracja tą drogą nigdy się nie zbiegnie i trzeba zmienić metodę, a nie dodać czasu.
Okno przełączenia. Najkrótszy odcinek i jedyny, w którym system nie działa. Kluczowa obserwacja: okno musi obejmować weryfikację spójności po stronie docelowej, a nie kończyć się na zakończeniu kopiowania. To weryfikacja jest podstawą decyzji o przełączeniu ruchu, więc jej czas jest częścią okna, a nie czymś, co dzieje się potem.
Do tego dochodzi element, który wywraca okna najczęściej, a w planach pojawia się najrzadziej: czas życia wpisów w systemie nazw. Jeżeli wasze rekordy mają czas życia liczony w godzinach, to powrót po nieudanym przełączeniu też trwa godziny, niezależnie od tego, jak sprawnie działa reszta. Skrócenie tego czasu do kilku minut trzeba wykonać z wyprzedzeniem — na tyle wcześnie, żeby stare, długie wartości zdążyły wygasnąć u wszystkich, którzy je zbuforowali. To jest jednoliniowa zmiana, którą robi się tydzień przed przełączeniem, i jedna z najtańszych rzeczy, jakie można zrobić dla odwracalności całego projektu.
Kryterium wyjścia dla tej fazy: przełączenie zostało przećwiczone w całości na środowisku przejściowym, łącznie z powrotem, a zmierzony czas obu operacji mieści się w uzgodnionym oknie z zapasem. Ćwiczenie bez powrotu nie liczy się jako ćwiczenie.
Jak wygląda checklista, którą da się przeczytać od tyłu?
Poniższa tabela jest streszczeniem całego tekstu w formie narzędzia. Kolumna z odwrotem jest w niej ważniejsza od kolumny z zadaniami — i to jest cała różnica wobec typowej checklisty migracyjnej.
| Faza | Kryterium wyjścia (sprawdzalne, zapisane przed startem) | Przećwiczony odwrót | Właściciel decyzji | Dowód do przedstawienia |
|---|---|---|---|---|
| 1. Inwentaryzacja | Każdy adres z ruchu ostatnich 30 dni przypisany do zasobu; każdy zasób ma właściciela biznesowego | Nie dotyczy — faza bez zmian w środowisku | Właściciel programu | Raport z narzędzia do mapowania zależności, nie arkusz z ankiet |
| 2. Klasyfikacja i zgodność | Klasyfikacja danych zatwierdzona; ustalona podstawa transferu; dla podmiotów nadzorowanych — zawiadomienie złożone w terminie | Nie dotyczy | Inspektor ochrony danych i osoba odpowiedzialna za zgodność | Umowa powierzenia, ocena ryzyka, potwierdzenie zawiadomienia |
| 3. Strategia per obciążenie | Każde obciążenie ma strategię z uzasadnieniem odwołującym się do jednego z trzech pytań | Zmiana strategii przed rozpoczęciem prac — koszt zerowy | Architekt wiodący | Rejestr decyzji z datami |
| 4. Środowisko docelowe | Infrastruktura jako kod, odtwarzalna od zera w mniej niż dobę; test odtworzenia wykonany | Usunięcie i odtworzenie środowiska — wykonane raz | Lider zespołu platformowego | Log z odtworzenia, nie deklaracja |
| 5. Migracja pilotażowa | Jedno obciążenie o niskim ryzyku działa na produkcji przez 14 dni bez odstępstw od wskaźników | Przełączenie ruchu z powrotem — wykonane, nie opisane | Właściciel systemu pilotażowego | Wykres wskaźników i log przełączenia w obie strony |
| 6. Migracja właściwa | Wskaźniki poziomu usług spełnione na środowisku docelowym przez uzgodniony okres | Powrót możliwy do zamrożenia źródła; koszt i czas policzone | Właściciel programu | Porównanie wskaźników przed i po |
| 7. Odcięcie źródła | Wszystkie zależności zweryfikowane jako martwe przez pełny cykl rozliczeniowy | Brak — krok nieodwracalny, brama decyzyjna | Sponsor biznesowy, imiennie | Protokół z listą zweryfikowanych zależności |
| 8. Optymalizacja | Koszt na jednostkę pracy zmierzony i porównany z założeniem sprzed migracji | Zmiany rozmiarów zasobów odwracalne z definicji | Właściciel budżetu | Raport kosztowy z podziałem na zespoły |
Trzy uwagi do tej tabeli.
Po pierwsze, jedyny wiersz z pustą kolumną odwrotu to wiersz siódmy — i to jest cała jego funkcja. Nieodwracalność jest tam skoncentrowana świadomie, za jedną bramą, z jednym imiennym właścicielem, po pełnym cyklu rozliczeniowym weryfikacji. W typowym planie nieodwracalność jest rozproszona po sześciu wierszach i nikt nie zauważa momentu, w którym projekt przestał mieć drogę powrotu.
Po drugie, kolumna dowodu jest ważniejsza od kolumny kryterium, bo to ona odróżnia raport od faktu. „Test odtworzenia wykonany” jako zdanie w statusie znaczy tyle, co nic. Log z odtworzenia znaczy dokładnie tyle, ile pokazuje.
Po trzecie, faza piąta jest tą, którą pomija się najczęściej pod presją terminu — i to ona jedyna daje wam pomiar, a nie oszacowanie. Czternaście dni pilotażu kosztuje czternaście dni. Odkrycie tych samych problemów w fazie szóstej kosztuje przeprojektowanie.
Kto musi być w zespole migracyjnym i czego nie da się dokupić z zewnątrz?
Skład zespołu jest w tej checkliście pozycją wykonawczą, nie kadrową, bo z niego wynika, czy kryteria wyjścia będzie kto stwierdzać.
Role, które muszą być wasze i których nie da się kupić. Właściciel programu z mandatem do zatrzymania migracji — nie do jej monitorowania, do zatrzymania. Właściciele biznesowi systemów, bo tylko oni mogą powiedzieć, że system da się wyłączyć. Osoba odpowiedzialna za zgodność i inspektor ochrony danych, bo ich decyzje są w tym projekcie kamieniami milowymi z datami, a nie konsultacją. I wreszcie ktoś, kto zna historię środowiska — te dziesięć lat decyzji, które nie zostały nigdzie zapisane. Ta ostatnia rola jest najczęściej niedoceniana i jednocześnie najtrudniejsza do odtworzenia, bo jej treścią jest wiedza, której nie ma w żadnym dokumencie.
Role, które sensownie dobiera się z zewnątrz. Inżynier platformowy do zbudowania środowiska docelowego jako kodu. Specjalista od migracji baz danych — to jest wąska kompetencja, potrzebna intensywnie przez kilka miesięcy i prawie wcale później. Architekt sieci na czas projektowania połączeń hybrydowych. Specjalista od licencjonowania, jeżeli w inwentarzu są produkty, których model licencyjny zmienia się w środowisku wirtualizowanym.
Podział przebiega dokładnie tam, gdzie kończy się wiedza kontekstowa, a zaczyna wiedza techniczna. Zewnętrzny inżynier zbuduje wam środowisko lepiej i szybciej, niż zrobi to zespół uczący się przy okazji. Nie powie wam natomiast, czy ten system wolno wyłączyć — i żaden dostawca, który twierdzi inaczej, nie zna waszej organizacji.
Praktyczna konsekwencja dla harmonogramu: zapotrzebowanie na kompetencje zewnętrzne jest w tym projekcie nierównomierne i to trzeba zaplanować. Faza czwarta i szósta pochłaniają ich najwięcej, faza druga prawie wcale. Etat obsadzony na cały rok pod szczyt trwający trzy miesiące jest kosztowną odpowiedzią na sezonowość; model elastyczny jest tu adekwatniejszy — nie dlatego, że tańszy, tylko dlatego, że pasuje do kształtu zapotrzebowania. Jeśli chcecie zobaczyć, jakie profile są dostępne od ręki, mamy je zebrane na stronie dostępnych ekspertów.
Czego nie widać w kalkulatorze kosztów i co i tak zapłacicie?
Rachunek kosztowy rozpisaliśmy osobno, więc tutaj tylko trzy pozycje, które wynikają wprost z tezy tego tekstu i które w kalkulatorach dostawców nie występują z definicji.
Koszt utrzymania dwóch środowisk równolegle. Między fazą piątą a siódmą płacicie za jedno i drugie. To nie jest marnotrawstwo — to jest cena odwracalności i tak należy ją przedstawić przy zatwierdzaniu budżetu. Projekt, który tej pozycji nie ma, w praktyce zaplanował odcięcie źródła zbyt wcześnie.
Koszt niezweryfikowanej zależności. Trudny do oszacowania z góry, ale łatwy do ograniczenia: pełny cykl rozliczeniowy obserwacji przed odcięciem wyłapuje integracje uruchamiane raz w miesiącu — zamknięcie okresu, raport do urzędu, rozliczenie prowizji. To są dokładnie te systemy, których nikt nie zgłosił w ankiecie, bo działają same.
Koszt zmiany modelu licencyjnego. Potrafi przewrócić cały rachunek i ujawnia się dopiero przy fakturze. Warto go policzyć w fazie pierwszej, razem z inwentaryzacją, a nie po wyborze regionu.
Po samej migracji dochodzi jeszcze warstwa, która nie jest kosztem migracji, tylko kosztem eksploatacji — i którą warto zaplanować od razu, bo pierwszy rachunek chmurowy potrafi być szokiem organizacyjnym. Praktykę zarządzania tym kosztem opisaliśmy w tekście o FinOps, a warstwę obserwacji, bez której nie da się stwierdzić, czy środowisko docelowe faktycznie działa lepiej — w tekście o obserwowalności.
Jakie są kluczowe wnioski?
Teza brzmiała: checklista migracji, której nie da się przeczytać od tyłu, nie jest checklistą. Co z niej wynika praktycznie?
Zamykajcie kroki dowodliwie, nie terminowo. Krok zamknięty to krok z kryterium wyjścia zapisanym przed startem, przećwiczonym odwrotem i imiennym właścicielem decyzji. Trzy warunki, wszystkie naraz.
Ćwiczcie powrót, nie opisujcie go. Plan odwrotu, którego nikt nie wykonał, jest akapitem. Pilotaż bez przełączenia w obie strony nie jest pilotażem.
Zgromadźcie nieodwracalność w jednym miejscu. Wszystkie kroki bez drogi powrotu przesuńcie tak późno, jak się da, i postawcie za jedną bramą z jednym właścicielem. Rozproszona nieodwracalność zabiera projektowi możliwość korekty, zanim ktokolwiek to zauważy.
Warstwę prawną zacznijcie w tygodniu pierwszym. Klasyfikacja danych, podstawa transferu, umowa powierzenia, a w sektorze regulowanym zawiadomienie nadzorcy z wyprzedzeniem i strategia wyjścia. To są terminy kalendarzowe, których nie da się nadrobić pracą.
Traktujcie odwracalność jako pozycję budżetową. Ma cenę — równoległe środowiska, czas pilotażu, ćwiczenia powrotu — i ta cena jest niższa niż koszt jednej korekty wykonanej po odcięciu źródła.
Jeżeli chcecie zacząć od jednego ćwiczenia: weźcie swój obecny plan migracji i przejdźcie go od ostatniego kroku do pierwszego, zapisując przy każdym, co dokładnie robicie, jeśli tydzień później okaże się błędny. Miejsce, w którym zabraknie wam odpowiedzi, jest miejscem, w którym wasz projekt straci odwracalność — i lepiej dowiedzieć się o tym teraz niż w fazie siódmej.
W ARDURA Consulting prowadzimy takie przeglądy planów migracyjnych i wspieramy zespoły w fazie wykonawczej. Jeżeli chcecie skonfrontować swój plan z tą checklistą, zanim ruszy pierwsze obciążenie — napiszcie do nas przez formularz kontaktowy. Rozmowę zaczniemy od kolumny z odwrotem, bo to ona zwykle pokazuje, gdzie plan jest napisany na kredyt.