Kiedy modernizacja systemu legacy staje się koniecznością? 

Firmy rzadko decydują się na modernizację przestarzałych systemów IT z własnej woli. Zwykle popycha je do tego jeden z trzech powodów. 

Pierwszy to brak zgodności z przepisami. Nowa regulacja wchodzi w życie, a istniejąca aplikacja nie jest w stanie jej spełnić bez gruntownej przebudowy. Dla dużych, często międzynarodowych korporacji jest to silny bodziec, ponieważ wiąże się z wysokimi karami, a nawet chwilową utratą prawa do prowadzenia części działalności. 

Drugi to koniec wsparcia technologicznego. Framework albo wersja języka przestają otrzymywać łatki bezpieczeństwa. Od tego momentu każdy dzień działania systemu to otwarte drzwi dla cyberprzestępców. Bezpieczeństwo aplikacji legacy przestaje być kwestią hipotetyczną i staje się konkretną podatnością, którą ktoś prędzej czy później wykorzysta. 

Trzeci to rosnący koszt. Im starsza technologia, tym mniej specjalistów, którzy ją znają, i tym drożej kosztuje każda ich godzina. Do tego dochodzi czas: zanim ktokolwiek wprowadzi zmianę, musi najpierw rozszyfrować, jak działa kod. Redukcja długu technologicznego przestaje być kwestią wygody, a staje się prostym rachunkiem. 

Zwykle te powody nie występują pojedynczo. Firma, która latami odkładała upgrade z powodu braku budżetu, znajduje go z dnia na dzień, gdy zmianę wymusza przepis.  

Compliance jako wyzwalacz modernizacji systemu legacy: dostępność cyfrowa (WCAG i EAA) 

Dostępność cyfrowa to jeden z najlepszych przykładów tego, jak wymóg formalny uruchamia modernizację całego stosu technologicznego. 

Zgodność z Europejskim Aktem o Dostępności (w Polsce dla firm komercyjnych obowiązuje ona od 28 czerwca 2025 r., zgodnie z ustawą z 26.04.2024 o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze) obejmuje między innymi dostępność stron sprzedażowych, a to oznacza, że aplikacja, która nie spełnia wymogów, wyklucza część klientów i naraża firmę na sankcje.  

Dostosowanie do WCAG na poziomie AA dla niektórych brzmi jak kosmetyczna zmiana po stronie frontendu: poprawić kontrasty, dodać opisy alternatywne, uporządkować nawigację klawiaturą. Ale w systemach zbudowanych na przestarzałej technologii sprawa jest bardziej skomplikowana. Stary sposób renderowania stron, brak elastyczności warstwy prezentacji, architektura wymuszająca ładowanie całej strony naraz. To wszystko sprawia, że zapewnienie zgodności z WCAG starej technologii bywa po prostu niewykonalne. 

Skoro zgodności nie da się osiągnąć na starym stosie technologicznym, a osiągnąć ją trzeba, decyzja praktycznie zapada sama. Modernizacja przestaje być tematem do dyskusji i staje się warunkiem dalszej sprzedaży online. 

Największe wyzwanie to modernizacja systemu IT bez dokumentacji 

W klasycznym procesie wytwarzania oprogramowania dysponuje się analizą i docelowym stosem technologicznym, a kod pisze się od zera. Analityk spotyka się z interesariuszami, spisuje wymagania, przekazuje dokumentację deweloperom. 

Modernizacja nieudokumentowanego kodu to przypadek, w którym na starcie pewny jest właściwie jeden element, czyli kod. To z niego trzeba wyprowadzić pozostałe składowe. Przepisanie systemu bez wymagań oznacza, że najpierw trzeba odtworzyć wiedzę o tym, co system robi, zanim w ogóle zacznie się go przenosić. 

Dlatego tak istotny jest rzetelny audyt starego systemu. Zanim padnie pierwsza linijka nowego kodu, trzeba wiedzieć, co dokładnie się przenosi, które funkcje są naprawdę wykorzystywane, a które stanowią martwe pozostałości sprzed lat. 

Jak AI przyspiesza modernizację systemu legacy 

W takich przypadkach świetnie spisują się modele językowe. Nie jako magiczny generator, który sam przepisze aplikację, ale jako zaawansowane narzędzie w rękach doświadczonych analityków systemowych. 

