Wdrożenia i migracje PrestaShop w Narolu — od czego zacząć

Ustal, w którym z trzech scenariuszy jesteś — od tego zależą godziny, ryzyko i kolejność prac.

• Nowy sklep od zera. Katalog do około 500 SKU, jeden kanał sprzedaży, brak ERP. Nie przenosimy niczego: nie ma mapowania URL-i ani historii zamówień. Cała praca idzie w konfigurację, treści i integracje.
• Sklep na starym CMS-ie (autorski CMS, osCommerce, PrestaShop 1.6). Typowe objawy: PHP w wersji poza wsparciem, brak aktualizacji bezpieczeństwa, baza z duplikatami SKU i pustymi produktami. Tu migracja jest zwykle pilna, bo zwłoka to realne ryzyko, nie tylko techniczny dług.
• Migracja z WooCommerce, Shoper lub IdoSell. Dane istnieją, ale trzeba je zmapować: kategorie, warianty, producentów, cechy, klientów, zamówienia. Im porządniejszy eksport, tym krótszy ten etap.

Wersje: nowe wdrożenia robimy na PrestaShop 8.x, bo to aktualna linia rozwojowa. Gałąź 1.7 nie jest już rozwijana, a wsparcie bezpieczeństwa dla niej zostało zakończone — migracja z 1.7 ma więc sens także wtedy, gdy nie zmieniasz niczego innego. Aktualny status wsparcia i wymagania PHP/MySQL sprawdź w dokumentacji dla deweloperów PrestaShop, bo zmieniają się przy każdym wydaniu.

Trzy kryteria decyzyjne. Liczba SKU: poniżej 500 — najpierw policz, czy obecna platforma nie wystarczy; 500–5000 — PrestaShop pracuje komfortowo, kluczowe są warianty i wydajność bazy; powyżej 5000 — dochodzi import, indeksy i zwykle zewnętrzny PIM albo ERP, bo ręczne zarządzanie katalogiem się kończy. Kanały sprzedaży: jeden sklep to jedno wdrożenie; sklep plus marketplace i porównywarki to już integracje i osobne testy. Obsługa B2B: grupy klientów, indywidualne cenniki, rabaty ilościowe, płatność odroczona i zamówienia na fakturę — jeśli tego brakuje w obecnym systemie, to zwykle główny powód przejścia na PrestaShop.

Jak wygląda ta sama organizacja projektu w mniejszym mieście, pokazujemy na przykładzie wdrożeń i migracji PrestaShop w Krasnobrodzie.

Wdrożenie nowego sklepu vs migracja — co wybrać w Twojej sytuacji

Obie ścieżki kończą się tym samym: działającym sklepem na PrestaShop 8.x. Różni je nakład pracy i ryzyko — poniżej konkretne liczby.

Migracja jest tańsza niż przepisanie od zera wtedy, gdy katalog ma wartość: setki opisów, zdjęcia, cechy, kategorie z historią i zaindeksowane adresy URL. Jeśli dane wychodzą z WooCommerce, Shopera albo IdoSell jako CSV lub XML, płacisz głównie za mapowanie i przeniesienie, a nie za odtwarzanie treści. Warunek: stara platforma pozwala wyeksportować klientów, zamówienia i stany magazynowe.

Przepisanie od zera wygrywa w dwóch przypadkach. Pierwszy: baza jest śmietnikiem — duplikaty SKU, brak EAN, tysiące produktów bez zdjęć i opisów. Czyszczenie takiego katalogu zajmie więcej niż ponowne wgranie danych. Drugi: struktura kategorii i URL-i jest tak chaotyczna, że lepiej zbudować ją od nowa i ręcznie przygotować mapę przekierowań na nowe adresy.

Sygnały, że obecna platforma blokuje rozwój: brak API (REST) do ERP albo magazynu, brak modułów do obsługi B2B i wielowalutowości, ręczne wystawianie faktur, wolne działanie na karcie produktu i w koszyku. Każdy z tych punktów oznacza pracę, której nie da się rozwiązać konfiguracją. Przy migracji kod odpowiedzi ma znaczenie: stare adresy muszą zwracać trwałe przekierowania, nie 404 — różnicę wyjaśnia dokumentacja MDN dotycząca HTTP, w tym kodu 301.

Jeśli szukasz punktu odniesienia dla większego rynku, zobacz nasze wdrożenia i migracje PrestaShop w Lublinie, a dla porównania projekt w mniejszym mieście: organizacja wdrożenia PrestaShop w Biłgoraju.

Proces wdrożenia PrestaShop krok po kroku — etapy i godziny

Poniżej rozkład prac dla sklepu do około 2000 SKU, jednego języka, jednej waluty, płatności online plus przelew i integracji z jednym systemem magazynowym. Widełki są szerokie, bo różnicę robi jakość danych wejściowych i liczba integracji.

