Kiedy migracja PrestaShop ma sens – a kiedy lepiej najpierw naprawić sklep

Migracja nie naprawia problemów, które nie wynikają z technologii. Zanim zamówisz wycenę, sprawdź, czy Twoje problemy w ogóle dotyczą wersji sklepu.

Migruj, gdy:

• PHP jest po końcu wsparcia bezpieczeństwa: 7.4 – listopad 2022, 8.0 – listopad 2023, 8.1 – grudzień 2025. Hostingi wyłączają stare wersje z dnia na dzień, a sklep po prostu przestaje działać.
• Moduł płatności nie dostał aktualizacji od 12 miesięcy lub dłużej (Przelewy24, PayU, tpay, Stripe). To realne ryzyko dla rozliczeń, zwrotów i reklamacji.
• TTFB przekracza 800 ms, a LCP na mobile 4 s przy kilku tysiącach produktów. Zależność między szybkością a widocznością w Google opisuje dokumentacja Core Web Vitals.
• Certyfikat SSL wygasł albo serwer obsługuje wyłącznie TLS 1.0/1.1 – klienci widzą ostrzeżenie przeglądarki.

Nie migruj, gdy:

• Wąskie gardło to shared hosting z memory_limit 64 MB i wyłączonym OPcache. Nowa wersja PrestaShop na tym samym serwerze będzie działać równie wolno.
• Masz 30 produktów i 200 sesji miesięcznie – problem jest w ofercie, cenie i treści, nie w kodzie.
• Kategorie nie mają opisów, zdjęcia ważą po 2 MB, a na blogu nie ma ani jednego wpisu.

Rozdziel trzy pojęcia, bo mieszają się w co drugiej rozmowie z klientem: migracja wersji (1.6 → 8.x), migracja hostingu (ta sama wersja, inny serwer) i migracja platformy (PrestaShop → WooCommerce). To trzy różne projekty, z różnym ryzykiem i innym budżetem.

Remont bywa tańszy. Aktualizacja PHP, włączenie OPcache, kompresja zdjęć i poprawka szablonu to zwykle 20–40 godzin. Podniesienie wersji z modułami własnymi: 40–80 godzin. Zmiana platformy: 80–120 godzin. Przy najtańszym scenariuszu naprawy migracja jest często wydatkiem bez zwrotu – porównaj stawki i godziny utrzymania sklepu PrestaShop, zanim podejmiesz decyzję.

Trzy ścieżki migracji: wersja, hosting, platforma – co wybrać w Twojej sytuacji

Te trzy projekty różnią się nie tylko czasem, ale i tym, co może pójść nie tak w trakcie.

Ścieżka 1: podniesienie wersji (1.6 → 1.7 → 8.x). Oficjalny moduł 1-Click Upgrade (autoupgrade) prowadzi aktualizację, ale nie przez skoki: 1.6.1.x do 1.7.8, potem do 8.x. Jeśli masz nadpisania w katalogu override/ albo moduły własne, kreator się zatrzyma – a gorzej, gdy przejdzie i zostawi niespójną bazę. Zawsze: pełna kopia plików i bazy, test na subdomenie za Basic Auth, robots.txt z Disallow, PHP w wersji wymaganej przez docelową gałąź. Zakres zmian w API i szablonach sprawdzisz w dokumentacji dla deweloperów PrestaShop. Paczkę instalacyjną pobieraj wyłącznie z oficjalnego źródła – skąd pobrać PrestaShop i czego nie robić przy rozpakowywaniu.

Ścieżka 2: zmiana hostingu bez zmiany wersji. Najniższe ryzyko SEO. Warunek: identyczne lub wyższe wersje PHP i MySQL/MariaDB, collation utf8mb4, OPcache, ten sam silnik (Apache/Nginx/LiteSpeed) i uprawnienia 755/644. Test przez wpis w /etc/hosts przed zmianą DNS – przy TTL 300 s ruch przełącza się w kilka minut. Stary serwer zostaw działający minimum 7 dni.

Ścieżka 3: PrestaShop → WooCommerce. Nie ma mapowania 1:1 na kombinacje produktowe – odpowiednikiem są wariacje WooCommerce, a grupy atrybutów przepisuje się ręcznie. Tak samo ceny specyficzne i cenniki grupowe B2B: w WooCommerce robi się to wtyczką, nie konfiguracją. Każdy stary adres wymaga przekierowania 301, a dane strukturalne Product/Offer trzeba odtworzyć od zera. Decydując się na tę ścieżkę, zaplanuj przegląd modułów PrestaShop i listę funkcji, które trzeba zastąpić.

