Migracja z legacy w 90 dni ma sens tylko przy wąskim, mierzalnym zakresie, realnym rollbacku i uruchomieniu nowej ścieżki na ograniczonym ruchu. Kluczowa decyzja dotyczy nie technologii, lecz granicy pierwszego etapu, sposobu pomiaru wyniku i warunków zatrzymania projektu.
Migracja z legacy w 90 dni ma sens tylko wtedy, gdy kupujesz kontrolowany eksperyment produkcyjny, a nie początek wielkiej odnowy całego krajobrazu IT. Jeśli pierwszy etap nie jest porównywalny ze starą ścieżką, odwracalny i ograniczony do jednego procesu albo jednej klasy integracji, projekt lepiej zatrzymać przed implementacją. Najczęściej to właśnie brak twardej granicy pierwszego etapu zamienia modernizację w kosztowny program bez wiarygodnego punktu decyzji.
Najwięcej błędów nie pojawia się przy wdrożeniu, tylko przy wyborze tego, co ruszyć najpierw. Zespoły biorą obszar najbardziej widoczny dla biznesu, choć realne ryzyko zwykle siedzi głębiej: w danych, wyjątkach operacyjnych, ręcznych obejściach i integracjach, których nikt nie potrafi już porządnie opisać. Kontrolę odzyskuje się nad wycinkiem systemu. Rdzenia z wieloletnimi zależnościami nie modernizuje się uczciwie w jednym krótkim etapie.
Dobry kandydat na szybki etap spełnia trzy warunki. Obejmuje jeden proces albo jedną klasę integracji, da się go porównać ze starą ścieżką przez logi i testy, a po stronie biznesu istnieje właściciel zdolny podejmować decyzje bez wielotygodniowej ścieżki akceptacji.
Nie potrzeba pełnej obserwowalności całej platformy. Potrzebne jest minimum operacyjne: identyfikator transakcji, błędy, czas odpowiedzi, wolumen i możliwość sprawdzenia, czy nowa ścieżka działa co najmniej nie gorzej niż stara. Bez tego ograniczanie ryzyka pozostaje opinią, nie oceną.
Rollback też bywa źle rozumiany. To nie deklaracja w ofercie, tylko procedura: kto przełącza ruch, po jakim sygnale, w jakim czasie i co dzieje się z danymi zapisanymi przez nowy komponent. Jeżeli nie da się tego opisać przed implementacją, zakres jest za szeroki albo architektura przejściowa nadal nie została zaprojektowana.
Są układy, w których 90 dni po prostu nie ma sensu. Zwłaszcza tam, gdzie nakładają się ręczne obejścia poza systemem, brak wiarygodnych danych do porównania wyników, wiele krytycznych integracji bez testowalnych kontraktów i konieczność równoczesnej migracji logiki transakcyjnej oraz danych historycznych. W takim przypadku krótkie discovery nie jest opóźnieniem. To tańsza decyzja niż wejście w implementację na ślepo.
Jeśli częściej pojawia się brak odpowiedzi na pytania o dane, zależności i warunki przełączenia niż konkretne decyzje projektowe, implementacja jest przedwczesna. Kilka tygodni rozpoznania zwykle wystarcza, by zmapować wyjątki operacyjne, granice odpowiedzialności i warunki pierwszego etapu. Dopiero wtedy ma sens decyzja, czy iść w wydzielenie procesu, warstwę pośrednią czy szersze przepisanie.
Przy takim wyborze pomaga też rozróżnienie, czy problem wymaga etapowej zmiany, czy jednak głębszego resetu architektury. Dobrze porządkuje to materiał refaktoryzacja czy przepisanie kodu.
Pierwszy etap nie powinien być najbardziej efektowny. Powinien dać mierzalny efekt operacyjny przy ograniczonym promieniu awarii. Najlepszym kandydatem bywa obszar, który dziś generuje ręczne korekty, incydenty albo blokuje wdrożenia, ale da się go odgrodzić interfejsem, kolejką, osobnym API lub kontrolą zapisu.
Często dobrym wyborem okazuje się niestabilna integracja z systemem zewnętrznym albo fragment walidacji biznesowej, który produkuje wyjątki i eskalacje. Zaskakująco rzadko najlepszym pierwszym ruchem jest interfejs użytkownika. Front jest widoczny, ale w systemach legacy źródło kosztu zwykle siedzi tam, gdzie użytkownik go nie widzi.
W dystrybucji hurtowej, przy organizacji obsługującej kilka magazynów i integrację z ERP, próba ruszenia całego modułu zamówień na starcie ugrzęzła nie na kodzie, tylko na wyjątkach operacyjnych i ręcznych korektach po stronie back office. Tarcie wdrożeniowe okazało się ważniejsze niż sam koszt programistów: bez odseparowania walidacji limitów i komunikacji z ERP każdy test kończył się sporem o dane i odpowiedzialność za wynik. Taki zakres wygląda ambitnie w planie, ale operacyjnie jest zły na pierwszy etap.
Wybór między API facade, adapterem a wydzieleniem procesu zależy od miejsca, w którym dziś kumuluje się ryzyko. Gdy stary system liczy poprawnie, ale jego interfejs blokuje zmianę kontraktów i tempa wdrożeń, sens ma facade. Gdy awarie wynikają głównie z formatów danych, timeoutów, kolejkowania i niestabilnych połączeń, lepszy będzie adapter integracyjny. Jeśli problem siedzi w regułach biznesowych, które można odseparować od reszty i uruchomić na ograniczonym zbiorze danych, wtedy warto wydzielić proces do osobnej usługi. Moda na wzorzec nie obniża ryzyka. Obniża je dopiero zgodność wzorca z faktycznym źródłem awarii i kosztem cofnięcia zmiany.
Wzorzec strangler, opisywany między innymi przez Microsoft Azure Architecture Center, działa wtedy, gdy można przejmować ruch stopniowo i porównywać wyniki starej oraz nowej ścieżki. Nie działa dobrze tam, gdzie system opiera się na ciężkich wsadach, ukrytych krokach poza aplikacją i ręcznych korektach bez śladu w logach.
Najczęściej problemem nie jest samo legacy, tylko zbyt ambitny pierwszy etap modernizacji. Z tą tezą część dostawców się nie zgodzi, bo rynek nadal premiuje duże programy transformacyjne sprzedawane przed uczciwym ograniczeniem zakresu. Operacyjnie wygrywa jednak zespół, który potrafi odrzucić połowę pomysłów na start.
Jeżeli potrzebna jest warstwa pośrednia między starym rdzeniem a nowym komponentem, sensowny punkt odniesienia daje materiał o połączeniu systemu legacy z nowym produktem. Chodzi nie o sam wzorzec, tylko o ograniczenie sprzężeń przed większą zmianą.
Dobry plan 90 dni nie składa się z trzech równych faz pod tytułem analiza, development i wdrożenie. Składa się z bramek decyzyjnych. Po każdej z nich projekt można zawęzić, zatrzymać albo dopuścić do kolejnego kroku bez utraty kontroli.
Na początku trzeba ustalić rzeczy mało efektowne, ale krytyczne: granicę modułu, źródła danych, ręczne obejścia, minimalny zestaw testów regresji i sposób pomiaru wyniku. Jeśli monitoring nie istnieje, trzeba go uruchomić od razu.
Wyjściem z tego etapu powinny być konkretne artefakty: opis przepływu krytycznego, lista zależności synchronicznych i asynchronicznych, plan rollbacku z odpowiedzialnościami oraz decyzja, czy nowy komponent zapisuje dane samodzielnie, czy tylko odczytuje i publikuje zdarzenia. Brak tych elementów oznacza, że szeroka implementacja jest przedwczesna.
Jest jeszcze jeden warunek stop. Jeśli po pierwszym miesiącu nadal nie wiadomo, które wyjątki operacyjne są dopuszczalne, a które zatrzymują transakcję, projekt nie ma granicy ryzyka i nie powinien wejść w pełną implementację.
Omówmy Twój projekt, kontekst techniczny i możliwe kierunki działania. Krótka rozmowa zwykle wystarcza, żeby ocenić ryzyka, zakres i sensowny następny krok.
Jak zaczynamy
24h
Po wiadomości wracamy z terminem rozmowy i pierwszym spojrzeniem na temat. Powiemy, czy warto budować, integrować, automatyzować czy zacząć prościej.
Jak zaczynamy
24h
Po wiadomości wracamy z terminem rozmowy i pierwszym spojrzeniem na temat. Powiemy, czy warto budować, integrować, automatyzować czy zacząć prościej.
W środku projektu najłatwiej stracić dyscyplinę zakresu. Kod już powstaje, więc pojawia się pokusa, by dorzucić kolejne funkcje. Właśnie wtedy projekty zaczynają przepisywać wspólny model danych i tracą możliwość sensownego rollbacku.
Do tej bramki powinien istnieć działający komponent z jasno określoną odpowiedzialnością, testy kontraktowe dla ruszanych integracji, mechanizm feature flag albo routingu ruchu oraz dashboard z błędami, czasem odpowiedzi i wolumenem. Dobrze, jeśli pojawia się też próbne uruchomienie na ograniczonych danych.
Brak testowalnych kontraktów po kilku tygodniach to nie drobne opóźnienie, tylko sygnał, że zespół nadal nie kontroluje granicy zmiany. Podobnie wygląda sytuacja, gdy plan przełączenia ruchu istnieje wyłącznie w rozmowach, a metryki porównawcze nadal są zbierane ręcznie. W takim układzie problemem bywa nie sam trudny system, lecz słaba egzekucja albo źle wybrany zakres. Lepiej zatrzymać rozszerzanie prac niż udawać, że kolejny sprint naprawi brak podstaw operacyjnych.
Końcówka etapu służy do uruchomienia nowej ścieżki na ograniczonym ruchu i sprawdzenia, czy wynik jest co najmniej nie gorszy od starego rozwiązania. Jeden segment użytkowników, jeden kanał albo jedna klasa transakcji. Nie więcej.
Przy ocenie warto patrzeć na proste wskaźniki operacyjne, bliskie logice metryk DORA: częstotliwość wdrożeń, odsetek nieudanych zmian i czas przywrócenia usługi. Jeśli nowy komponent wygląda lepiej na diagramie, ale pogarsza te trzy rzeczy, nie jest gotowy do szerszego przejęcia ruchu.
Na wyjściu potrzebna jest decyzja go lub no-go. Albo nowa ścieżka przejmuje uzgodniony zakres ruchu i można planować następny etap, albo dane z produkcji tego nie potwierdzają i projekt trzeba zatrzymać lub zawęzić. No-go po 90 dniach bywa oznaką kontroli, nie porażki.
Złe pytanie brzmi: ile kosztuje pełna modernizacja. Lepsze brzmi: ile kosztuje pierwszy etap, który realnie zmniejsza zależność od starego systemu. Kupuje się nie hasło modernizacji, tylko ograniczenie konkretnego ryzyka operacyjnego.
Na taki etap zwykle wystarcza mały zespół: lider techniczny lub architekt, kilku programistów, QA albo automatyzacja testów i częściowe wsparcie DevOps. Gdy dostawca od razu proponuje duży skład bez twardo wyciętego zakresu, często kompensuje niepewność liczbą ludzi. Większy zespół podnosi koszt koordynacji, wydłuża uzgodnienia między rolami, zwiększa liczbę zależności i rozmywa odpowiedzialność za decyzje graniczne, które w pierwszym etapie powinny zapadać szybko.
| Opcja zakupu | Kiedy ma sens | Główne ryzyko | Sygnał ostrzegawczy |
|---|---|---|---|
| Mały etap z twardym zakresem | Gdy da się wydzielić proces lub integrację i porównać wynik ze starą ścieżką | Zbyt wąski zakres bez wartości biznesowej | Brak właściciela procesu po stronie biznesu |
| Szerszy etap z architekturą przejściową | Gdy potrzebna jest warstwa pośrednia przed właściwą migracją | Rozrost rozwiązania tymczasowego do nowego długu | Brak daty wygaszenia komponentów przejściowych |
| Duży program modernizacyjny od startu | Rzadko, głównie gdy istnieją już dane, kontrakty i silny nadzór właścicielski | Utrata porównywalności, brak rollbacku, eskalacja kosztu | Oferta oparta głównie na liczbie osób i sprintach |
Dobra oferta opisuje zakres, założenia o danych, artefakty po kolejnych bramkach, sposób mierzenia sukcesu i warunki zatrzymania projektu. Słaba oferta sprzedaje stawkę, zespół i obietnicę elastyczności. To za mało, zwłaszcza przy systemach, w których koszt błędu ujawnia się dopiero po wdrożeniu.
W rozliczeniu lepiej sprawdza się etap z jasno opisanym wynikiem niż otwarty model Time and Material bez twardego celu. Oczekuj mapy zależności, planu rollbacku, testów krytycznej regresji, działającego komponentu i ograniczonego ruchu produkcyjnego. Same sprinty i statusy nie są jeszcze postępem.
Oferta bez rollbacku i bez środowiska porównawczego przenosi na klienta ryzyko, że pierwsze realne testy odbędą się dopiero na produkcji. Konsekwencja jest bardzo konkretna: trudniej odróżnić błąd nowego komponentu od starego problemu w rdzeniu, rośnie koszt incydentu, a decyzja o cofnięciu zmiany staje się sporem zamiast procedurą. Zamiast akceptować taki układ, wymagaj w ofercie ścieżki porównawczej, warunków przełączenia ruchu, odpowiedzialności za rollback i listy metryk, na podstawie których obie strony uznają etap za zakończony albo zatrzymany.
W podobnych projektach powtarza się jeden wzorzec, który widziałem wielokrotnie w pracy z zespołami produktowymi i integracyjnymi: najszybciej wykolejają się nie te organizacje, które mają najstarszy kod, tylko te, które nie umieją odmówić rozszerzania zakresu po pierwszych odkryciach. Dlatego kryterium zakupu jest proste. W umowie powinny znaleźć się granica pierwszego etapu, testy dla ścieżki krytycznej, środowisko porównawcze, przećwiczony rollback i warunki zatrzymania projektu. Jeśli wykonawca nie chce tego podpisać, lepiej nie zaczynać.
Jest jeszcze jedna niewygodna obserwacja. Część organizacji używa hasła modernizacji legacy jako sposobu na odłożenie trudnych decyzji właścicielskich: kto akceptuje wyjątki, które procesy naprawdę zarabiają, a które tylko odziedziczono po dawnych wdrożeniach. W takim układzie nawet dobry zespół techniczny nie dowiezie sensownego etapu 90-dniowego, bo projekt będzie pełnił funkcję politycznego parasola.
Jeśli po stronie biznesu nie ma właściciela zdolnego zamknąć sporu o zakres w ciągu dni, a nie tygodni, zakup modernizacji należy odłożyć. To mniej efektowne niż start programu, ale zwykle tańsze.
Przy migracji z legacy nie wystarczy porównać ceny i składu zespołu. Trzeba porównać mechanikę ograniczania ryzyka.
Jeśli dwie oferty mają podobną cenę, a tylko jedna zawiera te elementy, wybór jest prosty. Ta droższa na papierze bywa tańsza operacyjnie, bo zmniejsza ryzyko kosztownego chaosu po wdrożeniu. Z kolei najtańsza oferta bez porównywalnego i odwracalnego pierwszego etapu zwykle kończy się tym, że pierwsze tygodnie produkcji służą do ustalania, czy problem leży w nowym komponencie, starym rdzeniu czy w danych przejściowych. To nie jest etap modernizacji, tylko kosztowna diagnostyka prowadzona pod presją biznesu.
Migracja z legacy ma sens w 90 dni tylko wtedy, gdy pierwszy etap jest mały, porównywalny i odwracalny. Bez takiego startu organizacja nie kupuje kontroli ryzyka, tylko zwiększa prawdopodobieństwo sporu o dane, odpowiedzialność i zakres kolejnych prac. Dobra decyzja zakupowa nie polega na wyborze najładniejszej architektury, lecz na sprawdzeniu, czy wykonawca potrafi ograniczyć promień awarii, pokazać dane porównawcze i zgodzić się na warunki zatrzymania projektu, zanim pojawi się presja produkcyjna.
Gdy pierwszy etap wymaga jednocześnie migracji danych historycznych, zmian w raportowaniu, przebudowy wspólnego modelu uprawnień i obsługi wielu nieudokumentowanych integracji. W takim układzie lepiej zacząć od krótkiego discovery niż od implementacji bez granic.
Trzeba znać warunek przełączenia, osobę odpowiedzialną, czas przywrócenia usługi i sposób obsługi danych zapisanych przez nową ścieżkę. Jeśli wykonawca nie potrafi tego rozpisać operacyjnie, rollback istnieje tylko na slajdzie.
Tylko wtedy, gdy zakres danych jest ograniczony i da się go odseparować od historii oraz raportowania. Jeśli projekt wymaga pełnej rekonsyliacji wielu źródeł, pierwszy etap najpewniej został źle wybrany.
Po braku twardej granicy zakresu, braku środowiska porównawczego, ogólnikowym rollbacku i rozliczeniu opartym wyłącznie na czasie zespołu. Dobra oferta opisuje wynik, założenia o danych i warunki zatrzymania projektu.
