Migracja PrestaShop: co się przenosi, a co trzeba zbudować od nowa

Przenosi się to, co jest danymi. Nie przenosi się to, co jest zachowaniem. Produkty, kategorie, klienci, zamówienia i adresy URL przejdą. Moduły, motyw i nadpisania trzeba odtworzyć, a to one odróżniają Twój sklep od świeżej instalacji.

Ten tekst odpowiada na trzy pytania: co przeżyje migrację, gdzie siedzi koszt, którego nikt nie wycenia na starcie, i w jakiej kolejności to robić, żeby nie zapłacić dwa razy. Dotyczy zarówno przejścia między wersjami głównymi PrestaShopu, jak i przeprowadzki na inną platformę, bo podział na rzeczy przenoszalne i nieprzenoszalne jest w obu przypadkach ten sam. Wymagania techniczne sprawdziliśmy w dokumentacji PrestaShopu 21 października 2026.

Co przechodzi, a co budujesz od nowa

Podział jest zaskakująco ostry i warto go znać przed pierwszą rozmową o budżecie.

Podział dotyczy zarówno przejścia między wersjami głównymi, jak i przeniesienia na inną platformę.

Pułapka, o której nie piszą poradniki: wersja PHP

Przy przejściu z 1.7 na 9 najczęściej zaskakuje nie sklep, tylko serwer pod nim.

Dokumentacja PrestaShopu jest tu jednoznaczna: dziewiątka nie wspiera PHP 8.0 ani niższego. Wersja 8.1 działa, ale nie jest zalecana; wspierane są 8.2, 8.3 i 8.4. Do tego MySQL co najmniej 5.7 albo MariaDB co najmniej 10.2, a limit pamięci na skrypt minimum 512 MB.

Tymczasem sklep, który stoi dziś na 1.7, bardzo często pracuje na PHP 7.x. To znaczy, że zmieniasz wersję PHP, bazę i konfigurację serwera, a dopiero potem aplikację sklepową. Każda z tych zmian potrafi wywrócić moduł, który do tej pory działał bez zarzutu.

Zanim wycenisz migrację, sprawdź, na jakim PHP stoisz dzisiaj.

Ta jedna liczba zmienia zakres projektu bardziej niż liczba produktów w katalogu, bo przesądza, czy rozmawiamy o aktualizacji aplikacji, czy o przeprowadzce na nowy serwer razem z całą konfiguracją, testami i oknem, w którym coś może pójść inaczej, niż zakładaliście.

Gdzie naprawdę siedzi koszt: moduły

To jest pozycja, która rozsadza budżety, bo na starcie wygląda jak lista do odhaczenia, a okazuje się listą małych projektów.

Przy każdym module odpowiedz na jedno pytanie: czy ma wersję na linię, na którą idziesz. Jeśli nie, masz trzy wyjścia i żadne nie jest darmowe.

• Zamiennik. Inny moduł robiący to samo. Najtańsze, ale wymaga przeniesienia konfiguracji i zwykle zmienia zachowanie w drobiazgach, które zauważą klienci.
• Napisanie od nowa. Sensowne, gdy moduł obsługuje coś, co jest Twoją przewagą, a nie standardem.
• Rezygnacja. Najczęściej pomijana, a przy przeglądzie okazuje się, że część modułów nie jest używana od lat. Policz ich funkcje, zanim zapłacisz za przeniesienie.

Zrób ten przegląd na samym początku.

Lista modułów z odpowiedzią „zamiennik, przepisać, wyrzucić" przy każdym to jedyny dokument, który pozwala uczciwie wycenić migrację PrestaShopu, i jednocześnie najtańszy sposób, żeby skrócić jej zakres: przy sklepach z kilkuletnią historią regularnie okazuje się, że jedna trzecia pozycji na tej liście obsługuje funkcje, z których nikt nie korzystał od ostatniej zmiany w zespole.

Przekierowania: najtańsza pozycja, najczęściej pomijana

Migracja kasuje widoczność w wyszukiwarce prawie zawsze w ten sam sposób: ktoś zmienił strukturę adresów i nikt nie zbudował mapy przekierowań.

Skutek jest opóźniony i przez to podstępny. W dniu uruchomienia sklep działa, zamówienia wpadają, wszyscy są zadowoleni. Spadek ruchu widać dopiero po dwóch, trzech tygodniach, gdy wyszukiwarka przeindeksuje stare adresy i nie znajdzie pod nimi niczego.

