Organizacja wdrożenia PrestaShop w Szczebrzeszynie sprowadza się do trzech rzeczy: kto podejmuje decyzje, na jakich etapach odbieracie pracę i co dokładnie dostarczacie ze swojej strony. Sklep, nawet dobrze skonfigurowany, nie wystartuje w terminie, jeśli brakuje treści, zdjęć, stanów magazynowych i osoby, która powie „tak” bez czekania na zarząd. Poniżej znajdziesz listę błędów organizacyjnych, checklistę i odpowiedzi na pytania, które najczęściej padają na pierwszym spotkaniu. Nie ma tu obietnic typu „sklep w tydzień” — realny czas zależy od liczby produktów, integracji i tempa decyzji po stronie firmy.
Wdrożenie i migracja to dwie różne prace, choć w ofertach wyglądają podobnie. Wdrożenie to budowa sklepu od zera: instalacja PrestaShop 8.x, konfiguracja kategorii, atrybutów, płatności, wysyłek i szablonu, a katalog wprowadzacie Wy z arkusza albo my z Waszego pliku. Migracja to przeniesienie działającego sklepu — z WooCommerce, Shoper, Magento, IdoSell lub starego PrestaShop 1.6 — razem z produktami, klientami, zamówieniami i adresami URL.
Kryteria wyboru są cztery i da się je policzyć przed pierwszym spotkaniem:
Kiedy WooCommerce wygrywa: mały katalog, sklep przy blogu, treści jako główny kanał ruchu, zespół już obsługuje WordPressa. Kiedy PrestaShop: duży katalog, sprzedaż B2B, multistore, kilka magazynów.
Najczęstsza pułapka migracji to hasła klientów — hashe z WooCommerce czy Magento nie przenoszą się 1:1, więc trzeba wysłać reset hasła do bazy klientów. Druga to adresy URL: bez mapy przekierowań 301 tracicie pozycje z setek podstron. Zanim wybierzecie kierunek, zaplanujcie organizację wdrożenia PrestaShop w Szczebrzeszynie — kto decyduje i kto dostarcza dane. Dokumentację techniczną wersji 8.x znajdziecie w dokumentacji dla deweloperów PrestaShop.
Widełki opierają się na godzinach, nie na pakietach. Stawka rynkowa w Polsce to 120–250 zł netto za godzinę: 120–150 zł to prace wdrożeniowe i konfiguracja, 180–250 zł to własne moduły, integracje ERP i optymalizacja wydajności. Każda wycena bez liczby godzin jest wróżeniem z fusów.
| Zakres | Godziny | Koszt netto (160 zł/h) |
|---|---|---|
| Prosty sklep B2C do 300 SKU | 40–80 h | 6 400–12 800 zł |
| Migracja z WooCommerce do 1500 SKU | 60–150 h | 9 600–24 000 zł |
| Migracja z Magento lub Shoper | 80–200 h | 12 800–32 000 zł |
| Integracja ERP (gotowy moduł) | +10–40 h | +1 600–6 400 zł |
| Wielojęzyczność lub B2B | +20–60 h | +3 200–9 600 zł |
Typowy podział godzin w projekcie: analiza i dokumentacja 8–16 h, konfiguracja sklepu 20–40 h, migracja danych 15–50 h, integracje 10–40 h, testy 10–20 h, start i pierwsze 30 dni opieki 5–15 h. Testy to nie forma grzeczności — to etap, na którym wyłapuje się błędy w stawkach VAT i regułach wysyłki.
Co podnosi koszt: własne moduły (np. konfigurator produktu na wymiar), nietypowe ERP bez gotowego łącznika, każdy dodatkowy język (tłumaczenia plus konfiguracja), rejestracja B2B z akceptacją konta, integracja z kilkoma magazynami i płatnościami ratalnymi.
Przykład z życia: sklep B2C, 800 SKU, migracja z WooCommerce, łącznik z Subiektem GT, jeden język. Realnie 100–120 h, czyli 16 000–19 200 zł netto przy 160 zł/h. Poza godzinami dochodzą: hosting 300–800 zł rocznie, szablon 300–1500 zł jednorazowo, moduły płatności i kurierów 0–1500 zł. Szczegółowy cennik i organizacja migracji PrestaShop pokazują, jak rozbić te kwoty na etapy.
Proces, który się nie rozjeżdża, ma sześć etapów i odbiór po każdym z nich.
Rola klienta jest tu większa, niż się wydaje. Potrzebna jest jedna osoba z prawem decyzji o cenach, stanach, procesach i treściach — bez czekania na zarząd przy każdym produkcie. Jeśli tej osoby nie ma, etap 3 i 4 stoją. Zasady współpracy i podział obowiązków opisaliśmy w artykule o organizacji wdrożenia PrestaShop dla firmy.
Wydajność sprawdzaj przed startem, nie po kampanii: wytyczne Core Web Vitals to konkretne progi dla LCP, INP i CLS, które łatwiej poprawić na stagingu niż na żywym ruchu.
Migracja to nie „przepisanie produktów”. W PrestaShop dane siedzą w kilkudziesięciu tabelach i trzeba przenieść je w całości: ps_product, ps_category, ps_customer, ps_orders, ps_order_detail, ps_stock_available, a przy fakturach — ps_order_invoice. Przy 3 000 SKU i 8 000 klientów sam eksport i import to 2–4 godziny pracy, ale czyszczenie danych (duplikaty atrybutów, kategorie bez produktów, produkty bez zdjęć, opisy z Worda) zajmuje drugie tyle.
Kolejność jest sztywna. Najpierw kopia bazy na staging, potem zachowanie tych samych ID produktów i kategorii — bez tego nie zbudujesz poprawnej mapy 301. Mapę generujesz ze starych URL-i (produkt, kategoria, CMS, blog, stare linki z indeksu) na nowe. Wdrażasz ją w .htaccess jako Redirect 301 albo w module, jeśli przekierowań jest więcej niż kilkaset i potrzebujesz je raportować. Sprawdź to narzędziem do testowania nagłówków HTTP — przekierowanie musi zwracać dokładnie 301, nie 302. Stronę 404 ustaw tak, żeby prowadziła do kategorii i wyszukiwarki, a nie do pustego komunikatu.
Najczęstsza pułapka: przeniesienie tylko produktów. Klienci tracą historię zamówień, program lojalnościowy i możliwość ponowienia zakupu, a Ty — dane do statystyk i reklamacji. Hasła klientów są solone, więc kopiuj tabelę ps_customer, nie importuj CSV — po imporcie CSV każde konto wymaga resetu hasła. Praktyczne ramy organizacyjne opisujemy w tekście o organizacji wdrożenia PrestaShop w Szczebrzeszynie.
| Dane | Gdzie w PrestaShop | Uwaga przy migracji |
|---|---|---|
| Produkty i kombinacje | ps_product, ps_product_attribute | Zachowaj ID — od nich zależy mapa 301 |
| Klienci | ps_customer | Hash hasła z solą; CSV wymusza reset haseł |
| Zamówienia i faktury | ps_orders, ps_order_invoice | Ciągła numeracja, dokumenty historyczne |
| Stany magazynowe | ps_stock_available | Ustal jedno źródło prawdy: sklep albo ERP |
Integracje to miejsce, w którym „gotowa wtyczka” najczęściej się kończy. Zanim cokolwiek podłączysz, ustal jedno: co jest źródłem prawdy. Dla stanów i cen zwykle jest nim ERP — Subiekt GT/nexo, Comarch Optima, ERP24 albo WMS. PrestaShop odpowiada wtedy za treść, zdjęcia i sprzedaż, a nie za stany.
Każdy z tych systemów wymaga innego podejścia: Subiekt potrzebuje Sfery i serwera Windows, Optima — API lub dostępu do bazy, ERP24 — REST-a. Sensowny rytm to stany co 10–15 minut i ceny raz na dobę, z kolejką i logiem błędów, żeby jedna nieudana synchronizacja nie zatrzymała sprzedaży. Zasada: integracja musi być idempotentna, czyli powtórne wysłanie tego samego zamówienia nie tworzy duplikatu dokumentu w ERP.
Płatności (Przelewy24, PayU, tpay, Stripe, BLIK) podłączasz razem z mapowaniem statusów — musi istnieć jasna ścieżka: płatność zaksięgowana → status „opłacone” → faktura → etykieta. Kurierzy to InPost Paczkomaty (ShipX API + widget wyboru paczkomatu w koszyku), DPD i DHL. Samo generowanie etykiet to minimum; liczy się jeszcze przekazywanie statusów przesyłek do klienta i obsługa zwrotów.
Własny moduł bywa tańszy niż wtyczka z abonamentem. Policz: 250 zł miesięcznie przez 24 miesiące to 6 000 zł. Jeśli nietypowe mapowanie (cenniki B2B, jednostki, zestawy, kilku magazynów) wymusza i tak pisanie logiki na zamówienie, płacenie abonamentu to podwójny koszt. Punktem wyjścia do takiej kalkulacji jest zestawienie kosztów wdrożenia i migracji PrestaShop — łatwiej porównywać liczbami niż wrażeniami.
Testy przed startem: 10–15 scenariuszy, w tym płatność odrzucona, koszyk porzucony, zamówienie na dwa magazyny, zwrot, anulowanie i ponowne nadanie etykiety. Dokumentację techniczną modułów i hooków znajdziesz w dokumentacji deweloperskiej PrestaShop.
| Obszar | Typowe rozwiązanie | Kiedy własny moduł |
|---|---|---|
| ERP | Subiekt, Optima, ERP24, WMS — API lub baza | Nietypowe mapowanie cen i stanów, wiele magazynów |
| Płatności | Przelewy24, PayU, tpay, Stripe, BLIK | Rzadko; wyjątkiem rozliczenia B2B i odroczone terminy |
| Kurierzy | InPost ShipX, DPD, DHL | Gdy potrzebujesz etykiet zbiorczych i własnych reguł gabarytów |
PrestaShop 8.x wymaga PHP 8.1+ oraz MySQL 8 albo MariaDB 10.5+. Jeśli siedzisz na 1.7.8, pamiętaj, że część modułów nie działa poprawnie na PHP 8.x — aktualizację planuj razem z migracją, nie po niej. Do tego Redis lub Memcached na cache, poprawnie wdrożony SSL, działające crony (maile, synchronizacje, backup) i kopia zapasowa raz na dobę trzymana poza serwerem.
Hosting współdzielony wystarczy na start, ale tylko do pewnego progu. Sygnały, że czas na VPS: TTFB przekracza 600–800 ms przy normalnym ruchu, nie możesz ustawić cronów częściej niż raz na godzinę, brak dostępu do Redisa, a w panelu widzisz przekroczone limity procesów albo inode. Przy katalogu 1 000+ SKU i kilkudziesięciu modułach realne minimum to 4 vCPU, 8 GB RAM i dysk NVMe, z PHP-FPM i włączonym OPcache. Praktyczna reguła: liczba workerów PHP-FPM to około dwa razy liczba vCPU.
Wydajność ma bezpośredni związek z widocznością w Google — opóźnienia i przesunięcia układu strony opisuje dokumentacja Core Web Vitals. Zmierz się przed startem, a nie po kampanii, bo wtedy nie wiadomo, co było przyczyną spadku konwersji.
Pułapka: tani hosting za kilkadziesiąt złotych rocznie i brak ścieżki skalowania. W dniu wyprzedaży albo wysyłki newslettera do 20 000 odbiorców sklep po prostu przewraca się, a przeniesienie infrastruktury w trakcie kampanii jest droższe niż dobry serwer przez rok. Sposób ułożenia takich decyzji w projekcie opisujemy przy okazji organizacji migracji PrestaShop w Chełmie.
| Element | Minimum | Zalecane przy 1 000+ SKU |
|---|---|---|
| PHP | 8.1+ z OPcache | 8.2/8.3 po sprawdzeniu modułów |
| Baza danych | MySQL 8 / MariaDB 10.5+ | osobny serwer lub zarządzana baza |
| Cache | opcjonalnie | Redis lub Memcached |
| Serwer | hosting współdzielony | VPS 4 vCPU / 8 GB RAM, NVMe |
| Backup | raz na dobę | dzienny + offsite + test odtworzenia |
Pierwsze 30 dni po starcie nie służą do poprawiania wyglądu. Służą trzem rzeczom: zgłoszeniu sklepu do Google, sprawdzeniu, że nic nie blokuje indeksacji, i skróceniu czasu ładowania na telefonie.
Tydzień 1 — widoczność. Konfiguracja Google Search Console (property domenowa, weryfikacja rekordem DNS TXT) i GA4 przez Google Tag Manager. W GA4 włączone zdarzenia e-commerce: view_item, add_to_cart, purchase. Bez nich nie wiesz, który kanał realnie sprzedaje. Do Search Console wysyłasz plik sitemap.xml — w PrestaShop generuje go moduł gSitemap. Jeśli sitemap zawiera setki adresów z parametrami filtrów, najpierw je wycinasz. Sprawdź robots.txt: ma blokować panel administracyjny, koszyk, zamówienie i parametry fasetowe, ale nie katalogi produktów. Testuj przez narzędzie „Sprawdzenie robots.txt” w Search Console.
Tydzień 2–3 — indeksacja. W raporcie „Indeksowanie stron” patrz na dwie liczby: ile adresów jest zaindeksowanych i ile ma status „Wykluczono”. Pierwsze indeksacje nowej domeny to zwykle 3–14 dni, pełne pokrycie katalogu 4–8 tygodni. W tym czasie pilnujesz przekierowań 301 z mapy URL i wykluczasz przez noindex puste kategorie oraz wyniki wyszukiwarki wewnętrznej.
Tydzień 3–4 — szybkość. Cel dla 75. percentyla użytkowników: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — definicje i progi Core Web Vitals opisuje dokumentacja Google. W praktyce: zdjęcia w WebP po 120–200 KB, wymiary zgodne z tym, co widać na ekranie, obraz LCP bez lazy loadingu, cache Smarty i cache pełnostronicowy, Redis lub Memcached na obiekty, CDN dla statyki. Na koniec treści kategorii: 100–200 słów unikalnego tekstu plus 3–5 linków do produktów i poradnika. Koszt i organizacja wdrożenia PrestaShop to dobry punkt startu, jeśli chcesz zaplanować te prace w budżecie.
Wdrożenie kończy się w dniu startu. Sklep bez ustalonego SLA po pół roku zbiera 30 zaległych aktualizacji i zatrzymuje się na pierwszym błędzie płatności w szczycie sezonu.
Zanim podpiszesz umowę na opiekę, ustal cztery parametry: czas reakcji, czas naprawy, kanał zgłoszeń i godziny wsparcia. Czas reakcji to potwierdzenie przyjęcia zgłoszenia przez człowieka, nie autoresponder. Czas naprawy to moment, w którym sklep znów działa. To dwie różne liczby i obie muszą być w umowie.
Zakres opieki — minimum: aktualizacje rdzenia PrestaShop i modułów w oknie serwisowym (przy major update najpierw staging), backupy: baza codziennie, pełne pliki raz w tygodniu, retencja 14–30 dni, raz na kwartał test odtworzenia kopii. Bezpieczeństwo: 2FA do panelu, zmieniony adres panelu, WAF, limit prób logowania. Monitoring dostępności co 1–5 minut z alertem na maila i SMS oraz alert o wygasającym certyfikacie SSL 30 dni wcześniej. Drobne zmiany: 2–4 godziny miesięcznie z przenoszeniem niewykorzystanych godzin na kolejny miesiąc.
Bezpośredni kontakt z deweloperem. Zapytaj wprost, kto zaloguje się na serwer po awarii. Jeśli zgłoszenie wędruje od account managera do podwykonawcy, czas reakcji rośnie dwukrotnie, a Ty płacisz za pośrednictwo. Wymagaj dostępu do środowiska testowego, repozytorium i krótkiej dokumentacji konfiguracji. Jak wygląda podział zadań po stronie firmy, opisaliśmy na przykładzie organizacji wdrożenia PrestaShop w Chełmie.
| Priorytet | Przykład zdarzenia | Czas reakcji | Czas naprawy |
|---|---|---|---|
| P1 krytyczny | Sklep nie działa, płatność odrzuca zamówienia | 30–60 min | 4–8 h w godzinach wsparcia |
| P2 wysoki | Błąd dodawania do koszyka, brak maili z zamówieniem | 4 h | 1 dzień roboczy |
| P3 normalny | Błąd w opisie, literówka, poprawka w treści | 1 dzień | 3–5 dni roboczych |
| Zmiana rozwojowa | Nowy moduł, integracja, zmiana szablonu | 2 dni | według odrębnej wyceny |
Cztery punkty, każdy z konkretnym dowodem. Jeśli którykolwiek jest nieodhaczony, przesuwasz start — tańsze niż odtwarzanie sklepu po awarii.
Kolejność działań i podział odpowiedzialności w projekcie rozpisaliśmy w tekście o organizacji wdrożenia PrestaShop w Szczebrzeszynie.
| Pozycja z listy | Kto odpowiada | Dowód przed startem |
|---|---|---|
| Backup i test odtworzenia | wykonawca + osoba techniczna po stronie firmy | raport z odtworzenia na stagingu, data i rozmiar kopii |
| Mapa 301 | wykonawca | arkusz mapowania adresów zatwierdzony przez firmę |
| Zamówienie testowe | firma (realizuje zamówienie i potwierdza mailem) | zrzuty ekranu zamówienia, maila, faktury i statusu |
| Rollback i decydent | właściciel firmy | zapisane kryteria cofnięcia + nazwisko i numer telefonu |
Brak jednej osoby decyzyjnej po stronie firmy — decyzje zapadają na grupowych wątkach mailowych, a wykonawca czeka na akceptację cen, kategorii i regulaminu.
Jak wykryć: Policz, ile osób musi zaakceptować zwykłą zmianę ceny na stronie głównej. Jeśli więcej niż dwie — macie problem organizacyjny.
Jak naprawić: Wyznacz jedną osobę z prawem ostatecznej decyzji w sprawach operacyjnych (ceny, treści, kolejność działań) i zapisz to w ustaleniach na starcie projektu.
Zamówienie rozliczane „za sklep” bez rozbicia na godziny i zakres. Przy pierwszej zmianie wymagań brakuje podstawy, żeby ustalić, co jest w cenie, a co dodatkowo płatne.
Jak wykryć: Sprawdź, czy oferta zawiera liczbę godzin i listę funkcji, czy tylko kwotę końcową i ogólne „wdrożenie sklepu”.
Jak naprawić: Poproś o rozbicie na analizę, konfigurację, migrację danych, integracje i testy, z podaniem godzin w każdej pozycji i stawką.
Testowanie zmian bezpośrednio na działającym sklepie, bez środowiska testowego. Jeden błąd w szablonie albo module potrafi zablokować sprzedaż na kilka godzin.
Jak wykryć: Zapytaj wprost, czy istnieje osobna kopia sklepu z własną bazą i czy jest zablokowana przed robotami wyszukiwarek.
Jak naprawić: Wymagaj środowiska testowego z osobną bazą, hasłem dostępu i wpisem noindex, a wdrożenie produkcyjne rób po testach i po kopii zapasowej.
Treści, zdjęcia i opisy trafiają do wykonawcy dopiero na ostatnim tygodniu przed startem. To najczęstsza przyczyna przesunięcia terminu, niezależna od programisty.
Jak wykryć: Sprawdź, ile z zaplanowanych produktów ma już opis, zdjęcia w wymaganej rozdzielczości i uzupełnione atrybuty.
Jak naprawić: Ustal harmonogram dostarczania treści partiami i wpisz go do umowy jako kamień milowy po Waszej stronie, z datami.
Brak odbiorów etapowych — wszystko sprawdzane dopiero przed startem. Wtedy poprawki są najdroższe, bo dotyczą już całości.
Jak wykryć: Zapytaj, po których etapach podpisujecie protokół odbioru i co dokładnie jest wtedy weryfikowane.
Jak naprawić: Wprowadź odbiór po analizie, po konfiguracji i po migracji danych. Każdy odbiór to krótka lista do sprawdzenia i pisemne potwierdzenie.
Dostępy do domeny, DNS, hostingu, poczty i bramki płatności przekazywane pojedynczo, w trakcie prac. Wdrożenie stoi, bo brakuje jednego hasła do strefy DNS.
Jak wykryć: Zrób listę wszystkich usług związanych ze sklepem i sprawdź, kto ma do nich dostęp oraz czy są konta współdzielone.
Jak naprawić: Przygotuj dostępy (najlepiej osobne konta techniczne, nie hasła właściciela) przed pierwszym dniem prac i zapisz, kto nimi zarządza po zakończeniu projektu.
Organizacyjnie wdrożenie PrestaShop w Szczebrzeszynie wygląda podobnie jak w każdym innym mieście — różnica leży w liczbie integracji i tempie decyzji po stronie firmy. Największe ryzyko to brak jednej osoby decyzyjnej, brak środowiska testowego i treści dostarczone na ostatnią chwilę. Ustalcie zakres w godzinach, odbierajcie pracę etapami i zaplanujcie treści przed importem danych. Wtedy termin startu zależy od Was w przewidywalny sposób, a nie od przypadku.
Jedna osoba z prawem decyzji w sprawach operacyjnych: ceny, kolejność prac, treści, zakres testów. Właściciel firmy zwykle nie ma czasu na codzienne ustalenia, a zarząd podejmuje decyzje zbyt wolno. Wystarczy wyznaczyć jedną osobę odpowiedzialną i ustalić, że sprawy finansowe oraz strategiczne wracają do właściciela tylko na etapach odbioru.
Wykonawca odpowiada za konfigurację, migrację danych, integracje, testy techniczne i dokumentację. Firma odpowiada za treści, zdjęcia, decyzje o cenach i stanach, regulaminy oraz dostępy do zewnętrznych usług. Granica bywa nieostra przy opisach produktów i danych do importu — zapiszcie ją w umowie, żeby uniknąć nieporozumień w połowie projektu. Więcej o kolejności etapów piszemy w tekście o organizacji wdrożenia PrestaShop w Szczebrzeszynie.
Liczba godzin w podziale na etapy, stawka godzinowa, zakres funkcji, liczba integracji, terminy odbiorów i warunki prac dodatkowych. Dopiszcie też, kto dostarcza treści i do kiedy, jak przekazywane są dostępy i co obejmuje opieka po starcie. Widełki godzinowe i kosztowe dla podobnych projektów opisujemy w materiale o cenniku i organizacji wdrożenia.
Najpóźniej w momencie, w którym zaczyna się konfiguracja kategorii i szablonów produktu — czyli przed importem danych, nie po nim. Realnie warto zaplanować dostarczanie treści partiami, np. 20–30% katalogu na tydzień, i sprawdzić kompletność przed każdą partią. Jeśli treści dojdą po starcie, wejdą na sklep bez testów i najczęściej z błędami w metadanych.
Danych nie warto rozdzielać: jeśli uruchomicie sklep bez historii zamówień i klientów, stracicie możliwość obsługi zwrotów i reklamacji ze starych zamówień oraz konta klientów z historią. Przekierowania 301 muszą być gotowe w momencie przełączenia domeny, bo ruch ze starych adresów kierujecie od pierwszej minuty. Mechanikę kodów przekierowania opisuje dokumentacja MDN Web Docs – HTTP.
Ustalcie krótki, pisemny raport raz w tygodniu: co zostało zrobione, ile godzin zużyto, co czeka na decyzję firmy i jakie są ryzyka dla terminu. Taki raport wystarczy, żeby wychwycić opóźnienie po dwóch tygodniach, a nie na tydzień przed startem. Dobrą bazą do oceny efektu technicznego są wskaźniki opisane w dokumentacji Core Web Vitals.
Minimum 2–3 miesiące, żeby domknąć poprawki po realnym ruchu: błędy w mailach, drobne problemy z płatnościami, wydajność przy większej liczbie zamówień. Potem warto przejść na stały zakres: aktualizacje PrestaShop i modułów, kopie zapasowe, monitoring i czas reakcji na zgłoszenia. Wersje i wymagania techniczne znajdziecie w dokumentacji dla deweloperów PrestaShop.
Jeśli chcesz przejść przez wdrożenie lub migrację PrestaShop w Szczebrzeszynie z jasnym podziałem na etapy i godziny, napisz do DropDigital i opisz swój sklep. Odpowiemy, co da się zrobić w jakim czasie i co musi przygotować firma.