Aktualizacja PHP w firmowej aplikacji: dlaczego nie warto czekać i jak AI skraca migrację z PHP 7.4 i 5

W ostatnich miesiącach przeprowadziłem kilka migracji aplikacji webowych (głównie Symfony, czasem Laravel) z PHP 7.4, a jedną nawet z PHP 5, i mój werdykt jest jednoznaczny: aktualizacja PHP się opłaca i nie warto jej odkładać. PHP 7.4 nie dostaje poprawek bezpieczeństwa od 28 listopada 2022 r. (php.net), a każdy miesiąc zwłoki podnosi ryzyko i późniejszy rachunek. Dobra wiadomość: z pomocą AI (u mnie głównie Claude Code i Codex) migracje trwały od 2–3 dni do tygodnia, zależnie od wielkości aplikacji. Warunek: prowadzi je doświadczony programista, a zmiany przechodzą przez testy.

W skrócie (stan na październik 2026): PHP 7.4 straciło wsparcie 28.11.2022, PHP 5.6 – 31.12.2018, a PHP 8.2 straci je 31.12.2026 (php.net). W 2026 r. celem migracji powinno być PHP 8.4 lub 8.5. Zacznij od audytu i testów. AI wyraźnie skraca mechaniczną część prac.

Czemu musisz dbać o aktualizacje swojej aplikacji

Bo „działa” nie znaczy „jest bezpieczne” ani „będzie tanie w utrzymaniu”. Z każdym miesiącem na starym PHP rośnie ryzyko włamania, opłaty u hostingu, odpowiedzialność za dane klientów i koszt przyszłej migracji.

Czy warto aktualizować PHP, skoro „działa”? Oto pięć argumentów, które zwykle przekonują zarząd.

Koniec wsparcia PHP: co to znaczy w praktyce

Koniec wsparcia (EOL, end of life) oznacza, że twórcy PHP nie wydają już żadnych poprawek, także bezpieczeństwa. Koniec wsparcia PHP 7.4 minął prawie cztery lata temu.

Każda wersja PHP ma 2 lata pełnego wsparcia i 2 lata wyłącznie poprawek bezpieczeństwa (php.net). Stan na 22 października 2026 r.:

Źródła: php.net – wspierane wersje, php.net – wersje bez wsparcia.

Wniosek: migracja do PHP 8.2 w 2026 r. to ślepa uliczka, bo za dwa miesiące ta wersja też traci wsparcie. Celuj w PHP 8.4 lub 8.5.

Bezpieczeństwo: luki, których nikt już nie załata

Na wersji bez wsparcia każda nowo odkryta luka zostaje otwarta na stałe.

Sam php.net ostrzega, że użytkownicy wersji bez wsparcia mogą być narażeni na niezałatane luki i zaleca jak najszybszą aktualizację (php.net). Ryzyko starej wersji PHP zwiększają też stare wersje frameworka i bibliotek, które również nie dostają poprawek. Dla firmy to konkretne scenariusze: wyciek danych klientów, przejęcie sklepu, zaszyfrowanie bazy przez ransomware. Każdy kosztuje więcej niż zaplanowana migracja.

Hosting i rosnące koszty utrzymania

Hostingi każą dopłacać za stare wersje PHP i zastrzegają sobie prawo do ich wyłączenia.

Przykład: home.pl pobiera za usługę „Wsparcie obsługi starszych wersji PHP” 199 zł netto rocznie (home.pl). Według regulaminu samo utrzymywanie niewspieranej wersji jest równoznaczne z zamówieniem usługi, a home.pl może wymusić zmianę wersji PHP, jeśli stara zagraża infrastrukturze, po bezskutecznym wezwaniu klienta. Za skutki luk odpowiada klient jako administrator danych osobowych (regulamin home.pl, § 2 ust. 5–7).

Same 199 zł to niewiele. Gorzej, gdy po wymuszonej zmianie wersji aplikacja przestanie działać i trzeba migrować awaryjnie, czyli najdrożej.

RODO i odpowiedzialność firmy

Stara wersja PHP sama w sobie nie jest naruszeniem RODO, ale nieaktualne oprogramowanie utrudnia wykazanie, że firma odpowiednio chroni dane. Przy wycieku przez znaną, niezałataną lukę trudno będzie się bronić.

