Wdrożenie PrestaShop w Toruniu zwykle nie wywraca się na kodzie, tylko na organizacji: brak dostępu do bazy, nikt nie wie, kto akceptuje zakres, a lista kategorii pojawia się dopiero w dniu startu. Dlatego ten tekst nie jest o „ustawieniu sklepu”, tylko o tym, jak poukładać projekt: etapy, dni robocze, widełki godzinowe i dane, które trzeba zebrać przed pierwszym commitem.
Poniżej znajdziesz konkretne liczby (od 60 do 200 godzin w zależności od scenariusza), listę błędów, które najczęściej wydłużają projekt, oraz checklistę do odhaczenia przed go-live. Jeśli chcesz najpierw zobaczyć, jak dzielimy prace wdrożeniowe i dodatkowe, zajrzyj na stronę Wdrożenia PrestaShop.
„Wdrożenie PrestaShop” nie jest jedną usługą. To kilkanaście pozycji, z których część jest w standardzie, a część to praca dodatkowa rozliczana osobno. Bez ustalenia tego słownika na starcie klient po trzech tygodniach dowiaduje się, że integracja z systemem magazynowym nie była „w cenie sklepu”.
W standardowym wdrożeniu mieści się:
php.ini (memory_limit 256M, max_execution_time 120), zadania cron, kopie zapasowe bazy i plików.Pracą dodatkową jest wszystko, co wymaga kodu lub danych spoza instalacji: moduły własne, integracje (ERP, fakturowanie, API kurierów, marketplace), import katalogu i klientów, migracja z innej platformy, wersje językowe, funkcje B2B.
Kryteria gotowości do startu są cztery: SSL działa na wszystkich adresach, wydajność mieści się w progach Core Web Vitals, testowe zamówienie przechodzi całą ścieżkę (koszyk → płatność → mail → faktura → status → zwrot), a dane firmy figurują w stopce i regulaminach. Zakres opisujemy na piśmie — to podstawa wdrożenia PrestaShop rozliczanego bez niespodzianek.
| Obszar | W standardzie wdrożenia | Praca dodatkowa |
|---|---|---|
| Serwer | SSL, PHP, cron, backup | Migracja hostingu, CDN, konfiguracja Varnish |
| Podatki i wysyłka | Reguły krajowe i UE, 2–3 przewoźnicy | Reguły per kategoria, cenniki strefowe |
| Płatności | Przelew, za pobraniem, 1 bramka | Raty, subskrypcje, B2B na fakturę z limitem |
| Dane | Ręczne wprowadzenie kategorii | Import CSV/XML, migracja, synchronizacja z ERP |
| Szablon | Instalacja + konfiguracja | Modyfikacje kodu, nowe sekcje, RWD na miarę |
Pytanie „z czego migrujecie” zmienia wycenę bardziej niż liczba produktów. Poniżej pięć scenariuszy i to, co w każdym realnie się sypie.
| Źródło | Co przenosi się dobrze | Najczęstszy problem |
|---|---|---|
| WooCommerce | Produkty proste, kategorie, klienci | Warianty zapisane jako osobne produkty — trzeba je poskładać w kombinacje i odtworzyć relacje atrybutów |
| Shopify | Produkty, warianty, kolekcje, ceny | Brak dostępu do bazy; dane tylko przez CSV lub Admin API. Aplikacje (subskrypcje, rabaty) nie mają odpowiednika |
| Magento 1/2 | Katalog, klienci, zamówienia | Model EAV — kilkadziesiąt tabel, mapowanie atrybutów, produkty konfigurowalne, multistore. Hasła nie przenoszą się |
| PrestaShop 1.6 | Niemal cała baza | Moduły i szablon nie działają na 8.x; inna struktura kombinacji. „1-click upgrade” na produkcji to proszenie się o kłopoty |
| ERP (Subiekt, Comarch, WMS) | SKU, ceny, stany magazynowe | Brak zdjęć, opisów, pól SEO i kategorii sklepowych. Konieczne mapowanie SKU ↔ id_product |
Co przenosi się w 100%: SKU, nazwy, ceny netto, stany, kategorie (gdy drzewo jest spójne), zdjęcia nazwane od SKU.
Co przenosi się w ~90%: relacje produkt-wariant, klienci (bez haseł), zamówienia historyczne — te ostatnie wymagają mapowania statusów i często pokazują się w panelu jako „nieopłacone”.
Czego nie przenosi się wcale: hasła (WooCommerce i PrestaShop używają innych algorytmów — każdy klient musi zresetować hasło), koszyki i sesje, tokeny i autoryzacje w bramkach płatniczych, historia transakcji po stronie operatora, ustawienia modułów, logi.
Migracja nie ma sensu, gdy katalog to poniżej 300 SKU i brak integracji, gdy sklep nie ma ruchu organicznego wartego przenoszenia, a jedynym problemem jest szybkość — taniej jest optymalizować obecną instalację PrestaShop. Jeśli migrujesz, zaplanuj przekierowania 301 dla starych adresów; to standard protokołu HTTP i bez nich stracisz pozycje w Google.
Poniższy plan zakłada, że klient wyznaczył osobę decyzyjną i przekazał dostępy. Dni robocze, nie kalendarzowe: konfigurację i przygotowanie danych po stronie firmy można prowadzić równolegle.
Widełki nakładu. Typowe wdrożenie z gotowym szablonem: 60–140 godzin. Migracja z importem katalogu, klientów i przekierowaniami: 90–200 godzin. Różnica między 90 a 200 godzinami rzadko wynika z liczby produktów — zwykle z jakości danych wejściowych.
Co wydłuża projekt i jak to wychwycić już na etapie wyceny:
Stawki i terminy ustalamy przed stagingiem; porównywalny zakres opisujemy w cenniku wdrożeń i migracji PrestaShop.
| Etap | Dni robocze | Co musi być gotowe, żeby zamknąć etap |
|---|---|---|
| Audyt i zakres | 1–2 | Dostępy, lista integracji, decyzja o szablonie |
| Staging | 1 | Środowisko testowe, SSL, kopia danych |
| Konfiguracja | 3–7 | Podatki, wysyłka, płatności, maile, CMS |
| Import danych | 2–5 | Eksport źródłowy, zdjęcia, mapowanie kategorii |
| Integracje | 2–5 | Klucze API, dane testowe, transakcja w piaskownicy |
| Testy | 2–3 | Zamówienie end-to-end, lista błędów, akcept klienta |
| Go-live | 1 | Przekierowania 301, DNS, backup, monitoring |
Wdrożenie PrestaShop rozliczamy godzinowo: liczba godzin × stawka za godzinę pracy zespołu (konfiguracja, front, backend, testy). Nie dajemy fixed-price bez audytu zakresu, bo wycena „na ślepo” kończy się albo aneksem w połowie projektu, albo niedokończonym sklepem. Kolejność jest zawsze ta sama: audyt zakresu (2–5 h), na jego podstawie rozbicie godzinowe na etapy, dopiero potem pierwszy commit. Jeśli w trakcie wychodzi coś nowego, decyzja zapada przed wykonaniem, nie po.
Realne progi, jakie widzimy w projektach:
Utrzymanie to osobna pozycja: aktualizacje rdzenia i modułów, kopie zapasowe, monitoring dostępności, poprawki po zmianach w API kuriera, drobne zmiany w treściach — zwykle ryczałt miesięczny. Poza abonamentem rozliczamy wszystko, co jest nowym zakresem: nowe funkcje, nowe integracje, kolejne migracje katalogu, tłumaczenia, pracę nad szablonem graficznym. Ten podział zapisujemy w umowie, żeby nie było dyskusji „to przecież w abonamencie”. Pełny zakres etapów opisujemy w sekcji wdrożenia PrestaShop, a przykładowe rozbicie kosztów — w materiale o cenniku wdrożeń i migracji PrestaShop.
| Scenariusz | Widełki | Co zwykle wchodzi | Co idzie osobno |
|---|---|---|---|
| Do 500 SKU, 1 język, 1 kurier | 60–90 h | instalacja, szablon bazowy, płatności, wysyłka, import CSV | zdjęcia produktowe, teksty, tłumaczenia |
| 500–5000 SKU, ERP, warianty | 100–160 h | import z ERP, strefy wysyłki, warianty, migracja URL + 301 | rozbudowa B2B, więcej niż 2 języki |
| Powyżej 5000 SKU, multistore/B2B | 160–200 h i więcej | multistore, ceny klientów, rabaty, wydajność bazy | wyszukiwarka zewnętrzna, indywidualne cenniki B2B |
Zasada bazowa: każdy stary adres, który zwracał kod 200, po migracji musi zwracać 200 albo 301. Nigdy 302 — przekierowanie tymczasowe nie przekazuje sygnałów w ten sam sposób i łatwo zostaje na stałe, bo nikt go nie sprząta. Dwa sposoby na 301: reguły w .htaccess (szybkie, ale przy tysiącach URL-i plik staje się nieczytelny i łatwo o konflikt z regułami PrestaShop) oraz tabela przekierowań w PrestaShop, widoczna w back office, wygodna do audytu. Przy dużych katalogach praktyka jest mieszana: mapowanie w CSV → generacja reguł → tabela w PrestaShop dla wyjątków.
Osiem pułapek z projektów:
/img/.Weryfikacja przed i po: crawl Screaming Frog (porównanie pełnej listy adresów przed i po), logi serwera — grep " 404 " access.log tydzień po starcie, raport 404 w Search Console, a przy zmianie domeny narzędzie zmiany adresu. Sam mechanizm przekierowań w HTTP opisuje MDN Web Docs — HTTP. Cały proces planujemy razem z zespołem od PrestaShop, bo poprawki po go-live są droższe niż przygotowanie mapy.
| Kryterium | .htaccess | Tabela przekierowań w PrestaShop |
|---|---|---|
| .htaccess | tysiące reguł – plik trudny w utrzymaniu | skala nie problem, obsługa z panelu |
| Kto edytuje | programista / DevOps | osoba z obsługi sklepu |
| Ryzyko błędu | wysokie – reguły nadpisują się nawzajem | niskie, ale wymaga importu CSV |
| Audyt | tylko przegląd pliku | lista widoczna w back office |
Integracje rozjeżdżają harmonogram nie dlatego, że API nie działa, tylko dlatego, że nikt nie zebrał danych. Zanim zaczniemy kod, potrzebujemy kompletu: osobne klucze dla środowiska testowego (sandbox) i produkcyjnego, adresy IP serwera do whitelisty u dostawcy API, potwierdzone limity zapytań oraz adres webhooka — inny dla stagingu, inny dla produkcji. Bez tego pierwszy test płatności przesuwa start o dni.
Integracja z ERP — cztery rzeczy do ustalenia, zanim padnie pierwsze zapytanie:
Typowe błędy: brak mapowania stref wysyłki (Paczkomat i kurier muszą być osobnymi metodami z inną strefą), brak testu zamówienia zagranicznego (stawka VAT, waluta, adres bez polskiego kodu pocztowego) oraz brak obsługi płatności częściowych — zaliczka online i dopłata przy odbiorze rzadko są testowane, a psują się w momencie zmiany statusu. Zakres takich prac opisujemy też przy wdrożeniach i migracjach PrestaShop dla firm; dokumentację modułów i API pokrywa dokumentacja dla deweloperów PrestaShop.
| Co zebrać | Środowisko testowe | Produkcja | Kto dostarcza |
|---|---|---|---|
| Klucz / Client ID + sekret | klucze sandbox | klucze produkcyjne | dostawca płatności lub kuriera |
| Whitelist adresów IP | IP serwera stagingowego | IP serwera produkcyjnego | hosting + firma |
| Limity zapytań | potwierdzony limit | potwierdzony limit | dostawca API |
| Adres webhooka | domena stagingowa | domena produkcyjna | firma |
| Konto/dane testowe | dane fikcyjne | — | firma |
Krótka odpowiedź: przy standardowym sklepie odległość między Toruniem a wykonawcą nie zmienia ani jednej linii kodu. Zmienia organizację. W praktyce większość pracy dzieje się na środowisku testowym, więc liczy się nie adres biura, a to, czy w piątek o 15:00 ktoś odbierze zgłoszenie.
Trzy rzeczy do ustalenia w pierwszym tygodniu:
Przekazanie projektu to nie wgranie sklepu na serwer. Powinno zawierać: repozytorium Git z historią zmian, dostępy (SSH/SFTP, panel hostingu, baza, back office, DNS), dokumentację konfiguracji modułów i szkolenie z panelu administracyjnego — 2 godziny z nagraniem, żeby nowa osoba w zespole nie dzwoniła z pytaniem, gdzie zmienia się status zamówienia.
Kiedy warto spotkać się na miejscu: audyt infrastruktury (serwer stojący w biurze, program magazynowy lub ERP działający lokalnie, drukarka fiskalna, integracja z systemem księgowym) oraz wywiad z zespołem — kto przyjmuje zwroty, kto wystawia faktury, kto robi zdjęcia. Wideokonferencja wystarcza, gdy sklep stoi na hostingu zewnętrznym i nie łączy się z niczym w waszej sieci. Wtedy dwa spotkania zdalne po 60–90 minut i reszta w zgłoszeniach.
Utrzymanie po starcie to nie „jesteśmy dostępni”, tylko lista czynności z częstotliwością i parametrem. Minimum miesięczne wygląda tak:
SLA: rozdzielcie czas reakcji od czasu naprawy. „Reakcja 4 h” oznacza, że ktoś potwierdził zgłoszenie i nadał priorytet — nie że sklep działa. Naprawa błędu blokującego sprzedaż: do 8 godzin roboczych w oknie wsparcia. Błąd kosmetyczny: kolejne okno wydawnicze, czyli 7–14 dni. Zgłoszenia jednym kanałem, z priorytetami P1–P3 i eskalacją telefoniczną, jeśli P1 nie doczeka się reakcji w 2 godziny.
Co obserwować co miesiąc:
| Metryka | Gdzie sprawdzać | Wartość do pilnowania |
|---|---|---|
| TTFB | Panel hostingu, PageSpeed Insights, GA4 | poniżej 600 ms dla strony cache’owanej, poniżej 200 ms przy trafieniu w cache |
| Porzucone koszyki | GA4, raporty e-commerce | trend miesiąc do miesiąca; skok o więcej niż 5 pkt proc. to sygnał do sprawdzenia płatności i kosztów wysyłki |
| Błędy 500 | logi PHP i serwera (logi hostingu, /var/log) | zero wpisów; pojedyncze traktuj jako zadanie, nie jako tło |
| Czas indeksowania nowego produktu | Google Search Console, sitemap.xml | produkt widoczny w wynikach w 24–72 godziny od publikacji |
Checklista dzieli się na to, co przygotowujecie wy, i to, co dostarcza wykonawca. Bez odhaczenia wszystkich punktów go-live oznacza zwykle tydzień gaszenia pożarów i stracone zamówienia z pierwszych dni.
Zakres i etapy takiego projektu opisujemy w artykule wdrożenia PrestaShop — zakres i etapy, a sposób liczenia godzin w materiale cennik i organizacja projektu wdrożenia. Zamiast cennika z sufitu proponujemy 60–90-minutowy audyt zakresu: lista funkcji, widełki 60–200 godzin w zależności od scenariusza i dopiero na tej podstawie wiążąca wycena.
Wycena fixed-price bez audytu zakresu — klient dostaje kwotę „za sklep”, a wykonawca dopisuje prace dodatkowe, gdy pojawi się import z ERP albo moduł własny.
Jak wykryć: Zapytaj, czy wycena zawiera listę pozycji z liczbą godzin i co dokładnie jest poza nią. Jeśli odpowiedź brzmi „to się dogada”, cena jest z sufitu.
Jak naprawić: Zamów 1–2 dni audytu i dopiero na jego podstawie podpisz zakres: liczba godzin, lista integracji, kto dostarcza dane. Rozliczenie godzinowe z limitem budżetu działa lepiej niż fixed-price.
Brak dostępu do środowiska źródłowego (baza, panel, SSH, backup) w dniu startu prac.
Jak wykryć: Sprawdź, czy wykonawca ma konto z uprawnieniami do bazy i plików, a nie tylko do panelu WWW. Brak SSH lub dumpa bazy to niemal zawsze przestój.
Jak naprawić: Ustal jedną osobę po stronie klienta, która w ciągu 24 godzin dostarcza dostępy. Przygotuj zrzut bazy i katalogu plików przed startem, nawet jeśli nikt o to nie prosi.
Migracja bez mapowania kategorii i URL-i — po starcie połowa linków prowadzi do 404, a struktura kategorii nie odpowiada starej.
Jak wykryć: Poproś o arkusz: stary URL → nowy URL → typ przekierowania. Jeśli takiego pliku nie ma w harmonogramie, nie ma przekierowań.
Jak naprawić: Mapowanie zrób przed importem, nie po. Minimum: eksport adresów z sitemap.xml starego sklepu i przypisanie każdego do docelowego adresu.
Praca bezpośrednio na produkcji zamiast na stagingu — każdy błąd konfiguracji widzą klienci i roboty wyszukiwarek.
Jak wykryć: Zapytaj, czy jest subdomena testowa i czy jest na niej blokada indeksowania. Brak stagingu to brak testów.
Jak naprawić: Staging to jeden dzień pracy i zwykle najtańsze ubezpieczenie projektu. Wszystkie testy płatności i wysyłek rób na stagingu, produkcję traktuj jako środowisko tylko do odczytu dla klienta.
Obietnica przeniesienia haseł klientów i historii płatności razem z zamówieniami.
Jak wykryć: Wystarczy jedno pytanie do wykonawcy: jak przeniesiecie hasła? Jeśli odpowiedź brzmi „jakimś skryptem”, to znaczy, że nie wie.
Jak naprawić: Powiedz klientom wprost: hasła nie przenoszą się między systemami, będzie reset hasła mailem. Zaplanuj kampanię informacyjną na 2–3 dni przed startem, nie po.
Brak właściciela decyzji po stronie klienta — akceptacje idą przez trzy osoby i projekt stoi tydzień na pytaniu o kolor przycisku.
Jak wykryć: Sprawdź, kto podpisuje odbiór etapu i kto ma prawo powiedzieć „tak, idziemy dalej”. Jeśli to „zarząd”, ustal konkretną osobę.
Jak naprawić: Ustal osobę decyzyjną i termin odpowiedzi na pytania (np. 24 godziny w dni robocze). Pytania bez odpowiedzi w terminie traktuj jako akceptację lub blokadę — ale zawsze zapisane w jednym miejscu.
Wdrożenie i migracja PrestaShop to projekt organizacyjny, nie jednorazowa instalacja. Realny nakład to 60–140 godzin dla samego wdrożenia i 90–200 godzin przy migracji z importem danych i przekierowaniami. Największe opóźnienia nie wynikają z kodu, tylko z braku dostępów, mapowania kategorii i decyzji po stronie klienta. Ustal zakres, właściciela decyzji i listę danych na starcie — reszta harmonogramu układa się sama.
Typowe wdrożenie bez migracji danych to 60–140 godzin, czyli przy pracy jednej osoby od około dwóch do czterech tygodni. Migracja z importem i przekierowaniami to 90–200 godzin. Termin liczy się w dniach roboczych i zależy głównie od tego, jak szybko dostarczacie dane i akceptacje.
Nie, jeśli mówimy o sklepie z własnym szablonem, płatnościami, kurierami i importem danych. W tydzień da się postawić instalację na stagingu z prostym szablonem i podstawową konfiguracją, ale bez testów end-to-end i bez migracji. Publikacja takiego sklepu to najczęstszy powód problemów po starcie.
Fixed-price bez audytu zakresu jest ryzykiem dla obu stron. Sensowny model to 1–2 dni audytu, potem wycena jako liczba godzin × stawka, z zapisanym zakresem i listą prac dodatkowych. Wtedy wiesz, za co płacisz, a ewentualne rozszerzenia są dopisywane z ceną, nie „w trakcie rozmowy”.
Historia zamówień zwykle przenosi się w całości lub z pominięciem danych płatności. Hasła nie przenoszą się w żadnej sensownej formie — każdy system przechowuje je inaczej, więc trzeba zaplanować reset hasła i poinformować klientów przed startem. Koszyki porzucone i sesje również nie przechodzą.
Treści i zdjęcia dostarcza klient, chyba że zakres mówi inaczej. Zwróć uwagę na nazwy plików — jeśli zdjęcia nie mają nazw powiązanych z SKU, import wymaga dodatkowego mapowania i zwykle wydłuża projekt o kilka dni. Ustal to jeszcze na etapie wyceny.
W abonament wpisujemy zwykle aktualizacje bezpieczeństwa, kopie zapasowe, monitoring dostępności i podstawowe wsparcie konfiguracyjne. Osobno rozliczane są nowe moduły, nowe integracje, prace nad szablonem i kampanie. Podział powinien być zapisany w umowie, żeby nie było pozycji „do dogadania”.
Od audytu: co boli w obecnym sklepie, ile kosztuje utrzymanie, jak wygląda wydajność i pozycje w wyszukiwarce. Czasem taniej jest zoptymalizować obecną platformę niż przenosić sklep z historią i ryzykiem SEO. Audyt odpowiada na to pytanie w kilka dni, zanim wydasz budżet na wdrożenie.
Jeśli chcesz sprawdzić, ile godzin zajmie Twoje wdrożenie albo migracja, zacznijmy od krótkiego audytu zakresu — bez zobowiązania do dalszych prac.