Od czego zależy wdrożenie PrestaShop w Józefowie: zakres, skala, model pracy

Pytanie „ile to potrwa i ile będzie kosztować” ma sens dopiero po ustaleniu, który projekt faktycznie realizujesz. W rozmowach z firmami z Józefowa i okolic sprawa sprowadza się do trzech różnych scenariuszy.

• Sklep od zera. Instalacja PrestaShop 8.x, motyw, kategorie, strefy podatkowe, płatności, kurierzy, regulaminy i polityka zwrotów. Nie ma danych historycznych, ale cała konfiguracja startuje od pustej bazy — łącznie z setkami decyzji o strukturze katalogu, które później trudno cofnąć.
• Migracja z innej platformy. WooCommerce (WordPress + MySQL), Shoper, IdoSell. Eksport produktów, klientów i zamówień, mapowanie kategorii, atrybutów i wariantów. Historia zamówień musi zachować numery i daty — inaczej reklamacje i księgowość się rozjeżdżają.
• Migracja PrestaShop 1.6 → 8.x. Ta sama baza, ale inna struktura i inne hashowanie haseł klientów. Większość modułów i motywów z 1.6 nie działa na 8.x, więc przenosisz dane, a nie instalację.

Pracochłonność mnożą cztery rzeczy: liczba SKU, liczba kombinacji wariantów, języki i grupy klientów. Produkt z trzema atrybutami po pięć wartości to 125 kombinacji, każda z własnym stanem i zdjęciem. Każdy język powiela pola tekstowe w tabelach ps_product_lang i ps_category_lang; każda grupa klientów (B2B, hurt) to osobne reguły cenowe i dodatkowe testy koszyka.

Próg SKU	Co się zmienia w pracy
do 500 SKU	Import CSV w jednym–dwóch podejściach, płaska struktura kategorii, ręczna weryfikacja próbki 20–30 produktów
500–5000 SKU	Mapowanie kolumn, warianty przez kombinacje, masowa obróbka zdjęć, kategorie dopasowywane skryptem
powyżej 5000 SKU	Skrypt własny lub eksport przez API, walidacja wiersz po wierszu, import obrazów w tle, walka z limitami memory_limit i czasu wykonania

Praca zdalna działa tak samo jak lokalna, pod jednym warunkiem: dostępów nie przekazuje się na czacie. Potrzebujemy konta technicznego w panelu hostingu, danych do SFTP, dostępu do bazy (phpMyAdmin lub SSH), konta administratora w sklepie, dostępu do DNS u rejestratora domeny i skrzynki e-mail do testów zamówień. Po stronie klienta wyznaczacie jedną osobę decyzyjną i jeden kanał komunikacji — cotygodniowy status w jednym wątku. Gdy decyzje podejmuje pięć osób, projekt stoi. Podobne ustalenia opisujemy przy wdrożeniach w regionie, np. dla firm z Zamościa.

Migracja PrestaShop w Józefowie: harmonogram od audytu do startu

Kalendarz poniżej zakłada, że po stronie klienta jest jedna osoba decyzyjna i dostęp do panelu hostingu, bazy i administratora sklepu. Bez tego pierwszy etap nie ruszy.

• Audyt i inwentaryzacja (2–5 dni). Spis produktów, wariantów, klientów, zamówień, modułów, płatności i reguł koszyka. Sprawdzamy wersję PHP, limity hostingu (memory_limit, max_execution_time), wolumen bazy i plików. Wynik: lista rzeczy przenoszonych i zostawianych.
• Konfiguracja staging (3–7 dni). Kopia bazy i plików na subdomenę z blokadą w robots.txt i ochroną hasłem HTTP. Pełna kopia 1:1 jest obowiązkowa przy migracji 1.6 → 8.x, przy zmianie hostingu oraz przy sklepie z historią zamówień, do której odwołuje się księgowość. Przy małym sklepie od zera wystarczy środowisko testowe z kilkunastoma produktami.
• Import danych (2–10 dni). Zaawansowane parametry → Import: mapowanie kolumn, separator, kodowanie UTF-8, warianty dopasowywane po referencji. Klienci i zamówienia wymagają zachowania ID. Po imporcie z 1.6 testujemy logowanie klientów — to najczęstsze źródło zgłoszeń po starcie, bo sposób zapisu haseł zmienił się między wersjami.
• Testy i integracje płatności (3–5 dni). Sandbox operatora i scenariusze: płatność udana, odrzucona, zwrot, koszyk B2B. Pracę nad bramką warto rozdzielić od reszty — pokazujemy to na przykładzie wdrożenia PayPal w PrestaShop.
• Przełączenie produkcyjne (1 dzień + 7 dni obserwacji). Obserwacja oznacza konkret: monitoring błędów 404, logi płatności, koszyki porzucone.

