Modernizacja legacy PHP bez zatrzymywania firmy – praktyczny plan

Stary system PHP da się zmodernizować bez zatrzymywania firmy, jeśli najpierw zabezpieczy się to, co działa (kopie, środowisko testowe, powtarzalne wdrożenia), potem podniesie wersję PHP, a dopiero na końcu zacznie przenosić kolejne moduły do Laravel, uruchomionego obok starej aplikacji. Kluczowe jest to, że przez cały czas firma korzysta z jednego, działającego systemu, a każda zmiana jest na tyle mała, że w razie problemu można ją wycofać w kilka minut. Poniżej opisujemy taki plan krok po kroku – od pierwszego tygodnia po wyłączenie ostatniego starego skryptu.

Skąd bierze się strach przed modernizacją

W większości firm, z którymi rozmawiamy, stary system PHP nie jest „zły”. Obsługuje zamówienia, magazyn, rozliczenia z klientami czy panel dla handlowców i robi to od lat. Problem polega na tym, że:

• każda zmiana trwa długo i nikt nie wie, co przy okazji się zepsuje,
• wiedza o systemie jest w głowie jednej osoby – często byłego pracownika albo zewnętrznego programisty,
• serwer działa na PHP 7.x lub 8.0/8.1, czyli wersjach, które nie dostają już poprawek bezpieczeństwa (PHP 8.1 przestało je otrzymywać 31 grudnia 2025 r.),
• nie ma testów, a wdrożenie polega na wgraniu plików przez FTP.

W takiej sytuacji pomysł „napiszmy wszystko od nowa” brzmi kusząco, ale oznacza miesiące równoległej pracy i jeden ryzykowny dzień przełączenia. Znacznie bezpieczniejsza jest modernizacja etapami.

Etap 0: zabezpieczenie tego, co jest

Zanim ktokolwiek zmieni linijkę kodu, trzeba zadbać o podstawy. To najtańszy etap i ten, który najczęściej się pomija.

• Kod w repozytorium Git. Jeśli dziś jedyną „wersją” jest katalog na serwerze, pierwszym krokiem jest jego skopiowanie do repozytorium i opisanie różnic między tym, co jest na produkcji, a tym, co ktoś ma lokalnie.
• Kopie bazy danych z testem odtworzenia. Kopia, której nigdy nie przywrócono, jest tylko nadzieją.
• Środowisko testowe. Kopia systemu z zanonimizowanymi danymi, na której można sprawdzać zmiany bez ryzyka dla klientów.
• Powtarzalne wdrożenie. Nawet prosty skrypt, który wgrywa wersję z repozytorium i pozwala wrócić do poprzedniej, jest ogromnym postępem w porównaniu z ręcznym kopiowaniem plików.

Ten etap często wykonuje się w ramach audytu systemu przed modernizacją, który przy okazji pokazuje skalę problemu.

Etap 1: mapa systemu

Następnie powstaje mapa: jakie moduły istnieją, kto z nich korzysta i jak często, jakie tabele należą do jakiego obszaru, jakie zadania cron działają w tle, jakie pliki są importowane i eksportowane, z jakimi systemami zewnętrznymi (ERP, kurierzy, płatności, hurtownie) system się łączy. Logi serwera WWW pomagają odróżnić moduły używane codziennie od tych, których nikt nie otworzył od lat. Te drugie często można po prostu wyłączyć.

Etap 2: siatka bezpieczeństwa

Stary kod rzadko ma testy, więc zaczyna się od testów charakteryzujących. Nie sprawdzają one, czy system działa „dobrze”, tylko utrwalają, jak działa dziś: jaka cena wychodzi dla konkretnego klienta i produktu, jak wygląda eksport faktury, jakie są dozwolone zmiany statusu zamówienia. Jeśli po modernizacji wynik się zmieni, test to wychwyci. Do tego dochodzi analiza statyczna (PHPStan z tzw. baseline), która pilnuje, żeby nowy kod nie powielał starych błędów.

Etap 3: aktualizacja PHP

Podniesienie wersji PHP w starej aplikacji to zwykle najszybsza poprawa bezpieczeństwa. Narzędzie Rector automatyzuje dużą część zmian, resztę trzeba poprawić ręcznie i sprawdzić testami z poprzedniego etapu. Po tym kroku stary i nowy kod mogą działać na tym samym serwerze i tej samej wersji PHP (8.3 lub 8.4), co znacznie upraszcza dalsze prace.

