Wdrożenia i migracje PrestaShop w Chełmie i okolicy sprowadzają się do jednego pytania: budujesz sklep od zera czy przenosisz istniejący z WooCommerce, Magento albo starej wersji PrestaShop? Od tej odpowiedzi zależy zakres prac, liczba roboczogodzin i termin startu — nie od tego, jak ładnie wygląda oferta. Poniżej porządkujemy stronę organizacyjną projektu: jak w 2 minuty zakwalifikować własny przypadek, jakie dane zebrać przed podpisaniem umowy i jak wygląda realny harmonogram 4–8 tygodni. Każdy etap ma konkretny efekt, a nie ogólne „optymalizujemy i wdrażamy”.
Klienci mówią „potrzebuję nowego sklepu” i tym zdaniem opisują dwa różne projekty. Wdrożenie to zbudowanie sklepu na PrestaShop od zera. Migracja to przeniesienie istniejącego sklepu z WooCommerce, Magento, Shopware albo ze starej wersji PrestaShop 1.6/1.7 na 8.x. Różnica ma skutki projektowe: przy wdrożeniu sam ustalasz strukturę kategorii i adresów URL, przy migracji najpierw odwzorowujesz to, co już działa, i pilnujesz, żeby nie zniknęło z Google.
Cztery sygnały, że potrzebujesz wdrożenia od zera:
Trzy sygnały, że to migracja:
Trzeci scenariusz — przebudowa in place. Zostajesz na PrestaShop, ale naprawiasz strukturę: kanoniczne URL-e, drzewo kategorii, duplikaty produktów, motyw i wydajność. Platforma i baza zostają te same, więc ryzyko jest najniższe, a zysk często największy. Założenia takiego projektu opisujemy m.in. przy wdrożeniach i migracjach PrestaShop w Hrubieszowie oraz w organizacji projektu w Lublinie.
| Scenariusz | Punkt startu | Typowy czas | Główne ryzyko |
|---|---|---|---|
| Wdrożenie od zera | brak platformy lub brak historii SEO | 4–8 tygodni | brak danych do wyceny, pusty katalog na start |
| Migracja | WooCommerce, Magento, PS 1.6/1.7 | 6–10 tygodni | utrata pozycji i przekierowań, martwe integracje |
| Przebudowa in place | PrestaShop, który działa | 2–4 tygodnie | wysokie oczekiwania bez zmiany platformy |
Niedoszacowanie bierze się z brakujących danych, nie z trudnej technologii. Zanim podpiszesz umowę, zbierz dziewięć rzeczy. Zajmie to kilkadziesiąt minut, a oszczędza tygodnie sporów o zakres.
du -sh /var/lib/mysql albo rozmiar dumpu. Baza 4 GB zmienia plan przenoszenia i długość okna serwisowego.php -v) i MySQL/MariaDB (SELECT VERSION();). PrestaShop 8.x wymaga nowoczesnego stacku — aktualną listę wspieranych wersji trzymaj z dokumentacji deweloperskiej PrestaShop.override/ bez dokumentacji to najdroższy element projektu.Zbierz to w jednym dokumencie i załącz do zapytania ofertowego. Jeśli brakuje punktu 9, dolicz 15–20% rezerwy. Podobny zakres audytu przechodzimy przy projekcie wdrożenia i migracji PrestaShop w Narolu.
Kolejność prac jest ważniejsza niż tempo. Poniżej realny przebieg projektu dla MŚP — bez skrótów w stylu „postawimy na produkcji, będzie szybciej”.
Realny harmonogram dla MŚP: 4–8 tygodni przy sklepie do 5 tys. SKU z 2–3 integracjami. Podobne założenia stosujemy przy wdrożeniu PrestaShop w Biłgoraju i przy migracji sklepu w Bełżcu.
| Etap | Typowy czas | Efekt |
|---|---|---|
| Brief i audyt stanu wyjściowego | 2–3 dni robocze | zakres, lista integracji, decyzja o historii zamówień |
| Staging na osobnym VPS | 1 dzień | środowisko testowe odizolowane od produkcji |
| Instalacja PS 8.x, motyw, UX koszyka i checkoutu | 1–2 tygodnie | sklep z działającym procesem zakupu |
| Moduły: płatności, kurierzy, ERP, faktury | 1–2 tygodnie | integracje działające na stagingu |
| Import danych i mapowanie atrybutów | 3–5 dni | katalog, klienci i stany zgodne ze źródłem |
| Testy funkcjonalne i wydajnościowe (2 rundy QA) | 1 tydzień | lista błędów zamknięta przed cutoverem |
| Cutover + monitoring | 2–3 dni + 7 dni | sklep na produkcji z raportem po tygodniu |
Migracja to nie „przenosimy sklep”, tylko kilkanaście osobnych operacji. Przed podpisaniem umowy poproś wykonawcę o rozbicie prac na dwie kolumny: to, co wchodzi automatem, i to, co wymaga decyzji człowieka. Szersze ujęcie organizacyjne znajdziesz w materiale o wdrożeniach i migracjach PrestaShop w Lublinie.
Przenosi się w całości, przez import CSV lub API:
W PrestaShop import uruchomisz w Zaawansowane parametry → Import: plik CSV w UTF-8, separator średnik, kolumny mapowane na pola bazy (name, reference, price, id_category). Import nie tworzy relacji, których nie ma w pliku — kombinacje generujesz osobno i to zwykle najdroższy element całej migracji. Składnię pól i modułów opisuje dokumentacja developerska PrestaShop.
Wymaga mapowania, czyli pracy ręcznej: URL-e produktów i kategorii (tabela źródło → cel, z której generujesz reguły .htaccess), meta title i description z limitami znaków, wielopoziomowe drzewo kategorii, jednostki miary i format liczb w CSV. Zawsze zachowaj tabelę stary ID → nowy ID — bez niej przekierowania 301 nie powstaną.
Nie przenosi się: historia koszy i sesji, wewnętrzne ID produktów (nowa platforma nada własne), wtyczki specyficzne dla źródła. Hasła klientów: jeśli algorytm hashowania jest zgodny, importujesz skróty; jeśli nie — wymuszasz reset przy pierwszym logowaniu. W praktyce przy przejściu z WooCommerce czy Magento bezpieczniej założyć reset i przygotować mailing. Historia zamówień to decyzja: albo wrzucasz ją do aktywnej bazy i wiążesz z nowymi ID, albo archiwizujesz w read-only i pokazujesz klientowi osobno. Dokumenty księgowe i tak musisz przechowywać — ich nie kasujesz w żadnym z wariantów.
| Element | Status | Co trzeba zrobić |
|---|---|---|
| Produkty, kategorie, atrybuty | Przenosi się 1:1 | Import CSV (UTF-8, średnik), mapowanie kolumn na pola bazy |
| Stany magazynowe, ceny, EAN | Przenosi się 1:1 | Import razem z produktami, potem korekta po inwentaryzacji |
| Galeria zdjęć | Przenosi się 1:1 | Kopiowanie plików i przypisań, kompresja oraz konwersja do WebP |
| Kombinacje (warianty) | Wymaga pracy | Regeneracja kombinacji, limit liczby wariantów na produkt |
| URL-e produktów i kategorii | Wymaga pracy | Tabela stary → nowy URL, z niej reguły .htaccess |
| Meta title / description | Wymaga pracy | Przepisanie lub obcięcie do limitów pól |
| Drzewo kategorii | Wymaga pracy | Przeprojektowanie struktury, decyzja o wielopoziomowości |
| ID produktów | Nie przenosi się | Tabela stary ID → nowy ID (potrzebna do 301 i zamówień) |
| Historia koszy i sesji | Nie przenosi się | Pomijasz |
| Wtyczki źródłowej platformy | Nie przenosi się | Zastąpienie modułami PrestaShop |
| Hasła klientów | Zależne od algorytmu | Import skrótów przy zgodnym hashowaniu albo reset przy pierwszym logowaniu |
| Historia zamówień | Decyzja | Aktywna baza albo archiwum read-only; dokumenty księgowe trzymasz zawsze |
Spadek ruchu po migracji rzadko wynika z „kary Google”, prawie zawsze z konkretnych błędów technicznych. Poniżej sześć, które widzimy najczęściej — z sposobem wykrycia.
Przed cutoverem zamroź zmiany na starym sklepie na 24–48 godzin i zrób pełny eksport, a starą domenę trzymaj z 301 przez minimum rok. Ten sam schemat stosujemy w mniejszych miejscowościach — zobacz np. organizację wdrożeń i migracji PrestaShop w Hrubieszowie.
| Kiedy | Co sprawdzasz | Gdzie |
|---|---|---|
| Dzień 0 (przed cutoverem) | Top 100 fraz: pozycje, CTR, adresy z największym ruchem | GSC → Skuteczność, eksport do arkusza |
| Dzień 1–3 | Status 200/301 na 50 losowych URL-ach z mapy, brak łańcuchów | curl -I lub crawler (np. Screaming Frog) |
| Dzień 7 | Indeksacja nowych adresów, błędy w raporcie stron | GSC → Indeksowanie → Strony |
| Dzień 14 | Skuteczność przekierowań 301, liczba i typ 404 | GSC → Raport 404, logi serwera |
| Dzień 30 | Pozycje i CTR na top 100 fraz vs. zrzut z dnia 0 | GSC → Skuteczność |
| Dzień 30 i dalej | LCP, INP, CLS w porównaniu do starej wersji | CrUX w Search Console / PageSpeed Insights |
Widełki podajemy w godzinach, nie w „od X zł”. Powód jest prosty: dwie firmy z identyczną liczbą SKU mogą różnić się o połowę zakresu, jeśli jedna ma integrację z ERP, a druga wgrywa stany ręcznie.
Co podnosi cenę: niestandardowe moduły (konfigurator, integracja z API, którego nikt wcześniej nie podłączał), dedykowany motyw — projekt graficzny plus wdrożenie, wielojęzyczność (mnoży treści, meta, sitemapy i hreflang), B2B z cennikami indywidualnymi, wielopoziomowymi rabatami, limitami kredytowymi i zatwierdzaniem zamówień.
Model rozliczenia: stawka godzinowa plus raport przepracowanych godzin, z podziałem na zadania — co tydzień albo przy zamknięciu etapu. Żadnych widełek „z sufitu” i żadnych dopłat po cutoverze za rzeczy, które były w zakresie. Zmiana zakresu w trakcie to aneks z nową liczbą godzin, a nie cicha dopłata na końcu. Przykład rachunku: przy stawce 120 zł netto za godzinę małe wdrożenie 40–70 h to 4 800–8 400 zł netto. Podstaw swoją stawkę z oferty — to ilustracja mnożenia, nie cennik rynkowy. Podobny sposób rozliczania stosujemy przy projektach w innych miastach regionu, np. w wdrożeniach i migracjach PrestaShop w Biłgoraju.
| Zakres | Godziny | Co wchodzi |
|---|---|---|
| Małe wdrożenie (do 300 SKU, gotowy motyw, 1–2 płatności) | 40–70 h | Instalacja, konfiguracja, import produktów, płatności, wysyłka, podstawowe SEO, szkolenie |
| Średnie wdrożenie (300–3000 SKU, ERP + kurierzy + płatności) | 90–160 h | Jak wyżej plus integracje z ERP, wielokanałowa wysyłka, testy zamówień end-to-end |
| Migracja z WooCommerce / Magento / własnego CMS | 60–140 h | Eksport, import, regeneracja kombinacji, testy, cutover |
| Mapowanie SEO i przekierowania (osobna pozycja) | Wycena od liczby URL-i | Tabela stary → nowy URL, reguły .htaccess, weryfikacja w GSC |
Zanim podpiszesz umowę, podziel integracje na dwie grupy. Standardowe to gotowe moduły: bramka płatności (Przelewy24, Tpay, PayU, Stripe), kurier (InPost ShipX, DPD WebAPI, DHL24) i fakturowanie (Fakturownia, wFirma). Licencja takiej wtyczki to zwykle 200–800 zł rocznie za sztukę. Niestandardowe zaczyna się tam, gdzie wchodzi ERP z własnymi polami — Subiekt GT, Comarch Optima — albo autorska logika cenowa: ceny kontrahenta, progi rabatowe, kursy walut. Gotowego modułu nie ma, a obejście przez eksport CSV przenosi pracę na człowieka.
Policz to w horyzoncie trzech lat, nie jednego miesiąca. Sześć wtyczek po 400 zł/rok to 7 200 zł. Jeden własny moduł łączący płatności, kurierów i ERP to zwykle 4 000–10 000 zł jednorazowo plus około 10% rocznie na utrzymanie. Przy trzech i więcej integracjach oraz logice, której nie ustawisz w panelu, własny kod wychodzi taniej — i nie zniknie, gdy wydawca wtyczki przestanie ją rozwijać.
Każdą integrację testuj na sandboxie przed produkcją. Ustal scenariusz awaryjny: gdy API kuriera nie odpowiada, zamówienie nadal zapisuje się w sklepie, etykieta trafia do kolejki, a klient dostaje informację o ręcznym nadaniu. Bez tego jedna godzina awarii po stronie przewoźnika oznacza kilkadziesiąt zgłoszeń.
Zapytaj wprost: kto trzyma klucze API i opłaca licencje, kto odpowiada za aktualizację modułu, gdy kurier zmieni wersję API, i kto odtworzy dokumentację, jeśli współpraca się skończy. Standard wtyczek opisuje dokumentacja dla deweloperów PrestaShop.
| Integracja | Typ | Co musi przejść test | Model kosztu |
|---|---|---|---|
| Przelewy24 / Tpay / PayU | standardowa | webhooki statusów, zwroty, BLIK | wtyczka, licencja roczna |
| InPost Paczkomaty (ShipX) | standardowa | mapa punktów, etykieta PDF, statusy, webhook zwrotny | wtyczka lub własny moduł |
| DPD / DHL | standardowa | etykiety, tracking, przesyłka zwrotna, pobranie | wtyczka, licencja roczna |
| Subiekt GT / Comarch Optima | niestandardowa | stany, zamówienia, dokumenty, pola własne | własny moduł + utrzymanie |
Wdrożenie kończy się w dniu startu, ale sklep pracuje dalej. W umowie utrzymaniowej muszą być trzy liczby: czas reakcji, czas naprawy i okno serwisowe. Bez nich „wsparcie” oznacza odpowiedź wtedy, gdy wykonawca ma czas.
Wybór wykonawcy sprowadza się do pięciu punktów: rozmawiasz bezpośrednio z deweloperem, nie z pośrednikiem; dostajesz referencje z adresami działających sklepów; pokazuje własne moduły, a nie tylko opis; SLA jest w umowie, nie w e-mailu; na koniec przekazuje repozytorium i dostępy. Kontekst lokalny ma znaczenie w jednej rzeczy: praca zdalna z Chełma, Zamościa czy Lublina kosztuje tyle samo co stacjonarna, ale liczy się polski support i ta sama strefa czasowa. Jak wygląda to w większym mieście, opisujemy przy okazji projektu wdrożenia i migracji PrestaShop w Lublinie.
| Priorytet | Przykład | Czas reakcji | Czas naprawy |
|---|---|---|---|
| Krytyczny | sklep nie działa, płatności odrzucają transakcje | do 1–4 godzin | do 8 godzin |
| Wysoki | nie generują się etykiety, błąd w koszyku | do 8 godzin | do 24 godzin |
| Normalny | błąd w treści, zmiana w szablonie | 24–48 godzin | wg terminu z wyceny |
Zakres ustalany na podstawie liczby SKU podanej „na oko”. Klient mówi „mamy około 2000 produktów”, a w bazie siedzi 2000 produktów i 18 000 kombinacji atrybutów (rozmiar, kolor, wariant). Import i indeksowanie katalogu trwają wtedy kilka razy dłużej niż zakładano.
Jak wykryć: Wejdź w panel i porównaj liczbę produktów z liczbą wierszy w tabeli product_attribute w bazie MySQL. Jeśli stosunek jest większy niż 1:5, traktuj projekt jako katalog kombinacji, nie prosty katalog produktów.
Jak naprawić: Przed wyceną policz osobno produkty, kombinacje i kategorie. Wpisz do umowy stawkę za dodatkowy dzień prac importowych i próg, po którym zakres wymaga aneksu.
Praca bezpośrednio na produkcji. Wdrożenie prowadzone na żywym sklepie kończy się przerwami w sprzedaży, nadpisanymi szablonami i brakującą możliwością cofnięcia zmian.
Jak wykryć: Zapytaj wprost, na jakim środowisku będą prowadzone prace i czy baza staging jest odświeżana z produkcji. Odpowiedź „będziemy robić na kopii, ale czasem wejdziemy na żywo” oznacza brak procesu.
Jak naprawić: Wymagaj osobnego VPS-a staging z własną bazą i osobnym adresem, z blokadą indeksowania (noindex) i ograniczeniem dostępu po IP.
Import produktów przed ustaleniem struktury kategorii i atrybutów. Kategorie trzeba potem przebudowywać, a produkty przepinać ręcznie — podwójna praca i ryzyko bałaganu w URL-ach.
Jak wykryć: Sprawdź, czy istnieje dokument mapowania: stara kategoria → nowa kategoria, stary atrybut → nowa cecha, jednostka miary → jednostka docelowa. Brak dokumentu przed pierwszym importem to czerwona flaga.
Jak naprawić: Zamroź strukturę katalogu na piśmie i zaakceptuj ją przed importem. Import wykonaj najpierw na 50 produktach testowych, dopiero potem na całości.
Modyfikacje rdzenia i motywu bez dokumentacji. Po dwóch latach nikt nie wie, kto zmienił plik, dlaczego i czy zmiana przetrwa aktualizację.
Jak wykryć: Poproś o repozytorium Git i listę modułów spoza oficjalnego katalogu Addons. Jeśli odpowiedź brzmi „to robił pan X, ale już go nie ma”, projekt startuje bez historii zmian.
Jak naprawić: Zanim cokolwiek przeniesiesz, zrób inwentaryzację nadpisań (override) i modułów. Wszystko, co nie jest w repozytorium, traktuj jako kod do przepisania, nie do przeniesienia.
Traktowanie migracji jak kopiowania bazy 1:1. Produkty faktycznie przenoszą się w całości, ale adresy URL, meta title i drzewo kategorii wymagają mapowania — inaczej tracisz ruch organiczny z pozycji, które budowałeś latami.
Jak wykryć: Sprawdź, czy ktoś przygotował arkusz stary URL → nowy URL dla produktów i kategorii oraz plan wdrożenia przekierowań 301. Brak arkusza = brak planu na SEO.
Jak naprawić: Wyciągnij z Google Search Console listę najczęściej klikanych adresów i zabezpiecz je przekierowaniami w pierwszej kolejności. Nowe adresy projektuj raz, przed importem, nie po starcie. Zasady budowania adresów i treści znajdziesz w dokumentacji Google o treściach tworzonych dla ludzi: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
Cutover w poniedziałek rano albo w szczycie sezonu. Przełączenie DNS i bazy w godzinach sprzedaży oznacza, że każdy błąd widzi klient, a nie zespół.
Jak wykryć: Zapytaj o okno serwisowe i termin przełączenia. Jeśli padnie „w ciągu dnia” bez okresu poza sezonem, plan jest ryzykowny.
Jak naprawić: Przełączenie rób w nocy, poza kampaniami i świętami branżowymi, po dwóch rundach QA. Po starcie utrzymaj podwyższony monitoring przez 7 dni i miej gotowy plan rollbacku.
Strona organizacyjna projektu waży więcej niż wybór motywu. Najpierw zakwalifikuj przypadek — wdrożenie od zera, migracja czy przebudowa in place — potem zbierz dane o SKU, bazie, serwerze i integracjach, a dopiero na końcu ustal harmonogram i cenę. Wdrożenie do 5 tys. SKU z 2–3 integracjami to realnie 4–8 tygodni, z dwiema rundami testów i nocnym cutoverem. Jeśli któryś z tych elementów wypada z planu, ryzyko przenosi się na dni po starcie, czyli dokładnie tam, gdzie boli najbardziej.
Wdrożenie to budowa nowego sklepu na PrestaShop — bez historii i bez przenoszenia danych z innego systemu. Migracja to przeniesienie istniejącego sklepu z innej platformy (WooCommerce, Magento, własne rozwiązanie) albo ze starej wersji PrestaShop 1.6/1.7 na 8.x. Jest jeszcze trzeci scenariusz: przebudowa in place — zostajesz na PrestaShop, ale naprawiasz strukturę katalogu, motyw i wydajność bez zmiany platformy.
Dla sklepu do 5 tys. SKU z 2–3 integracjami sensowny harmonogram to 4–8 tygodni. Krótszy termin zwykle oznacza, że pominięto etap testów albo importu, a to wychodzi dopiero po starcie. Na sam brief z audytem zaplanuj 2–3 dni robocze, a na dwie rundy QA przed cutoverem — minimum tydzień.
Nie, jeśli przygotujesz mapowanie adresów URL i przekierowania 301 przed startem. Produkty i treści przenoszą się w całości, ale adresy i meta opisy wymagają pracy. Uwaga szczególnie na najczęściej klikane adresy z Google Search Console oraz na czasy ładowania — to obszar, w którym warto pilnować wskaźników z dokumentacji https://developers.google.com/search/docs/appearance/core-web-vitals i https://web.dev/articles/vitals.
Dane klientów i zamówień można przenieść, ale trzeba zdecydować, czy zostają w bazie operacyjnej, czy idą do archiwum read-only. Duża historia spowalnia panel i wydłuża migrację, a przy części platform źródłowych nie da się jej przenieść bez strat. Ustalenie tego przed startem jest tańsze niż przenoszenie „na wszelki wypadek” wszystkiego.
Hosting współdzielony wystarcza dla sklepów z bardzo małym katalogiem i brakiem integracji, ale przy kilku tysiącach SKU i module ERP szybko trafisz na limity pamięci i współdzielone CPU. Osobny VPS daje kontrolę nad wersją PHP, konfiguracją bazy i miejscem na środowisko staging. To również warunek prowadzenia prac bez dotykania produkcji.
Nie podajemy jednej liczby, bo zakres zmienia się drastycznie: inne prace to nowy sklep z jedną integracją płatności, inne to migracja z WooCommerce z ERp-em, mapowaniem URL-i i archiwizacją 60 tys. zamówień. Koszt wyceniamy po audycie, na podstawie realnej liczby SKU, kombinacji, integracji i modyfikacji własnych. Wycena bez tych danych jest zgadywaniem.
Zdarza się to regularnie, gdy źródłowa baza ma zduplikowane kategorie, martwe moduły i brak dokumentacji. Wtedy taniej wychodzi przebudowa struktury na PrestaShop z przeniesieniem danych niż przenoszenie błędu razem z danymi. Warto ustalić w umowie punkt kontrolny po audycie, w którym obie strony mogą zmienić kierunek bez kar.
Jeśli chcesz przejść przez audyt i harmonogram przed podpisaniem umowy, opisz krótko swój przypadek — platformę, liczbę SKU i integracje. Zobacz też, jak organizujemy podobne projekty w regionie: https://dropdigital.pl/wdrozenia-i-migracje-prestashop-lublin-organizacja i https://dropdigital.pl/wdrozenia-i-migracje-prestashop-bilgoraj-organizacja.