Migracja PrestaShop 1.7 do 9.x — pełna checklista 2026

PrestaShop 1.7 wychodzi z oficjalnego wsparcia, a wersja 9.x przynosi Symfony 6.x i obowiązkowy PHP 8.2+. Po ponad 500 migracjach zrealizowanych przez HelpGuru.eu od 2019 roku wiemy jedno: to nie jest kwestia kliknięcia „Aktualizuj”. To wymiana silnika w jadącym samochodzie.

Poniżej znajdziesz checklistę, której nie znajdziesz w oficjalnej dokumentacji — bo pochodzi z realnych projektów, nie z lab testów.

TL;DR: Migracja PrestaShop 1.7 do 9.x wymaga minimum 3-5 dni pracy dewelopera dla typowego sklepu. Kluczowe etapy to inwentaryzacja modułów, testy na staging i przebudowa override’ów pod nowe API. Sklepy z 10 000+ SKU lub rozbudowaną customizacją potrzebują 2-3 tygodnie. Źródło: HelpGuru.eu, 500+ migracji, 2019–2025.

Dlaczego nie można po prostu „zaktualizować” PrestaShop 1.7 do 9?

Odpowiedź krótka: bo to nie aktualizacja — to wymiana fundamentów. PrestaShop 1.7 opiera się na Symfony 3.x i PHP 7.x. Wersja 8.x i 9.x to Symfony 6.x z PHP 8.2+ jako minimum. Moduły skompilowane pod stary framework po prostu nie załadują się w nowym środowisku.

Na podstawie 500+ migracji przeprowadzonych przez HelpGuru.eu: 73% sklepów na wersji 1.7 korzysta z co najmniej jednego modułu, który nie ma oficjalnej wersji dla PS 9.x. Dla 31% sklepów oznacza to konieczność całkowitej zamiany modułu na alternatywę lub napisanie własnego.

Wewnętrzna architektura także się zmienia. System override’ów w PS 1.7 pozwalał na bezpośrednie nadpisywanie plików klas. W PS 9.x standardem stał się Symfony Dependency Injection i Dekoratury — override napisany „po staremu” może działać, ale przy kolejnej aktualizacji mniejszej wersji samodzielnie się zepsuje.

Trzecia pułapka to baza danych. Migracja nie przenosi bazy 1:1 — schemat tabeli ps_product i ps_product_lang uległ rozbudowie o kolumny wymagane przez nowe API produktów. Skrypt migracyjny musi te kolumny uzupełnić, inaczej sklep uruchomi się, ale import produktów przez API będzie failować w ciszy.

Co się zmienia w PrestaShop 9.x — architektura i nowe API

PrestaShop 9.x to nie tylko upgrade PHP. (PrestaShop Devdocs, 2024)

Symfony 6.x jako core. Większość warstwy backoffice jest już przepisana jako Symfony controllers z Twig templates. Stare Smarty templates w adminpanel są stopniowo wycofywane — jeśli twój moduł renderuje własne widoki w BO przez Smarty, będzie wymagał przepisania.

PHP 8.2+ obowiązkowe. PHP 7.x i 8.0 nie są wspierane. To oznacza konkretne problemy z legacy kodem: dynamiczne właściwości ($obj->dynamicProp = 'x') generują Deprecation Warning i od PHP 9.0 będą Error. Każdy moduł napisany przed 2022 rokiem trzeba audytować pod tym kątem.

Nowe Product API (v2). PrestaShop 9 wprowadza nowy endpoint REST dla produktów zgodny z CQRS/Event Sourcing. Stare API v1 jest dostępne, ale jeśli korzystasz z integracji z ERP lub PIM przez API PS, musisz sprawdzić kompatybilność przed migracją — nie po.

Smarty vs Twig w front-office. Frontowy motyw nadal może używać Smarty, ale ekosystem premium themes coraz częściej dostarcza wersję Twig. Jeśli twój motyw nie ma wersji PS 9, masz trzy opcje: kupić nowy motyw, przepisać obecny (kosztowne) lub zostać przy Smarty i zaakceptować ograniczenia przyszłego developmentu.