Punkt bez odwrotu wypada 48 h przed zmianą DNS: backup plików i bazy z testem odtworzenia na staging, TTL rekordu A obniżony do 300 s, okno serwisowe poza szczytem sprzedaży, gotowy plan wycofania (stary hosting działa, DNS wraca w kilkanaście minut), certyfikat SSL i przekierowania 301 przygotowane. Zamrożenie treści: 24 h przed startem klient przestaje dodawać produkty i edytować strony CMS. Ostatni import różnicowy robimy po zamrożeniu, a w dniu przełączenia nikt nie wgrywa treści na produkcję. Struktura tabel i konektorów jest opisana w dokumentacji deweloperskiej PrestaShop.

Ile kosztuje wdrożenie i migracja PrestaShop — widełki godzinowe zamiast cennika z sufitu

Wycena z sufitu („sklep to pięć tysięcy”) działa do pierwszej zmiany zakresu. Rozliczenie godzinowe jest odporne, bo każda nowa funkcja to konkretna liczba godzin do akceptacji, a nie kłótnia o to, czy mieści się w pierwotnej kwocie.

Element	Godziny	Od czego zależy
Konfiguracja bazowa sklepu	20–40 h	Liczba języków, walut, metod dostawy, grup klientów, gotowość motywu
Migracja danych	15–60 h	Źródło: WooCommerce/Shoper/IdoSell vs 1.6 → 8.x, liczba SKU i wariantów, stan historii zamówień
Integracja płatności	4–10 h	Jeden operator czy kilku, płatności ratalne, faktura, BLIK
Integracja kuriera	6–12 h	Liczba przewoźników, pobranie, punkt odbioru, etykiety i statusy przesyłek
Moduł własny	10–30 h	Zakres logiki, dostępność API po stronie systemu zewnętrznego, dokumentacja

Prace dodatkowe rozliczamy z puli godzin: zlecenie mailowe z opisem, szacunek godzin do akceptacji, raport tygodniowy z faktycznie przepracowanym czasem. Bez akceptacji szacunku nie zaczynamy — to chroni obie strony przed rozjazdem budżetu.

Osobno wyceniamy cztery rzeczy i mówimy o tym na starcie: treści i opisy produktów, obróbkę zdjęć, SEO po migracji (mapa 301, meta, dane strukturalne, obsługiwane przez Google typy oznaczeń) oraz szkolenie z panelu. Treści i zdjęcia to zwykle praca po stronie klienta — jeśli bierzemy ją na siebie, wchodzi do wyceny jako osobna pozycja, nie „w gratisie”.

Na koniec najczęstsze nieporozumienie: licencja płatnej wtyczki a moduł własny. Konektor do ERP dostępny jako gotowy moduł to koszt licencji razy lata użytkowania plus 4–8 h wdrożenia — ale zależysz od dostawcy przy każdej zmianie API. Moduł własny to 10–30 h developmentu i 2–4 h utrzymania rocznie, a kod zostaje u Ciebie. Policz trzy lata i porównaj. Jeśli system ERP zmienia API raz w roku, własny moduł często wychodzi taniej. Zależności między integracjami opisujemy szerzej w materiale o integracjach z PrestaShop, a mapowanie pól przy migracji z WooCommerce znajdziesz w dokumentacji WooCommerce.

Migracja danych i SEO: produkty, klienci, zamówienia i przekierowania 301

Kolejność przenoszenia danych nie jest dowolna: kategorie → produkty → kombinacje → zdjęcia → klienci → zamówienia → treści CMS → przekierowania → meta dane i mapa XML. Jeśli wgrasz przekierowania przed produktami, przekierowania będą celować w adresy, które jeszcze nie istnieją, a Google zapamięta 404 na kilka tygodni. Szerszy plan etapów opisujemy w materiale o tym, jak wygląda organizacja wdrożenia PrestaShop krok po kroku.

Mapowanie URL zaczynasz od zebrania starej listy adresów z trzech źródeł: stara sitemap.xml, eksport z bazy starego sklepu oraz Search Console (Wydajność → Linki → eksport). W arkuszu robisz cztery kolumny: stary URL, nowy URL, typ strony, kod odpowiedzi. Reguły wrzucasz do .htaccess przed blokiem mod_rewrite PrestaShop, pojedyncze adresy przez Redirect 301, wzorce przez RedirectMatch 301.