Odpowiednio instruowany model językowy analizuje „spaghetti” starego kodu i wskazuje, co dana funkcja faktycznie robi. Następnie wygenerowany wniosek jest weryfikowany przez człowieka. W systemach, w których logika jest tak splątana, że nikt nie potrafi jej rozczytać, AI code analysis często daje pierwszy punkt zaczepienia, który następnie jest pogłębiany. 

Przepisywanie kodu z AI pomaga też w zadaniu z pozoru banalnym, a w rzeczywistości pochłaniającym ogromne ilości czasu: w odróżnieniu kodu martwego od świadomie wyłączonego. Stary system potrafi zawierać funkcje nieużywane od lat obok kodu, który celowo wyłączono. 

Zostaje jeszcze automatyzacja migracji mechanicznych. Przechodzenie przez kolejne wersje frameworka czy języka to zadanie żmudne, długie i powtarzalne, idealne dla modeli językowych. To właśnie tu sztuczna inteligencja w rozwoju oprogramowania daje najczystszy zysk, bo w krótszym czasie wykonuje pracę, która człowieka często nudzi i męczy. 

Przykład: migracja aplikacji Java na nowy stos technologiczny 

Dobrze obrazuje to projekt zrealizowany dla dużego operatora telekomunikacyjnego. 

Punktem wyjścia była aplikacja sprzedażowa z 2004 roku, oparta na Javie 7. Klient dostarczył kod bez dokumentacji i bez wymagań. Do rozwiązania były trzy rzeczy naraz: podbicie stosu technologicznego, dostosowanie do wymogów dostępności oraz usunięcie martwych funkcjonalności, takich jak obsługa dawno wygasłej promocji sezonowej. 

Migracja Java nie mogła przebiegać skokowo. Nie da się przeskoczyć wprost z bardzo starej wersji do najnowszej, bo kolejne wydania nie są ze sobą kompatybilne wprost. Upgrade wersji Java trzeba było więc prowadzić etapami: migracja z Javy 7 do ósemki, potem dalej, aż do wersji na tyle świeżej, że pozostałą część drogi można było pokonać większym krokiem. Backend pozostał w Javie, bez zmiany technologii, a modernizacja aplikacji Java skupiła się na uporządkowaniu i podniesieniu wersji. 

Z kolei na frontendzie nastąpiła zmiana technologii. Migracja na Angulara, czyli przejście na nowoczesny framework, który pozwala spełnić wymogi dostępności i daje elastyczność, jakiej stara warstwa prezentacji nie miała. Aktualizacja stosu technologicznego po stronie frontendu była warunkiem, bez którego reszta celów była nieosiągalna. 

– Modernizując z pomocą AI platformę sprzedażową pewnej firmy telekomunikacyjnej, trafiliśmy na zaniedbanie i realną lukę bezpieczeństwa. Usługi pay-per-view były wyłączone od 2014 roku, choć ostatnią sprzedaż zrealizowano w 2010, a nikt tego nie wychwycił, bo po stronie klienta nie było testów regresji. Poważniejsza była druga sprawa: aplikacja wstawiała do stron treść z bazy bez oczyszczenia. Ten sam mechanizm w innym projekcie pozwolił kiedyś ukryć w dokumencie koparkę kryptowalut, obciążającą komputer każdego, kto go otworzył. – opowiada Piotr Decyk, Analityk biznesowo-systemowy w Nexio Management. 

Co daje, a czego nie daje AI przy modernizacji systemów legacy 

Przy zadaniach mechanicznych, takich jak migracja kolejnych wersji, AI potrafi skrócić pracę – gdybyśmy mieli szacować było by to 30% czasu klasycznego podejścia. To zysk czasowy, i to znaczący. Nie jest to jednak automatycznie zysk kosztowy. Tokeny, które zużywa model, kosztują. Do wynagrodzenia zespołu dochodzi koszt użycia narzędzia. 

AI nie zastępuje ludzi. Model bywa szybszy w analizie, ale jego wyniki wymagają weryfikacji. Analityk wciąż zatwierdza rozwiązania architektoniczne. Deweloper wciąż potwierdza, że wygenerowany kod jest wiarygodny. Właściciel modernizowanego rozwiązania, potwierdza, że wygenerowany przez AI wniosek nt. danej funkcji jest prawdziwy.  

Model potrafi „zhalucynować” odpowiedź albo potwierdzić błędne założenie, jeśli użytkownik na nie naciska. Czas, wcześniej poświęcany na analizę od zera, teraz jest wykorzystywany na weryfikację analizy wykonanej przez model.  

