Migracje & modernizacja systemów

Migracja systemu legacy
jakie są prawdziwe ryzyka (i jak ich uniknąć)

Rzadko wywraca ją zła technologia. Częściej to dane, których nikt nie sprawdził, i integracje, o których nikt nie pamięta.

Na pierwszy rzut oka wszystko wygląda dobrze.

System działa, użytkownicy logują się, zamówienia trafiają do realizacji, a kolejne dni mijają bez większych awarii. Skoro aplikacja spełnia swoje zadanie, trudno znaleźć argument za jej modernizacją.

Problem pojawia się dopiero wtedy, gdy firma chce zrobić kolejny krok. Nagle wdrożenie nowej funkcji zajmuje tygodnie, prosta integracja wymaga przebudowy kilku modułów, a każda zmiana rodzi to samo pytanie: co jeszcze przestanie działać?

Nieważne, czy mówimy o starym .NET, Javie, PHP, Rails czy Node.js. Większość systemów starzeje się w podobny sposób. Nie przez jedną błędną decyzję, lecz przez setki małych zmian. Kod staje się coraz bardziej złożony, dokumentacja przestaje nadążać za rzeczywistością, technologie tracą wsparcie, a utrzymanie systemu pochłania coraz więcej czasu i pieniędzy.

W pewnym momencie rozwój przestaje być największym wyzwaniem – staje się nim samo utrzymanie systemu.

Zanim przepiszesz choćby linię kodu: 4 pytania, które oszczędzą Ci zawału

Największym zagrożeniem dla migracji rzadko bywa technologia. Zazwyczaj jest to brak wiedzy o tym, jakie „trupy" kryją się w Waszym starym systemie. Zanim uroczyście ogłosicie start projektu, zadajcie sobie te 4 pytania.

1. Kto posprząta ten śmietnik w danych?

   Czy ktoś w ogóle sprawdził, ile macie duplikatów i rekordów z 2008 roku z adresem test@test.com? Nowy system będzie działał szybciej. Tyle że szybciej będzie zwracał błędne dane.

2. Czy wiecie o WSZYSTKICH integracjach? (Spoiler: nie wiecie)

   Stary monolit jest jak stuletnia kamienica. Nikt nie wie, dokąd idą te wszystkie samowolnie podłączone rury. Zapomniane skrypty do fakturowania, poboczne integracje z CRM-em robione przez stażystę 5 lat temu, webhooki do mailingu... Najgorsza opcja to odkryć je tydzień po wyłączeniu starego serwera, gdy księgowość przestanie dostawać wpłaty.

3. Czy Wasz zespół potrafi w tym pisać, czy dopiero ogląda tutoriale na YouTube?

   Nawet najbardziej „ekscytujący" framework z topki GitHub-a wyłoży projekt, jeśli zespół będzie się go uczył na żywej tkance produkcyjnej. Migracja to kiepski moment na naukę nowego frameworka. Produkcja rzadko bywa dobrym środowiskiem szkoleniowym.

4. Jaki jest plan B, gdy coś się wysypie?

   Wzorce typu Strangler Fig są super, bo pozwalają migrować system kawałek po kawałku. Ale co zrobicie, gdy po przełączeniu nowego modułu w piątek o 17:00 dane zaczną się rozjeżdżać? Czy macie przycisk „Ewakuacja" (rollback), czy będziecie gasić pożar na żywca przez cały weekend?

Jeśli na choć jedno z tych pytań odpowiedź brzmi: „sprawdzimy w trakcie", zatrzymajcie migrację na chwilę. To znacznie tańsze niż odkrywanie odpowiedzi już na produkcji.

Jak ograniczyć ryzyko? Buduj obok, nie zamiast

Naturalnym odruchem jest przepisanie aplikacji od zera. W praktyce takie projekty trwają miesiącami, pochłaniają duże budżety i kończą się jednym, ryzykownym przełączeniem całego systemu. Jeśli właśnie wtedy ujawnią się problemy z danymi lub integracjami, ich naprawa odbywa się już pod presją czasu.

Historia pokazuje, że takie scenariusze potrafią być bardzo kosztowne. W 2018 roku brytyjski bank TSB¹TSB Bank, migracja platformy bankowej, kwiecień 2018, doniesienia BBC i Financial Conduct Authority. podczas migracji nowej platformy odciął miliony klientów od dostępu do kont. Kilka lat wcześniej Knight Capital²Knight Capital Group, błąd wdrożeniowy, sierpień 2012, dokumentacja SEC. stracił 440 milionów dolarów w zaledwie 45 minut po błędzie we wdrożeniu nowej wersji oprogramowania. W obu przypadkach zawiódł moment jednorazowego przełączenia, a możliwość szybkiego wycofania zmian praktycznie nie istniała.