• Discovery i analiza — 8–16 h. Warsztat: procesy zamówień, zwroty, faktury, magazyn, mapa obecnych URL-i. Klient: lista SKU z EAN i ceną zakupu, nazwa systemu magazynowego, dostępy do domeny i hostingu, wskazanie osoby decyzyjnej. Checkpoint 1: akceptacja zakresu i listy integracji.
• Konfiguracja sklepu — 16–40 h. Strefy podatkowe i stawki (w tym sprzedaż do UE), waluty, języki, kurierzy z cennikami i progami darmowej dostawy, płatności, grupy klientów B2B, e-maile transakcyjne przez SMTP, Ustawienia zaawansowane > Wydajność (CCC, cache), SSL, kopie zapasowe, robots.txt. Klient: regulamin, polityka prywatności, dane do płatności i kurierów. Checkpoint 2: sklep działa w wersji testowej.
• Szablon i UI — 24–80 h. Gotowy motyw z Addons kontra projekt custom, child theme, strona główna, karta produktu, koszyk, checkout, mobile. Klient: zdjęcia, opisy, logotyp, decyzje o układzie. Checkpoint 3: akceptacja widoku na urządzeniach mobilnych.
• Integracje — 16–60 h. ERP lub magazyn, broker wysyłek, marketplace, księgowość; stany, ceny, zamówienia, kolejność synchronizacji i obsługa błędów. Klient: dostępy, dane testowe, osoba kontaktowa od systemu zewnętrznego. Checkpoint 4: jedno zamówienie testowe przechodzi pełną ścieżkę.
• Migracja danych — 8–40 h. Eksport CSV/XML, mapowanie kolumn, import przez Zaawansowane > Import, kombinacje, zdjęcia, klienci (hasła wymagają resetu), zamówienia historyczne, mapa przekierowań 301. Checkpoint 5: zgodność liczby produktów i stanów.
• Testy i odbiór — 8–24 h. Checklista 60–100 przypadków, zamówienia w piaskownicy płatności, e-maile, faktury, wydajność, przekierowania, 404, walidacja danych strukturalnych (typy produktowe są wymienione na liście danych strukturalnych obsługiwanych przez Google). Checkpoint 6: podpisany odbiór i 2–4 tygodnie monitoringu w Search Console.

Łącznie typowy projekt to 80–260 roboczogodzin. Jeśli oferta mówi o 30–40 godzinach na pełny sklep, zapytaj, czego w niej nie ma — najczęściej wypadają testy, e-maile transakcyjne, konfiguracja podatków, mapa 301 i dane strukturalne. Przykład podobnego rozkładu prac w innym mieście: organizacja wdrożenia PrestaShop w Józefowie.

Migracja ze starej platformy — co przenosi się samo, a co trzeba przepisać

Najczęstsze złudzenie przy migracji do PrestaShop brzmi: „to się po prostu przekopiuje”. Nie przekopiuje się. Zaczynamy od inwentaryzacji: ile SKU, ile kombinacji, ile zamówień, ile podstron CMS. Dopiero potem wybieramy kanał przenoszenia — eksport z bazy źródłowej do CSV (szybko i tanio, gdy mamy dostęp do bazy albo eksportu w panelu) albo API sklepu źródłowego (wolniej, ale gdy baza jest zamknięta na hostingu współdzielonym, to jedyna droga).

Integracje, które decydują o tym, czy sklep działa: InPost, DPD, DHL, ERP, płatności

Najwięcej problemów po starcie nie wynika z samego PrestaShop, a z integracji. Dlatego planujemy je w pierwszym tygodniu projektu, nie w ostatnim. Każda integracja ma trzy elementy do przetestowania: wystawienie danych, pobranie danych z powrotem i zachowanie przy błędzie.

• InPost ShipX — generowanie etykiet (Paczkomaty 24/7, kurier, punkty InPost), widget mapy na stronie koszyka do wyboru punktu, tracking po statusie „Wysłane”. Testujemy na koncie przedprodukcyjnym, bo etykieta wystawiona testowo kosztuje, jeśli poleci na prawdziwą przesyłkę.
• DPD (WebAPI) — etykiety PDF i Zebra, punkty DPD Pickup, powrót numeru przesyłki do zamówienia.
• DHL24 (WebAPI) dla przesyłek krajowych, DHL Parcel dla zagranicy, automaty DHL BOX 24/7.

W rejonie Narola liczba punktów odbioru w promieniu kilkunastu kilometrów bywa mała — nie zakładamy tego z góry, tylko sprawdzamy realną listę punktów zwracaną przez API i testujemy widget na telefonie. Jeśli mapa ładuje się wolno, klient rezygnuje z koszyka.

