Aktualizacja PrestaShop 1.7 do 8 lub 9: koszt, ryzyko i kiedy zmienić platformę

Dlaczego pytanie o aktualizację PrestaShop wraca właśnie teraz

Przez kilka lat sklep na PrestaShop 1.7 mógł działać bez większych zmian. Gałąź 1.7.8 dostawała poprawki bezpieczeństwa, a moduły z Addons miały wersje na 1.7. To się skończyło. Według komunikatu projektu PrestaShop ze stycznia 2023 gałąź 1.7.8 po wydaniu wersji 8.0 weszła w fazę wyłącznie poprawek bezpieczeństwa, a ta faza miała trwać do wydania 9.0.0. PrestaShop 9.0 wyszedł 10 czerwca 2025, więc od tego dnia 1.7 nie jest utrzymywany.

Z kolei gałąź 8.2 według komunikatu z lipca 2025 jest w fazie wsparcia rozszerzonego: dostaje tylko poprawki krytyczne i bezpieczeństwa, a faza skończy się wraz z wydaniem 10.0. To bezpieczna przystań na kilka kwartałów, nie plan na lata.

Właściciele sklepów czują to na własnej skórze. W wątku na Wykopie z sierpnia 2026 sprzedawca ze sklepem stacjonarnym i około 1,5 tys. ofert pyta, czy aktualizować 1.7 do 9.1, skoro „kosztuje parę tysięcy”, czy od razu zmienić platformę. Odpowiedzi są zgodne w jednym: stara wersja bez łatek to cel dla botów, a aktualizacja „na żywca” prawie na pewno się wysypie. W kwestii kosztu są sprzeczne, i to jest właśnie temat tego tekstu.

Co faktycznie oznacza aktualizacja z 1.7 do 8.2 lub 9

Słowo „aktualizacja” sugeruje, że to ta sama aplikacja w nowszej wersji. W przypadku przeskoku z 1.7 na 9 to nieprawda na trzech poziomach.

Serwer. Według oficjalnej strony wydania PrestaShop 9 wymaga co najmniej PHP 8.1 i działa do PHP 8.4. Sklep na 1.7 często stoi na PHP 7.x, więc zanim dotkniesz sklepu, zmienia się środowisko, a z nim zachowanie starszych modułów.

Framework. Ta sama strona podaje, że PrestaShop 9 przeszedł z Symfony 4.4 na Symfony 6.4 LTS. Dla ciebie oznacza to, że moduły, które sięgały do wnętrza Symfony (a robi to większość dużych modułów płatnych), muszą mieć wersję napisaną pod 9. Dokumentacja dla developerów mówi wprost, że wersja 9 zawiera wszystkie zmiany łamiące zgodność związane z Symfony.

Bezpieczeństwo plików. W wersji 9 pliki .php, do których nie powinno się wchodzić bezpośrednio, zwracają błąd 403. Starsze moduły, które miały własne skrypty wywoływane po adresie, przestają działać, dopóki autor nie przepisze ich na kontrolery modułu.

Do tego dochodzi narzędzie. Dawny 1-Click Upgrade został przebudowany na Update Assistant z kopią zapasową, aktualizacją i przywracaniem oraz obsługą z linii poleceń. To pomaga, ale nie sprawdzi za ciebie, czy twój motyw i moduły mają wersje na nową gałąź. W praktyce przy przeskoku z 1.7 większość wykonawców robi czystą instalację 9 i import danych, a nie aktualizację w miejscu. Dokładnie to radzi jeden z komentujących na Wykopie, i dokładnie w tym scenariuszu pojawia się problem z hasłami, o którym za chwilę.

Ile kosztuje aktualizacja PrestaShop: z czego składa się kwota

Nie podamy jednej liczby, bo bez listy modułów byłaby zgadywaniem. Podamy za to pozycje, które składają się na każdą uczciwą wycenę. Policz je dla swojego sklepu, a będziesz wiedzieć, czy wycena, którą dostałeś, jest kompletna.