Kryterium	Wersja (1.6 → 8.x)	Hosting	Platforma (→ WooCommerce)
Moduły własne (nie z marketplace)	2–5 modułów to 8–20 h pracy	bez zmian, przenosisz 1:1	każdy trzeba zastąpić wtyczką lub napisać od nowa
Zamówienia w bazie	do 50 tys. – przenoszone w oknie serwisowym	bez zmian	zwykle zostają w archiwum, nie przenoszą się
Multistore	testujesz każdy sklep osobno	bez zmian, sprawdź domeny i DNS	WooCommerce Multisite albo osobne instalacje
B2B z cennikami grupowymi	zostaje, jeśli moduł ma wersję na 8.x	bez zmian	konfiguracja od zera, wymaga wtyczki
Czas i ryzyko SEO	40–80 h, ryzyko średnie	10–25 h, ryzyko niskie	80–120 h, ryzyko wysokie

Audyt starego sklepu – 12 rzeczy do spisania przed pierwszym klikiem

Bez audytu migracja zatrzymuje się na pytaniu „a skąd wiemy, która wersja modułu była zainstalowana?”. Spisz wszystko w jednym arkuszu, z datą i osobą odpowiedzialną.

1. Wersja PrestaShop – pełny numer, np. 1.7.8.9. W 1.6 siedzi w config/settings.inc.php, w 1.7+ w app/config/parameters.php.
2. Wersja PHP, memory_limit, max_execution_time, OPcache (włączony czy nie).
3. Wersja MySQL/MariaDB, silnik tabel (InnoDB) i collation bazy (utf8mb4).
4. Silnik serwera i jego wersja: Apache + mod_php, Nginx + PHP-FPM czy LiteSpeed. Obsługa HTTP/2 albo HTTP/3.
5. Lista modułów z wersjami – eksport z zakładki Moduły. Oznacz każdy jako Addons / własny / z repozytorium. Te własne przepisuje się ręcznie; jeśli trafiły z Gita, pomoże czytanie repozytoriów PrestaShop na GitHubie.
6. Nadpisania szablonu: katalog override/, pliki w themes/[nazwa]/ oraz child theme. Wypisz każdy plik i powód zmiany.
7. Liczba produktów, kombinacji, kategorii, klientów, zamówień. Szybki licznik: SELECT COUNT(*) FROM ps_product_attribute. 10 tys. kombinacji to inny czas eksportu niż 500.
8. Płatności: Przelewy24, PayU, tpay, Stripe – wersja modułu i kto trzyma klucze API.
9. Kurierzy: InPost, DPD, DHL – moduły oraz ewentualne integracje pisane pod zamówienie.
10. Integracje z ERP i księgowością: API, pliki CSV czy webhooki i kto odbiera dane.
11. Mapa URL i Google Search Console: adresy w indeksie, kliknięcia i wyświetlenia za 3–12 miesięcy. To gotowa lista przekierowań. Znaczenie kodów 301 i 308 jako przekierowań trwałych opisuje specyfikacja HTTP.
12. Dostępy: DNS, panel hostingu, cron, kopie zapasowe, właściciel domeny i certyfikatu.

Dopisz do arkusza punkt odniesienia: konwersję, przychód i pozycje sprzed migracji. Bez baseline nie udowodnisz, że zmiana niczego nie zaszkodziła – cały proces krok po kroku przechodzimy w migracjach PrestaShop.

Metoda migracji: 1-Click Upgrade, ręczna czy z deweloperem

Metodę wybiera się na podstawie jednego pytania: czy sklep odbiega od standardu PrestaShop. Jeśli nie — wystarczy narzędzie i dyscyplina. Jeśli tak — potrzebna jest osoba, która zna strukturę bazy, modułów i szablonu.

1-Click Upgrade (nazwa techniczna modułu: autoupgrade) sprawdza się w sklepach bez modyfikacji core, bez własnych modułów i na standardowym szablonie. Warunki przed uruchomieniem: kopia na środowisku staging, wyłączony cache (Zaawansowane → Wydajność → pamięć podręczna i cache szablonów), wyłączone moduły niekompatybilne z docelową wersją PHP i pełny backup z kreatora. Nie uruchamiaj go na żywej bazie w godzinach sprzedaży — moduł nadpisuje pliki, a błąd 500 trudno cofnąć bez kopii.

