Wdrożenia i migracje PrestaShop Bełżec to dwa różne zlecenia, które klienci często traktują jak jedno. Wdrożenie oznacza sklep budowany od zera: instalacja, szablon, konfiguracja, integracje i dane startowe. Migracja oznacza przeniesienie istniejącego sklepu z PrestaShop 1.6/1.7, WooCommerce, Shopera albo autorskiego CMS-a. Mieszanie tych pojęć kończy się porównywaniem ofert opisujących zupełnie inny zakres prac. Poniżej rozkładamy projekt na etapy, dodajemy gotową checklistę i pokazujemy, co najczęściej wysypuje harmonogram.
Wdrożenie oznacza sklep budowany od zera: instalacja PrestaShop 8, wybór i konfiguracja szablonu, strefy wysyłki, metody płatności, podatki, waluty, moduły oraz dane startowe — kategorie, produkty, teksty, regulaminy. Migracja oznacza, że sklep już istnieje (PrestaShop 1.6/1.7, WooCommerce, Shoper, autorski CMS), a zadaniem jest przeniesienie katalogu, klientów, zamówień, treści i widoczności w Google na PrestaShop 8.
Różnica jest praktyczna: w migracji 60–70% pracy to dane i adresy URL, we wdrożeniu — konfiguracja i integracje. Dlatego jedna i druga oferta mogą brzmieć „sklep na PrestaShop”, a opisywać zupełnie inny zakres.
| Kryterium | Wdrożenie od zera | Migracja istniejącego sklepu |
|---|---|---|
| Punkt startowy | Brak sklepu, decyzja o platformie i szablonie | Działający sklep z danymi, historią zamówień i ruchem |
| Główne prace | Instalacja, szablon, moduły, płatności, wysyłka, treści startowe | Audyt, eksport i mapowanie danych, 301, integracje, testy |
| Typowy czas | 3–6 tygodni | 2–6 tygodni (bywa dłużej przy nietypowych danych) |
| Główne ryzyko | Zbyt długie ustalanie zakresu i zmiany szablonu w trakcie | Utrata danych, ruchu i pozycji przez brak mapy URL-i |
| Orientacyjny nakład | 40–90 h przy sklepie do ok. 500 produktów | 30–120 h przy sklepie do ok. 3 000 produktów |
Audyt robi się przed wyceną, nie po podpisaniu umowy. Poniżej sześć punktów, które w praktyce decydują o harmonogramie.
img/ w GB. Sprawdź to zapytaniem do bazy (ps_product, ps_product_attribute, ps_category) i poleceniem du -sh img/. Sklep z 8 000 produktów, 40 000 kombinacji i 12 GB zdjęć importuje się inaczej niż sklep z 300 produktami.ps_cart) oraz rekordów do archiwizacji: ps_connections, ps_guest, tabele statystyk. Ustal, czy przenosisz zamówienia z 24 miesięcy, czy całą historię — od tego zależy czas importu i rozmiar kopii.override/, niestandardowe pliki w motywie, dodatkowe kolumny w tabelach produktów, własne statusy zamówień. To odpowiada na pytanie, czy funkcje da się przenieść, czy trzeba je przepisać.Przykład z praktyki: sklep, który „miał 2 000 produktów”, po audycie okazał się mieć 2 000 produktów, 14 000 kombinacji i 230 adresów z ruchem — i to ta ostatnia liczba ustaliła zakres 301. Podobny schemat audytu stosujemy przy
Bełżec leży w powiecie tomaszowskim — kilkanaście kilometrów od Tomaszowa Lubelskiego, około 45 km od Zamościa i około 110 km od Lublina. W projekcie e-commerce przekłada się to na cztery konkretne decyzje.
Strefy wysyłki i przewoźnicy. Konfiguracja siedzi w Wysyłka → Przewoźnicy, ale najpierw uzupełniamy Międzynarodowe → Lokalizacja → Strefy i Zakresy. Realny zestaw w regionie to InPost (Paczkomaty plus kurier), DPD (klasyczny i DPD Pickup) oraz DHL. Pułapka: PrestaShop nie zna stref po kodzie pocztowym. Darmowej dostawy „w powiecie tomaszowskim” nie zrobisz natywnymi strefami — potrzebna jest reguła koszyka albo moduł. Zamiast tego sprawdź, czy w Lokalizacja → Stany województwo lubelskie jest przypisane do właściwej strefy, i przetestuj checkout na kodach z Bełżca, Tomaszowa Lubelskiego i Lubyczy Królewskiej.
Zdalnie czy na miejscu. Instalację, konfigurację, import danych i integracje zrobisz w 100% online — lokalizacja wykonawcy nie ma tu znaczenia. Spotkanie na miejscu ma sens w trzech sytuacjach: warsztat z danymi (przegląd starych kartotek i faktur), szkolenie obsługi oraz odbiór sklepu przed startem. Dojazd z Tomaszowa Lubelskiego czy Zamościa to kwestia godziny, z Lublina — połowy dnia.
Sezonowość i B2B. Sklepy nastawione na Roztocze pracują falami: maj–wrzesień to ruch turystyczny, poza sezonem sprzedaż siada. Warto to uwzględnić w planie — organizacja wdrożenia PrestaShop w Krasnobrodzie i przygotowanie sklepu pod ruch turystyczny w Zwierzyńcu wyglądają inaczej niż projekt dla hurtowni. Dlatego funkcje B2B (grupy klientów, ceny grupowe, reguły cenowe katalogu, minimalna wartość zamówienia) planuj od początku, a nie dokładaj po starcie.
Wsparcie po wdrożeniu. Liczy się czas reakcji i kanał kontaktu, nie odległość. Ustal SLA na piśmie: 4–8 godzin w dni robocze, jedna skrzynka na zgłoszenia, jasny podział „awaria / zmiana / rozwój”.
| Przewoźnik | Co skonfigurować | Typowa pułapka |
|---|---|---|
| InPost | Moduł z API, wybór Paczkomatu na mapie w checkoucie, waga gabarytowa | Brak wyboru punktu przy zamówieniu — etykiety nie da się wygenerować |
| DPD | Klasyczny plus DPD Pickup, mapowanie usług na zakresy wagowe | Zakresy wagowe w sklepie rozjeżdżają się z cennikiem z umowy |
| DHL | Umowa, prefiksy numerów, przypisanie usługi do typu przesyłki | Usługa krajowa podpięta pod strefę europejską |
| Pobranie (COD) | Dodatkowa opłata przypisana do konkretnego przewoźnika | Brak weryfikacji adresu — zwroty i dopłaty po stronie sklepu |
Integracje to miejsce, w którym harmonogram pęka najczęściej — nie dlatego, że są trudne, ale dlatego, że ktoś zaczyna je planować w tygodniu startu. Trzy obszary do zamknięcia przed importem danych.
ERP: Subiekt, Comarch ERP Optima, WF-Mag. Najpierw ustal kierunek synchronizacji, bo to determinuje całą resztę. Typowo: kartoteki, stany i ceny płyną z ERP do PrestaShop, a zamówienia, nabywcy i dokumenty sprzedaży — z PrestaShop do ERP. Odpytanie cronem co 5–15 minut w zupełności wystarczy; pełny przebieg katalogu na 5 000 SKU i tak zajmuje kilka minut, więc częstsze wywołania to marnowanie zasobów hostingu. Mapowanie ustal na piśmie w tabeli: Symbol w Subiekcie ↔ pole Reference w PrestaShop, EAN ↔ ean13, jednostka miary. Tu jest najczęstszy błąd: ERP liczy w opakowaniach zbiorczych, PrestaShop domyślnie w sztukach. Albo przeliczasz w module, albo prowadzisz osobne pozycje kartonowe — inaczej stany rozjeżdżają się po pierwszej większej dostawie. Zajrzyj też do dokumentacji dla deweloperów PrestaShop, żeby sprawdzić, jak działają hooki i tabela ps_stock_available.
Płatności. Przelewy24, PayU, Autopay — każdy moduł uruchamiamy najpierw w trybie sandbox. Test obejmuje pełną ścieżkę: koszyk → checkout → przekierowanie do operatora → płatność → powrót do sklepu → mail i faktura. Dodatkowo sprawdź scenariusze negatywne: anulowanie, timeout, błędny podpis. Bez tego pierwszy prawdziwy klient zgłosi „zapłaciłem, a zamówienia nie ma”.
Kurierzy. Etykiety generuje API, ale warunkiem są podpisana umowa i dane dostępowe. Ustal, kto odpowiada za numery statusów i punkty odbioru na mapie — dla sklepu z Biłgoraja czy okolic to zwykle jedna rozmowa z opiekunem handlowym, ale potrafi zająć tydzień.
Wtyczka czy własny moduł? Policz to na trzech liczbach: koszt roczny wtyczki, koszt jednorazowy modułu i liczba miejsc, w których wtyczka nie pokrywa procesu. Jeśli wtyczka kosztuje 900 zł rocznie, a moduł 9 000 zł, próg zwrotu wypada po dekadzie — chyba że wtyczka nie obsługuje Twoich cen grupowych i wtedy kosztem jest praca ręczna co miesiąc.
Nie ma sensownej odpowiedzi na pytanie „ile kosztuje sklep”, jeśli nie usłyszysz liczby godzin. Dwie oferty na identyczną kwotę mogą oznaczać 200 godzin po 200 zł albo 400 godzin po 100 zł — i to są dwa różne projekty, z różnym ryzykiem.
Podziel projekt na bloki i policz każdy osobno. Audyt obejmuje inwentaryzację danych, wtyczek i integracji źródłowego sklepu (przy migracji z WooCommerce trzeba przejść przez strukturę zamówień, klientów i wariantów produktów w dokumentacji WooCommerce i sprawdzić, co da się przenieść bez strat). Konfiguracja to strefy, przewoźnicy, podatki, maile, uprawnienia. Import danych — najczęściej niedoszacowany blok. Integracje, testy, cutover i opieka zamykają listę.
Prosta migracja sklepu z 100–300 SKU, jednym szablonem, jedną bramką płatniczą i jednym kurierem to kilkadziesiąt godzin. Koszt skalują cztery rzeczy: liczba SKU (import rośnie nieliniowo, gdy pojawiają się warianty i kombinacje), liczba integracji, nietypowa logika cenowa (rabaty progowe, ceny grupowe, różne cenniki dla hurtu) oraz jakość danych źródłowych.
Rozliczenie godzinowe bywa korzystniejsze dla klienta, gdy zakres jest niepewny — płacisz za faktycznie wykonaną pracę, a nie za ryzyko wkalkulowane w pakiet. Pakiet ma sens wtedy, gdy zakres jest domknięty i porównujesz oferty wykonawców z okolic, np. organizację wdrożenia PrestaShop we Frampolu albo projekt migracji PrestaShop w Szczebrzeszynie — wtedy pytaj wyłącznie o liczbę godzin i stawkę.
Dodatkowe godziny generują najczęściej: duplikaty SKU i braki w opisach, brak dostępu do API po stronie starego dostawcy oraz zmiany zakresu w trakcie prac. Każdy z tych punktów sprawdź przed podpisaniem umowy.
| Blok | Orientacyjny zakres godzin | Co przesuwa go w górę |
|---|---|---|
| Audyt i inwentaryzacja | 4–10 h | Brak dostępu do panelu, starego hostingu lub bazy |
| Konfiguracja sklepu | 8–20 h | Wiele stref wysyłki, ceny grupowe, wielojęzyczność |
| Import i migracja danych | 4–40 h | Liczba SKU, warianty, bałagan w opisach i zdjęciach |
| Integracje (ERP, płatności, kurierzy) | 8–60 h | Własny moduł, nietypowe mapowanie SKU i jednostek |
| Testy i QA | 6–20 h | Scenariusze negatywne, płatności, stany magazynowe |
| Cutover (DNS, SSL, przekierowania) | 2–8 h | Stary sklep na tym samym serwerze, brak backupu |
| Opieka po starcie | 2–10 h / miesiąc | Aktualizacje, poprawki po wdrożeniu, rozwój funkcji |
Migracja wygląda na skończoną, dopóki nie porównasz starej i nowej wersji sklepu punkt po punkcie. Poniżej siedem pułapek, które w praktyce wypadają najczęściej, wraz z testem do wykonania na stagingu i progiem, który uznajemy za zaliczony.
ps_product_lang i ps_category_lang, w polu link_rewrite. Import CSV z jednym adresem dla dwóch produktów kończy się doklejeniem „-1” i „-2” albo nadpisaniem przy zapisie z panelu. Sprawdź zapytaniem grupowym po link_rewrite i id_lang, a osobno po meta_title — sklep nie blokuje duplikatów meta. Strukturę tabel opisuje dokumentacja dla deweloperów PrestaShop./img/p/ oraz stare ścieżki /img/cms/ — przy przejściu z 1.6 na 1.7/8 zmienia się układ katalogów i część plików zostaje na starym serwerze.Disallow w robots, bez nagłówka X-Robots-Tag: noindex i bez hasła HTTP wpada do indeksu i konkuruje z produkcją. Po cutoverze sprawdź, czy noindex zniknął — zostawiony blokuje cały sklep.Kolejność prac przy przenoszeniu sklepu z WooCommerce rozpisaliśmy w planie wdrożenia i migracji PrestaShop Józefów — punkty krytyczne są tam te same, więc łatwo porównać z własnym harmonogramem.
| Pułapka | Jak wykryć przed launchem | Próg zaliczenia |
|---|---|---|
| Brak 301 | Zestawienie starych URL z nowym sitemap.xml | 0 adresów bez mapowania, 410 dla wycofanych |
| Duplikaty link_rewrite | SQL: GROUP BY link_rewrite, id_lang HAVING COUNT(*) > 1 | 0 wierszy w wyniku |
| Znikające media | Crawl stagingu, raport błędów 404 na plikach /img/ | 0 błędów 404 dla zdjęć |
| Ceny brutto/netto | 3–5 zamówień testowych na różnych grupach i walutach | Zgodność 1:1 z arkuszem cennika |
| Webhooki płatności | Transakcja w sandboxie na nowej domenie | Status „opłacone” + e-mail potwierdzający |
| Indeksowanie stagingu | curl -I na staging, podgląd robots.txt | noindex obecny na stagingu, brak na produkcji |
| Wydajność 10 000+ SKU | TTFB kategorii i wyszukiwarki na stagingu | TTFB kategorii poniżej 1 s, cache aktywny |
Wdrożenie kończy się w dniu cutoveru, ale sklep zaczyna żyć później. Bez ustalonej opieki pierwsza aktualizacja modułu albo zmiana wersji PHP na hostingu zostaje zrobiona „na produkcji, w piątek”, a skutki naprawia się w poniedziałek.
Zakres opieki zapisz punktowo: aktualizacje PrestaShop i modułów, kopie zapasowe bazy i plików (minimum raz dziennie, retencja 30 dni, test odtworzenia raz na kwartał), monitoring uptime z próbą co minutę, reakcja na incydenty, comiesięczny przegląd logów 404 i błędów PHP.
SLA to nie hasło marketingowe, a tabela. Powinny się w nim znaleźć: czas reakcji, czas naprawy, kanał zgłoszeń, godziny wsparcia i definicja awarii krytycznej — sklep nie przyjmuje zamówień albo bramka płatności nie odpowiada. Bez tej definicji każde zgłoszenie staje się krytyczne i kolejka przestaje działać.
Monitoring po starcie obejmuje Search Console (błędy indeksowania, nowe 404, spadki wyświetleń), logi 404, czas ładowania i Core Web Vitals — Google opisuje, które metryki bierze pod uwagę w wynikach wyszukiwania — oraz cotygodniowy test koszyka i ścieżki płatności: dodaj produkt, nałóż kupon, wybierz kuriera, wejdź na bramkę i przerwij.
Aktualizacje na produkcji zawsze przez staging: kopia → środowisko testowe → aktualizacja modułu → test koszyka, płatności, faktury i maili → okno serwisowe → produkcja. Automatyczne aktualizacje w panelu wyłącz. Ręczne wdrożenie bez testu to najczęstsza przyczyna sklepu bez zamówień na kilka godzin.
Przykładowe zakresy opieki rozpisaliśmy w materiale o organizacji po wdrożeniu w Krasnobrodzie i w planie dla Zwierzyńca — różnią się głównie liczbą integracji, nie logiką pracy.
| Element SLA | Wartość przykładowa | Po co to zapisać |
|---|---|---|
| Czas reakcji | 4 h w dni robocze 8:00–16:00 | Odróżnia „odezwiemy się” od konkretnego zobowiązania |
| Czas naprawy — awaria krytyczna | do 8 h | Sklep bez zamówień generuje stratę liczoną w godzinach |
| Czas naprawy — zwykłe zgłoszenie | do 3 dni roboczych | Porządki w treściach nie mogą blokować obsługi awarii |
| Kanał zgłoszeń | mail + telefon tylko dla awarii krytycznych | Telefon bez maila gubi historię ustaleń |
| Limit pracy w pakiecie | np. 5 h/mies., nadwyżka wg stawki godzinowej | Pakiet bez limitu kończy się konfliktem |
| Godziny wsparcia | 8:00–16:00 albo 24/7 | Tryb całodobowy zwykle jest osobną pozycją w cenniku |
Checklista przed cutoverem jest krótka, ale każdy punkt musi mieć właściciela. Bez tego zawsze zostają niezrobione te same dwa: poczta i płatności.
Ten sam schemat działa w całym regionie: w organizacji wdrożenia w Biłgoraju i w planie dla Szczebrzeszyna zmieniają się integracje, ale punkty krytyczne są identyczne. Jeśli działasz w Frampolu, Józefowie, Krasnobrodzie albo Zwierzyńcu, możesz użyć tej listy bez zmian.
Do wyceny w widełkach wystarczy jeden mail: dostępy, liczby i lista integracji. Dostępy — FTP/SFTP, SSH, panel hostingu i DNS, admin PrestaShop, Search Console, GA4, panele płatności i kurierów. Liczby — SKU, kategorie, kombi producentów, zamówienia miesięcznie, języki, waluty, grupy klientów, rozmiar bazy. Integracje — wymień po nazwie, z informacją, czy zostają. Dorzuć planowany termin startu i to, czy chcesz opiekę po wdrożeniu, czy samo uruchomienie. Bez tych danych każda wycena jest zgadywaniem i widełki wychodzą szerokie.
| Co wysłać wykonawcy | Format | Jak wpływa na wycenę |
|---|---|---|
| Dostępy | FTP/SFTP, SSH, panel hostingu i DNS, admin PrestaShop, GSC, GA4 | Bez dostępu do bazy i SSH wycena migracji to zgadywanie |
| Liczby | SKU, kategorie, kombi, zamówienia/mies., języki, waluty, grupy klientów, rozmiar bazy | 500 SKU i 20 000 SKU to dwie różne prace |
| Integracje | płatności, kurierzy, ERP/Subiekt, faktury, marketplace, newsletter | Każda integracja to osobne godziny i osobny test po cutoverze |
| Termin i okno serwisowe | data startu, godziny przełączenia, sezonowość | Start w listopadzie wycenia się inaczej niż w lutym |
| Zakres po starcie | samo uruchomienie albo opieka z SLA | Opieka to stały koszt miesięczny, nie jednorazowy |
Zapytanie ofertowe nie rozróżnia wdrożenia od migracji
Jak wykryć: Dostajesz wyceny różniące się kilkukrotnie i nie wiesz, dlaczego jedna firma liczy tak mało, a druga tak dużo.
Jak naprawić: W zapytaniu napisz wprost: czy sklep już istnieje, na jakiej platformie działa, ile ma produktów i czy historia zamówień ma zostać przeniesiona. Bez tego wyceny nie da się porównać.
Dostępy do panelu, serwera, DNS i API zbierane dopiero w trakcie prac
Jak wykryć: Wykonawca pyta o hasła w drugim albo trzecim tygodniu projektu, a Ty szukasz kontaktu do poprzedniego wykonawcy.
Jak naprawić: Zrób listę dostępów przed dniem pierwszym i sprawdź, czy każde dane logowania faktycznie działa. To najtańszy sposób na skrócenie projektu.
Brak mapy URL-i i planu przekierowań 301
Jak wykryć: Po przełączeniu domeny w Search Console rośnie liczba błędów 404, a ruch z wyszukiwarki spada.
Jak naprawić: Przed cutoverem wyeksportuj wszystkie adresy kategorii i produktów do pliku CSV i przygotuj dla nich przekierowania. To praca wykonywana raz, przed startem, nie po nim.
Założenie, że migracja przenosi automatycznie wszystko
Jak wykryć: Nikt nie zapytał, czy przenosimy zamówienia historyczne, klientów i koszyki porzucone — po prostu przyjęto, że tak.
Jak naprawić: Ustal osobno dla każdej tabeli: importujemy, archiwizujemy czy pomijamy. Decyzję podejmij na etapie audytu, bo wpływa na czas i koszt.
Integracje płatności i kurierów testowane dopiero po przełączeniu na produkcję
Jak wykryć: Nie ma ustalonego testu na środowisku testowym operatora płatności ani na sandboxie API kuriera.
Jak naprawić: Zamów dane do sandboxa z wyprzedzeniem i przetestuj pełną ścieżkę zamówienia — od koszyka do potwierdzenia wysyłki — zanim ruszy cutover.
Projekt kończy się w dniu przełączenia domeny
Jak wykryć: Po dwóch tygodniach nikt nie sprawdził błędów 404, indeksacji ani pierwszych zamówień.
Jak naprawić: Zaplanuj osobny etap monitoringu po starcie: przekierowania, indeksacja, wydajność i zamówienia. Typowo dwa tygodnie obserwacji.
Migracja i wdrożenie to dwa różne projekty, a różnicę widać już na poziomie listy dostępów i mapy URL-i. Jeśli przed startem zbierzesz dane o produktach, modułach i integracjach, harmonogram 2–6 tygodni jest realny. Jeśli audyt pominiesz, te same prace rozjadą się o kolejne tygodnie. Zacznij od checklisty, a dopiero potem wybieraj szablon i wykonawcę.
Typowy projekt zamyka się w 2–6 tygodniach, ale to widełki, nie obietnica. Najwięcej czasu zabiera import danych i testy integracji, a nie sama instalacja PrestaShop. Jeśli audyt wykaże dużą liczbę kombinacji produktów albo nietypowe moduły, harmonogram trzeba rozciągnąć.
To decyzja biznesowa, nie techniczna. Historia zamówień bywa potrzebna do obsługi reklamacji i zwrotów, ale jej import bywa kosztowny i wymaga czyszczenia danych. Koszyki porzucone często lepiej zostawić w archiwum niż przenosić. Ustal to na etapie audytu — zmiana decyzji w trakcie importu oznacza powtórzenie pracy.
Przy poprawnej mapie przekierowań 301 i zachowaniu struktury adresów nie powinno dojść do trwałego spadku. Ryzyko rośnie, gdy adresy produktów zmieniają się bez przekierowań albo gdy nowa strona ma gorszą wydajność. Warto też pilnować danych strukturalnych i czasu ładowania — Google opisuje te zależności w dokumentacji o danych strukturalnych i Core Web Vitals.
Tak, ale to nie jest aktualizacja w miejscu. Zwykle buduje się nową instalację PrestaShop 8 i importuje do niej dane, a moduły przepisuje lub zastępuje. Część starych modułów nie ma odpowiednika dla wersji 8 i trzeba je wygasić. Punktem wyjścia jest dokumentacja dla deweloperów dostępna w PrestaShop Developer Documentation.
Tak, to jedna z częstszych migracji. Kluczowe jest odwzorowanie produktów z wariantami, kategorii i klientów oraz zachowanie adresów URL. Warto wcześniej przejrzeć dokumentację WooCommerce, żeby ustalić, jak nazwane są dane w starym sklepie i jak mapują się na strukturę PrestaShop.
Większość prac wykonuje się zdalnie i nie wymaga dojazdu: audyt, instalacja, konfiguracja, import, integracje. Spotkanie na miejscu przydaje się przy odbiorze projektu, ustaleniu zakresu i szkoleniu zespołu. Klienci z Krasnobrodu, Zwierzyńca czy Józefowa pracują z nami w tym samym trybie co firmy z Lublina — różnica dotyczy logistyki spotkań, nie jakości wdrożenia.
Lista dostępów do panelu, serwera i DNS, dane do API płatności i kurierów, decyzja o zakresie importu historii zamówień oraz informacja o modułach, które muszą działać dalej. To cztery rzeczy, których brak najczęściej przesuwa start projektu o tygodnie.
Jeśli chcesz, żebyśmy przeliczyli Twój projekt na konkretny zakres prac i harmonogram, napisz do DropDigital i podaj, na jakiej platformie działa dziś sklep oraz ile ma produktów. Odpowiemy wprost, co da się przenieść, a co lepiej zbudować od nowa.