Co należało sprawdzić przed migracją

Przez lata w sklepie zainstalowano 40 modułów. Siedem miało zmieniony kod, a trzech nie rozwijali już producenci. Środowisko działało na PHP 7.1 u kresu wsparcia, co blokowało dalsze aktualizacje.

Klient rozmawiał wcześniej z dwiema agencjami. Obie proponowały nowy sklep i przewidywały około 40% spadku ruchu organicznego w pierwszym półroczu. Przy takim udziale Google w sprzedaży strata byłaby większa niż koszt wdrożenia.

Przez dekadę powstały tysiące adresów kategorii, filtrów, producentów i kampanii. Część nadal sprowadzała klientów, choć firma nie korzystała już aktywnie z tych stron. Trzeba było je odnaleźć i uwzględnić w nowej strukturze.

Inwentaryzacja adresów i modułów

Pierwsze dwa tygodnie przeznaczyłem na analizę, przed rozpoczęciem pisania kodu produkcyjnego. Połączyłem dane z Search Console, mapy witryny i logów serwera z ostatnich dwunastu miesięcy. Lista objęła 11 800 unikalnych adresów z przynajmniej jednym wejściem. Dla każdego określiłem stronę docelową.

Sprawdziłem również funkcję każdego z 40 modułów. 22 okazały się zbędne, w tym cztery powielały tę samą funkcję. Pozwoliło to ograniczyć liczbę elementów przenoszonych do nowego sklepu.

Przygotowanie nowej wersji

Przez jedenaście tygodni przygotowywałem sklep na PrestaShop 8.1 na oddzielnym środowisku. Skrypt migracyjny uruchamiałem wielokrotnie, żeby wykryć nietypowe przypadki w danych i sprawdzić ich obsługę. Ostatni przebieg przed przełączeniem, na świeżej kopii produkcji, trwał czterdzieści minut.

Mapa przekierowań 301 objęła wszystkie 11 800 adresów. Automatyczna kontrola po wdrożeniu sprawdziła odpowiedzi serwera, liczbę przekierowań po drodze i zawartość stron docelowych. Wykryła 340 adresów prowadzących do pustych kategorii. Poprawiłem je przed zgłoszeniem nowej mapy witryny.

Wyniki po przełączeniu

• Przerwa potrzebna do uruchomienia nowej wersji trwała 22 minuty.
• Największy dzienny spadek ruchu organicznego wyniósł 12% i wystąpił szóstego dnia po migracji.
• Po 17 dniach ruch wrócił do poziomu sprzed przeniesienia sklepu.
• Czas generowania strony kategorii zmniejszył się z 2,9 do 0,7 sekundy.
• Sklep korzystał z 18 modułów zamiast wcześniejszych 40.

Znaczenie przygotowania

Rozpoznanie starego sklepu zajęło znaczną część pracy. Lista działających funkcji i adresów pozwoliła zaplanować migrację, zanim zaczęło się wdrożenie. W tym projekcie właśnie te przygotowania pomogły ograniczyć ryzyko, którego obawiały się wcześniejsze agencje.

Artykuł Migracja hurtowni B2B z PrestaShop 1.6 na 8 pochodzi z serwisu eCommerce Expert.

Dlaczego ręczny test nie wykrył błędu

Pierwszą godzinę poświęciłem na kopię bazy i plików, a drugą na porównanie logów z trzech tygodni. Problem dotyczył jednej metody płatności, wybieranej przez 78% klientów.

W niedzielę w nocy automatycznie zaktualizował się moduł płatności. Nowa wersja zmieniła format odpowiedzi bramki. Sklep nie rozpoznawał potwierdzenia i pozostawiał zamówienie ze statusem „oczekujące na płatność”, mimo pobrania pieniędzy przez operatora.

Klient sprawdzał zakupy, wybierając przelew tradycyjny. Ta metoda działała, dlatego test nie ujawnił awarii. Cała diagnoza zajęła cztery godziny.

Poprawka i obsługa zamówień w toku

W ciągu kolejnych dwóch godzin dodałem obsługę nowego formatu oraz zgodność ze starym. Dzięki temu sklep mógł prawidłowo przetwarzać także wcześniejsze zamówienia. Odzyskałem 214 zamówień, które utknęły przez trzy dni. Klienci otrzymali wiadomość, również ci, którzy zdążyli już kupić produkty w innym sklepie.

Dlaczego zgłoszenie przyszło dopiero po trzech dniach