Integracje od pierwszego dnia: płatności, InPost, DPD, DHL i ERP

Kolejność ma znaczenie: płatności → kurierzy → faktury i ERP → synchronizacja magazynu. Odwrotna kolejność blokuje testy, bo nie da się przejść ścieżki od koszyka do wydrukowanej etykiety. Praktyczne rozwinięcie tej sekwencji znajdziesz w artykule o tym, jak wyglądają integracje z PrestaShop – kolejność prac.

8 miejsc, w których migracja PrestaShop się wykłada — i jak to wykryć przed startem

Każda z tych pułapek ma tani test do wykonania jeszcze na kopii sklepu. Kolejność poniżej odpowiada temu, jak często je widzimy. Szersze tło organizacyjne znajdziesz w materiale o tym, jak wygląda migracja PrestaShop w praktyce.

• Polskie znaki i kodowanie. Test: zaimportuj 10 rekordów z ó, ł, ś, ć, ż, ź, ń, ą w nazwie, opisie i URL. Po imporcie otwórz te adresy ręcznie. CSV zapisuj w UTF-8, bazę miej na utf8mb4. Sygnał ostrzegawczy: w URL-u widzisz %C5%82 albo znaki zapytania.
• Wersje PHP i moduły. Przejście z 7.4 na 8.x usuwa funkcje, na których stały stare moduły. Wyeksportuj z obu sklepów listę modułów (SELECT name, version, active FROM ps_module), zrób różnicę i sprawdź, które hooki rejestruje każdy z nich. Objaw po starcie: biała strona i wpisy w error_log.
• Strefa czasowa i formaty dat. Baza na UTC przy sklepie w Europe/Warsaw to zamówienie z 23:50 w raporcie dnia następnego i inna data na fakturze. Test: złóż zamówienie testowe po 23:00 i porównaj datę w zamówieniu, raporcie i dokumencie.
• Drzewo kategorii. PrestaShop trzyma kategorie w strukturze nested set (nleft, nright, level_depth). Zapętlenie powoduje, że kategoria znika z frontu. Sprawdź produkty bez kategorii: SELECT COUNT(*) FROM ps_product p LEFT JOIN ps_category_product cp ON cp.id_product = p.id_product WHERE cp.id_product IS NULL.
• Brak pełnego backupu. Archiwizujesz trzy rzeczy: bazę (mysqldump), pliki (img/, modules/, themes/, override/) i konfigurację serwera (vhost, PHP-FPM, crony) — tę ostatnią trzymaj poza katalogiem sklepu. Kopia poza serwerem i jeden test odtworzenia przed startem.
• Pliki mediów. Same rekordy w bazie bez fizycznych plików to 404 na zdjęciach. Porównaj liczbę plików w katalogu img z liczbą rekordów i sprawdź 50 losowych adresów zdjęć.
• Reguły koszyka i promocje. Stara reguła bez daty końcowej potrafi dawać darmową dostawę od pierwszego dnia. Po imporcie wyłącz wszystkie reguły i włączaj je pojedynczo, testując koszyk po każdej zmianie.
• Hasła i konta. Hash z innego systemu (md5, sha1) nie zadziała z bcryptem — nikt się nie zaloguje. Sprawdź format hasha w tabelach klientów i pracowników i zaplanuj reset hasła przy pierwszym logowaniu.

Testy przed przełączeniem: co odklikać na stagingu

Staging to kopia sklepu na subdomenie, z bazą z produkcji, wyłączonym indeksowaniem i płatnościami w trybie sandbox. Testuj na koncie gościa i klienta, nie na adminie — administrator widzi inne ceny i ma włączone narzędzia, które maskują błędy.

• Gość: koszyk, zmiana ilości, checkout bez rejestracji, dane do faktury. Sprawdź, czy koszyk się czyści i czy nie da się zamówić produktu z zerowym stanem.
• Klient zalogowany: stary adres dostawy, historia zamówień po migracji, ponowienie zamówienia.
• Kod rabatowy: kupon procentowy, kwotowy i z minimalną wartością koszyka. Pułapka: reguła katalogowa sumuje się z regułą koszyka i klient dostaje podwójny rabat.
• Płatność za pobraniem i online: pełny cykl — autoryzacja, potwierdzenie, anulowanie, zwrot. Każda metoda osobno, bo moduły mają własne stany zamówienia.

E-maile transakcyjne: przycisk „wyślij wiadomość testową” w panelu nic nie mówi o dostarczalności. Sprawdź SPF, DKIM i DMARC, log SMTP oraz skrzynkę poza własną domeną (Gmail, Onet). Potem przejdź wszystkie statusy — nowe, w realizacji, wysłane, zrealizowane, anulowane — i sprawdź, czy każdy faktycznie wychodzi z serwera i podstawia numer zamówienia. W PrestaShop szablony leżą w katalogu mails/, a wysłane wiadomości widać w tabeli ps_mail.