Checklista PRE-migration — 30+ punktów przed uruchomieniem

Nie zaczynaj migracji bez przejścia przez ten etap. Z naszego doświadczenia: 60% problemów pojawiających się „po migracji” można było wykryć przed nią.

Inwentaryzacja modułów i kompatybilność

• Wyeksportuj listę wszystkich aktywnych modułów z panelu: Moduły → Menedżer modułów → eksportuj CSV
• Dla każdego modułu premium sprawdź zakładkę kompatybilności na Addons.prestashop.com
• Zidentyfikuj moduły, które nie mają wersji dla PS 8.x/9.x — szukaj alternatyw lub zamówień aktualizacji u dewelopera
• Sprawdź moduły z opuszczonymi repozytoriami GitHub (brak commitów od >2 lat = ryzyko)
• Oceń moduły do płatności (PayU, Przelewy24, Stripe) — te zmieniają się najczęściej i są krytyczne
• Sprawdź, które moduły korzystają z ObjectModel::override — to najczęstsze źródło konfliktów

Audit override’ów i hooków

• Wylistuj wszystkie pliki w katalogu /override/classes/ i /override/controllers/
• Dla każdego override sprawdź, czy klasa bazowa zmieniła sygnaturę metody w PS 9.x (Devdocs changelog)
• Zidentyfikuj hooki które zostały usunięte lub zmienione: actionProductUpdate → actionProductSave to klasyczny przykład
• Sprawdź custom hooki dodawane przez moduły — po migracji mogą nie być rejestrowane w nowej kolejności
• Przetestuj każdy override na staging z włączonym error_reporting(E_ALL)

Backup procedura

• Backup bazy danych: mysqldump --single-transaction --routines --triggers — NIE przez phpMyAdmin dla baz >500MB
• Backup plików: pełne archiwum / łącznie z .htaccess i app/config/parameters.php
• Backup media: katalog /img/ osobno — to zwykle 80% rozmiaru backupu
• Zweryfikuj backup przez przywrócenie na oddzielnym środowisku (nie „backup jest” ale „backup działa”)
• Zapisz wersję PHP, MariaDB/MySQL i konfigurację php.ini obecnego serwera

Staging environment

• Sklonuj sklep na staging z identyczną wersją PHP i MySQL co produkcja
• Uruchom migrację NAJPIERW na staging — bez wyjątków
• Przetestuj staging pod adresem innym niż produkcja (subdomena lub osobna domena)
• Wyłącz indeksowanie staging przez robots.txt i meta noindex
• Zablokuj płatności na staging (tryb testowy PayU/Przelewy24)

Ocena motywu

• Sprawdź, czy autor motywu wydał wersję dla PS 8.x/9.x
• Jeśli motyw jest starszy niż 3 lata — oceń koszt przebudowy vs zakup nowego
• Zidentyfikuj customizacje motywu spoza systemu potomnego (child theme) — będą nadpisane przy aktualizacji motywu
• Przetestuj motyw na PS 9.x staging pod kątem błędów Twig/Smarty

Infrastruktura

• Sprawdź obsługę PHP 8.2+ na hostingu (wielu polskich hostingów nadal domyślnie serwuje PHP 7.4)
• Oceń wymagania RAM — PS 9.x potrzebuje minimum 256MB, optymalnie 512MB+ per PHP worker
• Sprawdź limit execution_time (generowanie sitemap lub przebudowa indeksu wymaga >120s)
• Zaplanuj okno serwisowe — minimum 4h dla typowego sklepu

Z naszej praktyki: właściciele sklepów najczęściej pomijają punkt z audytem override’ów, bo „przecież działają od lat”. To błąd. W trzech migracjach w 2024 roku override kontrolera zamówień (napisany pod PS 1.6) był przyczyną cichego błędu, gdzie zamówienia trafiały do bazy ale nie wysyłały emaila potwierdzającego. Sklep działał pozornie poprawnie przez 3 dni po migracji.