Migracja ręczna to mysqldump bazy i kopia plików przez tar, a potem żmudne poprawki: prefiks tabel w pliku konfiguracyjnym (app/config/parameters.php w 1.7+, config/settings.inc.php w 1.6), wpisy PS_SHOP_DOMAIN i PS_SHOP_DOMAIN_SSL w ps_configuration, domena, physical_uri i virtual_uri w ps_shop_url, konta w ps_employee. Ręcznie nie przeskoczysz zmian w schemacie między wersjami głównymi — 1.6 → 8.x wymaga kolejnych upgrade'ów po drodze. Zmiany w strukturze tabel opisuje dokumentacja dla deweloperów PrestaShop.

Deweloper wchodzi w grę, gdy masz własne moduły, niestandardowe płatności, integrację z ERP (Subiekt, Comarch Optima), multistore albo sklep B2B z indywidualnymi cennikami. Zanim wybierzesz metodę, zrób listę modułów i ich zgodność z nową wersją — jeden niezgodny moduł potrafi wyłączyć koszyk. Praca bezpośrednio z osobą wdrażającą, bez pośredników, skraca czas, bo nie ma przekazywania kontekstu między handlowcem a wykonawcą. Migracja przez kopiowanie staging → produkcja jest bezpieczniejsza niż upgrade na żywej bazie zawsze wtedy, gdy nie możesz pozwolić sobie na godzinę przestoju lub na utratę zamówień złożonych w trakcie prac.

Migracja krok po kroku – od backupu do uruchomienia na produkcji

Kolejność jest ważniejsza niż tempo. Każdy krok kończy się weryfikacją, zanim przejdziesz do następnego.

1. Pełny backup. Baza: mysqldump --single-transaction --routines --triggers. Pliki: tar -czf z katalogu sklepu. Trzecia kopia na nośniku poza serwerem (S3, dysk zewnętrzny, inny region hostingu). Kopia leżąca na tym samym serwerze to nie kopia.
2. Klon na staging. Osobna baza, osobny URL, osobny katalog. Jeśli staging jest dostępny publicznie, wyłącz indeksowanie nagłówkiem X-Robots-Tag: noindex lub hasłem na poziomie serwera — sam robots.txt nie wystarczy, bo nie blokuje wejścia po linku.
3. Upgrade lub przeniesienie plików. Najpierw moduły (zgodność z nowym PHP), potem szablon (nadpisania w /themes), na końcu core. Odwrotna kolejność kończy się wersją core, której stare moduły nie rozumieją. Warianty dla skoków między wersjami głównymi opisujemy w sekcji Migracje PrestaShop.
4. Kontrola bazy. Prefiks tabel musi być identyczny w pliku konfiguracyjnym i w bazie. Sprawdź ps_configuration (PS_SHOP_DOMAIN, PS_SHOP_DOMAIN_SSL, ustawienia serwisowe), ps_shop_url (domain, domain_ssl, physical_uri) oraz konta w ps_employee.
5. Płatności i kurierzy. Klucze API i adresy IPN/webhooków muszą wskazywać nowy adres, inaczej płatność wraca w pustkę. Bramkę testuj w sandboxie na stagingu, potem na produkcji. Zrób jedno zamówienie testowe i jedno z realną płatnością na symboliczną kwotę.
6. PHP i SSL. memory_limit 256–512M, max_execution_time 300 przy imporcie, włączony OPcache, wersja PHP zgodna z wybraną wersją PrestaShop. Certyfikat SSL wystawiony i wymuszony na całej domenie — mieszana treść psuje koszyk.
7. Przełączenie. Tryb serwisowy na starym sklepie (z wyjątkiem własnego IP), zmiana DNS przy wcześniej obniżonym TTL, restart PHP-FPM, wyczyszczenie cache w panelu i katalogu /var/cache, usunięcie plików instalacyjnych z produkcji.

SEO po migracji: mapowanie URL, przekierowania 301 i GSC

Najwięcej ruchu traci się nie na samym upgrade, a na zmianie adresów URL. Jeśli migrujesz hosting i struktura linków zostaje identyczna, przekierowania 301 nie są potrzebne — masowe dokładanie reguł to kolejne miejsce na błąd. 301 stosujesz przy zmianie domeny, platformy albo struktury kategorii. RFC 9110 przypomina, że 301 oznacza przeniesienie trwałe, a 302 tego nie przekazuje.

Przed migracją wyeksportuj zaindeksowane URL z Search Console (Indeksowanie → Strony → Eksport) i pobierz sitemap.xml ze starego sklepu. Połącz oba pliki w mapę stary → nowy adres i przygotuj reguły także dla parametrów GET: paginacji (?page=2), sortowania (?orderby=) i filtrów. Tu decydujesz świadomie: albo przekierowanie na wersję bazową adresu, albo zostawienie 200 z canonicalem — bez decyzji zostajesz z tysiącami zaindeksowanych wariantów.

