Z PrestaShop 1.7 nie przejdziesz od razu na 9 — 8.x jest jedynym wspieranym punktem pośredni, więc każda migracja to tak naprawdę dwie aktualizacje. Zanim zapytasz o koszt, ustal zakres: ile masz modułów własnych, jak stary jest motyw i które integracje trzymają sklep przy życiu. Ta część artykułu to warstwa organizacyjna: kolejność działań, lista kontrolna i błędy, które najczęściej wydłużają projekt o tygodnie, a czasem o miesiące. Punktem wyjścia dla całego procesu jest nasze wprowadzenie do migracji PrestaShop.
Nie. Z PrestaShop 1.7 nie przejdziesz bezpośrednio na 9 — taka ścieżka aktualizacji nie istnieje. Najpierw musisz stanąć na ostatniej gałęzi 1.7, czyli 1.7.8.x, potem wejść na 8.x, a dopiero z 8.x na 9. Wersja 8.x jest jedynym wspieranym punktem pośrednim, bo dla niej powstały skrypty aktualizujące schemat bazy oraz kod zgodny z tym, czego oczekuje 9.
Pominięcie 8.x jest ryzykowne z konkretnego powodu: brakuje zmian schematu bazy i skryptów aktualizujących dla części tabel. W praktyce wygląda to tak, że sklep startuje i back office się otwiera, ale część tabel zostaje w starym kształcie — brakuje kolumn i indeksów, których oczekują nowe moduły. Najczęściej wychodzi to dopiero przy zamówieniach, kombinacjach albo statystykach, czyli po dwóch tygodniach testów.
Do tego dochodzi PHP. PrestaShop 1.7 działał na PHP 7.1–7.4, a wersja 9 wymaga PHP 8.1 i wyżej. Jeśli hosting trzyma sklep na 7.4, sam przeskok PHP potrafi wyłączyć połowę modułów, jeszcze zanim dojdziesz do aktualizacji. Realny czas takiego projektu przy sklepie ze stu modułami i niestandardowym motywem to zwykle 4–10 tygodni pracy, nie jedno popołudnie. Kolejność działań i punkty kontrolne rozpisaliśmy w materiale o migracji sklepu PrestaShop bez chaosu, a aktualne zakresy wersji sprawdzisz w dokumentacji dla deweloperów PrestaShop.
| Wersja | Rola w migracji | Wspierane PHP |
|---|---|---|
| 1.7.8.x | punkt startowy — ostatnia gałąź 1.7 | 7.1–7.4 |
| 8.x | jedyny wspierany punkt pośredni | 8.0–8.1 |
| 9.x | cel migracji | 8.1+ (realnie 8.2 lub 8.3) |
PrestaShop 9 to nie „nowszy 1.7”. Wymagania serwera i warstwa techniczna zmieniają się na tyle, że część rozwiązań z Twojego sklepu przestanie działać od razu.
Zanim cokolwiek uruchomisz, porównaj to z tym, co masz na serwerze. Pełne zestawienie wersji PHP, MySQL i rozszerzeń znajdziesz w naszym omówieniu wymagań serwera i PHP dla PrestaShop.
Audyt to jedna, maksymalnie dwie dniówki, które potrafią oszczędzić tygodnie. Rób go na kopii produkcyjnej, nie na produkcji.
Wynik audytu to lista: co działa, co wymaga przepisania, co wyłączamy. Dopiero na tej podstawie policzysz projekt. Kolejność działań opisaliśmy w materiałach o migracjach PrestaShop.
Nie ma jednej słusznej drogi z 1.7 na 9 — są trzy. Wybór zależy od liczby customizacji, nie od budżetu na start. Każda kończy się tym samym: sklepem na 9.x, ale różni się czasem, kosztem i tym, ile pracy idzie na marne.
Ścieżka A — aktualizacja etapami: 1.7 → 8.x → 9, wszystko na kopii. Klonujesz produkcję na staging, potem robisz kolejne skoki (np. 1.7.8 → 8.0 → 8.2 → 9.0) modułem 1-Click Upgrade lub z CLI. Zachowujesz historię zamówień, koszyki gości, ID produktów i adresy URL — nie tracisz pozycji w indeksie i nie mapujesz danych. Przy 0–3 modułach własnych i motywie z 2022 roku to zwykle 20–40 godzin pracy i 2–4 tygodnie kalendarzowo. Ryzyko: błędy się kumulują, a debugowanie potrafi trwać dłużej niż sam upgrade.
Ścieżka B — przebudowa na 9 z zachowaniem domeny. Produkty, klientów i zamówienia przenosisz skryptem lub narzędziem ETL do czystej instalacji 9, motyw i moduły budujesz od nowa. Sensowna, gdy motyw i tak był do wymiany, a połowa modułów nie ma wydania zgodnego z 9. Koszt: 60–120 godzin, ale dostajesz kod bez dziedziczonego długu technicznego. Uwaga na hasła klientów — przed importem potwierdź w dokumentacji sposób ich przechowywania w obu wersjach.
Ścieżka C — równoległe 9 i przełączenie ruchu po testach (blue-green). Dwie infrastruktury, niskie TTL DNS (300 s), podmiana w kilka minut. Dla sklepów przy obrocie powyżej ok. 200–300 tys. zł miesięcznie lub w szczycie sezonu, gdzie okno serwisowe oznacza utracone zamówienia.
Jeśli po lekturze nadal nie wiesz, którą wybrać, przejrzyj opis naszych migracji PrestaShop — to zestawienie realnych scenariuszy, nie cennik. Zanim podejmiesz decyzję, zweryfikuj, czy hosting udźwignie docelowe PHP i MySQL: wymagania PrestaShop 8 i 9 dla PHP i MySQL to najczęstszy blokujący problem, a nie sam kod sklepu. Ścieżka B daje przy okazji szansę na naprawę wydajności — nowy motyw to nowy pomiar Core Web Vitals, a nie tylko nowa grafika.
| Liczba modułów własnych | Wiek motywu | Liczba integracji | Miesięczny obrót | Rekomendowana ścieżka |
|---|---|---|---|---|
| 0–3 | 2022 lub nowszy | 1–3 | do 50 tys. zł | A — aktualizacja etapami |
| 4–8 | 2019–2021 | 3–5 | 50–200 tys. zł | A po audycie modułów; przy wątpliwościach B |
| 9+ | 2017–2018, bez aktualizacji | 6+ | 200–500 tys. zł | B — przebudowa na 9 |
| dowolna | dowolny | dowolna | powyżej 500 tys. zł lub szczyt sezonu | C — blue-green |
Ta sekwencja działa niezależnie od tego, czy migrację robisz sam, czy weryfikujesz wykonawcę. Kolejność kroków ma znaczenie — przestawienie punktu 2 i 3 to najczęstsza przyczyna tygodniowego opóźnienia.
X-Robots-Tag: noindex, wpis Disallow w robots.txt i hasło na poziomie serwera (HTTP Basic Auth). Wyłącz wysyłkę maili — inaczej staging wyśle prawdziwym klientom testowe potwierdzenia zamówień.Najwięcej czasu traci się nie na samym upgrade, a na braku decyzji, kto odpowiada za testy po stronie biznesu — o tym piszemy w materiale o organizacji migracji sklepu PrestaShop bez chaosu. Formalną stronę procesu, w tym tryby aktualizacji i CLI, opisuje dokumentacja deweloperska PrestaShop — warto zajrzeć przed, a nie w trakcie okna serwisowego.
Te awarie mają jedną wspólną cechę: wychodzą po starcie kampanii, nie w testach — o ile testów nie zaplanujesz dokładnie pod te punkty.
Zakres prac zależy od tego, ile z tych elementów masz u siebie: katalog modułów własnych i lista integracji to pierwsze pytanie w każdym projekcie PrestaShop, i pierwsze miejsce, w którym projekt się rozjeżdża.
Przekierowania to najczęstszy realny koszt migracji — jedyny, który widać w Analytics tygodniami po starcie. Zacznij od eksportu starych adresów w czterech grupach: produkty, kategorie, strony CMS, producenci. Sama kolumna link_rewrite nie wystarczy — klucz mapowania buduj na id_product + id_lang + id_shop, inaczej przy multistore i kilku językach zgubisz część wariantów.
Mapowanie robisz 1:1: stary URL, nowy URL, kod 301. Regułę catch-all dopisujesz na końcu pliku i nie kierujesz jej na stronę główną — jeśli wyślesz tam wszystko, Google potraktuje to jak soft 404 i wyzeruje długi ogon fraz. Catch-all ma łapać tylko to, czego nie ma w mapowaniu, i tylko w obrębie sklepu: wyklucz /admin, /modules i pliki statyczne. 301, nie 302 — 302 jest tymczasowe, nie podmienia adresu w indeksie.
W 9 sprawdź schemat URL: czy produkty nadal kończą się na .html, czy kategoria ma ten sam prefiks i separatory co w 1.7. Jeśli nie — dopasuj nowy schemat do starego albo wygeneruj przekierowania. Nową sitemapę zgłoś w Google Search Console, a przy zmianie domeny użyj narzędzia Zmiana adresu. Dalej monitoruj: Raport indeksowania i Statystyki wydajności w interwałach 30/60/90 dni. Migracja to też dobry moment na nadgonienie wydajności — przy okazji zmiany PHP zmierz TTFB przed i po, a progi wydajności opisane w materiałach o Core Web Vitals potraktuj jako punkt odniesienia, nie jako cel sam w sobie.
| Co eksportujemy | Tabela (domyślny prefiks ps_) | Pole z adresem |
|---|---|---|
| Produkty | ps_product_lang | link_rewrite |
| Kategorie | ps_category_lang | link_rewrite |
| Strony CMS | ps_cms_lang | link_rewrite |
| Producenci | ps_manufacturer_lang | link_rewrite |
| Dostawcy | ps_supplier_lang | link_rewrite |
Wycena bez audytu to zgadywanie. Dwa realne scenariusze: sklep 500–2000 produktów na standardowych modułach, bez modułów własnych — orientacyjnie 40–80 godzin; przebudowa z customami i integracją ERP — 150–350 godzin. Różnica nie bierze się z liczby produktów, tylko z kodu, który ktoś napisał pod 1.7.
Rozbicie na etapy pokazuje, gdzie znika czas:
Suma pięciu pozycji daje 54–157 godzin. W prostym sklepie schodzisz do dolnych wartości i mieścisz się w 40–80 h. W scenariuszu z customami górne wartości są regułą, a dochodzi jeszcze osobna pula na przejście modułów własnych i integracji — dlatego projekt sięga 150–350 h.
Co najbardziej podnosi wycenę: liczba modułów własnych (każdy to osobne nadpisania przez override, hooki i własne tabele w bazie), integracja z ERP (Subiekt, Comarch, WF-Mag), multistore, nietypowe metody dostawy i płatności, własne szablony maili i tłumaczenia. Stawek zł/h celowo nie podaję — rozstrzał między wykonawcami jest zbyt duży. Policz sam: godziny × stawka + bufor 15–20% na niespodzianki. Ten bufor to nie zachowanie — to jedyna pozycja, która ratuje projekt, gdy trzeci moduł z rzędu okaże się niekompatybilny z 8.x.
Kolejność działań i listę kontrolną rozpisujemy szerzej w materiale o organizacji migracji sklepu PrestaShop.
| Etap | Orientacyjny czas | Co decyduje o górnej granicy |
|---|---|---|
| Audyt | 6–12 h | Liczba modułów, stan motywu, lista integracji |
| Aktualizacja i poprawki | 20–60 h | Nadpisania (override), niekompatybilne moduły, motyw |
| Migracja danych | 10–40 h | Multistore, języki, własne tabele dodatkowe |
| SEO i przekierowania 301 | 8–20 h | Zmiana schematu URL, liczba adresów, domena |
| Testy i odbiór | 10–25 h | Płatności, dostawy, koszyk, scenariusze zamówień |
Migracja to start, nie koniec projektu. Pierwszy miesiąc ustaw jako okres obserwacji z konkretnymi zadaniami i osobą odpowiedzialną po każdej stronie.
Monitoring. Włącz podglądanie logów PHP (error_log, logi PHP-FPM) oraz logów serwera — błędy 500 i 404 często nie trafiają do panelu PrestaShop, a wyłącznie do logów. Sprawdzaj też logi sklepu w Zaawansowane → Logi. Najczęstsze problemy wychodzą przy pierwszym szczycie ruchu: koszyk, moduł płatności, cache (Redis/Memcached), sesje. Typowy przykład: 500 przy finalizacji zamówienia w pierwszy poniedziałek po kampanii, bo moduł płatności korzysta z funkcji wycofanej w nowszym PHP.
Aktualizacje. Core, moduły i PHP aktualizuj w oknach poza szczytem sprzedaży — nie w piątek przed kampanią. Przed każdą zmianą backup bazy, plików i konfiguracji serwera; raz w miesiącu sprawdź, czy backup da się realnie odtworzyć. Zasada: jedna zmiana na raz, żeby po błędzie wiedzieć, co go wywołało.
SLA i zakres opieki. Ustal czas reakcji, czas naprawy, dostęp do dewelopera (kanał inny niż kolejka ticketów), okno wdrożeniowe i raportowanie.
Zakres migracji opisujemy w sekcji Migracje PrestaShop, a bieżące wdrożenia i opiekę w PrestaShop.
| Element SLA | Przykładowy zapis |
|---|---|
| Czas reakcji | np. 4 h w godzinach pracy, 1 h dla awarii krytycznej (sklep nie przyjmuje zamówień) |
| Czas naprawy | np. 8 h roboczych dla błędów blokujących sprzedaż |
| Kanał kontaktu | np. dedykowany kontakt do dewelopera, nie tylko kolejka ticketów |
| Okno wdrożeniowe | np. wtorek–środa, 2:00–5:00, poza szczytem sprzedaży |
| Raportowanie | np. miesięczne: uptime, błędy PHP, TTFB, stan aktualizacji |
Praca na żywym sklepie bez osobnego snapshotu bazy i bez testu odtworzenia kopii.
Jak wykryć: Zapytaj wykonawcę, gdzie leży kopia, z jakiej godziny i kiedy ostatnio ktoś ją odtworzył na innym serwerze. Jeśli nie ma na to odpowiedzi w pięć minut, kopii nie ma.
Jak naprawić: Zrób pełny backup plików i bazy, wykonaj osobny snapshot produkcji i odtwórz kopię na środowisku testowym. Dopiero gdy testowe odtworzenie działa, zaczynaj pracę.
Próba przejścia 1.7 → 9 jednym skryptem, z pominięciem 8.x.
Jak wykryć: W planie projektu jest jedno okno aktualizacji i brak etapu na 8.x. Tabela wersji PHP też się nie zgadza: 1.7 obsługuje PHP 7.1–7.4, a 9 wymaga 8.1+.
Jak naprawić: Rozbij migrację na dwa etapy: najpierw stabilne 1.7.8.x, potem 8.x, dopiero potem 9. Każdy etap kończ testem zamówienia i płatności.
Brak inwentaryzacji modułów, zwłaszcza własnych i porzuconych.
Jak wykryć: Nikt nie potrafi podać listy modułów z wersją i autorem. W panelu widać moduły, których nie ma już w repozytorium PrestaShop Addons i których autor nie odpowiada na maile.
Jak naprawić: Zrób arkusz: nazwa modułu, wersja, autor, data ostatniej aktualizacji, czy istnieje wersja zgodna z 9. Moduły własne zaplanuj do przepisania albo zastąpienia — to zwykle najdroższa pozycja projektu.
Nadpisania w katalogu /override i zmiany w motywie, o których nikt nie pamięta.
Jak wykryć: Porównaj katalog /override i szablony .tpl motywu z wersjami z paczki. Każdy plik, który różni się od oryginału, to miejsce, które po aktualizacji może przestać działać.
Jak naprawić: Spisz listę nadpisań i modyfikacji custom CSS/JS. Część z nich da się zastąpić hookiem lub modułem, resztę trzeba świadomie przenieść albo wyrzucić.
Brak zamrożenia zmian w trakcie migracji — ktoś nadal dodaje produkty, zmienia ceny i instaluje wtyczki na produkcji.
Jak wykryć: W trakcie prac na kopii liczba zamówień lub produktów na produkcji rośnie. Pojawia się moduł, którego nie było w inwentaryzacji.
Jak naprawić: Ustal datę zamrożenia: żadnych instalacji, aktualizacji i zmian w motywie. Treść i zamówienia można przenosić zbiorczo na końcu, ale kod nie może się zmieniać w trakcie.
Testowanie wyłącznie wyglądu strony, bez pełnej ścieżki zakupu, maili i integracji.
Jak wykryć: Po migracji brakuje potwierdzeń zamówień, statusy nie aktualizują się w ERP, a kurier nie dostaje danych paczki. Front wygląda dobrze, więc nikt tego nie wychwycił.
Jak naprawić: Przed startem wykonaj na kopii pełne zamówienie: od koszyka, przez płatność w trybie testowym, po mail, fakturę i eksport do systemu zewnętrznego.
Migracja z PrestaShop 1.7 do 9 to dwie aktualizacje, nie jedna: najpierw stabilne 1.7.8.x, potem 8.x, dopiero na końcu 9. Powodzenie projektu rozstrzyga się przed pierwszym uruchomieniem skryptu — na liście modułów, przeglądzie nadpisań, rozmiarze bazy i mapie integracji. Jeśli dane są kompletne, wybór ścieżki i harmonogram są policzalne; jeśli ich nie ma, projekt zjada budżet na poprawki. Zacznij od audytu, nie od kopii zapasowej na produkcji.
Nie. Nie ma oficjalnej ścieżki aktualizacji z 1.7 wprost do 9. Najpierw trzeba stanąć na stabilnej gałęzi 1.7.8.x, a następnie przejść na 8.x, bo to jedyny wspierany punkt pośredni przed 9. Dopiero z gotowego 8.x wykonuje się aktualizację do 9.
Wersja 8.x zawiera zmiany schematu bazy i skrypty aktualizujące, których nie ma dla części tabel przy próbie skoku bezpośredniego. Pominięcie tego etapu kończy się brakiem wymaganych kolumn i błędami, które trzeba potem łatać ręcznie na produkcji. To także moment, w którym weryfikuje się kompatybilność modułów i motywu.
Rozrzut jest duży i zależy od liczby modułów własnych, wieku motywu i liczby integracji — przy prostym sklepie to dni, przy rozbudowanym projekcie tygodnie lub miesiące. Samo przejście na kopii jest zwykle krótkie, czas zjadają testy i poprawki po nich. Dlatego harmonogram buduje się od tyłu: od daty startu, nie od pierwszego dnia prac.
Nie zawsze. Przy aktualizacji etapami na kopii okno serwisowe ogranicza się do przełączenia ruchu i przeniesienia zamówień, które wpłynęły w trakcie prac. Sklepy, które nie mogą pozwolić sobie na przerwę, stawiają nowe środowisko obok starego i przełączają ruch po testach. Wybór zależy od tego, jak duży ruch i obrót obsługuje sklep.
Przy aktualizacji etapami historia zostaje na miejscu, bo pracujesz na tej samej bazie. Przy przebudowie na 9 dane trzeba przenieść skryptem lub narzędziem ETL i każdy element osobno zweryfikować. W obu scenariuszach sprawdź przed startem, czy logowanie klientów i dostęp do starych zamówień działają poprawnie.
Nie musi to być nowy motyw, ale stary trzeba zweryfikować pod kątem szablonów i hooków. Widoki administracyjne przeszły na Twig, a część hooków i sposobów wyświetlania treści się zmieniła, więc motyw z czasów 1.7 często wymaga poprawek. Jeśli i tak planujesz wymianę, przebudowa na 9 bywa prostsza niż ciągnięcie starych plików.
Od audytu: lista modułów, nadpisania w /override, rozmiar bazy i mapa integracji. To kilka godzin pracy, które dają odpowiedź, którą ścieżkę wybrać i z jakim budżetem się liczyć. Bez tych danych każde szacowanie kosztu jest zgadywaniem.
Jeśli chcesz, żeby ktoś przeszedł przez Twój sklep i powiedział wprost, ile pracy wymaga migracja, zajrzyj do naszego materiału o organizacji migracji bez chaosu. Możemy też zacząć od samego audytu — bez zobowiązania do dalszych prac.