Migracja krok po kroku — CLI i panel administracyjny

Krok 1: Upgrade PHP na staging

Zanim cokolwiek dotkniesz w PrestaShop, przestaw PHP na staging na wersję 8.2 lub 8.3. Następnie uruchom sklep i sprawdź logi PHP — zobaczysz wszystkie Deprecation Warnings z modułów i override’ów. To twoja lista naprawcza.

# Sprawdź aktualne PHP workers
php -v
# Włącz logowanie deprecacji
php -d error_reporting=E_ALL -d display_errors=1 index.php

Krok 2: Aktualizacja przez CLI (zalecana metoda)

PrestaShop od wersji 8.x posiada oficjalny moduł autoupgrade z interfejsem CLI. To znacznie bezpieczniejsza opcja niż panel, szczególnie dla sklepów z dużymi bazami.

# Pobierz najnowszy autoupgrade
composer require prestashop/autoupgrade

# Uruchom migrację w trybie dry-run (tylko analiza)
php bin/console prestashop:autoupgrade:run --dry-run

# Właściwa migracja
php bin/console prestashop:autoupgrade:run

Tryb --dry-run to jeden z najważniejszych kroków — raportuje konflikty bez wprowadzania zmian. Nie pomijaj go.

Krok 3: Naprawa override’ów i modułów

Po migracji uruchom sklep w trybie debug (_PS_MODE_DEV_ = true w config/defines.inc.php). Przejrzyj logi w /var/log/ lub panel Konfiguracja Zaawansowana → Logi. Naprawiaj kolejno — zacznij od modułów płatności, potem checkout, potem reszta.

Krok 4: Rebuild cache i indeksów

php bin/console cache:clear
php bin/console prestashop:generate:htaccess
php bin/console prestashop:module:uninstall smarty_cache
php bin/console prestashop:module:install smarty_cache

Przebuduj indeks wyszukiwania. Dla sklepów z >10 000 produktów rób to CLI, nie przez panel — timeout przeglądarki przerwie proces w połowie.

Krok 5: Przełączenie DNS na produkcję

Dopiero gdy staging działa bez błędów przez minimum 48h testów — przełączaj DNS. Utrzymaj stary serwer w gotowości przez minimum 7 dni jako fallback.

TOP 5 najczęstszych błędów po migracji — z naszego doświadczenia

Po 500+ migracjach widzimy te same błędy. Oto pięć najczęstszych, które zjadają łącznie 80% czasu debugowania post-migracyjnego.

1. Białe strony w checkout bez błędu w logach. Przyczyna: override klasy Cart lub Order nie jest kompatybilny z nowym PHP 8.2+. Rozwiązanie: włącz display_errors=1 tymczasowo, znajdź TypeError lub deprecated dynamic property.

2. Moduł płatności nie przetwarza zamówień. Przyczyna: zmiana struktury hooków actionValidateOrder i actionPaymentConfirmation między PS 1.7 a 8/9. Rozwiązanie: sprawdź wersję modułu płatności — PayU i Przelewy24 mają osobne wersje dla PS 8.x.

3. Zdjęcia produktów nie wyświetlają się. Przyczyna: po migracji miniaturki muszą być przebudowane. Panel: Parametry Zaawansowane → Obrazy → Przebuduj miniaturki. Dla sklepów z >5000 zdjęć rób przez CLI.

4. Wolny backoffice (panel ładuje się >5s). Przyczyna: Symfony profiler pozostał aktywny w trybie produkcyjnym lub cache Symfony nie został wyczyszczony poprawnie. Rozwiązanie: APP_ENV=prod w .env.local i php bin/console cache:warmup --env=prod.