Checklista testów przed startem – 14 punktów, których nie wolno pominąć

Testy robisz na stagingu — kopii sklepu z produkcyjną bazą i produktami, ale z wyłączonym indeksowaniem (hasło na katalogu, robots.txt, w PrestaShop dodatkowo wyłączone indeksowanie w ustawieniach SEO). Poniżej 14 punktów do odhaczenia po kolei.

• 1. Checkout z realną płatnością. Przelewy24 i BLIK za 1 zł — nie sandbox. Sprawdzasz webhooki, status zamówienia i fakturę z produkcyjnej serii numeracji.
• 2. Zwrot i anulowanie płatności. Czy status zamówienia wraca, czy stany magazynowe się cofają.
• 3. List przewozowy u każdego kuriera. InPost (Paczkomat, gabaryty A/B/C), DPD, DHL: numer nadawczy, waga, punkt odbioru na etykiecie.
• 4. Skrajne gabaryty. Produkt 120 cm i 0,5 kg — czy etykieta wychodzi bez błędu i bez dopłaty od kuriera.
• 5. Koszyk z kumulacją rabatów. Kupon procentowy plus rabat katalogowy jednocześnie: kolejność naliczania i kwota końcowa.
• 6. Darmowa dostawa od progu. Próg liczony przed rabatem czy po — inaczej klient traci promocję w koszyku.
• 7. B2B z cennikiem grupowym. Minimalna ilość, termin płatności, faktura z odroczoną datą, logowanie konta firmowego.
• 8. Podatki i waluty. Netto/brutto, VAT UE, zaokrąglenia przy zamówieniu na 5 pozycji.
• 9. Maile transakcyjne. Wysyłka przez SMTP, nie przez mail(). SPF i DKIM, test na Gmailu i Outlooku — czy nie wpada do spamu.
• 10. Faktury. Numeracja, NIP, PDF w załączniku, ponowne wysłanie do klienta z panelu.
• 11. Powiadomienia o statusach. Każdy krok zamówienia generuje maila po polsku, bez niewypełnionych zmiennych szablonu.
• 12. Wydajność. Zmierz LCP, INP, CLS i TTFB i porównaj ze starym sklepem — cel to wynik nie gorszy. Definicje metryk podaje dokumentacja Core Web Vitals.
• 13. Test mobilny. Koszyk, filtry, wyszukiwarka, BLIK i Przelewy24 na Androidzie i iPhonie.
• 14. Eksport zamówień. CSV lub ERP — zgodność kolumn, kodów produktów i stawek VAT.

Jeśli którykolwiek punkt wypada, nie przechodzisz na produkcję. Cały proces od audytu po wdrożenie rozkładamy na ścieżki w sekcji Migracje PrestaShop.

Ile trwa i ile kosztuje migracja PrestaShop – realne widełki

Wycena migracji zależy od trzech rzeczy: liczby modułów własnych, liczby kombinacji produktów i tego, czy zostajesz na PrestaShop. Poniżej widełki, które realnie widać w projektach.

Godziny rozbij na cztery bloki: audyt i inwentaryzacja (10–15%), praca na stagingu (40–45%), testy (20–25%), wdrożenie i bufor na niespodzianki (20%). Górna granica widełek bierze się z konkretów: moduł nieaktualizowany od trzech lat i brak zgodności z PHP 8.2, modyfikacje szablonu wpisane w pliki core, baza z 200 tys. zamówień, których nie przenosisz w całości.

Dlatego rozliczenie godzinowe jest uczciwsze niż ryczałt. Przy ryczałcie każda nieprzewidziana rzecz — np. moduł, który się nie kompiluje — kończy się aneksem albo cięciem jakości, a Ty nie wiesz, ile realnie zapłaciłeś. Przy godzinach widzisz, co wchodzi w zakres i gdzie możesz ciąć: przenieść do nowej bazy tylko 3 ostatnie lata zamówień, a starsze zostawić w archiwum CSV, albo odłożyć multistore na drugi etap. Sprawdzając ofertę, patrz, czy jest w niej osobna pozycja na testy — jej brak oznacza, że testy robisz na produkcji. Najczęstszy powód rozjazdu wyceny to lista modułów i ich zgodność z nową wersją; pomaga ją uporządkować materiał o tym, jak wybierać i wdrażać moduły PrestaShop.

Opieka po migracji – co powinno wejść w SLA