Etap 4: Laravel obok starego systemu

Nowa aplikacja w Laravel 12 lub 13 staje obok starej. Serwer WWW albo reverse proxy decyduje, które adresy obsługuje Laravel, a które nadal stary kod. Na początku Laravel nie obsługuje nic – wszystko działa jak dotąd. Żeby użytkownicy nie odczuli „szwu”, obie aplikacje współdzielą:

• logowanie – wspólną sesję albo proste SSO,
• bazę danych – modele Laravel mapuje się na istniejące tabele, a zmiany struktury muszą być zgodne wstecz,
• wygląd – wspólny układ i menu.

Etap 5: przenoszenie modułów

Kolejność ustala się według wartości biznesowej i ryzyka, a nie według struktury katalogów. Na początek dobrze nadają się moduły wyraźnie wydzielone i głównie odczytujące dane: raporty, API dla partnerów, eksport katalogu, panel klienta z historią zamówień. Procesy zapisujące kluczowe dane, jak przyjmowanie zamówień czy rozliczenia, przenosi się później, gdy zespół ma już doświadczenie z równoległym działaniem dwóch aplikacji.

Każdy moduł przechodzi ten sam cykl: budowa w Laravel, testy na środowisku testowym, udostępnienie najpierw pracownikom, potem części klientów, przełączenie adresu, obserwacja, a na końcu usunięcie starego kodu. Jeśli coś pójdzie źle, wystarczy przywrócić poprzednią regułę routingu. O tym, jak bezpiecznie wypuszczać takie zmiany, piszemy w artykule bezpieczne wdrożenia Laravel w firmie.

Etap 6: zadania w tle i porządki w danych

Skrypty cron przechodzą do harmonogramu Laravel, a długie operacje – do kolejek z logowaniem, ponawianiem i alertami. Importy i eksporty stają się idempotentne, czyli ponowne uruchomienie nie tworzy duplikatów. Strukturę bazy porządkuje się dopiero wtedy, gdy stary kod przestaje korzystać z danej tabeli.

Najczęstsze błędy

• Kopiowanie wszystkich dziwactw starego systemu. Każdy przenoszony moduł to okazja, żeby zapytać dział sprzedaży czy magazyn, które reguły są jeszcze potrzebne.
• Brak osoby decyzyjnej po stronie firmy. Gdy stare zachowanie jest niejasne, ktoś musi zdecydować, jak ma być.
• Przełączanie bez monitoringu. Rejestr błędów i podgląd kolejek muszą działać przed przełączeniem pierwszego adresu.
• Przeciąganie okresu przejściowego. Dwie aplikacje równolegle to koszt. Warto mieć cel wyłączenia starego systemu i śledzić, jaka część ruchu obsługiwana jest już przez Laravel.
• Brak komunikacji z użytkownikami. Pracownicy powinni wiedzieć, który moduł się zmienia i gdzie zgłaszać uwagi.

Czy zawsze warto migrować etapami?

Nie zawsze. Jeśli system jest niewielki, a model biznesowy firmy zmienił się tak, że stare procesy i tak nie mają sensu, napisanie go od nowa może być rozsądniejsze. Kryteria takiej decyzji omawiamy w tekście kiedy przepisać system PHP do Laravel. W większości firm B2B, gdzie system obsługuje codzienną sprzedaż, podejście etapowe jest jednak bezpieczniejsze.

Checklista na start

• dostęp do kodu i informacja, czy wersja na serwerze zgadza się z repozytorium,
• aktualna wersja PHP, systemu operacyjnego i bazy danych,
• lista integracji i zadań cron,
• lista modułów z informacją, kto z nich korzysta,
• osoba po stronie firmy odpowiedzialna za decyzje,
• jeden moduł, od którego chcecie zacząć.

Następny krok

Najlepiej zacząć od krótkiej analizy technicznej: przeglądu kodu, bazy, serwera i integracji, która kończy się planem etapów i listą ryzyk, a nie od razu wyceną nowego systemu. Tak prowadzimy projekty modernizacji backendu PHP i Laravel. Jeśli chcesz, żebyśmy spojrzeli na Twój system, napisz do nas – na początek wystarczy dostęp do repozytorium i lista systemów, z którymi się łączy.