Sklep miał monitoring dostępności strony, czasu odpowiedzi i miejsca na dysku. Nie kontrolował jednak liczby zamówień. Strona pozostawała dostępna, więc działające powiadomienia nie sygnalizowały problemu ze sprzedażą.

Dodałem alert SMS porównujący liczbę zamówień z dwóch godzin ze średnią dla tego samego przedziału z poprzednich czterech tygodni. Powiadomienie uruchamia się po spadku poniżej 30% tej średniej. Przygotowanie monitoringu zajęło dzień pracy. Koszt trzech dni przestoju był ponad sto razy wyższy.

Co zmieniło się po interwencji

• Proces zakupowy działał prawidłowo sześć godzin po zgłoszeniu.
• Odzyskałem 214 zamówień zatrzymanych przez błąd płatności.
• Automatyczne aktualizacje modułów zastąpiła procedura sprawdzania zmian na kopii sklepu.
• Monitoring objął spadek liczby zamówień, a nie tylko dostępność strony.

Artykuł Awaria płatności po aktualizacji modułu pochodzi z serwisu eCommerce Expert.

Sklep na PrestaShop miał trzy moduły cenników B2B, kupowane w różnym czasie od różnych producentów. Każdy realizował część zasad naliczania cen, ale nie uwzględniał działania pozostałych. Cena w koszyku potrafiła różnić się od kwoty na fakturze. Wyjaśnienie pojedynczej rozbieżności zajmowało handlowcowi pół dnia.

Analiza przed zakupem kolejnego modułu

Klient chciał wycenić czwarty moduł, który połączy działanie trzech istniejących. Zaproponowałem najpierw dwa tygodnie diagnozy. Opis problemu wskazywał, że potrzebne jest sprawdzenie całego sposobu wyliczania ceny.

Analiza pokazała, że cena zależała od czterech zmiennych: kontrahenta, produktu, wcześniejszych zakupów i salda. Moduły realizowały te zasady niezależnie, obchodząc ograniczenia przyjętego w sklepie modelu danych. Ich połączenie nie zapewniało spójnego wyniku.

Porównanie trzech rozwiązań

Przygotowałem trzy warianty z kosztem, ryzykiem i przewidywanym okresem zwrotu:

• Czwarty moduł oznaczał najmniejszy wydatek, ale oceniałem jego przydatność na około rok.
• Przepisanie zasad cenowych wewnątrz PrestaShop wymagało większej inwestycji i utrzymywania własnego obejścia architektury.
• Osobna usługa naliczająca ceny, a następnie zmiana platformy, była najdroższa, ale pozwalała usunąć źródło rozbieżności.

Do porównania dodaliśmy koszt czasu handlowców i wstrzymanych zamówień w skali roku. Przekraczał różnicę między wariantami. Po uwzględnieniu tej kwoty klient zdecydował się na wydzielenie cen i późniejszą migrację.

Najpierw ceny, potem cały sklep

W pierwszym etapie wydzieliłem obliczanie cen do usługi z API. Dotychczasowy sklep pobierał wynik przez HTTP. Ten etap zajął osiem tygodni i rozwiązał najpilniejszy problem przy zachowaniu bieżącej sprzedaży.

Docelowo sklep został przeniesiony na Syliusa, w którym reguły cenowe można było bezpośrednio opisać w modelu domenowym. Wdrożenie zajęło kolejne pięć miesięcy. Przełączenie nastąpiło po zebraniu półrocznej historii działania usługi cenowej bez rozbieżności.

Wyniki po roku

• Liczba różnic między ceną w koszyku a fakturą spadła z kilkunastu miesięcznie do zera.
• Dodanie reguły rabatowej zajmowało jeden dzień zamiast dwóch lub trzech tygodni oczekiwania na producenta modułu.
• Zamówienia z pliku były obsługiwane bezpośrednio przez sklep, bez zewnętrznego modułu.
• Testy pokrywały 94% logiki cenowej, której błędy bezpośrednio wpływały na rozliczenia.

Dlaczego ten zakres był uzasadniony

O wyborze zdecydowała skala problemu i koszt jego codziennej obsługi. Przy trzydziestu kontrahentach rekomendowałbym pozostanie przy PrestaShop i uporządkowanie modułów. Przy 380 porównanie kosztów uzasadniło zmianę. Migrację warto rozważać po sprawdzeniu, czy tańsze rozwiązanie wystarczy do osiągnięcia celu.

Artykuł Cenniki B2B dla 380 kontrahentów: zmiana sposobu naliczania cen pochodzi z serwisu eCommerce Expert.