Modernizacja legacy PHP — utrzymanie i rozwój starych systemów

Legacy code to działający kod, którego nie da się bezpiecznie zmieniać: brak testów, nieaktualne zależności, wiedza o systemie tylko w głowie jednej osoby. System legacy nie jest zły dlatego, że jest stary — staje się ryzykowny, gdy blokuje rozwój: każda zmiana grozi regresją, wdrożenia robi się ręcznie w nocy, a framework i wersja PHP dawno wypadły z okresu wsparcia. Sygnały, że czas na modernizację: PHP 7.x lub starszy (brak poprawek bezpieczeństwa), zależności, których nie da się już zaktualizować, rosnący czas wdrożeń i koszty utrzymania, brak możliwości zatrudnienia nowych osób do projektu. Modernizacja to nie to samo co przepisanie od zera — to uporządkowanie istniejącego systemu krok po kroku, z zachowaniem tego, co działa. Więcej o rozpoznawaniu i klasyfikacji problemu piszę w artykule „Czym jest legacy code?”.

Przeprowadzam kompleksowy audyt: analiza architektury i zależności, identyfikacja martwego kodu i długu technicznego, sprawdzenie bezpieczeństwa (OWASP Top 10), analiza wydajności i skalowalności, rekomendacje z roadmapą modernizacji. Audyt odpowiada na trzy pytania: co dokładnie blokuje rozwój systemu, jaka kolejność napraw minimalizuje ryzyko biznesowe i ile kosztuje każdy etap. Wynikiem jest raport z priorytetami, szacunkami i planem modułów — na jego podstawie decydujesz, co modernizować najpierw. Audyt za 2 000 zł netto daje dokładny kosztorys całego programu; pełny zakres opisuję w artykule „Audyt kodu legacy krok po kroku”.

Nie przepisuję wszystkiego od zera — to zbyt ryzykowne i zbyt drogie. Stosuję sprawdzony wzorzec strangler fig: nowe moduły (np. w Laravelu) działają obok starej aplikacji i przejmują kolejne obszary systemu, a stary kod wygaszany jest dopiero wtedy, gdy nowa ścieżka jest przetestowana na produkcji. Wybieram jeden moduł, zabezpieczam go testami charakterystycznymi, refaktoryzuję, wdrażam na staging, monitoruję i promuję na produkcję. Dopiero wtedy przechodzę do kolejnego modułu. Strategia małych kroków minimalizuje ryzyko, pozwala szybko dostarczać wartość i nigdy nie zostawia firmy bez działającego systemu. Jak wygląda to w praktyce, opisuję w artykule o wzorcu strangler fig.

Refaktoryzacja poprawia strukturę kodu bez zmiany jego zachowania — i tylko wtedy jest bezpieczna, gdy najpierw opiszemy obecne działanie systemu testami charakterystycznymi. To testy pisane na podstawie obserwowanego zachowania: utrwalają to, co system robi dzisiaj (łącznie z bugami, które mają znaczenie biznesowe), żeby refaktoryzacja nie zmieniła niczego nieoczekiwanie. W praktyce: pokrywam testami krytyczne ścieżki (zamówienia, rozliczenia, integracje), refaktoryzuję modułami, usuwam martwy kod i zależności, a każdą zmianę wdrażam przez staging z planem rollbacku. Refaktoryzacja zamiast przepisywania to zwykle 3–5 razy niższy koszt i nieporównywalnie mniejsze ryzyko. Kiedy refaktoryzować, a kiedy przepisać od zera — rozpisuję w artykule o refaktoryzacji legacy code.

PHP 7.x nie dostaje już poprawek bezpieczeństwa — każda wersja poniżej 8.1 jest poza wsparciem, a PHP 8.1 traci je 31.12.2026. Migracja to jednak nie tylko zmiana numerka: nowe wersje PHP łamią część starych konstrukcji, więc potrzebna jest warstwa po warstwie: audyt zgodności (PHPCompatibility, PHPStan), testy regresji, automatyczna refaktoryzacja z Rector (narzędzie automatyzuje zmiany PHP — przepisuje konstrukcje deprecated do nowych odpowiedników), wdrożenie na staging i monitoring po przełączeniu. Skok z PHP 5.6 wymaga przejścia przez wersję pośrednią. Aktualizacja z 8.2/8.3 na 8.4 to zwykle 1–3 dni pracy, migracja z 7.4 na 8.x — 1–2 tygodnie dla małego projektu. Pełny proces z tabelą dat wsparcia opisuję w przewodniku migracji PHP 5.6/7.x → 8.x.

