Kiedy przepisać system PHP do Laravel?

System PHP warto przenieść do Laravel wtedy, gdy stary kod – pisany w natywnym PHP albo w frameworku, który nie jest już rozwijany – blokuje aktualizację PHP, integracje i nowe funkcje, a jednocześnie logika biznesowa jest na tyle cenna, że nie chcesz jej wymyślać od nowa. Najbezpieczniej robi się to nie jednym „wielkim przepisaniem”, tylko ścieżką: mapujesz elementy starego systemu na odpowiedniki w Laravel, stawiasz Laravel obok starej aplikacji na tej samej bazie danych i przenosisz moduły po kolei, kierując do nowego kodu coraz więcej adresów. Poniżej opisujemy tę ścieżkę technicznie – od mapy elementów po kolejność modułów.

Nie każdy system trzeba przepisywać

Stary system PHP nie zawsze wymaga migracji do nowego frameworka. Czasem wystarczy aktualizacja PHP, porządek we wdrożeniach i refaktoryzacja najbardziej ryzykownych miejsc. Ogólną macierz decyzji – refaktoryzacja, modularyzacja, nowa warstwa API czy przepisanie – opisujemy we wpisie Modernizacja backendu – kiedy przepisać system. Ten artykuł zakłada, że decyzja o przejściu na Laravel już zapadła, i pokazuje, jak ją przeprowadzić.

Sygnały, że czas na Laravel

• system działa na wersji PHP bez wsparcia (np. 7.x albo 8.1, która nie dostaje poprawek bezpieczeństwa od końca 2025 roku), a aktualizacja psuje kod,
• framework, na którym powstał, nie jest już rozwijany (np. pierwsze wersje Zend Framework, Yii 1, CodeIgniter 2, symfony 1) albo system nie ma frameworka wcale,
• każda nowa integracja API wymaga pisania wszystkiego od podstaw – bez kolejek, walidacji i obsługi błędów,
• w kodzie nie ma testów, a zmiana w jednym pliku psuje funkcję w innym miejscu.

Przed startem migracji warto przeprowadzić przegląd – co sprawdzić, opisuje checklista audytu przed modernizacją.

Mapa elementów: co w starym systemie odpowiada czemu w Laravel

Pierwszy krok techniczny to inwentaryzacja. Dla każdego elementu starej aplikacji wskazujemy odpowiednik:

• pliki `.php` wywoływane bezpośrednio (`zamowienia.php?id=5`) → trasy (routes) i kontrolery,
• `include`/`require` z funkcjami pomocniczymi i zmiennymi globalnymi → klasy usług wstrzykiwane przez kontener zależności,
• zapytania SQL sklejane w kodzie (często jeszcze w stylu starych funkcji `mysql_*`, które zniknęły w PHP 7) → Query Builder lub modele Eloquent z parametrami, co przy okazji usuwa ryzyko SQL injection,
• szablony mieszające PHP i HTML → widoki Blade albo komponenty frontendu,
• ręczna walidacja `if (empty($_POST[...]))` → klasy Form Request z regułami walidacji,
• skrypty w cronie → zadania Artisan i harmonogram (scheduler),
• długie operacje w żądaniu HTTP (wysyłka maili, eksporty, synchronizacje) → joby w kolejce,
• konfiguracja w plikach `config.php` z hasłami w kodzie → pliki konfiguracyjne i zmienne środowiskowe `.env`,
• własny mechanizm logowania użytkowników → uwierzytelnianie Laravel, z zachowaniem kont i haseł (o tym niżej).

Taka mapa pokazuje skalę pracy i od razu wskazuje miejsca szczególnego ryzyka: zmienne globalne, logikę w szablonach i zapytania pisane ręcznie w wielu miejscach.

Strangler: Laravel obok starej aplikacji

Wzorzec „strangler” polega na tym, że nowa aplikacja stopniowo przejmuje ruch od starej. W praktyce PHP wygląda to tak:

1. Laravel jest instalowany obok starego kodu, na tym samym serwerze lub w osobnym kontenerze.
2. Serwer WWW (np. nginx) kieruje ruch – adresy przeniesionych modułów trafiają do Laravel, wszystko inne do starej aplikacji.
3. Po przeniesieniu modułu kolejne ścieżki przełącza się na Laravel, a stary kod tego modułu jest usuwany, gdy nowy działa stabilnie.
4. Stare adresy (np. `produkt.php?id=12`) dostają przekierowania na nowe trasy, żeby nie zgubić linków i pozycji w wyszukiwarce.

