Wdrożenia i migracje PrestaShop w Zamościu i okolicy sprowadzają się do dwóch pytań: co przenosimy i w jakim trybie. Wdrożenie od zera to zwykle 40–120 godzin pracy wykonawcy, migracja z innej platformy 60–200 godzin. Różnica nie siedzi w samej instalacji PrestaShop 8, tylko w ilości danych, liczbie integracji i stanie obecnego sklepu. Poniżej część organizacyjna: kolejność etapów, pytania do wykonawcy i lista błędów, które najczęściej kończą się spadkiem ruchu albo wstrzymanym launchem.
Wdrożenie od zera to postawienie sklepu na pustej bazie: instalacja PrestaShop 8, konfiguracja serwera, szablon, moduły, wpisanie katalogu. Migracja to przeniesienie istniejącego sklepu — z WooCommerce, Magento, IdoSell albo ze starego PrestaShop 1.6. O budżecie decyduje punkt startowy, nie sama instalacja CMS-a.
Kiedy migracja jest konieczna, a nie opcjonalna? Trzy sygnały: wersja nie dostaje poprawek bezpieczeństwa, a nowe wydania PHP i modułów ją omijają; karta produktu ładuje się dłużej niż 3 s na 4G mimo włączonego cache; kolejne moduły przestają działać po aktualizacji PHP. Gdy występują dwa z trzech równocześnie, lepiej zaplanować migrację na 2–3 miesiące niż łatać sklep co kwartał. Status wersji i wymagania środowiska sprawdzisz w dokumentacji deweloperskiej PrestaShop.
| Kryterium | Wdrożenie od zera | Migracja |
|---|---|---|
| Praca wykonawcy | 40–120 h | 60–200 h |
| Punkt startowy | pusta baza | istniejący sklep i dane |
| Główne ryzyko | konfiguracja podatków, wysyłek, płatności | mapowanie pól i utrata historii zamówień |
| Dane do przeniesienia | brak (wpisanie katalogu) | produkty, zdjęcia, klienci, zamówienia, treści |
| Typowy klient | firma bez sklepu albo z katalogiem PDF | firma ze sklepem na innej platformie lub na PrestaShop 1.6 |
Firma z Zamościa daje trzy konkretne rzeczy. Pierwsza: spotkanie bez wideokonferencji — analizę z etapu 1 można zrobić u Ciebie, z podglądem magazynu i pytaniami do osób, które realnie obsługują zamówienia. Druga: reakcja na miejscu, gdy problem dotyczy sprzętu — drukarki etykiet, czytnika kodów, dostępu do panelu hostingu. Trzecia: znajomość lokalnego rynku, czyli przewoźników, sezonowości (Roztocze, branża rolno-spożywcza) i tego, jak miejscowi klienci podchodzą do płatności za pobraniem.
Zasięg dojazdu z Zamościa: Krasnystaw i Biłgoraj to kilkadziesiąt kilometrów i około godziny jazdy, Chełm podobnie, Lublin ok. 90 km, czyli 1,5 h w jedną stronę. Warsztat analityczny na miejscu jest realny. Codzienne wizyty w Lublinie przez trzy tygodnie wdrożenia to już koszt, który lepiej wydać na godziny deweloperskie. Dlatego działa model mieszany: 2–3 spotkania na żywo (analiza, odbiór, szkolenie z panelu) i praca zdalna w pozostałych etapach. Tak samo wygląda organizacja wdrożenia sklepu PrestaShop w Poznaniu — proces jest identyczny, różni się tylko logistyka.
Praca zdalna nie oznacza gorszej jakości. Sprawdzasz ją po czterech rzeczach: portfolio z wdrożeniami na PrestaShop 8 (a nie ogólnie „sklepy internetowe”), staging na osobnym serwerze z basic auth i noindex, SLA zapisane w umowie (np. reakcja do 4 h w dni robocze) oraz bezpośredni kontakt z deweloperem zamiast przekazywania pytań przez handlowca. Zapytaj też, co dostajesz na koniec: dokumentację, dostępy założone na Twoje konto (domena, serwer) i listę zadań cron. Jeśli wykonawca nie chce pokazać stagingu przed launchem, to sygnał ostrzegawczy — niezależnie od tego, czy ma biuro 5 km od Ciebie.
Proces to osiem etapów. Godziny podaję z praktyki małych i średnich sklepów — u Ciebie mogą się różnić, ale proporcje zostają.
Co robi klient. Treści, zdjęcia, opisy, decyzje i akceptacje to 20–40% czasu projektu. Najczęstsza przyczyna przesunięcia launchu to brak opisów i zdjęć na trzy tygodnie przed terminem, nie problemy techniczne. Ustal z góry, kto akceptuje etap i w jakim terminie — milczenie nie jest akceptacją.
Przekazanie. Po wdrożeniu dostajesz dostępy w menedżerze haseł (domena i serwer na Twoje konto), opis modułów, instrukcję obsługi zamówień, listę cronów i miejsce backupów. Bez tego dokumentu każda drobna zmiana zaczyna się od odtwarzania wiedzy.
| Etap | Czas | Kto odpowiada za efekt |
|---|---|---|
| Analiza | 2–6 h | wykonawca, akceptacja klienta |
| Konfiguracja VPS | 2–8 h | wykonawca |
| Instalacja PrestaShop 8 | 1–2 h | wykonawca |
| Szablon | 8–40 h | wykonawca, treści i zdjęcia – klient |
| Moduły i integracje | 10–60 h | wykonawca, dostępy API – klient |
| Migracja danych | 10–80 h | wykonawca, weryfikacja poprawności – klient |
| Testy | 8–20 h | wykonawca i klient |
| Launch | 2–4 h | wykonawca, decyzja o terminie – klient |
Migrację zaczynamy od inwentaryzacji adresów, nie od instalacji PrestaShop 8. Krok pierwszy: crawl starego sklepu w Screaming Frog (darmowa wersja do 500 URL-i, powyżej potrzebna licencja) i eksport do arkusza: adres, kod odpowiedzi, tytuł, canonical. Krok drugi: logi serwera z ostatnich 60–90 dni — pokazują, co roboty faktycznie odwiedzają, czego nie ma w sitemapie i gdzie stare przekierowania się sypią. Z tych dwóch plików powstaje mapa URL-i 1:1: stary adres, nowy adres, typ treści, właściciel, status.
Przekierowania ustawiamy wyłącznie na 301, w jednym przeskoku. Łańcuch A → B → C rozmywa sygnały i wydłuża czas odpowiedzi; semantykę kodów definiuje RFC 9110, ale praktyczna zasada jest krótka: 301 dla trwałych zmian, 302 tylko na czas testów. Przekierowujemy wszystko, co miało ruch: produkty, kategorie, strony CMS, obrazy w /img/p/, pliki PDF, feedy i adresy z parametrami. Jeśli przenosisz sklep z WooCommerce, zakres bywa podobny do opisanych przez nas wdrożeń i optymalizacji WooCommerce w Zamościu — różni się głównie warstwa szablonów i koszyk.
Pułapka numer jeden: migracja bez mapy URL. Efekt to 404 na tysiącach produktów, wypadnięcie kategorii z wyników i odbudowa pozycji liczona w tygodniach, nie dniach. Druga pułapka to staging z noindex przeniesiony na produkcję — jeden tag w szablonie i sklep nie istnieje w Google.
| Element | Co sprawdzić | Czym weryfikujemy |
|---|---|---|
| Produkty i kategorie | mapowanie 1:1, przekierowanie w jednym przeskoku | arkusz mapy URL + Screaming Frog |
| Obrazy /img/p/, PDF, załączniki | przekierowanie na nowe ścieżki zamiast 404 | crawl po migracji, logi serwera |
| Adresy z parametrami i końcowym / | kanonizacja, ustawienie preferowanego URL | Search Console, test adresu URL |
| Nowe adresy | sitemap.xml i jej zgłoszenie | Search Console → Sitemapy |
Typowy sklep ma 6–10 integracji. Najczęściej wdrażamy InPost ShipX, DPD i DHL po stronie wysyłki oraz PayPal, Przelewy24 i tpay po stronie płatności. Pojedyncza integracja to 8–40 godzin pracy — rozrzut wynika nie z samego API, a z liczby miejsc, w których trzeba coś dopasować. Kolejność i podział prac opisujemy szerzej w materiale o integracjach z PrestaShop i organizacji wdrożenia.
Własny moduł opłaca się wtedy, gdy proces jest nietypowy (B2B, zatwierdzanie zamówień, własna logika stanów), gdy dostawca wtyczki nie wspiera PrestaShop 8 albo nie udostępnia API. Płatna wtyczka to koszt kilkuset złotych i ryzyko, że aktualizacja rdzenia ją zepsuje. Kod na miarę piszemy zgodnie ze standardami z dokumentacji dla deweloperów PrestaShop — zostaje na Twoim serwerze i nie zniknie po zmianie licencji.
Trzy pułapki widzimy najczęściej: limity API (katalog 5 000 produktów w jednym żądaniu nie przejdzie), błędne statusy (zamówienie „zrealizowane” przed wysyłką) i duplikaty zamówień, gdy cron oraz webhook działają równolegle bez blokady.
Rozliczamy się godzinowo. Stawka to 120–250 zł netto za godzinę i zależy od specjalizacji: inaczej wyceniamy konfigurację PrestaShop, inaczej moduł do ERP, a inaczej pracę z logami i wydajnością. Cennik „z sufitu” (np. 4 999 zł za sklep) prawie zawsze kończy się dopłatami w połowie projektu, bo nikt nie wie, ile danych jest do przeniesienia. Dlatego wycena startuje od arkusza zakresu, a nie od tabelki na stronie.
Poza wdrożeniem i migracją doliczamy integracje, np. integrację Allegro z PrestaShop, i opiekę techniczną. Skala porównawcza bywa przydatna — podobny sposób liczenia stosujemy przy projektach WooCommerce, gdzie organizacja wdrożenia sprowadza się do tych samych pytań o dane i integracje.
Co podnosi koszt najbardziej: liczba SKU i wariantów przy imporcie, wielojęzyczność (każda wersja to osobne meta, treści i hreflang), funkcje B2B (grupy klientów, cenniki indywidualne, limity kredytowe, zatwierdzanie zamówień) oraz moduły pisane na miarę. Osobna pozycja, o której klienci zapominają: przeniesienie kont klientów. Hasła są hashowane, więc albo wymuszasz reset przy pierwszym logowaniu, albo migrujesz hash i sprawdzasz zgodność algorytmu — jedno i drugie to praca.
Ukryte opłaty, które warto wyjąć na stół przed podpisaniem umowy: licencje modułów (często roczne), hosting i certyfikat, kopie zapasowe z testem odtworzenia, dyżur po launchu. Górna granica widełek odpowiada średniej stawce ok. 170 zł/h; projekt prowadzony w całości przez specjalistę na stawce 250 zł/h wycenimy wyżej i powiemy to wprost przed startem.
| Zakres | Czas pracy | Typowy koszt netto |
|---|---|---|
| Wdrożenie od zera (PrestaShop 8) | 40–120 h | 6 000 – 20 000 zł |
| Migracja z innej platformy | 60–200 h | 9 000 – 35 000 zł |
| Pojedyncza integracja (płatność, kurier, ERP) | 8–40 h | 960 – 10 000 zł |
| Opieka techniczna | miesięcznie | 300 – 1 500 zł/mies. |
Typowy scenariusz z Zamościa i okolic: sklep stoi na hostingu z PHP 7.4, ma 3 000 produktów i pięć modułów płatności, z których realnie działa jeden. Migracja na PrestaShop 8 zaczyna się od podniesienia wersji PHP i w tym momencie dwa moduły zwracają błąd 500. Wykryte na kopii — kosztuje jedno popołudnie. Wykryte po starcie — kosztuje wstrzymaną sprzedaż i telefony od klientów.
Zanim cokolwiek przeniesiesz, przygotuj pełny backup: zrzut bazy (mysqldump), katalogi /img, /modules, /themes oraz plik konfiguracyjny (app/config/parameters.php w PrestaShop 1.7/8, config/settings.inc.php w 1.6). Backup, którego nie odtworzyłeś na osobnym środowisku, nie jest backupem — jest nadzieją.
| Ryzyko | Jak wykryć przed startem | Objaw po starcie |
|---|---|---|
| Brak backupu | Odtworzenie kopii na stagingu i uruchomienie sklepu z tego zrzutu | Brak możliwości rollbacku, ręczne składanie danych |
| Brak stagingu | Kopia na osobnej subdomenie z Basic Auth i noindex | Testy na produkcji, klienci widzą błędy |
| Nieprzetestowane płatności | Transakcja w sandboxie plus jedna realna na 1 zł i zwrot | Zamówienia bez potwierdzenia płatności |
| Złe uprawnienia | Katalogi 755, pliki 644, katalogi img/ i var/ zapisywalne | Brak możliwości wgrywania zdjęć, błędy instalacji modułów |
| Szablony z niekompatybilnymi modułami | Sprawdzenie hooków motywu i zgodności z PrestaShop 8 | Rozjechany layout, niedziałający koszyk |
| Duplikaty produktów | Porównanie liczby pozycji po EAN i polu reference przed i po imporcie | Zdublowane SKU, błędne stany magazynowe |
| Problemy z indeksacją | Crawl przed i po, porównanie kodów 200/301/404 i canonicali | Spadek ruchu, masowe 404 w Search Console |
| Wolne zapytania SQL | Slow query log i EXPLAIN na ps_product oraz ps_product_attribute | Wysoki TTFB, timeouty w koszyku |
| Błędy 500 po zmianie PHP | Test na stagingu z docelową wersją PHP, tryb debug i katalog var/logs | Biała strona tuż po aktualizacji |
Wdrożenie kończy się w dniu, w którym sklep przyjmuje pierwsze zamówienie — od tego momentu zaczyna się utrzymanie. Minimum to monitoring dostępności co 1–5 minut z alertem SMS i e-mail, codzienny backup bazy, cotygodniowy backup plików, retencja 30 dni i kopia poza serwerem produkcyjnym (S3, Backblaze albo drugi host). Kopia trzymana wyłącznie na tym samym serwerze to nie zabezpieczenie, tylko złudzenie.
Aktualizacje robi się partiami: najpierw wersje minor PrestaShop 8.x i moduły na stagingu, potem produkcja w oknie serwisowym poza szczytem sprzedaży. Bezpieczeństwo to 2FA do panelu, zmiana domyślnej nazwy katalogu administracyjnego, limit prób logowania i aktualna wersja PHP wspierana przez producenta.
SLA musi być zapisane w umowie, nie w mailu. Sensowne poziomy: 1 godzina na awarię blokującą sprzedaż (brak płatności, sklep nie odpowiada), 4 godziny na błąd uniemożliwiający działanie funkcji, 8 godzin na drobne zgłoszenia, w godzinach 8:00–18:00 w dni robocze. Warto wprost wypisać, co jest w pakiecie, a co płatne osobno — to ucina 90% nieporozumień.
KPI, które warto raportować co miesiąc: LCP (cel do 2,5 s), TTFB poniżej 600 ms, konwersja i liczba błędów 404 zgłaszanych w Search Console. Koszt utrzymania w praktyce: 300–500 zł/mies. za podstawową opiekę, 600–900 zł/mies. z pakietem godzin deweloperskich, 1200–1500 zł/mies. przy rozwoju, integracjach i priorytetowym czasie reakcji.
Własny moduł zamiast kolejnej wtyczki opłaca się, gdy: potrzebujesz logiki, której nie ma na rynku; gotowy moduł robi 20 rzeczy, a Ty używasz dwóch i obciąża każdą stronę; roczny koszt licencji zbliża się do jednorazowego kosztu napisania modułu; wymiana danych z ERP wymaga formatu, którego wtyczka nie obsługuje. Backlog rozwojowy przeglądaj co miesiąc i trzymaj na niego 10–20% budżetu.
| Pakiet | Zakres | Orientacyjny koszt miesięczny |
|---|---|---|
| Podstawowy | Monitoring uptime, kopie, aktualizacje bezpieczeństwa, czas reakcji 8 h | 300–500 zł |
| Standard | Powyższe plus pula godzin deweloperskich i czas reakcji 4 h | 600–900 zł |
| Rozwojowy | Powyższe plus nowe integracje, rozwój backlogu, czas reakcji 1 h | 1200–1500 zł |
Wycena wdrożenia PrestaShop bez pytań o dane i integracje jest wróżeniem z fusów. Dobry wykonawca przed podaniem ceny zapyta o liczbę produktów, kategorie, sposoby dostawy, moduły płatności, magazyn i to, czy dane mają trafiać do ERP. Zanim podpiszesz cokolwiek, zadaj siedem pytań.
Czerwone flagi: brak umowy albo umowa „na mailu”; cena z sufitu bez wyceny zakresu; wykonawca trzyma hosting i domenę na swoim koncie; brak dokumentacji i przekazania dostępów; pośrednik bez dewelopera w zespole, który zleca pracę dalej; wycena bez pytania o dane i integracje. Realna opieka po starcie i bezpośredni kontakt z osobą, która zna kod Twojego sklepu, skracają czas reakcji z dni do godzin — i to jest zwykle więcej warte niż najniższa cena wdrożenia.
Praca bezpośrednio na produkcji, bez stagingu
Jak wykryć: Zapytaj o adres testowy i kopię bazy. Jeśli wykonawca mówi, że nie ma stagingu, każda poprawka szablonu wchodzi od razu do klientów.
Jak naprawić: Postawić kopię sklepu na osobnym adresie, wszystkie zmiany testować tam, a na produkcję wypuszczać dopiero po sprawdzeniu koszyka i płatności.
Migracja bez arkusza mapowania starych adresów na nowe
Jak wykryć: Poproś o mapę URL przed startem. Brak arkusza dla produktów, kategorii, stron CMS i bloga oznacza, że część ruchu zostanie na 404.
Jak naprawić: Przygotować mapowanie 1:1, wdrożyć trwałe przekierowania 301, zaktualizować sitemap i znaczniki canonical, a po launchu porównać crawl przed i po.
Brak kopii zapasowej albo kopia, której nikt nie testował
Jak wykryć: Zapytaj, gdzie leży backup, kto go robi i kiedy ostatnio odtwarzano go na kopii testowej. Sam plik bez testu to nie backup.
Jak naprawić: Wykonać pełną kopię plików i bazy poza serwerem produkcyjnym, a przed startem prac odtworzyć ją na stagingu i sprawdzić, czy sklep wstaje.
Płatności i wysyłki nietestowane po przełączeniu na produkcję
Jak wykryć: Po launchu wykonaj testowe zamówienie i sprawdź, czy status wrócił poprawnie do PrestaShop oraz czy etykieta wysyłkowa się wygenerowała.
Jak naprawić: Najpierw transakcje w trybie sandbox dla każdej metody, potem jedna realna na niską kwotę, na końcu pełny cykl: zamówienie, płatność, etykieta, faktura, wysyłka.
Brak jednej osoby decyzyjnej po stronie klienta
Jak wykryć: Sprawdź, kto akceptuje szablon, treści i zakres modułów oraz w jakim terminie. Jeśli decyzje podejmuje kilka osób, harmonogram się rozjeżdża.
Jak naprawić: Wyznaczyć jedną osobę akceptującą, spisać listę elementów do odbioru i terminy. Akceptacje zbierane mailem, nie ustnie.
Dokumentacja i dostępy przekazywane na koniec albo wcale
Jak wykryć: Przejrzyj umowę pod kątem punktu o dokumentacji powdrożeniowej i przekazaniu dostępów. Brak zapisu oznacza, że zostaniesz z wiedzą u wykonawcy.
Jak naprawić: Przekazać plik z listą modułów, zadań cron, integracji, dostępów do paneli i zasad aktualizacji, plus krótkie szkolenie i okres wsparcia.
Organizacja wdrożenia albo migracji PrestaShop to kwestia kolejności decyzji, nie doboru technologii. Najpierw inwentaryzacja danych i mapa adresów, potem staging, testy płatności i dopiero launch. Sklep w Zamościu nie potrzebuje lokalnego wykonawcy, żeby działać szybko — potrzebuje kogoś, kto odda dokumentację, poda liczbę godzin i odbierze telefon po starcie.
Nie z definicji. Lokalny wykonawca daje szybszy dojazd i reakcję na miejscu w Zamościu, Lublinie, Chełmie, Krasnystawie i Biłgoraju, ale o jakości decyduje coś innego: portfolio we wdrożeniach PrestaShop 8, staging, dokumentacja i kontakt bezpośrednio z deweloperem, a nie z handlowcem. Jeśli te cztery rzeczy są na miejscu, praca zdalna nie jest wadą.
Wdrożenie od zera to zwykle 40–120 godzin pracy wykonawcy. Migracja z WooCommerce, Magento albo starego PrestaShop 1.6 to 60–200 godzin, bo dochodzi mapowanie danych, przepisanie adresów i testy. Do tego dolicz swój czas na treści, zdjęcia i akceptacje — bez tego harmonogram rozjeżdża się niezależnie od wykonawcy.
Nie, jeśli adresy są mapowane 1:1, a stare URL-e zwracają trwałe przekierowanie 301. Semantykę tego kodu opisuje RFC 9110 i to jest podstawa, na której opiera się cała reszta. Problem pojawia się wtedy, gdy migracja startuje bez arkusza mapowania i część adresów zwraca 404 — dlatego crawl przed i po wdrożeniu jest obowiązkowy.
Tak, ale najpierw trzeba ustalić, co przenosimy: produkty, klientów, zamówienia, opinie, rabaty. Każdy z tych zbiorów ma inną strukturę w obu systemach, więc import to osobny etap prac, a nie dodatek do instalacji. Orientacyjnie sam import danych to 10–80 godzin, zależnie od liczby SKU i historii zamówień. Więcej o samej organizacji takiego projektu piszemy w tekście o wdrożeniach WooCommerce w Zamościu.
Staging to kopia sklepu, na której testuje się szablon, moduły i migrację bez ryzyka dla ruchu i zamówień. Bez niego każda poprawka wchodzi od razu do klientów, a błędny moduł potrafi zablokować koszyk na kilka godzin. Adres stagingu i kopię bazy warto wymagać już na etapie wyceny, nie po podpisaniu umowy.
Zwykle wykonawca, ale zakres trzeba zapisać przed startem. Najczęściej wdrażane integracje to InPost ShipX, DPD, DHL, PayPal, Przelewy24, tpay oraz ERP typu Subiekt, Comarch czy WF-Mag. Typowy integrator to 8–40 godzin, a najczęstsze pułapki to limity API, błędne statusy i duplikaty zamówień. Zakres takich prac opisujemy w materiale o integracjach z PrestaShop i osobno o module PayPal w PrestaShop.
Stawki w Polsce mieszczą się w przedziale 120–250 zł netto za godzinę, zależnie od specjalizacji. Uczciwa wycena to liczba godzin razy stawka, z listą tego, co poza zakresem: import, wielojęzyczność, B2B, moduły niestandardowe. Unikaj ryczałtu z sufitu bez rozbicia na etapy, bo wtedy każda zmiana zakresu staje się sporem, a nie kwestią dopisania godzin.
Jeśli chcesz sprawdzić, ile godzin zajmie Twoje wdrożenie albo migracja, napisz do nas — przejrzymy dane, wersję PrestaShop i listę integracji, a potem podamy zakres w godzinach. Możesz też zacząć od krótkiej rozmowy o tym, co już masz na serwerze.