Płatności: Przelewy24, PayU, Autopay — wymagają umowy i weryfikacji sklepu (regulamin, polityka prywatności, dane firmy, działający SSL). Czas akceptacji zależy od operatora i kompletności dokumentów, więc wniosek składamy równolegle z pracami, nie po nich. BLIK obsługujemy przez operatora płatności — osobna integracja zwykle nie ma sensu. Płatności odroczone (np. PayPo) podnoszą konwersję koszyka, ale mają wyższą prowizję, dłuższą akceptację i wymagają zapisów w regulaminie.

ERP (Subiekt GT/nexo, Comarch, WAPRO): stany co 5–15 minut, zamówienia co 15–60 minut albo webhookiem, dokument sprzedaży i numer przesyłki z powrotem do ERP. Konflikt numer jeden to brak rezerwacji w ERP — rozwiązaniem jest bufor stanu 1–2 szt. albo rezerwacja po stronie sklepu. Własny moduł piszemy wtedy, gdy roczna licencja wtyczki plus czas na obejścia przekracza w 1–2 lata koszt napisania i utrzymania modułu.

Ile realnie kosztuje wdrożenie PrestaShop — widełki godzinowe

Widełki są po to, żeby porównywać oferty w tych samych jednostkach — godzinach, a nie „pakietach”. Poniżej zakresy, które w praktyce pokrywają większość projektów. Górna granica widełek to nie straszak, a miejsce na rzeczy, których nie widać przed zajrzeniem do bazy danych.

SEO techniczne i przekierowania 301 — jak nie stracić pozycji przy migracji

Mapowanie starych adresów na nowe to pierwszy dokument w projekcie — powinien powstać, zanim ruszy kodowanie szablonu. Zbierz dane z dwóch źródeł: logów serwera (access_log z ostatnich 90 dni) i Search Console (Wydajność → Wyniki wyszukiwania → zakładka Strony). Z logów wyciągnij ścieżki zwracające kod 200 i policz wejścia; z GSC adresy z klikami i wyświetleniami. Po scaleniu masz arkusz: stary URL, ruch miesięczny, nowy URL, typ (produkt, kategoria, strona CMS), reguła.

Przykład reguł w .htaccess dla PrestaShop 1.7/8.x — na górze pliku, po RewriteEngine On i RewriteBase /:

RewriteRule ^stara-kategoria/(.*)$ /nowa-kategoria/$1 [R=301,L]
RewriteRule ^stary-produkt\.html$ /nowa-kategoria/nowy-produkt.html [R=301,L]
RedirectPermanent /stara-strona-cms.html /nowa-strona-cms.html

Trzy pułapki. Pierwsza: pętla — jeśli wzorzec starego adresu nadal pasuje do nowego URL-a, przekierowanie zawraca i przeglądarka pokazuje „zbyt wiele przekierowań”. Testuj każdą regułę pojedynczo. Druga: 301 zapamiętują przeglądarki i Google, więc najpierw sprawdź całość jako 302 na stagingu, dopiero potem włącz 301 na produkcji. Trzecia: AllowOverride All i aktywny mod_rewrite — bez tego reguły milczą, a ty szukasz błędu w składni. Semantykę kodów przekierowania opisuje dokumentacja HTTP w MDN.

Kolejność po starcie: 1) przekierowania 301 razem ze zmianą DNS, 2) canonical — tylko self-referencing, 3) meta title i description z nowych szablonów, 4) sitemap.xml z nowymi adresami i robots.txt bez blokady stagingu, 5) kontrola raportu „Strony” w GSC po 7 i 30 dniach.

Parametry /id_product i /id_category możesz zostawić (mniej pracy, dłuższe adresy) albo wyłączyć w Preferencje → SEO i URL i budować czyste URL-e. Przy migracji z innego CMS-a mapowanie i tak robisz od zera, więc warto ciąć. Przy przejściu PrestaShop → PrestaShop z 20 000 SKU zostawienie ID oszczędza tygodnie pracy. Harmonogram takich prac opisaliśmy przy organizacji wdrożenia PrestaShop w Bełżcu.

Hosting, wydajność i opieka po starcie — SLA, kopie, aktualizacje

Hosting współdzielony wystarcza, gdy sklep ma do około 1000 SKU, do 10 000 wizyt miesięcznie i 1–3 osoby obsługi, a synchronizacja z hurtownią chodzi raz na godzinę. Powyżej tego progu bolą limity: jednoczesne połączenia MySQL, CPU na koncie, brak kontroli nad PHP-FPM. Wtedy VPS — minimum 2 vCPU, 4 GB RAM, dysk NVMe. Liczba workerów PHP-FPM to zwykle 2 × vCPU + 2, czyli przy 4 vCPU celuj w 10 procesów, nie w 40: nadmiar workerów przy zbyt małym RAM kończy się swapem i sklepem wolniejszym niż na hostingu współdzielonym. innodb_buffer_pool_size ustaw na 50–70% RAM. Serwer dedykowany ma sens przy 50 000+ SKU, katalogu synchronizowanym co kilka minut i ruchu ponad 100 000 wizyt miesięcznie.