Dług techniczny to koszt, który firma płaci za każdą zmianę w systemie: dłuższe wdrożenia, więcej błędów, wolniejszy rozwój i rosnące koszty utrzymania. Zamiast opisywać go ogólnikami, mierzę go konkretnymi wskaźnikami: pokrycie krytycznych ścieżek testami, liczba znanych podatności w zależnościach, czas wdrożenia zmiany, liczba incydentów produkcyjnych na kwartał i czas potrzebny nowej osobie na pierwszy commit. Te liczby pokazują przed i po modernizacji — dzięki temu program modernizacji ma mierzalny efekt, a nie tylko „porządek w kodzie”. Przykładowe metryki z realnego projektu pokazuje grafika poniżej.

Wdrażam CI/CD, automatyzuję deploymenty, konfiguruję monitoring (serwery, bazy, aplikacje), backup i disaster recovery, a także optymalizuję serwery i bazy danych oraz przenoszę aplikacje na cloud hosting o przewidywalnych kosztach. Wdrożenia przestają być ręcznym rytuałem: każda zmiana przechodzi przez testy automatyczne, statyczną analizę (PHPStan/Larastan) i wdrożenie jednym poleceniem z możliwością natychmiastowego rollbacku. Monitoring z alertami (Sentry, Horizon, New Relic) wykrywa problemy, zanim zauważą je użytkownicy.

Asystenci AI skracają najdroższy etap modernizacji: zrozumienie, co stary kod właściwie robi. W praktyce używam AI w trzech miejscach: przy mapowaniu zależności w module, który widzę pierwszy raz; przy generowaniu szkiców testów charakterystycznych, które potem weryfikuję uruchomieniem; i przy masowych refaktoryzacjach, gdzie Rector wykonuje zmianę, a AI pomaga przygotować reguły. Granica jest stała: decyzje architektoniczne, ocena ryzyka i code review zostają po stronie człowieka — żaden nieprzejrzany kod nie trafia na produkcję, a Twój kod i dane nie są używane do trenowania publicznych modeli. Efekt: krótszy czas zrozumienia codebase i szybsze pokrycie testami — bez oddawania kontroli nad systemem.

Legacy to nie tylko własny kod. Przestarzałe strony i sklepy na WordPress, WooCommerce i PrestaShop mają dokładnie te same problemy: PHP po końcu wsparcia, nieaktualizowane wtyczki i motywy, rosnące ryzyko bezpieczeństwa, wolne działanie i utrudniony rozwój. Modernizuję je tą samą metodyką: inwentaryzacja i kopie zapasowe, aktualizacje przez staging (nigdy „na żywo” na produkcji), usunięcie złośliwego kodu po infekcji, migracja PHP i optymalizacja wydajności. Strony WordPress i sklepy PrestaShop prowadzę dalej w ramach opieki technicznej — z aktualizacjami, backupem, monitoringiem i SLA.

Typowo pracuję z: aplikacjami e-commerce i sklepami (PrestaShop, WooCommerce) zintegrowanymi z ERP, marketplace i kurierami; systemami B2B i wewnętrznymi narzędziami firm (zamówienia, magazyn, rozliczenia, panel handlowców); aplikacjami SaaS i portalami klientów; systemami przejętymi po innym wykonawcy — bez dokumentacji i bez osób, które je znają. Wyzwania są zawsze podobne: brak testów, ręczne wdrożenia, dług techniczny blokujący rozwój i wersja PHP po końcu wsparcia. Pierwszy krok jest zawsze ten sam: audyt, raport ryzyk i roadmapa modernizacji z kosztorysem.