Użytkownik przez cały czas korzysta z jednego systemu i nie musi wiedzieć, która część działa już na nowym kodzie.

Wspólna baza danych: zalety i pułapki

Na czas migracji obie aplikacje zwykle pracują na tej samej bazie. To upraszcza przejście, bo nie trzeba synchronizować danych, ale wymaga dyscypliny:

• modele Eloquent na istniejących tabelach – w modelu można wskazać nazwę tabeli, klucz główny i wyłączyć automatyczne kolumny dat, jeśli stary schemat ich nie ma,
• zmiany schematu tylko przez migracje – i tylko takie, które nie psują starej aplikacji (dodawanie kolumn i tabel tak, usuwanie i zmiana nazw dopiero po wyłączeniu starego kodu),
• kodowanie znaków i strefy czasowe – stare bazy często mają mieszane kodowania lub daty zapisane w lokalnym czasie; trzeba to wyjaśnić, zanim nowy kod zacznie zapisywać dane,
• logika w bazie – triggery i procedury składowane muszą zostać spisane, bo Laravel ich „nie widzi”.

Sesje i logowanie w dwóch aplikacjach

Najtrudniejszy element okresu przejściowego to wspólne logowanie. Użytkownik zalogowany w starym systemie nie powinien logować się drugi raz w module Laravel. Typowe rozwiązania to wspólny magazyn sesji (np. Redis) z mechanizmem odczytu sesji starej aplikacji albo przeniesienie logowania do Laravel jako jednego z pierwszych kroków i przekazywanie tożsamości do starego kodu.

Jeśli hasła w starym systemie są przechowywane słabym algorytmem (np. MD5), nie trzeba resetować wszystkich kont. Przy pierwszym udanym logowaniu hasło weryfikuje się starym sposobem i od razu zapisuje ponownie bezpiecznym hashem.

Kolejność modułów

Nie ma jednej kolejności dla wszystkich systemów, ale sprawdza się zasada: najpierw to, co odblokowuje dalszą pracę i niesie mało ryzyka, potem rdzeń.

1. Fundamenty – logowanie, uprawnienia, konfiguracja, logi błędów i monitoring.
2. Nowe integracje API – budowane od razu w Laravel, z kolejkami; nie dopisujesz nowego kodu do starego systemu.
3. Moduły tylko do odczytu – raporty, listy, eksporty; łatwe do porównania ze starą wersją.
4. Panel administracyjny i słowniki – mniej użytkowników, szybka informacja zwrotna.
5. Procesy krytyczne – zamówienia, rozliczenia, dokumenty – na końcu, gdy zespół zna już dobrze dane i reguły.

Przy każdym module warto porównywać wyniki starej i nowej wersji na tych samych danych, zanim ruch zostanie przełączony. Szerzej o organizacji takiej modernizacji bez przestojów piszemy w artykule Modernizacja legacy PHP bez zatrzymywania firmy.

Typowe błędy przy migracji PHP do Laravel

• Przepisywanie 1:1 – przenoszenie złej struktury do nowego frameworka zamiast uporządkowania logiki.
• Zmiana schematu bazy na starcie – stara aplikacja przestaje działać, zanim nowa jest gotowa.
• Brak testów porównawczych – nie wiadomo, czy nowy moduł liczy tak samo jak stary.
• Ominięte zadania cron – po wyłączeniu starego serwera okazuje się, że nocny skrypt robił coś ważnego.
• Ostatni moduł, który „zostaje na zawsze” – bez planu wyłączenia starego kodu firma utrzymuje dwa systemy.

Następny krok

Zrób listę plików wejściowych starej aplikacji, zadań w cronie i integracji – to pierwsza wersja mapy elementów i podstawa do oszacowania migracji. Jeśli chcesz przejść ścieżkę do Laravel etapami, bez zatrzymywania pracy firmy, zobacz, jak prowadzimy modernizację backendu, i umów rozmowę – zaczniemy od przeglądu kodu i bazy.