Migracja starszych witryn PHP bez zakłócania operacji biznesowych

W DigiForge widzieliśmy zbyt wiele projektów migracji legacy PHP, które poszły nie tak — nie dlatego, że technologia była trudna, ale dlatego, że biznes działał podczas przenosin. Samo słowo „migracja” pochodzi z łaciny i oznacza przenoszenie się z jednego miejsca do drugiego, a w informatyce konkretnie „rozpoczęcie używania nowego systemu komputerowego lub przenoszenie danych z jednego typu systemu do innego” [1]. Brzmi to prosto, ale gdy migrujesz monolit PHP obsługujący zamówienia, sesje użytkowników i integracje płatności, prawdziwym wyzwaniem jest zapewnienie, że Twoi klienci niczego nie zauważą.

Oceń, zanim dotkniesz linii kodu

Zanim w ogóle pomyślimy o pisaniu nowych routerów czy instalowaniu nowoczesnego frameworka, przeprowadzamy audyt istniejącej aplikacji — nie tylko jej kodu, ale także zachowania w czasie rzeczywistym. Zacznij od dokładnej inwentaryzacji wszystkich punktów wejścia: każdej ścieżki, każdego zadania cron, każdego zadania w kolejce. Legacy aplikacje PHP często mają ukryte punkty końcowe — może to być cron.php uruchamiający płace w każdą niedzielę lub niestandardowy endpoint API używany przez zewnętrzną firmę kurierską. Jeśli przegapisz jeden, migracja coś zepsuje.

Podczas audytu udokumentuj również przepływ danych: jak stara aplikacja łączy się z bazą danych? Czy są procedury składowane? Czy istnieje współdzielony system plików dla przesłanych obrazów lub plików sesji? Wiele legacy aplikacji PHP polega na sesjach plikowych, które nie skalują się poziomo. To czerwona flaga, którą rozwiązujemy wcześnie, często migrując sesje do Redis lub bazy danych.

Wybierz strategię migracji dopasowaną do swojego apetytu na ryzyko

W DigiForze zazwyczaj rekomendujemy jedną z trzech strategii, w zależności od tego, ile ryzyka firma jest w stanie zaakceptować.

Przepisanie metodą Big Bang

To najbardziej radykalne podejście: budujesz nowy system od zera, a następnie przełączasz się na niego w jednym momencie. Jest to również największe ryzyko. Widzieliśmy, że sprawdza się tylko wtedy, gdy starsza aplikacja jest niewielka (np. kilkadziesiąt stron) lub gdy firma może pozwolić sobie na zaplanowane okno konserwacyjne. W przypadku systemów z transakcjami czasu rzeczywistego lub obsługą klientów 24/7 lepiej unikać tego podejścia.

Wzorzec Strangler Fig

Nazwany na cześć tropikalnej rośliny, która powoli oplata swojego żywiciela, ten wzorzec pozwala stopniowo zastępować fragmenty starszej aplikacji. Kierujesz określone adresy URL lub punkty końcowe API do nowego kodu, podczas gdy reszta nadal działa na starym PHP. Load balancer lub odwrotne proxy (np. Nginx lub HAProxy) może kierować ruchem na podstawie ścieżki żądania. Każdy zastąpiony element zmniejsza ryzyko, ponieważ zmieniasz tylko mały obszar naraz. Używamy tego wzorca w prawie każdej dużej migracji.

Flagi funkcji wszędzie

Nawet przy wzorcu figowca dusiciela, flagi funkcji dają wyłącznik awaryjny. Jeśli nowy punkt końcowy kasy zwraca błędy, przełączasz flagę i ruch wraca do starego kodu – wszystko bez wdrożenia. Narzędzia takie jak LaunchDarkly lub prosty przełącznik oparty na bazie danych sprawdzają się dobrze. Wszystko kodujemy za flagą, nawet połączenie z bazą danych. Dzięki temu możemy przetestować nowe zapytanie w produkcji z kilkoma użytkownikami, zanim udostępnimy je wszystkim.

Wykonaj migrację z zerowym przestojem

Zerowy przestój nie oznacza zerowego ryzyka – oznacza, że użytkownik nigdy nie widzi strony błędu. Kluczem jest podwójny zapis: podczas przechodzenia na nowy schemat bazy danych lub inny backend pamięci masowej, zapisuj dane jednocześnie do starego i nowego systemu. Zacznij od zapisu do obu, odczytując ze starego. Gdy nowy system nadrobi zaległości i zweryfikujesz integralność danych, przełącz odczyty na nowy system. Na koniec przestań zapisywać do starego systemu. Działa to w przypadku baz danych, kolejek, przechowywania plików, a nawet integracji API.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