Zabezpieczenie jest proste i tanie: przed startem wyeksportuj listę wszystkich adresów ze starego sklepu, dopasuj każdy do nowego i przygotuj przekierowania stałe. Przy dużym katalogu robi się to regułą, nie ręcznie. Jak przeprowadzić całość bez wyłączania sprzedaży, rozkładamy w tekście o migracji bez zatrzymywania sklepu.

Dwie drogi: aktualizacja w miejscu albo świeża instalacja

Wybór między nimi przesądza o ryzyku i o tym, co odziedziczysz razem ze sklepem.

Przy sklepach, które żyją kilka lat, częściej opłaca się druga droga.

Powód jest prozaiczny: świeża instalacja pozwala nie przenosić rzeczy, których i tak nikt już nie używa, a przy aktualizacji w miejscu przenoszą się one same, razem z konfiguracją, której nikt nie pamięta, i z modułami wyłączonymi przed dwoma laty, których nikt nie odważył się usunąć.

Kolejność prac, która ogranicza ryzyko

Zmiana kolejności tych kroków jest najczęstszym powodem, dla którego migracja wychodzi dwa razy drożej.

• Sprawdź stos. Wersja PHP, baza, limit pamięci. To decyduje, czy w ogóle rozmawiamy o aktualizacji, czy o przeprowadzce na nowy serwer.
• Zrób przegląd modułów z decyzją przy każdym. Bez tej listy każda wycena jest zgadywaniem.
• Postaw kopię i przećwicz migrację na niej. Pierwsze przejście zawsze coś wykrywa; lepiej, żeby wykryło na kopii.
• Przygotuj mapę przekierowań przed startem, nie po.
• Przetestuj ścieżkę zakupu na realnym koszyku: podatki, dostawa, płatność, faktura. Najdroższe błędy migracji siedzą w kasie, bo nie widać ich w panelu.
• Uruchom i obserwuj ruch przez trzy tygodnie. Wtedy wychodzą skutki przekierowań.

Czy to robić samodzielnie

Uczciwa odpowiedź brzmi: często tak, i warto to powiedzieć przed ofertą, a nie po.

Jeśli Twój sklep jest blisko domyślnej instalacji, ma kilka popularnych modułów i stoi na wspieranej wersji PHP, aktualizacja jest wykonalna własnymi siłami w kilka dni. Wtedy zlecanie jej na zewnątrz jest wydawaniem pieniędzy na coś, co zrobicie sami.

Rozmowa o pomocy zaczyna się gdzie indziej: przy sklepie z nadpisaniami, własnym motywem, integracją z systemem magazynowym i katalogiem, którego nikt nie porządkował od lat. Tam największym ryzykiem jest to, co wyjdzie po drodze: ile rzeczy działało przypadkiem.

Moment, w którym warto zadać inne pytanie

Jest sytuacja, w której budżet na migrację lepiej wydać inaczej, i szkoda ją przegapić, bo wraca dopiero za kilka lat.

Jeśli i tak przepisujesz motyw, odtwarzasz kilkanaście modułów i zmieniasz serwer, to realnie budujesz sklep od nowa, tylko na tej samej platformie. W tym momencie warto policzyć, czy platforma, z której korzystasz, jest nadal właściwa, bo koszt zmiany nigdy nie będzie niższy niż teraz.

Pytanie jest zasadne zwłaszcza wtedy, gdy przez ostatnie lata dokładaliście moduły do rzeczy, których platforma nie robi w standardzie: cen zależnych od klienta, kont firmowych z akceptacją zamówień, nietypowych jednostek sprzedaży. Rozkładamy to przy platformie B2B, a zbudowane widać w case study hurtowni DrillStom.

Kryteria niezależne od nazw zebraliśmy w tekście o wyborze platformy, porównania samych platform stoją w hubie, a pełny rachunek na trzy lata w tekście o koszcie sklepu na własność.

Zastrzeżenie, bo to jedyny tekst z tej serii, który celuje w naszą usługę: nie każda migracja jest powodem do zmiany platformy i w większości przypadków nie jest. Przenosimy sklepy także wtedy, gdy klient zostaje tam, gdzie był, i to jest najczęstszy scenariusz. Zakres opisujemy przy platformach B2B, a model wyceny w cenniku.