Tę tabelę warto zestawić z wyceną, którą dostajesz. Jeśli w wycenie są tylko „aktualizacja PrestaShop” i jedna kwota, brakuje w niej modułów, motywu albo testów. Jeśli wycena wynosi „parę stów”, jak sugeruje jeden z komentarzy na Wykopie, obejmuje czystą instalację i import produktów modułem, ale nie obejmuje tego, co w sklepie B2B kosztuje najwięcej: odtworzenia rabatów, kont klientów i integracji.

Więcej o tym, jak liczyć pełny koszt sklepu, a nie tylko pierwszą fakturę, piszemy w tekście o tym, ile kosztuje sklep internetowy.

Co się psuje po drodze: hasła, moduły, integracje

Hasła klientów po czystej instalacji

To najczęstsza niespodzianka. Na polskim forum PrestaShop dwaj właściciele sklepów opisują w 2025 i 2026 roku tę samą sytuację: po migracji z 1.7 do 8.2 lub 9 klienci nie mogą się zalogować, a reset hasła nie działa. Powód jest techniczny, ale ważny dla decyzji. PrestaShop haszuje hasła klientów z użyciem klucza z konfiguracji instalacji. Przy czystej instalacji nowej wersji sklep dostaje nowy klucz, więc zaimportowane hasła nie pasują. Rozwiązania są dwa: przenieść klucz ze starej instalacji albo zaplanować wymuszone ustawienie nowego hasła przy pierwszym logowaniu i uprzedzić klientów mailem. Obie działają, pod warunkiem że ktoś o tym pomyśli przed startem, a nie po pierwszych telefonach od klientów.

Moduły bez wersji na nową gałąź

Każdy sklep po kilku latach ma kilkanaście modułów: płatności, przewoźnicy, Allegro, opinie, SEO, cennik PDF, rabaty. Przy aktualizacji dzielą się na trzy grupy: te, które mają wersję na 8.2 lub 9, te, które trzeba zastąpić, i te, z których nikt już nie korzysta. Trzecia grupa jest zwykle większa, niż się wydaje, i to dobra wiadomość. Zła jest taka, że w drugiej grupie najczęściej lądują moduły, które robią w sklepie rzeczy nietypowe: rabaty per klient, ceny po zalogowaniu, własne formularze zamówień. Czyli dokładnie te, dla których sklep B2B został kiedyś dopasowany.

Konektor do ERP decyduje o wersji sklepu

To najmniej widoczny, a najbardziej kosztowny punkt. Na forum InsERT administratorzy sklepów opisują w 2025 roku, że wstrzymywali przejście z 1.7.8 na 8.2 do czasu, aż zadziała integracja z Subiektem. W innym wątku z grudnia 2025 firma przed migracją rozważa PrestaShop 9 głównie dlatego, że konektor do Subiekta ją obsługuje, choć wolałaby szybszy sklep headless. Innymi słowy: o platformie decyduje dostępność konektora, nie potrzeby sprzedaży. Jeśli rozpoznajesz u siebie tę sytuację, to sygnał, że aktualizacja nie jest twoim prawdziwym problemem. Problemem jest integracja sklepu z ERP, która powinna być zaprojektowana pod twój proces, a nie pod wersję sklepu.

Kiedy aktualizacja wystarczy

Aktualizacja jest właściwą odpowiedzią częściej, niż chcieliby wykonawcy migracji. Zostań przy PrestaShop i zleć aktualizację do 8.2 albo 9, jeśli:

• sklep sprzedaje standardowo: katalog, koszyk, płatności, dostawa, bez cen per klient i bez kont firmowych,
• kluczowe moduły mają wersje na nową gałąź, a ich autorzy nadal je rozwijają,
• motyw jest standardowy albo na tyle mały, że przeniesienie go jest tańsze niż nowy storefront,
• integracja z ERP, Baselinkerem i przewoźnikami działa i ma konektor na nową wersję,
• masz wykonawcę, który zrobi aktualizację na kopii, przetestuje logowanie klientów i dopiero potem dotknie produkcji.

W takim sklepie zmiana platformy nie ma uzasadnienia. Jeśli sklep jest tylko wolny, to osobny temat: sprawdź najpierw, czy wystarczy optymalizacja PrestaShop, zanim pomyślisz o migracji.

Kiedy aktualizacja nie rozwiąże problemu

