Legacy bez paniki: jak bezpiecznie przejąć starą aplikację?

Dyskomfort to nie ryzyko

Kod może być brzydki i stabilny, a nowy moduł może wyglądać elegancko i nie mieć działającego backupu. Zamiast pytać, czy technologia jest przestarzała, sprawdź, co dzieje się przy kolejnej zmianie i awarii: czy da się odtworzyć środowisko, znaleźć błąd, przywrócić dane i wycofać wdrożenie.

Jeśli aplikacja obsługuje ważny proces, rewrite o dużym zakresie może zamrozić rozwój na wiele miesięcy, a przy okazji odtworzyć reguły, których nikt nie zapisał. To ocena ryzyka konkretnego projektu, nie uniwersalna statystyka. Najpierw warto zmniejszyć ryzyko operacyjne i poznać granice systemu.

• czy znamy krytyczne procesy i dane;
• czy działają backup oraz restore;
• czy wdrożenie można powtórzyć bez autora;
• czy znamy role, uprawnienia, cron-y i zewnętrzne API;
• czy potrafimy zmierzyć, że poprawka nie pogorszyła działania.

Przejęcie zaczyna się od dostępu i odtworzenia

Zbierz repozytoria, konta chmurowe, domeny, certyfikaty, usługi, sekrety, zadania cykliczne i środowiska. Nie przechowuj sekretów w zwykłym dokumencie, ale ustal, kto ma do nich dostęp i jak można je bezpiecznie zmienić. Sam dostęp do repozytorium nie oznacza jeszcze, że system da się uruchomić.

Pierwszy etap powinien zakończyć się krótką mapą: jak uruchomić projekt, jak wykonać wdrożenie, gdzie są logi, jak przywrócić dane, co jest ręczne i czego nadal nie wiadomo. Eurostat podał, że w 2024 roku co najmniej jeden incydent ICT zgłosiło 22% badanych przedsiębiorstw w UE i 32% w Polsce. To odsetek firm deklarujących incydent, a nie prawdopodobieństwo awarii tej aplikacji. Jest dobrym argumentem za sprawdzeniem procesu, nie powodem do straszenia każdą starą zależnością.

Nie każda migracja zaczyna się od dobrego planu

Kiedy dołączyłem do pracy przy Trans.info, produkt był w trakcie migracji z Next.js 12 do 14, ale do jej zakończenia było jeszcze daleko. W idealnych warunkach kolejne strony i ścieżki przenosilibyśmy stopniowo z Pages Routera do App Routera. Na tym etapie te decyzje nie zostały jednak podjęte na początku projektu.

Z perspektywy czasu problemem nie była sama technologia, tylko zarządzanie migracją. To był mismanagement: bieżące utrzymanie i decyzje zarządcze nie zostawiły wcześniej przestrzeni na przedstawienie etapowej ścieżki jako równorzędnej opcji. Developer, który nie działa proaktywnie albo jest zgnieciony przez management, zwykle realizuje ustalony plan zamiast powiedzieć: możemy migrować po kawałku, z mniejszym zakresem ryzyka i możliwością wycofania. Taka propozycja wymaga zarówno odwagi technicznej, jak i miejsca na dyskusję.

Dzięki wspólnym ustaleniom ograniczyliśmy później zakres migracji: część funkcji została tymczasowo wycięta, żeby dokończyć podstawę, a następnie zrealizować je osobno. AI również może odruchowo proponować przeniesienie wszystkiego naraz, bo łatwiej opisać stan docelowy niż granice przejściowe. Czasem lepiej rozpisać migrację na mniejsze kroki — kolejne strony lub endpointy, warstwę zgodności, pomiar różnic i możliwość wycofania. Może to zużyć więcej pracy i tokenów, ale bywa skuteczniejsze, bo ogranicza rozmiar pojedynczej awarii i pozwala uczyć się na każdym etapie.

Podobną lekcję widziałem przy PolyTrans. Pomysł wyszedł od kolegi z redakcji Trans.info, a ja sam zaimplementowałem narzędzie i rozwijałem je na podstawie własnych doświadczeń z procesem wydawniczym. Wraz z rozwojem modeli AI rozwiązanie stawało się skuteczniejsze, ale jego wartość wynikała z dopasowania do istniejącego WordPressa, statusów i pracy redakcji, nie z samego użycia modelu. Rozwijałem je samodzielnie, przy głośnym kibicowaniu zespołu redakcyjnego i deweloperskiego.

Brak testów nie oznacza konieczności przepisywania

Gdy nie ma testów, zacznij od reprezentatywnych danych, logów, wyników i obserwacji pracy użytkowników. Test charakteryzujący zapisuje aktualne zachowanie i chroni przed przypadkową zmianą, ale nie potwierdza, że to zachowanie jest poprawne. O tym trzeba porozmawiać z właścicielem procesu.

AI może znaleźć punkty wejścia, nazwać moduły, wskazać podobne funkcje i przygotować szkic testu. Nie potwierdzi jednak, że wyjątek widoczny w kodzie jest błędem, a nie nieformalną regułą firmy. Każdy wygenerowany opis trzeba porównać z rzeczywistym działaniem.

Wydziel zmianę i obserwuj jej granice

Bezpieczny prototyp zmiany powinien mieć ograniczony zakres, osobne środowisko, dane testowe, metrykę sukcesu i instrukcję wycofania zmiany. W legacy dobrą granicą może być jeden punkt wejścia, typ dokumentu, krok procesu albo rola użytkownika. Nie musi być idealna — musi być możliwa do obserwacji i wycofania.

Przełącznik funkcji, tryb równoległy, porównanie starej i nowej ścieżki albo mała grupa użytkowników pozwalają uczyć się bez przełączania całego systemu. NIST SSDF porządkuje bezpieczny rozwój wokół przygotowania organizacji, ochrony oprogramowania, wytwarzania zabezpieczonego oprogramowania i reagowania na podatności. Z kolei model DevSecOps NIST łączy planowanie, budowanie, testowanie, wydanie, wdrożenie i operowanie z monitorowaniem oraz informacją zwrotną. Konkretne techniki ograniczania wdrożenia są już praktycznym wyborem zależnym od systemu, nie gwarancją wynikającą ze standardu.

• zapisz, co zmieniasz i czego nie zmieniasz;
• przygotuj kopię zapasową oraz sprawdzone odtworzenie;
• rejestruj różnice między starą i nową ścieżką;
• ustal, kto może wycofać zmianę i po jakim sygnale.

AI może pomóc w produkcji, ale nie przejmuje odpowiedzialności

Model może przygotować test, szkic migracji, analizę logów albo propozycję poprawki. Przy kodzie produkcyjnym musi pracować bez sekretów i niekontrolowanego dostępu, a zmiana powinna być widoczna w porównaniu wersji, sprawdzona na danych testowych i możliwa do wycofania. W samo-selekcyjnej ankiecie Stack Overflow Developer Survey 2025 66% respondentów wskazywało frustrację rozwiązaniami „prawie poprawnymi”, a 45% twierdziło, że debugowanie kodu AI zajmuje więcej czasu niż napisanie go samodzielnie. To deklaracje doświadczeń developerów, nie audyt każdego modelu, ale dobrze pokazują, dlaczego przegląd kodu pozostaje potrzebny.

Przepisanie ma sens dopiero wtedy, gdy nie da się wyznaczyć bezpiecznej granicy zmian, obecny model danych blokuje wymagane bezpieczeństwo albo koszt każdej kolejnej poprawki przewyższa koszt zastąpienia konkretnego fragmentu. Warto przepisywać etapami, zachowując wiedzę o tym, co system robił do tej pory.