Art. 32 RODO wymaga, by zabezpieczenia uwzględniały „stan wiedzy technicznej” i były regularnie testowane (RODO, EUR-Lex). Analogią jest sprawa opisana przez UODO w 2023 r. (system operacyjny bez wsparcia i nieaktualna baza wirusów, nie PHP). Urząd uznał, że korzystanie z systemów przetwarzających dane osobowe po zakończeniu wsparcia producenta „w sposób istotny obniża ich poziom bezpieczeństwa”. Kara wyniosła 30 tys. zł, m.in. za nieskuteczne i nietestowane zabezpieczenia (UODO).

Koszt zwłoki: im później, tym drożej

Każdy rok zwłoki podnosi koszt migracji: rośnie przepaść między kodem a aktualnym PHP i maleje liczba ludzi do pracy ze starym kodem.

1. Dług technologiczny rośnie jak odsetki. Przeskok o jedną wersję to zwykle kilka poprawek, z 7.4 to kilka wersji naraz, a z PHP 5 bywa osobnym projektem.
2. Coraz trudniej o programistów. Wiedza o starym systemie często siedzi w głowie jednej osoby (pisałem o tym w tekście Co się stanie, jeśli jutro odejdzie jedyny programista?). Jeśli to już się stało, pomagam w przejęciu i ratowaniu starej aplikacji.
3. Blokada integracji, także z AI. Laravel 13 wymaga co najmniej PHP 8.3, a to w nim pojawił się oficjalny Laravel AI SDK (Laravel).

Aktualizacja czy przepisanie od nowa?

Zwykle lepiej zaktualizować istniejącą aplikację niż pisać ją od zera. Przepisanie ma sens, gdy aktualizacja kosztowałaby więcej niż nowy system albo firma potrzebuje zupełnie innego produktu.

Pełne przepisanie naraz (tzw. big bang rewrite) oznacza miesiące utrzymywania dwóch systemów, a nowy musi odtworzyć niespisane reguły biznesowe. Braki wychodzą zwykle dopiero po starcie.

Przy decyzji „przepisać czy aktualizować” patrzę na cztery kryteria:

• Czy aplikacja odpowiada dzisiejszym potrzebom firmy? Jeśli model biznesowy się zmienił, rozważ nowy system.
• Czy kod da się zrozumieć i uruchomić poza produkcją? Jeśli nie, to argument za głębszą przebudową.
• Na czym jest zbudowana? Laravel, Symfony i WordPress mają udokumentowane ścieżki aktualizacji.
• Ile kosztuje przestój? Im droższa godzina niedziałania, tym bardziej opłaca się podejście stopniowe.

Często najlepsza jest droga pośrednia: najpierw aktualizacja PHP, która zamyka ryzyko bezpieczeństwa, potem modernizacja starego oprogramowania moduł po module. Taką ocenę robię w ramach audytu IT, a przy większych systemach przydaje się zewnętrzny CTO, który poprowadzi modernizację.

Jak wygląda migracja PHP krok po kroku (bez żargonu)

Migracja PHP do wersji 8 to audyt, testy, aktualizacja kodu, wdrożenie z planem wycofania i monitoring. Nie musisz znać szczegółów, ale warto wiedzieć, o co pytać.

Audyt i inwentaryzacja (wersje, biblioteki, serwery)

Pierwszy krok to sprawdzenie, co dokładnie masz: wersję PHP, biblioteki, serwery i powiązane systemy.

Audyt kodu przed migracją odpowiada na pytania:

• Jaka wersja PHP i frameworka działa na produkcji?
• Które zależności Composer (zewnętrzne biblioteki, z których korzysta aplikacja) działają na PHP 8.4/8.5, a które porzucili autorzy?
• Jakie są integracje: płatności, kurierzy, ERP, API partnerów?
• Czy kod jest w repozytorium i kto ma dostęp do serwerów i haseł?

Dobry audyt kończy się listą ryzyk i planem prac (zob. Jak przeprowadzić audyt kodu projektu na Laravel).

Siatka bezpieczeństwa: testy i środowisko testowe

Zanim ktokolwiek zmieni kod, potrzebujesz sposobu, by sprawdzić, czy po zmianie wszystko działa jak wcześniej: testów automatycznych i środowiska testowego (staging), czyli kopii aplikacji do bezpiecznych prób.

