PrestaShop: aktualizacja do 9 czy nowa platforma

Decyzja zaczyna się od numeru wersji, bo od niego zależy, czy sklep dostaje poprawki bezpieczeństwa i czy moduły mają jeszcze aktualizacje. Stan według komunikatów projektu PrestaShop, sprawdzony w październiku 2026.

Jeśli poniższe zdania opisują twój sklep, nie potrzebujesz nas. Zleć aktualizację sprawdzonemu wykonawcy PrestaShop i wróć, gdy sklep zacznie blokować sprzedaż.

• Sklep sprzedaje standardowo: katalog, koszyk, płatności, dostawa, bez cen per klient i bez kont firmowych.
• Kluczowe moduły mają wersje na PrestaShop 8.2 lub 9, a ich autorzy nadal je rozwijają.
• Motyw jest standardowy albo niewielki, więc przeniesienie go na nową gałąź jest tańsze niż nowy storefront.
• Integracja z ERP, Baselinkerem i przewoźnikami działa i ma konektor na nową wersję.
• Masz kogoś, kto zrobi aktualizację na kopii, przetestuje logowanie klientów i dopiero potem dotknie produkcji.

Gdy rozpoznajesz dwa lub więcej z tych punktów, aktualizacja kupuje czas, ale nie rozwiązuje problemu. Wtedy liczymy drugą drogę.

• Rabaty per klient. Grupy klientów dają jeden procent na grupę, a przy kilku grupach liczy się grupa domyślna. Rabat zależny od obrotu klienta z zeszłego roku wymaga modułu, który i tak przepisujecie przy każdej dużej aktualizacji.
• Konta firmowe. Tryb B2B dodaje pola firmy i limit kupiecki, ale nie wprowadza ról: kto zamawia, kto akceptuje, kto widzi faktury.
• Integracja z ERP. Jeśli konektor do Subiekta, Comarch albo enova decyduje o tym, na której wersji PrestaShop stoisz, to konektor rządzi sklepem, a nie odwrotnie.
• Hasła i dane klientów. Przy czystej instalacji nowej wersji i imporcie danych hasła działają tylko wtedy, gdy przeniesie się klucz instalacji. Da się to zrobić, ale trzeba to zaplanować, a nie odkryć w dniu startu.
• Dwa sklepy. Osobny sklep B2B i B2C na dwóch instalacjach PrestaShop to dwa katalogi, dwa zestawy modułów i podwójna praca przy każdej zmianie.

Na rozmowie zbieramy pięć rzeczy: wersję PrestaShop i PHP, listę modułów z ich statusem na nowej gałęzi, integracje (ERP, płatności, przewoźnicy, marketplace), liczbę produktów i klientów oraz jedną zmianę, której sklep dziś nie potrafi.

Aktualizację liczymy jako: praca wykonawcy, nowe wersje płatnych modułów, przeniesienie motywu i testy na kopii. Migrację liczymy jako: nowy sklep na naszej podstawie z Medusą, przeniesienie danych i adresów URL, integracje i utrzymanie przez 24 miesiące. Obie kwoty dostajesz w tym samym układzie.

Wynikiem rozmowy jest jedno z trzech: aktualizuj, migruj albo zostaw na 8.2 i wróć do tematu za rok. Każde z nich jest w porządku.

Jeśli rachunek wskazuje migrację, prowadzimy ją według tych zasad.

• Produkty, kombinacje, kategorie, zdjęcia, klienci, adresy i historia zamówień idą z bazy PrestaShop przez próbną migrację na kopii. Różnice widać przed startem, nie po.
• Adresy URL mapujemy jeden do jednego, z przekierowaniami 301 dla kategorii, produktów i stron CMS. Po starcie porównujemy indeksację ze stanem sprzed migracji.
• Hasła klientów przenosimy, gdy da się to zrobić bezpiecznie. Jeśli nie, projektujemy wygodne ustawienie nowego hasła przy pierwszym logowaniu.
• Rabaty i ceny specyficzne odtwarzamy jako cenniki per klient albo grupę w Medusie, a reguły, które były obejściem, upraszczamy.
• Integrację z ERP uruchamiamy równolegle do starego sklepu i testujemy na prawdziwych zamówieniach, zanim przełączymy domenę.