W fazie podwójnego zapisu co kilka minut uruchamiasz skrypty uzgadniające, które porównują oba magazyny. Wszelkie rozbieżności są szybko wychwytywane. Gdy nowy system jest zgodny przez pełny cykl biznesowy (zwykle 48 godzin), przełączasz odczyty. Przez następną godzinę uważnie monitoruj logi błędów – jeśli coś wygląda nieprawidłowo, wracasz do poprzedniej konfiguracji.

Obsługa stanu sesji

Starsze aplikacje PHP często używają $_SESSION przechowywanej w plikach. Nowa aplikacja Laravel lub Symfony prawdopodobnie oczekuje sesji w bazie danych lub Redis. Aby utrzymać zalogowanych użytkowników podczas migracji, implementujemy most sesyjny: stara aplikacja zapisuje sesje zarówno do plików, jak i do współdzielonego Redis; nowa aplikacja odczytuje z Redis. Po zakończeniu migracji wyłączasz zapis do plików i usuwasz stary handler sesji.

Walidacja po migracji i planowanie wycofania

Nawet przy starannym planowaniu coś pójdzie nie tak. To nie pesymizm – to inżynieryjny realizm. Zanim przełączysz ostatni przełącznik, napisz plan wycofania, który obejmuje przywrócenie rekordów DNS, cofnięcie zmian w schemacie bazy danych i uruchomienie starej aplikacji z migawki. Przećwicz wycofanie na środowisku stagingowym przynajmniej raz.

W DigiForge zawsze utrzymujemy stare środowisko produkcyjne przez co najmniej dwa tygodnie po dużej migracji. Koszt kilku dodatkowych serwerów jest niczym w porównaniu z kosztem nieudanego wycofania, które trwa godzinami.

Walidacja wykracza poza sprawdzanie, czy strony się ładują. Przeprowadzamy zautomatyzowane testy transakcji biznesowych: złóż zamówienie, zaktualizuj profil, przetwórz zwrot. Porównaj wyniki krytycznych punktów końcowych API między starym a nowym systemem. Jeśli używasz narzędzia monitorującego, takiego jak New Relic czy Sentry, skonfiguruj niestandardowe alerty dla wszelkich błędów 5xx lub wolnych zapytań. Na koniec zaangażuj zespół biznesowy – niech uruchomią swoje codzienne przepływy pracy na nowym systemie w środowisku stagingowym przed uruchomieniem produkcyjnym.

Typowe pułapki i jak ich unikamy

• Zakładanie, że stary kod jest poprawny. Starszy PHP często zawiera ciche błędy, które stały się „funkcjami”. Powielać każde zachowanie? Czasami bezpieczniej jest naprawić błąd w nowej wersji, jeśli biznes się zgodzi.
• Zapominanie o cron jobach i zaplanowanych zadaniach. Te stare wywołania curl do niestandardowego skryptu? Potrzebują miejsca w nowym systemie. Migrujemy zadania cron do harmonogramu zadań, takiego jak harmonogram Laravela lub dedykowany worker.
• Zaniedbywanie integracji zewnętrznych. Bramki płatności, API wysyłkowe i webhooki partnerów wysyłają dane w określonych formatach. Testuj punkty końcowe integracji wcześnie – nie chcesz odkryć niezgodności formatu w Czarny Piątek.

Kolejna lekcja, którą wynieśliśmy: nie ufaj starej dokumentacji. Kod jest źródłem prawdy. Zawsze przeprowadzamy dogłębną analizę kodu z deweloperem, który go napisał (jeśli jest dostępny) lub z członkiem zespołu, który utrzymywał go przez lata. Ich mentalny model osobliwości aplikacji jest bezcenny.

Podsumowanie

Migracja starszej witryny PHP jest jak przeprowadzanie operacji na otwartym sercu u pacjenta, który biegnie maraton. Ryzyko jest realne, ale nagroda — nowoczesna wydajność, bezpieczeństwo i produktywność deweloperów — jest ogromna. W DigiForge przeprowadziliśmy dziesiątki firm przez ten proces. Kluczem jest poruszanie się małymi, odwracalnymi krokami, zawsze utrzymywanie starego systemu w działaniu i nieprzerwane monitorowanie, aż do momentu, gdy nowy system będzie stabilny.

Pamiętaj: migracja to nie tylko technologia — to utrzymanie działalności biznesowej podczas wymiany silnika w locie. Planuj starannie, testuj nieustannie i zawsze miej przygotowany plan wycofania. Twoi użytkownicy nigdy nie zauważą, że coś się zmieniło.