5. Niespójna walidacja formularzy checkout. Przyczyna: formularz w PS 9.x korzysta z Symfony Form Validator zamiast własnej walidacji PS 1.7. Customowe pola (PESEL, NIP, data urodzenia) wymagają osobnego migrowania do nowego systemu walidacji.

Post-migration audit checklist

Po uruchomieniu na produkcji przejdź ten checklist w ciągu pierwszych 24h.

• Złóż testowe zamówienie przez każdą metodę płatności
• Sprawdź wysyłkę emaili transakcyjnych (potwierdzenie zamówienia, status wysyłki)
• Zweryfikuj poprawność naliczania podatku VAT (szczególnie dla B2B)
• Sprawdź sitemap.xml — czy produkty i kategorie są obecne
• Przebuduj indeks wyszukiwania
• Sprawdź Google Search Console pod kątem nowych błędów crawl
• Zweryfikuj szybkość sklepu (PageSpeed Insights) — migracja często zmienia wynik
• Sprawdź logi błędów PHP przez pierwsze 48h
• Zweryfikuj synchronizację z Baselinker/Shoper/ERP jeśli dotyczy

Ile trwa i kosztuje profesjonalna migracja PrestaShop 1.7 do 9.x?

Na podstawie 500+ migracji zrealizowanych przez HelpGuru.eu (2019–2025):

Stawka HelpGuru.eu za prace migracyjne PrestaShop to 200–249 zł/h. Najdłuższy element to nie sama migracja, ale debug i naprawa modułów/override’ów po migracji — stanowi zwykle 50-60% całego czasu projektu.

Citable fragment: Migracja PrestaShop 1.7 do 9.x to wymiana silnika — nie aktualizacja. Sklep korzystający z niestandardowych override’ów lub nieoficjalnych modułów wymaga minimum 3-5 dni pracy dewelopera, a w przypadku sklepów z 10 000+ SKU — nawet 2-3 tygodnie. Na podstawie ponad 500 migracji przeprowadzonych przez HelpGuru.eu od 2019 roku.

FAQ — najczęstsze pytania o migrację PrestaShop 1.7 do 9

Czy mogę migrować bezpośrednio z 1.7 do 9.x, pomijając wersję 8.x?

Tak, ale nie jest to zalecane. PrestaShop oficjalnie wspiera ścieżkę 1.7 → 8.0 → 8.1 → 9.0. Próba skoku o dwie główne wersje zwiększa liczbę konfliktów modułów i override’ów. W praktyce: przy prostych sklepach działa, przy rozbudowanych — planuj etapowo.

Czy muszę kupić nowe moduły po migracji?

Zależy od modułów. Moduły z Addons.prestashop.com w subskrypcji rocznej zazwyczaj obejmują update do PS 9. Moduły kupione jednorazowo >3 lata temu — sprawdź politykę wydawcy. Niestety część wydawców traktuje wsparcie dla PS 9 jako osobny, płatny produkt.

Czy moja pozycja w Google ucierpi po migracji?

Migracja techniczna (bez zmiany URL) nie powinna pogorszyć pozycji. Najczęstsze SEO-ryzyka to: zmiana struktury URL (niedopuszczalne bez 301), usunięcie treści lub zmiana canonical. Sprawdź GSC przez pierwsze 30 dni po migracji.

Czy można zrobić migrację „na żywo” bez trybu konserwacji?

Technicznie można, ale nie należy. Tryb konserwacji chroni przed zamówieniami złożonymi w trakcie migracji bazy (ryzyko utraty danych) i przed widocznością błędów przez użytkowników. Minimum 2-4h okna serwisowego to standard.

Co z modułem Autoblog AI HelpGuru — działa na PS 9.x?

Tak. Moduł Autoblog AI HelpGuru jest rozwijany z myślą o PS 8.x i 9.x. Wspieramy PHP 8.2 i Symfony 6.x. Jeśli korzystasz z wcześniejszej wersji modułu, skontaktuj się z nami — aktualizacja jest bezpłatna dla aktywnych subskrybentów.