Kopie: pełny backup bazy i plików codziennie, w innym miejscu niż produkcja (inny dostawca lub S3). Retencja: 7 kopii dziennych, 4 tygodniowe, 3 miesięczne. Raz na kwartał odtwarzasz kopię na stagingu i mierzysz czas. Cel: RPO 24 h, RTO poniżej 4 h. Backup, którego nikt nie odtworzył, to nie backup, a nadzieja.

Po starcie zostają aktualizacje. PrestaShop i moduły aktualizuj partiami po 3–5, nigdy wszystkie naraz w piątek. Testy na stagingu z kopią danych produkcyjnych (zanonimizowanych), okno serwisowe poza szczytem sprzedaży — np. wtorek 2:00–4:00, z włączonym trybem maintenance. Po każdej aktualizacji przechodzisz ścieżkę: koszyk → zamówienie → płatność → mail potwierdzający → faktura → stan magazynowy. Zakres opieki warto ustalić na piśmie, podobnie jak przy organizacji projektu wdrożenia PrestaShop w Lublinie.

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

Lista kontrolna do odklikania

• Inwentaryzacja SKU i kombinacji — Zrób eksport liczby produktów oraz kombinacji atrybutów — dopiero to pokazuje, czy projekt zamknie się w 120 h, czy wymknie poza 300 h.
• Lista kanałów sprzedaży — Wypisz, gdzie dziś sprzedajesz: sklep, marketplace, B2B, stacjonarnie. Każdy dodatkowy kanał to osobna integracja i osobne testy.
• Wersja PrestaShop i wymagania hostingu — Ustal docelową gałąź (8.x) i sprawdź, czy hosting spełnia wymagania PHP oraz bazy. Jeśli działasz na 1.7, potraktuj to jako powód do migracji w perspektywie miesięcy, nie lat — dokładny status wsparcia wersji weryfikuj w dokumentacji deweloperskiej PrestaShop.
• Dostępy do starego sklepu i infrastruktury — FTP/SSH, panel bazy danych, panel DNS, konto administratora w starym sklepie, eksport z ERP — wszystkie z terminem przekazania, najlepiej przed pierwszym spotkaniem projektowym.
• Mapa przekierowań 301 — Przygotuj plik stary URL → nowy URL na podstawie sitemap.xml i danych z Google Search Console. Zweryfikuj ją przed przełączeniem domeny.
• Decyzja o hasłach klientów — Sprawdź, czy platforma źródłowa pozwala wyeksportować hashe haseł. Jeśli nie, zaplanuj wymuszony reset i komunikację do kupujących na 3–5 dni przed startem.
• Lista integracji kurierskich — InPost ShipX, DPD, DHL — dla każdej ustal, czy potrzebujesz generowania etykiet, tracking numerów i mapy punktów odbioru. W mniejszych miejscowościach mapa paczkomatów realnie wpływa na konwersję.
• Lista operatorów płatności — Przelewy24, PayU, Autopay, BLIK, płatności odroczone — sprawdź wymagania formalne i czas akceptacji wniosku, bo to często wąskie gardło niezależne od wykonawcy.
• Konta sandbox u dostawców — Zamów środowiska testowe u kurierów i operatorów płatności przed etapem integracji — bez nich testy końcowe nie mają czego sprawdzać.
• Backup starego sklepu i bazy — Pełny zrzut plików i bazy wykonaj w dniu poprzedzającym przełączenie i trzymaj go przez co najmniej 30 dni po starcie nowego sklepu.
• Punkty kontrolne akceptacji etapu — Ustal z wykonawcą 4–6 checkpointów (konfiguracja, szablon, integracje, migracja danych, testy) — każdy z pisemną akceptacją, zanim ruszy kolejny etap.
• Plan testów odbiorczych — Jedno zamówienie testowe end-to-end: koszyk, płatność, etykieta kurierska, faktura, mail do klienta, aktualizacja stanu magazynowego. Każdy element podpisany przez klienta.
• Monitoring po wdrożeniu — Ustaw sprawdzanie błędów 404, działania koszyka i płatności na pierwsze 14 dni. Dodatkowo śledź Core Web Vitals, żeby wychwycić regresję wydajności po przeniesieniu.
• Dane strukturalne po migracji — Sprawdź, czy produkty, ceny i dostępność nadal mają poprawne znaczniki. Pomocna jest lista typów obsługiwanych przez Google: dane strukturalne wspierane w wyszukiwarce.

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
• PrestaShop – dokumentacja dla deweloperów
• MDN Web Docs – HTTP