Aktualizacja przenosi sklep na nową wersję tej samej platformy. Nie doda tego, czego PrestaShop nie ma w rdzeniu. Jeśli rozpoznajesz dwa lub więcej z poniższych punktów, aktualizacja kupuje czas, ale nie rozwiązuje problemu.

Rabaty per klient. Według dokumentacji grup klientów rabat grupy to jeden procent na wszystkie produkty, a klient w kilku grupach ma grupę domyślną. Hurtownia z czterema tysiącami klientów i rabatami od 5 do 22 procent zależnymi od zeszłorocznych zakupów, jak w wątku na forum PrestaShop ze stycznia 2026, potrzebuje modułu. A moduł to pozycja z drugiej grupy w poprzednim rozdziale: przepisujesz go przy każdej dużej aktualizacji. Szerzej opisujemy to w tekście PrestaShop B2B: moduł czy osobna platforma.

Konta firmowe z rolami. Tryb B2B w PrestaShop dodaje pola firmy i limit kupiecki, ale nie wprowadza ról: kto zamawia, kto akceptuje, kto widzi faktury. Jeśli u twoich klientów zamawia jedna osoba, a akceptuje druga, sklep tego nie odwzoruje bez kolejnego modułu.

Integracja z ERP, która rządzi sklepem. Opisaliśmy to wyżej. Gdy konektor decyduje o wersji sklepu, każda następna aktualizacja będzie czekała na konektor.

Dwa sklepy na dwóch instalacjach. Osobny sklep B2B i B2C na dwóch instalacjach PrestaShop to dwa katalogi, dwa zestawy modułów, dwie aktualizacje i podwójna praca przy każdej zmianie ceny. W takiej sytuacji aktualizacja kosztuje dwa razy, a problem zostaje.

W każdym z tych przypadków warto policzyć drugą drogę: platformę B2B zbudowaną pod twoje zasady sprzedaży, która może działać obok obecnego sklepu B2C albo go zastąpić.

Jak policzyć obie drogi przez 24 miesiące

Porównanie „aktualizacja za kilka tysięcy” z „migracja za kilkadziesiąt tysięcy” jest fałszywe, bo porównuje jedną fakturę z całym projektem. Uczciwe porównanie obejmuje ten sam okres i te same pozycje.

Wynikiem tego rachunku jest jedno z trzech: aktualizuj, migruj albo zostań na 8.2 i wróć do tematu za rok. Każda z tych odpowiedzi jest w porządku, jeśli wynika z liczb, a nie z nazwy platformy. Jeżeli wolisz przejść przez ten rachunek z nami, mamy do tego osobną stronę o PrestaShop: aktualizacja do 9 czy nowa platforma, z opisem tego, co przynieść na 20-minutową rozmowę.

Jak wygląda migracja z PrestaShop na Medusę

Jeśli rachunek wskaże migrację, prowadzimy ją według kilku zasad, które chronią przed tym, co najczęściej psuje się przy aktualizacji.

1. Próbna migracja na kopii. Produkty, kombinacje, kategorie, zdjęcia, klienci, adresy i historia zamówień idą z bazy PrestaShop na kopię nowego sklepu. Różnice widać przed startem.
2. Adresy URL jeden do jednego. Mapa przekierowań 301 dla kategorii, produktów i stron CMS powstaje razem z modelem danych, a po starcie porównujemy indeksację ze stanem sprzed migracji.
3. Hasła klientów. Przenosimy je, gdy da się to zrobić bezpiecznie. Jeśli nie, projektujemy wygodne ustawienie nowego hasła przy pierwszym logowaniu i informujemy klientów przed startem, nie po.
4. Rabaty i ceny specyficzne. Odtwarzamy je jako cenniki per klient albo grupę, a reguły, które były obejściem ograniczeń PrestaShop, upraszczamy.
5. Integracja z ERP równolegle. Nowy sklep łączymy z ERP obok starego i testujemy na prawdziwych zamówieniach, zanim przełączymy domenę.

Pełny opis procesu znajdziesz na stronie migracji sklepu internetowego. Zanim jednak zdecydujesz, sprawdź jedną rzecz: czy dane w twoim obecnym sklepie i w ERP w ogóle się zgadzają. Jeśli nie, migracja przeniesie rozjazd na nową platformę. Do tego służy nasz bezpłatny test rozjazdu ERP i sklepu.