Migracja kończy się w momencie wdrożenia. Potem zaczyna się utrzymanie — i tu brak SLA kosztuje najwięcej, bo sklep stoi w środku dnia handlowego.

• Monitoring. Dostępność sprawdzana co minutę, TTFB, Core Web Vitals i log błędów PHP. Alert 24/7 na maila i SMS, nie dashboard, który ktoś otworzy w poniedziałek.
• Backupy. Codziennie baza i pliki, retencja 30 dni, raz na kwartał test odtworzenia na osobnym środowisku. „Mamy backup” bez testu odtworzenia to nie backup.
• Aktualizacje bezpieczeństwa. PrestaShop, PHP i moduły: okno serwisowe poza godzinami sprzedaży, kopia przed każdą zmianą i opisana procedura rollbacku. Skala zmian między wersjami jest udokumentowana w dokumentacji deweloperskiej PrestaShop.
• SLA z definicjami. Krytyczne to sklep bez zamówień, niedziałające płatności, biała strona. Zwykłe to literówka w mailu. Realny poziom: reakcja do 1 h, naprawa 4–8 h dla krytycznych, 2 dni robocze dla zwykłych.
• Dostęp do dewelopera. Osoba, która zna Twoje modyfikacje szablonu i moduły — nie ticket do call center, które pierwszy raz widzi Twoją instalację.

Przed podpisaniem umowy przejdź przez pięć pytań z tabeli. Jeśli dostawca nie umie na nie odpowiedzieć, to nie jest umowa utrzymaniowa. Model rozliczenia i stawki opisujemy w materiale o tym, jak wygląda praca w PrestaShop i godziny utrzymania sklepu.

Najczęstsze błędy i jak je wykryć

Lista kontrolna do odklikania

• Wersja PrestaShop — Sprawdź w panelu i w plikach (np. stała _PS_VERSION_ w config/settings.inc.php lub app/config). To punkt wyjścia dla każdej decyzji.
• Wersja PHP — Zapisz dokładną wersję i datę końca wsparcia. Jeśli hosting trzyma starą gałąź PHP, najpierw ustal, czy w ogóle da się ją podnieść.
• Wersja MySQL/MariaDB — Sprawdź w panelu hostingu i porównaj z wymaganiami docelowej wersji sklepu. Różnice w wersjach potrafią blokować upgrade.
• Silnik serwera (Apache, Nginx, LiteSpeed) — Sprawdź, czy sklep korzysta z .htaccess, czy z reguł Nginx. Po zmianie hostingu pliki konfiguracyjne trzeba napisać od nowa.
• Lista modułów z wersjami — Wyeksportuj wszystkie moduły i zaznacz, które pochodzą z oficjalnego katalogu, a które są własne lub porzucone.
• Modyfikacje plików core — Porównaj katalogi z czystą paczką tej samej wersji, np. przez diff. Każda zmiana w core to pozycja do osobnej decyzji: przenieść do override, przepisać w module czy porzucić.
• Nadpisania szablonu i child theme — Sprawdź, czy motyw nadpisuje szablony modułów i czy te nadpisania są kompatybilne z docelową wersją.
• Liczba produktów, kombinacji i kategorii — Zapisz liczby z bazy. To bezpośrednio przekłada się na czas importu i migracji danych.
• Liczba klientów i zamówień — Duża tabela zamówień wydłuża dump i import oraz utrudnia testowanie na stagingu bez anonimizacji danych.
• Czy działa multistore — Sprawdź liczbę sklepów w konfiguracji i czy dzielą one magazyn, cenniki i klientów. Multistore wyklucza prosty scenariusz 1-Click.
• Czy jest B2B z cennikami grupowymi — Zapisz liczbę grup klientów i typy rabatów. To logika, której nie da się przenieść automatycznie przy zmianie platformy.
• Konfiguracja płatności i kurierów — Wypisz aktywnych operatorów (np. Przelewy24, PayU, Stripe, tpay) oraz firmy kurierskie (InPost, DPD, DHL) i wersje ich modułów.
• Integracje z ERP i księgowością — Ustal, jakimi plikami lub API wymieniane są dane i kto odpowiada za połączenie po stronie systemu zewnętrznego.
• Mapa URL i dane z GSC — Wyeksportuj zaindeksowane adresy i te generujące kliknięcia. To lista obowiązkowa przy planowaniu przekierowań 301.

Najczęściej zadawane pytania

Źródła i materiały

• Google Search Central – tworzenie treści dla ludzi
• Google Search Central – dane strukturalne
• Google Search Central – Core Web Vitals
• RFC 9110 – HTTP Semantics
• PrestaShop – dokumentacja dla deweloperów