Wydajność mierz liczbami: TTFB poniżej 600 ms, LCP największego elementu poniżej 2,5 s (to jedno z kryteriów opisanych w dokumentacji Core Web Vitals), liczba zapytań do bazy na stronie kategorii z filtrami. W PrestaShop włącz tryb debug i policz zapytania w stopce. Kategoria z czterema filtrami potrafi wygenerować 150–300 zapytań; powyżej 100–150 to sygnał do sprawdzenia indeksów i cache przed startem, nie po.

Na koniec porównaj sklep z ERP: 20–30 losowych SKU, cena brutto, cena netto, stan magazynowy i jednostka. Ustal, co się dzieje, gdy stan spadnie do zera w trakcie zamówienia, i jaki jest interwał synchronizacji — 15 minut czy godzina zmienia skalę problemu. Osobny wątek, czyli połączenia z systemami zewnętrznymi, opisujemy w artykule o integracjach z PrestaShop, a samo podłączenie bramki — w materiale o PayPal w PrestaShop.

Po wdrożeniu: opieka techniczna, SLA i monitoring w praktyce

SLA to dokument, który da się wyegzekwować. „Reagujemy szybko” nic nie znaczy. Spotykany, sensowny zapis wygląda tak: zgłoszenie krytyczne — reakcja do 4 godzin w dni robocze 8:00–16:00; pozostałe — 1 dzień roboczy. Okno serwisowe: np. wtorek 2:00–5:00, z powiadomieniem 48 godzin wcześniej, jeśli prace mogą chwilowo wyłączyć sklep. Zakres kopii: baza, pliki i konfiguracja, codziennie, retencja 30 dni, kopia poza serwerem produkcyjnym. Kopia, której nie odtworzono, nie jest kopią — test odtworzenia raz na kwartał. Aktualizacje bezpieczeństwa: poprawki krytyczne wdrażane do 7 dni, najpierw na stagingu, potem na produkcji. Zakres zmian w kolejnych wersjach najlepiej weryfikować w PrestaShop Developer Documentation, a nie na podstawie changelogu modułu.

Monitoring to konkretne alarmy, nie „uptime 99,9%” ze strony hostingu:

• Dostępność: HTTP 200 na stronie głównej, karcie produktu i koszyku, sprawdzane co minutę, alert po dwóch nieudanych próbach.
• Kolejka e-maili: jeśli liczba niewysłanych wiadomości rośnie przez 15 minut, zwykle skrzynka nadawcy trafiła na blacklistę albo hosting wprowadził limit wysyłki.
• Zamówienia w panelu: alert, gdy w godzinach 8:00–20:00 nie pojawi się żadne nowe zamówienie przez 6 godzin — przy działającym ruchu to niemal zawsze zepsuty moduł płatności.
• Błędy PHP: alert na każdy nowy Fatal error w logu, zamiast codziennego przeglądania logów.

Przeglądy techniczne mają rytm. Kwartalnie: wersje PHP i modułów, rozmiar bazy (rosnące tabele ps_connections, ps_guest, ps_log), logi błędów, ważność certyfikatu SSL, test kopii. Przed sezonem — Black Friday, święta — 4–6 tygodni wcześniej: test obciążeniowy, limity hostingu (procesy PHP-FPM, CPU), sprawdzenie integracji z kurierami i płatnościami, bufory magazynowe. Zakres i kolejność takich połączeń opisujemy szerzej w artykule o integracjach z PrestaShop.

Druga iteracja migracji zdarza się w dwóch realnych sytuacjach: sklep rośnie z 500 do 3000+ SKU i płaska struktura kategorii przestaje działać, albo wchodzisz na nowe rynki — multistore, druga waluta, tłumaczenia, VAT OSS. Wtedy nie robi się „poprawek”, tylko osobny etap z własnym zakresem i kalendarzem.

Józefów, Roztocze i Lubelszczyzna: jak wygląda współpraca z DropDigital

Józefów leży na skraju Roztocza i to widać w tym, jakie sklepy tu powstają: lokalne produkty (miody, przetwory, sery), rękodzieło, usługi turystyczne. Ich wspólna cecha to sezonowość. Dla sklepu z Roztocza sensowne okno wdrożenia to listopad–marzec: ruch jest najmniejszy, a sklep zdąży przed majem i przed grudniem.