Dlatego coraz więcej firm wybiera Strangler Fig Pattern. Nazwę tego wzorca spopularyzował Martin Fowler, inspirując się figowcem dusicielem. Brzmi groźnie, ale w świecie IT to wyjątkowo uprzejmy sposób pożegnania starego systemu. Zamiast wyrywać go z korzeniami, nowa aplikacja krok po kroku przejmuje jego obowiązki, aż stary system może spokojnie przejść na zasłużoną emeryturę.

W praktyce oznacza to, że przez pewien czas oba systemy działają równolegle. Warstwa routingu kieruje użytkowników do nowych modułów, a pozostałe funkcje nadal obsługuje stara aplikacja. Obie korzystają z tej samej bazy danych, dzięki czemu każdą zmianę można wdrażać i weryfikować etapami, bez jednego ryzykownego „dnia przełączenia".

To największa zaleta tego podejścia. Zamiast jednego dużego wdrożenia masz serię małych, kontrolowanych zmian. Jeśli coś pójdzie nie tak, wystarczy wycofać konkretny moduł, a nie całą migrację.

Diabeł tkwi w szczegółach

Wyobraźmy sobie firmę, która migruje pięć modułów: zamówienia, magazyn, fakturowanie, raporty i obsługę klienta. Sam wybór technologii to dopiero początek. O powodzeniu projektu decydują zwykle znacznie mniej oczywiste rzeczy.

1. Kolejność migracji

   Zespół od lat najbardziej narzeka na magazyn. To najgorzej napisany fragment systemu, każda zmiana zajmuje tygodnie. Naturalną pokusą jest zacząć właśnie od niego, żeby wreszcie mieć go z głowy.

   Problem w tym, że po czterech miesiącach magazyn nadal nie działa. Okazuje się jeszcze bardziej skomplikowany, niż ktokolwiek przypuszczał. Poza zespołem IT nikt nie widzi żadnych efektów migracji, a zarząd zaczyna pytać, na co właściwie wydawane są pieniądze.

   A teraz drugi scenariusz. Firma zaczyna od fakturowania. Ten moduł jest technicznie prostszy, ale codziennie utrudnia pracę księgowości i blokuje integrację z nowym systemem płatności. Cztery miesiące później działa już w nowej aplikacji, podłączony przez warstwę routingu do tej samej bazy co reszta jeszcze niezmigrowanego systemu. Księgowość przestaje ręcznie poprawiać błędy, użytkownicy widzą zmianę, a zarząd dostaje pierwszy dowód, że projekt zmierza w dobrym kierunku.

2. Monitoring

   Jeszcze przed pierwszym przełączeniem zespół uruchamia logi, tracing i metryki starego systemu. Dzięki temu, gdy nowy moduł zaczyna przejmować ruch, można porównać zachowanie obu aplikacji dla tych samych operacji. W ten sposób nawet niewielkie różnice, choćby w zaokrąglaniu wartości, wychodzą na jaw, zanim wpłyną na pracę użytkowników.

   Monitoring powinien pojawić się przed migracją, a nie po niej. W przeciwnym razie pierwszym systemem zgłaszania błędów stają się... użytkownicy.

3. Ludzie

   Jest jeszcze jedna rzecz, o której rzadko się mówi głośno. W trakcie migracji zespół naturalnie dzieli się na dwie grupy: tych, którzy piszą błyszczący nowy kod, i tych, którzy wciąż łatają stary magazyn, bo ktoś musi. Ta druga grupa zaczyna czuć się jak zespół zesłany na Sybir, podczas gdy reszta buduje przyszłość firmy.

   To nie jest problem techniczny, ale potrafi zabić migrację skuteczniej niż zły framework. Ludzie odchodzą, motywacja spada, a wiedza o starym systemie, ta sama, której tak bardzo potrzeba, żeby bezpiecznie go wyłączyć, znika razem z nimi. Warto rotować zespół między starym a nowym kodem i jasno komunikować, że utrzymanie legacy to nie kara, tylko tymczasowy, kluczowy etap projektu.

4. Sukces

   Cztery miesiące później moduł fakturowania działa. Harmonogram się zgadza, co samo w sobie cieszy, ale prawdziwa ulga przychodzi dopiero wtedy, gdy księgowość milczy. Nikt nie wysyła screena z komentarzem: „Co to za kwota?!". W IT taka cisza to najlepszy możliwy komunikat: wszystko działa.

Na co migrować? To zależy, który pożar dzisiaj gasisz

