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ć deploy, 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ą.

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ę rollbacku. W legacy dobrą granicą może być jeden endpoint, typ dokumentu, krok procesu albo rola użytkownika. Nie musi być idealna — musi być możliwa do obserwacji i wycofania.

Feature flag, tryb shadow, 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 monitoringiem 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 backup oraz sprawdzony restore;
• loguj 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 jako diff, 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 review pozostaje potrzebne.

Rewrite 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.