Pracujemy z firmami z całego regionu. Jeśli szukasz konkretów dla sąsiednich miejscowości, zobacz materiały o wdrożeniach i migracjach PrestaShop w Zamościu, Zwierzyńcu, Krasnobrodzie i Szczebrzeszynie.

Kontakt wygląda tak: praca zdalna plus spotkania na miejscu w Józefowie i okolicach, gdy wymaga tego wdrożenie lub szkolenie. Zdalnie prowadzimy audyt, ustalenie zakresu, testy na stagingu i większość prac programistycznych — telefonicznie, mailowo, przez Google Meet. Na miejscu pojawiamy się przy odbiorze sklepu, szkoleniu zespołu z panelu PrestaShop (2–3 godziny na konkretnych zadaniach: dodanie produktu, obsługa zamówienia, faktura, zwrot) albo przy konfiguracji, której nie zrobisz przez zdalny pulpit.

Lokalizacja serwera nie decyduje o możliwości współpracy. Co ma znaczenie: doświadczenie z PrestaShop 1.7 i 8, dostęp do stagingu od pierwszego dnia, umiejętność przeniesienia danych (kategorie, klienci, hasła, zamówienia) i ustawienia przekierowań 301, jasny czas reakcji oraz to, kto odpowiada za integracje — płatności, kurierów, ERP. Gdzie stoi serwer, ma znaczenie dla czego innego: lokalizacja w Polsce lub Niemczech to zwykle kilkadziesiąt milisekund opóźnienia, serwer w USA — 120–180 ms. To kwestia hostingu, nie biura wykonawcy. Powiązane tematy rozwijamy w artykułach o integracjach z PrestaShop oraz o PayPal w PrestaShop.

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

Lista kontrolna do odklikania

• Rodzaj projektu — Ustal na starcie, czy budujesz sklep od zera, migrujesz z innej platformy, czy podnosisz PrestaShop 1.6 na 8.x. Każdy z tych scenariuszy ma inny zestaw prac.
• Liczba SKU i wariantów — Policz produkty i kombinacje atrybutów. Progi pracochłonności to orientacyjnie do 500 SKU, 500-5000 oraz powyżej 5000 — powyżej 5000 import wymaga zwykle pracy skryptem, nie gotowym modułem.
• Języki i grupy klientów — Sprawdź, ile języków i grup cenowych działa dziś w sklepie. Każdy dodatkowy język to osobne tłumaczenia treści, atrybutów i metadanych.
• Dostępy przekazane w jednym miejscu — Hosting, baza danych, panel PrestaShop, panel domeny, konta płatności i kurierów. Zweryfikuj, że hasła działają, zanim zaplanujesz pierwszy etap.
• Audyt i inwentaryzacja — Etap zajmuje zwykle 2-5 dni. Na jego końcu powinieneś znać liczbę rekordów, wtyczek do zastąpienia i miejsca wymagające decyzji.
• Środowisko staging — Konfiguracja zajmuje 3-7 dni. Sprawdź, czy staging ma kopię bazy i plików oraz czy jest zamknięty przed indeksowaniem.
• Import danych — 2-10 dni w zależności od źródła i liczby rekordów. Po imporcie porównaj liczbę produktów, klientów i zamówień ze stanem źródłowym.
• Testy i integracje płatności — 3-5 dni. Przejdź pełną ścieżkę zamówienia z płatnością testową i rzeczywistą, w tym zwrot i anulowanie.
• Backup i plan wycofania — Gotowe na 48 godzin przed przełączeniem. Backup bazy i plików, skrócony TTL rekordu DNS, ustalone okno serwisowe i opisana droga powrotu do starego środowiska.
• Zamrożenie treści — Ustal dzień i godzinę, od której nikt nie dodaje produktów ani nie zmienia zamówień. Zmiany z tego okna wprowadzasz po starcie.
• Plik przekierowań 301 — Gotowy przed przełączeniem. Obejmuje produkty, kategorie, paginację, filtry i wpisy blogowe. Testuj wyrywkowo po starcie.
• Mapa XML i metadane — Sprawdź, czy meta title i meta description zostały skopiowane lub przeliczone świadomie, a nie wygenerowane domyślnym szablonem.
• Szkolenie z panelu — Zaplanuj je po starcie, kiedy sklep działa na docelowych danych. Szkolenie na stagingu bez realnych produktów zwykle nie działa.
• Zasady rozliczania prac dodatkowych — Ustal stawkę godzinową i sposób zatwierdzania dodatkowego zakresu przed startem, nie w trakcie migracji.

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
• WooCommerce – dokumentacja