W praktyce nie istnieje jedna „święta" technologia. Dobry wybór wynika z potrzeb firmy, możliwości zespołu i tego, w jakim stanie jest Twoja obecna aplikacja.

Zanim zaczniesz porównywać frameworki i przeglądać rankingi „najlepszych technologii 2026", odpowiedz sobie na kilka prostszych pytań.

Czy zespół będzie umiał to rozwijać?

Framework, którego nikt nie potrafi rozwijać, za kilka lat stanie się kolejnym legacy. Wybierz coś, w czym zespół już pracuje albo do czego bez większego problemu znajdziesz specjalistów. Nawet najlepsza technologia niewiele pomoże, jeśli jedynym ekspertem będzie autor prezentacji z kick-offu.

Do czego ta aplikacja jest naprawdę potrzebna?

Framework powinien pasować do problemu, a nie odwrotnie.

Czy nowy system przez jakiś czas będzie mieszkał ze starym?

Przy podejściu Strangler Fig oba systemy przez pewien czas żyją obok siebie i często korzystają z tej samej bazy danych. Dlatego warto sprawdzić, czy wybrana technologia bez problemu poradzi sobie z istniejącym schematem bazy, niestandardowymi tabelami, starymi kluczami głównymi i rozwiązaniami sprzed kilkunastu lat.

Ile będzie kosztować utrzymanie, gdy opadnie pierwszy entuzjazm?

Koszt wdrożenia to dopiero początek. Równie ważne jest to, ile będzie kosztował rozwój systemu za dwa lub trzy lata i jak łatwo znajdziesz kolejnych programistów. Egzotyczna technologia potrafi zachwycić na początku, ale przy pierwszej rekrutacji szybko pokazuje swój prawdziwy koszt.

Czy AI będzie pomagać, czy zgadywać?

Popularne technologie, takie jak Laravel, Django czy Rails, mają dużą przewagę. AI uczyło się na milionach przykładów ich kodu i dokumentacji, dzięki czemu lepiej rozumie ich konwencje i częściej podpowiada poprawne rozwiązania. Im bardziej niszowy framework wybierzesz, tym częściej model będzie zgadywał zamiast pomagać.

Najgorsza decyzja to rzadko wybór konkretnego frameworka. Znacznie częściej problemem jest technologia, która świetnie wygląda na slajdach, ale kompletnie nie pasuje do ludzi, projektu i sposobu prowadzenia migracji.

Gdzie AI w migracji naprawdę daje radę (a gdzie polegnie)

Hasło „AI pisze kod" można włożyć między bajki. W praktyce AI nie jest architektem. To bardzo szybki, skrupulatny i nigdy nienarzekający junior, któremu zlecasz najbardziej żmudną robotę. Tam, gdzie AI wnosi realną wartość, są cztery konkretne sytuacje.

1. Archeologia kodu, czyli „co autor miał na myśli w 2012 roku?"

   Zamiast przez kilka dni przedzierać się przez kod bez jednego komentarza, pozwalasz AI przeanalizować projekt. W kilka minut dostajesz mapę zależności: co z czym się łączy, którędy płyną dane i dlaczego ten jeden moduł w ogóle jeszcze działa.

2. Testy dla „archeologicznych zabytków"

   Zanim cokolwiek ruszysz w starym systemie, musisz wiedzieć, czy go nie zepsujesz. AI potrafi wygenerować testy pokazujące, jak system zachowuje się dzisiaj, dzięki czemu po migracji łatwo sprawdzić, czy wszystko nadal działa tak samo.

3. Powtarzalna praca na masową skalę

   CRUD-y, formularze, setny panel administracyjny. Tworzysz jeden wzorcowy moduł, a kolejne AI generuje znacznie szybciej niż ręczne odtwarzanie tego samego schematu po raz dziesiąty.

4. Rozgryzanie dziwactw sprzed dekady

   Przy jednej z migracji z ASP.NET do Laravela stary ASP.NET Identity przechowywał hasła w kilku wariantach PBKDF2, zależnie od wersji frameworka. Ręczne rozgryzienie tego mechanizmu zajęłoby wiele godzin. AI zrozumiało schemat znacznie szybciej, a test był prosty: stary użytkownik się loguje? Loguje. Działa.

A gdzie AI polegnie?

Tam, gdzie trzeba myśleć strategicznie. AI nie wie, które moduły przenieść najpierw, jak podzielić monolit na sensowne kawałki ani co jest priorytetem dla biznesu. Z samego kodu tego nie wywróży.

Dlatego traktuj AI jak świetnego analityka i asystenta od żmudnej pracy. Wykona ogrom powtarzalnych zadań, ale ster projektu wciąż powinien trzymać człowiek.

← Wróć do bloga