W starych aplikacjach testów zwykle brakuje. Zaczynam wtedy od testów charakteryzujących: zapisują, jak aplikacja zachowuje się dziś (np. jaką fakturę generuje dla zamówienia). Takie testy przed migracją pokazują potem, czy coś się zmieniło. Od Ciebie przyda się lista najważniejszych procesów biznesowych, np. „klient zamawia, płaci i dostaje fakturę”.

Aktualizacja kodu

Programista dostosowuje kod i biblioteki do nowego PHP. Dużą część poprawek robią dziś narzędzia automatyczne i agenci AI, a człowiek je weryfikuje.

Aktualizację aplikacji firmowej prowadzę małymi krokami. Przy aktualizacji PHP 7.4 do 8 zwykle najpierw podnosi się biblioteki i framework do wersji działających na obu wersjach PHP, a dopiero potem samo PHP.

Dla zespołu technicznego

• PHPCompatibility (standard dla PHP_CodeSniffer) – wskazuje kod niezgodny z docelową wersją PHP.
• Rector – automatyczne refaktoryzacje i podnoszenie składni do kolejnych wersji PHP. Jeden zestaw reguł = jeden commit.
• PHPStan – analiza statyczna; podnoś poziom stopniowo, z baseline dla starego kodu.
• Przewodniki migracji na php.net: od PHP 7.4 do 8.0 aż do PHP 8.5.
• Kolejność: testy charakteryzujące → composer why-not php 8.4 → zależności → Rector → PHPStan → staging.

Wdrożenie z planem wycofania i monitoring

Nową wersję wdraża się po testach na stagingu i zawsze z planem wycofania (rollback), czyli sposobem na szybki powrót do poprzedniej wersji.

W praktyce: wdrożenie przy najmniejszym ruchu, świeża kopia bazy i ktoś, kto przez pierwsze dni pilnuje logów błędów, bo wtedy wychodzą rzadkie ścieżki, np. raport miesięczny. Potem wystarczą małe, regularne aktualizacje w ramach aktualizacji i rozwoju istniejącej aplikacji.

Z PHP 7.4 vs z PHP 5: czym się różnią

Migracja z PHP 7.4 to zwykle przewidywalna aktualizacja, a aktualizacja PHP 5 do 8 bywa częściową przebudową. Decyduje liczba wersji do przeskoczenia i skala zmian w języku.

Aplikacja na PHP 7.4 ma zazwyczaj framework ze ścieżką aktualizacji. Kod z czasów PHP 5 częściej powstawał bez frameworka i testów, a bywa, że korzysta z elementów usuniętych z języka. Przykład: rozszerzenie mysql, przez które wiele starych aplikacji łączyło się z bazą, zniknęło już w PHP 7.0 (php.net).

W moich projektach (aplikacje webowe, głównie Symfony, czasem Laravel) proces wyglądał tak: AI przygotowuje plan zmian, CTO go weryfikuje i poprawia, a potem AI iteracyjnie wprowadza poprawki.

Laravel, Symfony, WordPress: na co uważać

Aktualizacja PHP zwykle wymusza też aktualizację frameworka, bo jego starsze wersje nie działają na nowym PHP albo nie dostają poprawek.

• Laravel: Laravel 13 wymaga PHP 8.3–8.5 (poprawki bezpieczeństwa do 17.03.2028), Laravel 12 działa na PHP 8.2–8.5 (do 24.02.2027), a Laravel 11 stracił wsparcie 12.03.2026 (Laravel).
• Symfony: Symfony 8 wymaga PHP 8.4+, a wersja z długim wsparciem 7.4 wymaga PHP 8.2+ (Symfony).
• WordPress: wymaga co najmniej PHP 7.4, a wersje 7.0 i 7.1 są zgodne z PHP do 8.5 (WordPress). Problemem bywają wtyczki i motywy, zwłaszcza porzucone lub mocno przerobione.

Jak AI (Claude Code, Codex, Cursor) skraca migrację i gdzie nie wystarcza

AI skraca migrację tam, gdzie praca jest żmudna i powtarzalna: przy czytaniu dużego kodu, setkach podobnych poprawek i pisaniu testów. Nie zastępuje decyzji, przeglądu zmian ani odpowiedzialności doświadczonego programisty.

Agent AI czyta kod, uruchamia polecenia i proponuje zmiany, które programista akceptuje lub odrzuca. Najpopularniejsze narzędzia to Claude Code, Codex od OpenAI i Cursor. Przy migracji kodu z pomocą AI zyskuję najwięcej w trzech miejscach:

1. Zrozumienie dużego, nieznanego kodu. Agent szybko tworzy mapę aplikacji, co skraca audyt.
2. Mechaniczne poprawki na dużą skalę. Setki podobnych zmian AI razem z Rectorem robi szybciej i bez zmęczenia.
3. Testy charakteryzujące. AI sprawnie pisze testy obecnego zachowania aplikacji.

W moich migracjach pracowałem głównie z Claude Code i Codexem. AI dostawało konkretne informacje, co ma zrobić, i najpierw przygotowywało plan zmian: co zmienić, co usunąć, co dodać. Plan przechodził ręczną weryfikację i poprawki przez CTO, a dopiero potem AI iteracyjnie wprowadzało poprawki w kodzie.

Granice AI dobrze pokazuje opis migracji 24-letniego serwisu DVHARDWARE do PHP 8.5 z pomocą Codexa (DVHARDWARE). Autor chwali tempo, ale opisuje też, jak agent zamiast naprawić przyczynę błędu w liczniku użytkowników online dodał do wyniku „+1”, żeby liczba na ekranie się zgadzała. Przyznaje też, że przy takiej ilości kodu łatwo zatwierdzać zmiany bez dokładnego przeglądu.

Główne pułapki:

• Łatanie objawów zamiast przyczyn. Test przechodzi, problem zostaje.
• Nadmiar kodu. AI chętniej dopisuje, niż upraszcza.
• Zmęczenie przy przeglądzie dużych zmian. Dlatego dzielę pracę na małe kroki.
• Brak kontekstu biznesowego. AI nie zna wyjątków ważnych dla Twoich klientów.

AI to narzędzie doświadczonego programisty, nie samodzielny wykonawca. Więcej: 10 zagrożeń vibe codingu, o których CEO powinien wiedzieć, Czym się różni architekt programowania od vibe codera oraz, dla zespołów technicznych, Najlepsze praktyki vibe coding dla programistów.

Ile kosztuje i ile trwa migracja PHP

Ile kosztuje i jak długo trwa migracja PHP, zależy od punktu startowego, wielkości i jakości kodu, stanu testów oraz liczby porzuconych bibliotek. Uczciwą wycenę da się podać dopiero po audycie.

Najważniejsze czynniki:

• Punkt startowy: z PHP 8.1 to inny projekt niż z 7.4 czy PHP 5.
• Wielkość i jakość kodu: liczy się nie tylko ilość, ale i porządek.
• Testy: jeśli ich nie ma, trzeba je najpierw napisać.
• Biblioteki i framework: porzucone pakiety trzeba zastąpić, framework podnieść o kilka wersji.
• Integracje i infrastruktura: każda zewnętrzna usługa to dodatkowe scenariusze do sprawdzenia.

Widełki z mojej praktyki: migracje aplikacji webowych z pomocą AI trwały od 2–3 dni (mniejsze aplikacje) do około tygodnia (większe). Przy większych projektach koszt wynosił 5 000–10 000 zł. Realny koszt zależy od czynników opisanych wyżej, a dokładną wycenę daje audyt.

AI skraca głównie poprawki w kodzie i pisanie testów, ale nie decyzje ani testy akceptacyjne. Porównuj koszt migracji nie z zerem, ale z migracją awaryjną po incydencie. Zobacz też: wycena prac programistycznych i Projekt IT przekracza budżet.

Od czego zacząć? Audyt

Zacznij od audytu kodu przed migracją. Pokaże, na czym stoisz, co blokuje aktualizację i ile może kosztować.

Co możesz zrobić jeszcze w tym tygodniu:

1. Zapytaj zespół lub dostawcę, na jakiej wersji PHP działa aplikacja.
2. Sprawdź na fakturach hostingu, czy nie płacisz za wsparcie starej wersji PHP.

Jeśli odpowiedzi Cię zaniepokoją, zamów audyt kodu przed migracją. Dostaniesz ryzyka i priorytety prac, czyli punkt wyjścia do planu migracji. Wolisz najpierw porozmawiać? Napisz do mnie.

FAQ

Czy muszę aktualizować PHP, skoro moja aplikacja działa?

Tak, jeśli działa na wersji bez wsparcia. „Działa” oznacza tylko, że nikt jeszcze nie wykorzystał jej luk. PHP 7.4 nie dostaje poprawek bezpieczeństwa od listopada 2022 r., hostingi doliczają opłaty za stare wersje, a każdy rok zwłoki podnosi koszt migracji. Lepiej zaplanować ją spokojnie.

