Migracja do PrestaShop najczęściej nie wywraca się na kodzie, tylko na organizacji: nie ma jednej listy danych do przeniesienia, nikt nie pilnuje przekierowań 301, a testy robi się na 20 produktach zamiast na całym katalogu. Ten tekst dotyczy właśnie strony projektowej: typowych błędów, kolejności prac i listy kontrolnej do odhaczenia przed startem. Jeśli dopiero wybierasz platformę, zacznij od przeglądu PrestaShop. Jeśli decyzja już zapadła, punktem startowym jest sekcja Migracje PrestaShop.
Migracja ma sens wtedy, gdy problemem jest model sprzedaży, a nie jedna wtyczka. Pięć sygnałów, które w praktyce pojawiają się najczęściej:
Trzy sygnały, że migracja nic nie da. Wolne działanie wynikające z hostingu — najpierw sprawdź RAM, liczbę workerów PHP i cache, bo to naprawia się w dni, nie w miesiące. Brak ruchu, bo to problem marketingowy, a nowa platforma nie przyprowadzi klientów. Brak osób do utrzymania systemu — PrestaShop wymaga aktualizacji i pilnowania zgodności modułów przy każdej zmianie wersji PHP.
Kryterium decyzyjne jest jedno: zestaw koszt migracji (wycena wdrożenia plus Twoje godziny na dane i testy) z kosztem pozostania na rok — suma abonamentów wtyczek, godzin wsparcia i kosztu przestojów. Jeśli pozostanie kosztuje mniej niż około 30% wartości migracji, nie zaczynaj projektu. Jeśli wciąż porównujesz platformy, punktem startowym jest przegląd PrestaShop.
Każda platforma źródłowa to inny scenariusz i inne ryzyko. Rozpoznaj swój przypadek, bo kolejność prac będzie inna.
WooCommerce → PrestaShop. Dane pobiera się przez bazę MySQL (wp_posts, wp_postmeta, wp_terms) albo przez REST API WooCommerce. REST jest bezpieczniejszy, ale przy 5000 produktów trzeba paginować po 100 rekordów i pilnować limitów zapytań. Warianty są w WooCommerce osobnymi produktami z meta _variation — mapowanie na kombinacje wymaga skryptu. Największa pułapka to adresy URL generowane przez wtyczkę SEO i unikalne meta typu _yoast_wpseo_title, które po imporcie trzeba odtworzyć ręcznie. Struktura endpointów jest opisana w dokumentacji WooCommerce.
Shoper / IdoSell → PrestaShop. Dane pobierasz eksportem XML/CSV z panelu lub przez API. Produkty, stany i kategorie przenoszą się dobrze. Historia zamówień i klienci — słabo; obie platformy nie oddają pełnych danych, więc często kończy się na otwartych zamówieniach i archiwum faktur w PDF.
Sklep autorski / legacy PHP → PrestaShop. Tu potrzebny jest dedykowany skrypt mapujący tabele źródłowe na ps_*. Ryzyko leży po stronie danych: brak walidacji, zduplikowane SKU, ceny zapisane w kilku formatach, brudne znaki w opisach.
Shopify → PrestaShop. Eksport CSV obejmuje products, customers i orders. Warianty i kolekcje nie przenoszą się 1:1, a dane płatności zostają po stronie Shopify — nie ma czego przenosić.
| Platforma źródłowa | Przenosi się w ~90% automatycznie | Wymaga mapowania | Odtworzyć ręcznie |
|---|---|---|---|
| WooCommerce | produkty proste, kategorie, stany magazynowe | warianty → kombinacje, klienci, zamówienia | meta SEO, reguły promocji, szablony e-mail |
| Shoper / IdoSell | produkty, stany, kategorie, zdjęcia | grupy cenowe, klienci | historia zamówień, opinie |
| Autorski / legacy PHP | zależy od schematu bazy źródłowej | praktycznie wszystkie pola | unikalna logika cen i rabatów |
| Shopify | produkty proste, klienci, zamówienia | warianty, kolekcje | dane płatności, aplikacje zewnętrzne |
Ta lista jest dokumentem, który wysyłasz zespołowi i wykonawcy. Bez niej import rozjedzie się już na drugim pliku.
Produkty i kombinacje. W PrestaShop wariant to kombinacja atrybutów (ps_product_attribute + ps_product_attribute_combination), a nie osobny produkt. Kolejność importu ma znaczenie: producenci i kategorie → atrybuty i wartości → produkty → kombinacje → zdjęcia → ceny i stany.
Klienci. Przeniesienie haseł jest możliwe tylko wtedy, gdy uda się przenieść hash w formacie zrozumiałym dla PrestaShop (np. bcrypt). Jeśli źródło używa innego mechanizmu, trzeba wymusić reset hasła: import kont z pustym hasłem, wysyłka maila resetującego, 2–3 przypomnienia w odstępach tygodniowych, komunikat na stronie głównej i w stopce. Nie wysyłaj całej bazy w jednym dniu — skrzynka nadawcy może zostać zablokowana.
Zamówienia i historia. Zdecyduj, czy przenosisz tylko zamówienia otwarte, czy całą historię. Pełna historia daje wygodę w panelu, ale wymaga zgodnych ID produktów, inaczej faktury i stany w ERP się rozjadą.
Reszta danych: stany magazynowe, ceny i grupy cenowe, kategorie, producenci, atrybuty, zdjęcia (mapowanie plików, konwersja do WebP, pilnowanie polskich znaków w nazwach plików).
Zostaje po starej stronie: opinie z zewnętrznych wtyczek, wpisy blogowe oparte na shortcode'ach, indywidualne reguły promocji, szablony e-mail. To odtwarza się ręcznie — zaplanuj na to osobne godziny.
Tabele, których dotyczy import: ps_product, ps_product_attribute, ps_category, ps_customer, ps_orders. Duplikacja powstaje najczęściej w ps_product (ponowny import bez referencji SKU), w ps_product_attribute (kombinacje bez produktu nadrzędnego) i w ps_customer (ten sam e-mail w dwóch rekordach). Schemat tabel znajdziesz w dokumentacji dla deweloperów PrestaShop, a szerszy opis kolejności prac w tekście o organizacji migracji sklepu PrestaShop.
Punkt startowy to pełny zrzut adresów URL ze starej platformy. Sama sitemap.xml nie wystarczy — zwykle nie ma w niej produktów wyłączonych, stron paginacji ani adresów z parametrami filtrów, które i tak zbierały ruch. Bierzemy więc dwa źródła: sitemapę oraz logi serwera z ostatnich 60–90 dni. Na pliku access.log wystarczy jedno polecenie, żeby wyciągnąć unikalne ścieżki, a wynik porównać z eksportem adresów z raportu „Strony” w Search Console.
Drugi krok to mapowanie 1:1 w jednym arkuszu. Kolumny: stary URL, nowy URL, decyzja (bez zmian / 301 / 410), priorytet, osoba odpowiedzialna, status wdrożenia, data testu. Wiersz bez nowego adresu i bez decyzji to zadanie niedokończone, a nie „do przemyślenia”.
| Typ adresu | Decyzja |
|---|---|
| Produkt przeniesiony | 301 na nowy URL produktu |
| Produkt wycofany z oferty | 410 albo 301 na pokrewną kategorię, jeśli produkt wróci |
| Kategoria | 301 na nową kategorię, ta sama ścieżka |
| Paginacja | bez zmian, jeśli struktura jest ta sama; inaczej 301 na pierwszą stronę |
| Filtry i sortowanie | 410 lub noindex, nigdy na stronę główną |
| Strona CMS | 301 na nową treść |
Kolejność działań: przekierowania wdrażamy przed startem nowego sklepu, aktualizujemy sitemapę XML, zgłaszamy ją w Search Console i pilnujemy ciągłości treści na najważniejszych stronach. Czego nie robić: masowych 301 na stronę główną (Google czyta to jak soft 404), łańcuchów A → B → C oraz przekierowań produktów na kategorie bez pokrewieństwa.
Błędy wyłapiesz crawlerem (Screaming Frog, Sitebulb) w trybie list mode — wrzucasz plik starych URL-i i sprawdzasz kody 200/301/404 oraz raport łańcuchów. Wersja darmowa obsłuży 500 adresów; przy katalogu 3000 SKU potrzebna licencja. Całą stronę organizacyjną projektu opisaliśmy w materiale migracja sklepu PrestaShop — organizacja bez chaosu. Jeśli jednocześnie zmieniasz wersję, zobacz migrację PrestaShop 1.7 do 9.
| Element mapy | Co wpisać w arkuszu |
|---|---|
| Stary URL | Pełna ścieżka, np. /buty-zimowe-42.html |
| Nowy URL | Docelowy adres w PrestaShop, sprawdzony na staging |
| Decyzja | bez zmian / 301 / 410 |
| Priorytet | Strony z ruchem i przychodem ze Search Console na pierwszym miejscu |
| Status | do wdrożenia / wdrożone / przetestowane |
Harmonogram poniżej dotyczy sklepu z katalogiem do kilku tysięcy SKU i standardowym zestawem integracji. Przy 20 000 produktów albo ERP po stronie klienta fazy 2 i 3 wydłużają się o tygodnie.
| Faza | Czas | Zakres |
|---|---|---|
| 0. Audyt i decyzje | 1–3 dni | Inwentarz: liczba SKU, kombinacji, klientów, zamówień, integracji; zakres i kryteria odbioru |
| 1. Środowisko | 1–2 dni | PHP zgodne z wymaganiami wersji, baza, SSL, cron, osobny staging na subdomenie z Basic Auth |
| 2. Import danych | 3–10 dni | Iteracyjny import na staging, mapowanie kolumn, poprawki, powtórzenia do skutku |
| 3. Integracje | 2–7 dni | Przelewy24, PayU, Stripe; InPost, DPD, DHL; fakturowanie; ERP |
| 4. Konfiguracja i UX | 2–5 dni | Szablon, metody dostawy, podatki, regulaminy, maile, zamówienia testowe end-to-end |
| 5. Start | 1 dzień | Publikacja, mapa 301, wyłączenie starego sklepu, przełączenie DNS przy niskim TTL |
| 6. Stabilizacja | 1–4 tygodnie | Monitoring, poprawki, obsługa zgłoszeń klientów |
Faza 0 decyduje o reszcie. Konkretne kryteria odbioru zapisane w umowie brzmią np. tak: 100% aktywnych produktów z ceną i stanem, 0 zamówień bez zmapowanej metody płatności, wszystkie maile transakcyjne przetestowane. Bez tego spór o „gotowość” rozstrzyga się po fakcie, na produkcji.
W fazie 1 sprawdź wymagania serwera, zanim kupisz hosting — wymagania PrestaShop dla serwera i PHP to najczęstsze źródło niespodzianek przy przenoszeniu na nową wersję. W fazie 3 realnie oszczędza czas gotowy moduł przewoźnika zamiast integracji pisanej pod klienta; o tym, jak to wygląda w praktyce, piszemy w materiale wysyłka w PrestaShop i WooCommerce. Szczegóły techniczne struktury bazy i modułów: dokumentacja dla deweloperów PrestaShop.
Poniższe problemy mają jedną wspólną cechę: wychodzą dopiero po starcie, choć sygnały ostrzegawcze są widoczne na staging tygodnie wcześniej. Kluczowe jest to, żeby każdą pułapkę miała przypisana jedna, powtarzalna metoda sprawdzenia — nie „rzucimy okiem”.
| Pułapka | Objaw | Jak wykryć |
|---|---|---|
| Duplikaty kombinacji przy ponownym imporcie | Liczba wariantów rośnie po każdym imporcie | Porównanie liczby rekordów w ps_product_attribute przed i po imporcie |
| Inne kodowanie znaków (UTF-8 vs latin2) | Krzaki w nazwach produktów i kategorii | Import próbki 50 produktów z polskimi znakami diakrytycznymi |
| Strefa czasowa i format daty | Zamówienia z innego dnia w raportach | Porównanie 10 zamówień sprzed migracji z ich datami po imporcie |
| Brak przeniesienia haseł klientów | Klienci nie mogą się zalogować | Test logowania na 5 kontach testowych; przygotowany automatyczny reset hasła |
| Metody dostawy i płatności nie pokrywają historii | Zamówienia z błędnym statusem | Raport „zamówienia bez zmapowanej metody” |
| Maile z linkami do starej domeny | Klienci trafiają na wygaszone strony | Wysyłka i odbiór 1 maila z każdego scenariusza: potwierdzenie, wysyłka, faktura, reset hasła |
Praktyczna zasada: każda z tych kontroli powinna być punktem na liście odbioru stagingu, z osobą odpowiedzialną i datą. Import wykonany „na sucho” bez sprawdzenia liczby rekordów to najdroższy typ oszczędności — poprawianie 4000 zdublowanych wariantów zajmuje więcej czasu niż sam import.
Dobrą praktyką jest też wykonanie pełnej kopii bazy przed każdym powtórzeniem importu, żeby móc wrócić do stanu sprzed 10 minut. Szerszy kontekst organizacyjny znajdziesz w sekcji Migracje PrestaShop, gdzie zbieramy materiały o kolejności prac i testach.
Migrację do PrestaShop rozliczamy w godzinach, nie w „podejściu do tematu”. Widełki poniżej zakładają, że klient dostarczył listę SKU, dostęp do bazy starego sklepu, lista integracji i informację, kto odpowiada za treści. Bez tego każda wycena jest zgadywaniem.
Godziny rozkładają się na sześć bloków:
Suma godzin w trzech typowych scenariuszach wygląda tak:
| Blok prac | Mały sklep (do 500 SKU, 2 integracje) | Średni (500–5000 SKU, 4–6 integracji) | Duży (5000+ SKU, multi-store, B2B, ERP) |
|---|---|---|---|
| Audyt i mapowanie danych | 8–16 h | 16–40 h | 40–80 h |
| Import danych | 12–24 h | 24–60 h | 60–160 h |
| Integracje | 8–16 h | 24–60 h | 80–200 h |
| Konfiguracja sklepu | 16–30 h | 30–60 h | 60–120 h |
| Testy | 8–16 h | 16–40 h | 40–100 h |
| Wdrożenie i 301 | 8–16 h | 16–32 h | 32–80 h |
| Razem | 60–118 h | 126–292 h | 312–740 h |
Start to nie koniec projektu. Pierwsze 30 dni rozstrzyga, czy spadek widoczności w Google będzie jednorazowym drgnięciem, czy problemem na kwartał.
Dzień 1–3. Puść crawla po starych i nowych adresach (Screaming Frog w wersji darmowej obsłuży 500 URL-i). Sprawdź, czy każdy stary URL zwraca 301 na swój odpowiednik, a nie na stronę główną – przekierowanie „wszystko na home” to najczęstszy błąd w tym miejscu. Osobno wyciągnij listę 404. W Search Console dodaj nową sitemap.xml i zajrzyj do raportu indeksowania. Zrób jedno zamówienie end-to-end: koszyk, płatność testowa i jedna prawdziwa (np. za 1 zł), mail potwierdzający, faktura, zmiana statusu, stan magazynowy, etykieta kurierska. Sprawdź, czy maile transakcyjne nie wpadają do spamu (SPF, DKIM). W tym samym czasie zweryfikuj konfigurację serwera – checklistę znajdziesz w zestawieniu PrestaShop system requirements: wymagania serwera i PHP.
Tydzień 1. Porównaj ten sam zakres dni z okresem przed migracją: ruch z Organic Search, konwersję, współczynnik odrzuceń i pozycje na 10–20 frazach, które dają najwięcej przychodu. Sprawdź też raport Core Web Vitals – jeśli LCP pogorszyło się po zmianie szablonu, widać to właśnie tutaj.
Tydzień 2–4. Logi serwera (access log) przefiltruj po kodzie 404, pogrupuj adresy i dodaj reguły 301 dla tych, do których prowadzą linki zewnętrzne. Poprawki w danych produktowych zbieraj w jednej liście – widać je przy pierwszych zamówieniach i w mailach do klienta.
Zakres migracji ustalany ustnie, bez jednego dokumentu
Jak wykryć: Zadaj dwa razy to samo pytanie — „co dokładnie przenosimy?” — dwóm osobom z zespołu. Jeśli odpowiedzi się różnią, zakres nie jest zamknięty.
Jak naprawić: Spisz mapę danych w jednym pliku: encja, źródło, sposób przeniesienia (automat / mapowanie / ręcznie), kto odbiera wynik. Ten dokument jest podstawą wyceny i odbioru prac.
Import produktów przed zaprojektowaniem modelu kombinacji
Jak wykryć: Po pierwszym imporcie otwórz listę produktów w PrestaShop. Jeśli zamiast jednego produktu z wariantami masz kilka osobnych pozycji, mapowanie atrybutów nie zostało ustalone.
Jak naprawić: Najpierw zdecyduj, które warianty ze źródła stają się kombinacjami, a które osobnymi produktami. Dopiero potem dopasuj do tego plik eksportu i importuj.
Praca bez środowiska testowego, importy na żywym sklepie
Jak wykryć: Sprawdź, czy ktokolwiek wykonuje import na kopii produkcyjnej bazy. Jeśli tak — nie masz stagingu, masz ryzyko zamiast testu.
Jak naprawić: Postaw kopię sklepu na osobnym hostingu lub subdomenie, z wyłączoną indeksacją i wyłączonymi płatnościami. Wszystkie importy i testy wykonuj tam.
Przekierowania 301 przygotowywane po przełączeniu domeny
Jak wykryć: Weź 20–30 najczęściej klikanych adresów ze starego sklepu i sprawdź, czy zwracają 301 na nowy adres, a nie 404. Zrób to przed startem, nie po.
Jak naprawić: Wyeksportuj adresy z Search Console i sitemap, przypisz im nowe adresy i przygotuj reguły przekierowań. Wdróż je razem ze zmianą DNS, nie tydzień później.
Przenoszenie haseł klientów bez sprawdzenia, jakim algorytmem są zapisane
Jak wykryć: Zajrzyj do tabeli klientów w źródłowej bazie. Jeśli hasła nie są zapisane algorytmem obsługiwanym przez PrestaShop, import nic nie da — klienci nie zalogują się.
Jak naprawić: Zaplanuj wymuszony reset hasła i osobny e-mail do klientów, wysłany po starcie, z krótkim wyjaśnieniem, dlaczego muszą ustawić nowe hasło.
Testy wyłącznie na wycinku danych
Jak wykryć: Zapytaj, na ilu produktach testowano import. Jeśli na 20, a produkcyjny katalog ma kilka tysięcy pozycji, testu wydajności nie było.
Jak naprawić: Importuj cały eksport na staging i zmierz czas importu oraz działanie katalogu, filtrów i koszyka. Dopiero potem planuj okno serwisowe.
Migracja do PrestaShop to przede wszystkim projekt organizacyjny: bez zamkniętego zakresu danych, środowiska testowego i mapy przekierowań 301 każdy błąd wychodzi dopiero po starcie, na żywym ruchu. Największe ryzyko nie leży w samym imporcie, tylko w elementach, które trzeba odtworzyć ręcznie i w decyzjach, których nikt nie zapisał — na przykład o historii zamówień czy o hasłach klientów. Zacznij od mapy danych i testu pełnego importu na stagingu, a dopiero potem ustalaj termin startu. Jeśli planujesz migrację z wersji 1.7, osobny materiał o organizacji znajdziesz tutaj: https://dropdigital.pl/migracja-prestashop-1-7-do-9
Nie ma jednej liczby, którą da się podać uczciwie. Czas zależy od liczby SKU, liczby kombinacji, wolumenu zamówień do przeniesienia i tego, ile elementów trzeba odtworzyć ręcznie. Sklep z kilkuset produktami prostymi i katalog z tysiącami wariantów to dwa różne projekty. Dlatego pierwszym etapem jest inwentaryzacja danych, a termin ustala się po niej, nie przed.
Tylko wtedy, gdy hasła w źródłowej bazie są zapisane algorytmem, który PrestaShop obsługuje w procesie logowania. W wielu sklepach na autorskich rozwiązaniach tak nie jest. Wtedy zostaje wymuszony reset hasła i e-mail do klientów z prostym wyjaśnieniem. To niewygodne, ale bezpieczniejsze niż przenoszenie haseł w sposób, którego nie da się zweryfikować.
To decyzja biznesowa, nie techniczna. Pełna historia bywa potrzebna przy zwrotach, reklamacjach i rozliczeniach, ale komplikuje integrację z ERP i księgowością. Część firm zostawia historię w archiwum po starym sklepie i przenosi wyłącznie zamówienia w toku. Wybierz jedną z opcji i zapisz ją w mapie danych, zanim ruszy import.
Zwykle krótkie okno serwisowe jest potrzebne, bo trzeba zamrozić zmiany w źródle i wykonać ostatni eksport danych. Długość przerwy zależy od tego, jak duży jest przyrost danych między ostatnim testem a startem. Zaplanuj okno w godzinach najniższego ruchu i poinformuj klientów wcześniej.
Sama zmiana platformy nie musi oznaczać spadku, ale brak mapy przekierowań 301 prawie zawsze kończy się utratą ruchu. Kluczowe jest to, żeby stare adresy prowadziły do nowych odpowiedników, a nie do strony głównej. Po starcie monitoruj 404 i indeksację w Search Console. Nie warto przy okazji migracji zmieniać całej struktury URL-i i treści — rozdziel te dwa projekty.
Nie zawsze, ale warto to sprawdzić przed startem, a nie po. Jeśli obecny serwer nie spełnia wymagań PrestaShop, migracja tylko przeniesie problem na nową platformę. Porównaj wersję PHP, MySQL oraz limity pamięci i czasu wykonania z wymaganiami: https://dropdigital.pl/prestashop-system-requirements
Od jednego dokumentu z mapą danych i jednego pytania: co przenosimy automatycznie, co wymaga mapowania, a co odtworzymy ręcznie. Dopiero potem sensowne jest planowanie środowiska testowego, harmonogramu i okna serwisowego. Kolejność prac w projektach migracyjnych opisujemy szerzej w materiale https://dropdigital.pl/migracja-sklepu-prestashop
Jeśli chcesz przejść przez migrację do PrestaShop bez zgadywania, możemy zacząć od inwentaryzacji danych i planu prac dopasowanego do Twojego katalogu. Napisz, z jakiej platformy migrujesz i ile masz produktów oraz wariantów — powiemy wprost, co da się przenieść automatycznie, a co trzeba odtworzyć.