– Zapytasz AI, ile jest dwa plus dwa, a odpowie, że cztery. Ale kiedy powiesz, że wolałbyś, żeby wyszło pięć, model po chwili przyzna ci rację. Dlatego każdy model językowy trzeba traktować jak narzędzie, a nie jak wyrocznię. Owszem, analizę wykonuje szybciej niż człowiek, więc oszczędność czasu jest realna, ale odpowiedzialność za wynik cały czas zostaje po stronie człowieka. – zauważa Piotr Decyk. 

Są też obszary, w których ostrożność jest obowiązkowa. Tam, gdzie w grę wchodzą dane wrażliwe albo wymóg poufności, przekazywanie całego kodu zewnętrznemu modelowi bywa niedopuszczalne. Rozsądne podejście to praca na fragmentach, a nie na całości oraz jasne ustalenia dotyczące tego, co dzieje się z kodem po stronie dostawcy modelu. 

Do tego dochodzą testy regresji, bez których żadna modernizacja nie powinna trafić na produkcję, oraz świadomość, że dług techniczny da się spłacić tylko wtedy, gdy zmiany są kontrolowane na każdym etapie. 

Kiedy warto zlecić modernizację systemu na zewnątrz 

Modernizacja legacy jest trudna z jednego prostego powodu: łączy archeologię kodu, znajomość wielu wersji technologii i umiejętność rozmowy z klientem, który sam nie zawsze wie, jak działa jego system. Zespół, który robił to wielokrotnie, wie, o co zapytać na starcie, żeby uniknąć niespodzianek w połowie projektu. 

Outsourcing modernizacji IT ma sens wtedy, gdy wewnętrzny zespół nie ma ani wiedzy o starym systemie, ani czasu, żeby ją odtwarzać od zera. Wtedy warto oddać zadanie ludziom, którzy mają sprawdzoną metodę, narzędzia i doświadczenie w wyprowadzaniu logiki z surowego kodu. 

Nexio Management realizuje takie projekty, łącząc klasyczną inżynierię oprogramowania ze wsparciem modeli językowych tam, gdzie faktycznie skracają one pracę. Jeśli masz system, który działa, ale nikt już nie wie dokładnie jak, i wiesz, że prędzej czy później trzeba będzie go ruszyć, dobrym pierwszym krokiem jest rozmowa i audyt.  

 ——
Najczęściej zadawane pytania 

Jak zmodernizować stary system, do którego nie ma dokumentacji? 

Punktem wyjścia jest audyt istniejącego kodu. Zanim zacznie się cokolwiek przepisywać, trzeba odtworzyć wiedzę o tym, co system faktycznie robi, oddzielić funkcje rzeczywiście działające od „martwych” pozostałości i dopiero na tej podstawie zaplanować przeniesienie na nowy stos technologiczny. Modele językowe potrafią tu znacząco przyspieszyć analizę, ale każdy wniosek wymaga weryfikacji przez analityka i potwierdzenia po stronie klienta. 

Co zrobić z przestarzałą aplikacją, która wciąż działa? 

Sam fakt, że aplikacja działa, nie oznacza, że jest bezpieczna ani tania w utrzymaniu. Jeśli technologia przestała być wspierana, koszt utrzymania rośnie, a przepisy wymuszają zmiany, których nie da się wprowadzić na starym stosie, modernizacja przestaje być opcjonalna. Dobrym pierwszym krokiem jest ocena stanu systemu i realnego ryzyka, a nie czekanie na awarię lub kontrolę. 

Ile czasu można zaoszczędzić dzięki wsparciu AI przy migracji? 

Zależy to od charakteru zadania. Przy pracach mechanicznych, takich jak przechodzenie przez kolejne wersje frameworka czy języka, oszczędność bywa znacząca. Warto jednak pamiętać, że jest to głównie oszczędność czasu, nie kosztu, ponieważ użycie modeli wiąże się z własnymi wydatkami, a wygenerowane wyniki wciąż wymagają weryfikacji przez człowieka. 

Czy modernizacja z użyciem AI jest bezpieczna dla danych wrażliwych? 

Wymaga to szczególnej ostrożności. W obszarach objętych wymogiem poufności przekazywanie całego kodu zewnętrznemu modelowi bywa niedopuszczalne. Rozsądne podejście opiera się na pracy na fragmentach kodu oraz na jasnych ustaleniach dotyczących tego, co dzieje się z przekazywanymi danymi po stronie dostawcy modelu.