Co grozi firmie, jeśli aplikacja działa na PHP 7.4 albo PHP 5?

Przede wszystkim włamanie przez znane, niezałatane luki: wyciek danych klientów, przejęcie sklepu lub zaszyfrowanie bazy. Do tego dopłaty za hosting, ryzyko wymuszonej zmiany wersji przez hostingodawcę, trudność w znalezieniu programistów i blokada nowych integracji. Przy danych osobowych musisz też wykazać, że stosujesz odpowiednie zabezpieczenia.

Do kiedy jest wspierane PHP 7.4 / 8.2 i jaką wersję wybrać w 2026 roku?

PHP 7.4 straciło wsparcie 28 listopada 2022 r., a PHP 8.2 traci poprawki bezpieczeństwa 31 grudnia 2026 r. W 2026 r. wybierz PHP 8.4, wspierane do końca 2028 r., albo PHP 8.5, wspierane do końca 2029 r. Migracja na 8.2 nie ma już sensu. Źródło: harmonogram na php.net.

Ile kosztuje aktualizacja PHP w aplikacji firmowej?

W moich większych projektach migracja z pomocą AI kosztowała 5 000–10 000 zł. To widełki z praktyki, a nie cennik. Realny koszt zależy od punktu startowego, wielkości i jakości kodu, stanu testów, porzuconych bibliotek i integracji. Z PHP 5 bywa to częściowa przebudowa. Dokładną wycenę podaję po audycie kodu.

Jak długo trwa migracja z PHP 7.4 do PHP 8?

W moich ostatnich migracjach z pomocą AI trwało to od 2–3 dni przy mniejszych aplikacjach do około tygodnia przy większych. Czas zależy od wielkości aplikacji, stanu testów, bibliotek i integracji, więc duży system bez testów może wymagać więcej. Realny harmonogram ustalam po audycie kodu.

Czy aktualizacja PHP może zepsuć moją aplikację albo sklep?

Tak, jeśli robi się ją bez przygotowania, np. przełączając wersję PHP w panelu hostingu na działającej stronie. Dlatego migrację przeprowadza się najpierw na środowisku testowym, z testami najważniejszych procesów i gotowym planem wycofania. Wtedy ryzyko jest kontrolowane, a błędy wychodzą przed wdrożeniem, nie u klientów.

Czy hosting może wyłączyć starą wersję PHP albo kazać za nią płacić?

Tak. Na przykład home.pl pobiera 199 zł netto rocznie za wsparcie starszych wersji PHP, a jego regulamin pozwala wymusić zmianę wersji, jeśli stara zagraża infrastrukturze, po bezskutecznym wezwaniu klienta. Niezaktualizowana aplikacja może wtedy przestać działać z dnia na dzień. Sprawdź warunki swojego hostingu.

Czy stara wersja PHP to problem z RODO?

Może być. Art. 32 RODO wymaga zabezpieczeń uwzględniających stan wiedzy technicznej i regularnie testowanych. UODO, w sprawie dotyczącej systemu operacyjnego bez wsparcia, uznał, że używanie oprogramowania po zakończeniu wsparcia producenta istotnie obniża bezpieczeństwo. Nie chodziło o PHP, ale logika jest ta sama.

Czy AI (np. Claude Code albo Codex) może samo zaktualizować moją aplikację?

Nie samo. AI wyraźnie przyspiesza mechaniczną część pracy: analizę kodu, powtarzalne poprawki i pisanie testów. Potrafi jednak łatać objawy zamiast przyczyn i nie zna kontekstu biznesowego. Potrzebny jest doświadczony programista, który ustala plan, przegląda zmiany małymi porcjami i odpowiada za wynik, oraz testy potwierdzające, że wszystko działa.

Lepiej zaktualizować starą aplikację czy napisać ją od nowa?

Zwykle lepiej zaktualizować. Przepisanie od zera trwa długo, wymaga utrzymywania dwóch systemów naraz i grozi utratą niespisanych reguł biznesowych. Nowy system ma sens, gdy aplikacja nie odpowiada już potrzebom firmy albo aktualizacja kosztowałaby więcej. Często najlepsza jest droga pośrednia: aktualizacja PHP, potem stopniowa modernizacja.

Zobacz wersję Markdown →