Wdrożenie PrestaShop dla firmy ze Szczecina najczęściej zajmuje 4–8 tygodni, ale migracja z WooCommerce, Shopify albo starego PrestaShop to osobny projekt z własnym ryzykiem — przede wszystkim dla pozycji w Google. Ten tekst porządkuje oba scenariusze: co trzeba przygotować, w jakiej kolejności pracować i gdzie projekty realnie się zatrzymują. Nie znajdziesz tu obietnic, że wystarczy 5 dni, bo tak nie jest. Znajdziesz sekwencję prac, widełki godzinowe i checklistę, którą da się zamknąć przed pierwszym spotkaniem — ogólne zasady organizacji projektu też są tu rozwinięte.
Wdrożenie od zera to projekt, w którym sklep dopiero powstaje: instalujesz PrestaShop na nowym hostingu, budujesz katalog od pustej bazy, konfigurujesz płatności i kurierów. Migracja to przeniesienie istniejącego sklepu — z WooCommerce, Shopify albo starszego PrestaShop (1.6 / 1.7) — razem z produktami, kombinacjami, zdjęciami, kategoriami, klientami i zamówieniami. Najdroższym elementem migracji nie jest import danych, tylko utrzymanie ruchu z Google, który generuje przychód.
Trzy przypadki, w których technicznie lepiej zostać na obecnej platformie:
Jeśli decyzja pada na PrestaShop, celuj w gałąź 8.x i PHP 8.1. Dokładną macierz zgodności PHP/MySQL dla konkretnej wersji minor sprawdź w dokumentacji dla deweloperów PrestaShop — część modułów nie nadąża za najnowszym PHP i wersja 8.3 potrafi wyłączyć sklep szybciej, niż się go włącza. Hosting przed startem musi spełnić: OPcache, memory_limit 256 MB lub więcej, max_execution_time 300 s (importy CSV i generowanie kombinacji), MySQL/MariaDB na InnoDB, dostęp SSH i cron, poprawne mod_rewrite oraz SSL. Zakres prac i kolejność etapów rozwijamy osobno przy temacie wdrożeń PrestaShop, a ogólne zasady organizacji projektu wdrożenia i migracji PrestaShop działają niezależnie od platformy źródłowej.
| Kryterium | Wdrożenie od zera | Migracja z innej platformy |
|---|---|---|
| Czas realizacji | 4–8 tygodni | 6–12 tygodni, zależnie od liczby URL-i |
| Orientacyjny nakład pracy | ok. 120–250 h | ok. 80–200 h + audyt SEO |
| Główne ryzyko | opóźnienia w treściach i decyzjach, brak sprzedaży przed launchem | spadek widoczności w Google i utrata danych przy imporcie |
| Wpływ na pozycje w Google | brak — nowa domena startuje od zera | realny; ogranicza go mapa przekierowań 301 i zachowanie slugów |
| Kiedy wybrać | nowy sklep, nowy katalog, zmiana modelu sprzedaży | sklep już sprzedaje, ale platforma ogranicza rozwój |
Harmonogram 4–8 tygodni rozbija się na osiem etapów. Czasy są orientacyjne dla sklepu do ok. 500 SKU w jednej wersji językowej, postawionego na PrestaShop 8.x.
Projekty zatrzymują się w czterech miejscach: brak decyzji o szablonie (tygodnie porównywania motywów, a prace frontendowe stoją), brak treści (opisy kategorii, zdjęcia, regulaminy — nikt ich nie wymyśli za klienta), brak danych do integracji (klucze API, dostęp do panelu kuriera, dokumentacja ERP) oraz brak dostępu do DNS (domena u poprzedniego wykonawcy to klasyczne opóźnienie o tydzień).
Sam staging nie wystarczy, jeśli się go tylko „przeklika”. Importuj na niego 20–50 prawdziwych zamówień z ostatnich 3 miesięcy i przejdź pełną ścieżkę: koszyk → zamówienie → mail potwierdzający → faktura → status w panelu → eksport do ERP. Bramkę płatniczą testuj w trybie sandbox, dopiero potem przełączaj produkcję.
| Etap | Po stronie klienta | Po stronie dewelopera | Decyzja biznesowa |
|---|---|---|---|
| Analiza | cele, lista funkcji, budżet | dokument zakresu i wycena | co wchodzi na start, a co w fazie 2 |
| Serwer i staging | dane dostępowe do domeny | konfiguracja, SSL, backup, cron | wybór hostingu i lokalizacji serwera |
| Szablon | akceptacja motywu i wyglądu | wdrożenie, responsywność, szybkość | wybór motywu — jedna decyzja z terminem |
| Katalog | dane produktów, zdjęcia, opisy | import, kombinacje, kategorie, cechy | format i kompletność danych źródłowych |
| Płatności i dostawa | umowy z bramką i kurierami, klucze API | konfiguracja modułów i testy | metody płatności i cennik dostaw |
| Testy i launch | testy akceptacyjne, treści prawne | testy techniczne, DNS, sitemap | data startu i okno serwisowe |
W migracji SEO jest kryterium akceptacji, nie dodatkiem. Kolejność prac:
RODO w praktyce: hasła przenoś jako skróty, nigdy jawnie — i tak bezpieczniej wymusić reset, bo skróty z WooCommerce i PrestaShop nie zawsze są zgodne. Zgody marketingowe przenoś tylko z dowodem: data, treść, źródło (checkbox, formularz); bez dowodu traktuj kontakt jako brak zgody. W zamówieniach przenoś minimum do obsługi reklamacji i księgowości, notatki wewnętrzne czyść.
Po 7 dniach sprawdź logi serwera pod kątem 404, łańcuchy przekierowań w crawlerze i błędy w raporcie Indeksowanie stron. Po 30 dniach porównaj kliknięcia z Search Console: spadek 10–20% w pierwszych dwóch tygodniach jest normalny, spadek 40% bez odbicia oznacza brakujące przekierowania lub canonicale wskazujące na stare adresy. Podobny zakres prac opisujemy w materiale wdrożenia i migracje PrestaShop Krasnobród dla firmy.
| Dane | Przenosimy? | Uwagi |
|---|---|---|
| Produkty, kategorie, cechy, zdjęcia | tak | CSV lub konektor; sprawdź kombinacje i stany magazynowe |
| Klienci | tak, z ograniczeniem | bez haseł jawnych; wymuś reset hasła po migracji |
| Zgody marketingowe | tylko udokumentowane | brak dowodu zgody = brak zgody |
| Zamówienia | tak, w zakresie niezbędnym | potrzebne do reklamacji, zwrotów i rozliczeń |
| Historia koszyków i sesje | nie | dane nieoperacyjne, obciążają bazę |
| Logi, cache, kopie starych wersji | nie | przenoszą błędy i bałagan do nowego środowiska |
| Dane płatnicze | nie | nie ma ich w bazie, jeśli płatność szła przez bramkę |
Wycena „od 3 000 zł” nie mówi nic, dopóki nie wiesz, ile godzin pracy za nią stoi. Realistyczne widełki dla PrestaShop 1.7 i 8.x wyglądają tak:
Wycena czytana pozycja po pozycji powinna się rozkładać na pięć bloków: konfiguracja serwera i środowiska (2–6 h), szablon i wygląd (8–20 h), funkcje sklepowe (10–25 h), import danych (8–30 h), testy i publikacja (8–16 h). Jeśli w ofercie nie ma osobnej pozycji „testy”, to albo jest ukryta w innych punktach, albo nikt jej nie zaplanował. W zapytaniu ofertowym doprecyzuj cztery rzeczy: stawkę netto za godzinę, limit godzin wliczonych w cenę, stawkę powyżej limitu i okres poprawek po odbiorze.
Czynniki, które realnie podnoszą budżet: integracja ERP (+40–120 h), mechanizmy B2B, czyli ceny indywidualne, limity kredytowe i grupy klientów (+30–80 h), drugi język (+15–40 h razem z tłumaczeniem e-maili i metadanych), wielosklepowość (+30–60 h, jeśli stany i konta klientów mają być wspólne).
Trzy przykładowe kosztorysy przy założonej stawce 140 zł/h netto: 55 h = 7 700 zł (wdrożenie na gotowym szablonie), 110 h = 15 400 zł (migracja z WooCommerce), 220 h = 30 800 zł (sklep z ERP i funkcjami B2B). Stawka to zmienna — liczy się iloczyn, nie sama kwota końcowa.
Sztywne „od X zł” jest wygodne dla wykonawcy: przy niedoprecyzowanym zakresie każda zmiana kończy się renegocjacją albo cichym obcięciem prac. Rozliczenie godzinowe pokazuje, co dokładnie kupujesz — dlatego przy porównywaniu ofert na wdrożenie PrestaShop pytaj o godziny, nie o cenę. Zanim usiądziesz do porównania, ustal kolejność prac; pomaga w tym opisana u nas organizacja projektu migracji PrestaShop.
| Scenariusz | Widełki godzinowe | Co wchodzi w zakres |
|---|---|---|
| Proste wdrożenie | 40–80 h | Szablon, podatki, dostawy, płatności, import do 300 produktów |
| Migracja z treścią | 60–150 h | Mapowanie kategorii, opisy, zdjęcia, przekierowania 301, testy |
| Sklep z ERP | 150–300 h | Stany, zamówienia, ceny, kolejki, obsługa błędów synchronizacji |
| Wdrożenie z B2B | +30–80 h | Ceny indywidualne, limity kredytowe, grupy klientów, faktury |
Projekt wdrożenia PrestaShop zatrzymuje się najczęściej nie na kodzie, a na brakujących materiałach. Cztery grupy, które warto zamknąć przed pierwszym spotkaniem.
Dostępy. Panel hostingu z kontem SSH (nie tylko FTP), dostęp do bazy MySQL, możliwość zarządzania rekordami DNS (A, CNAME, MX), potwierdzenie, że kopie zapasowe są włączone. Osobno: Google Analytics 4 (właściwość plus uprawnienia edytora), Search Console (weryfikacja domeny rekordem DNS — przy migracji zostaje na miejscu) oraz dostęp do domeny i certyfikatu SSL.
Treści. Unikalne opisy produktów o długości 400–1000 znaków, zdjęcia minimum 1000–1500 px na dłuższym boku, regulamin, polityka prywatności, zasady zwrotów (14 dni), informacje o dostawie i płatnościach, pełne dane firmy do stopki.
Dane operacyjne. Umowy z kurierami i numery klienta (InPost, DPD, DHL), konto w operatorze płatności — weryfikacja konta firmowego zajmuje zwykle 1–3 dni robocze — oraz dane do ERP: adres serwera, nazwa bazy, użytkownik z prawem odczytu i zapisu.
Decyzje biznesowe. Szablon: kupiony czy projektowany. Struktura kategorii, maksymalnie trzy poziomy. Waluty i źródło kursów. Języki. Sposób liczenia dostawy: progi kwotowe, waga, wymiary gabarytowe.
Pułapka, którą widzimy najczęściej: projekt stoi 4–6 dni, bo brakuje opisów produktów albo numeru klienta u kuriera. To dni policzone w harmonogramie, mimo że nikt wtedy nie pracuje. Druga: weryfikacja w Search Console zrobiona plikiem HTML zamiast rekordem DNS — przy zmianie adresu trzeba ją powtarzać. Wymagania techniczne dla konkretnej gałęzi sklepu sprawdzisz w dokumentacji dla deweloperów PrestaShop, a opis modułów i funkcji znajdziesz w naszej sekcji o PrestaShop. Całą checklistę przechodzimy też przy przygotowaniu firmy do migracji PrestaShop — warto ją zamknąć, zanim podpiszesz cokolwiek.
Tu siedzi większość budżetu. Kolejność prac: ERP, kurierzy, płatności.
ERP. W polskim MŚP najczęściej Subiekt GT/nexo, Comarch Optima i WF-Mag. Trzy tryby integracji: plikowy (eksport XML/CSV z Subiekta i import po stronie sklepu — najtańszy, opóźnienie 5–30 minut), API (nexo przez Sferę, Optima przez API/biblioteki — wymaga licencji i ustalonej wersji), bezpośredni odczyt bazy (MSSQL w Subiekcie i Optimie, Firebird w WF-Mag — szybkie, ale aktualizacja programu potrafi zepsuć mapowanie kolumn). Ustal przed startem: kierunek synchronizacji, częstotliwość, kto wygrywa przy konflikcie stanu magazynowego i po czym system poznaje, że zamówienie już przeszło.
Kurierzy. InPost ShipX API: etykiety, punkty odbioru przez Geowidget, zdarzenia statusowe. DPD: token, etykiety PDF/ZPL, osobne środowisko testowe. DHL: DHL24 oraz MyDHL API. W zapytaniu ofertowym sprawdź cztery rzeczy: generowanie etykiet, źródło statusów (webhook czy odpytywanie), obsługa zwrotów, limity zapytań na minutę.
Płatności. Przelewy24, PayU, tpay, BLIK — pytaj o prowizję, czas wypłaty, podpis webhooka i zachowanie sklepu przy płatności nieudanej: zamówienie ma zostać w stanie „oczekuje na płatność” czy przejść w anulowane.
Moduł gotowy czy na zamówienie? Cztery kryteria: pokrycie Twoich scenariuszy (zwroty, punkty odbioru, faktury), kto aktualizuje moduł po zmianie API i co dzieje się po wygaśnięciu subskrypcji, zgodność z Twoją wersją PrestaShop i PHP, koszt w trzyletnim horyzoncie, nie w pierwszym roku. Typowe stawki w marketplace to kilkaset złotych rocznie — własny moduł kosztuje więcej raz, ale nie zależy od cudzego harmonogramu. Więcej o tym, jak układamy te integracje, jest przy okazji integracji w projekcie PrestaShop.
Gdy API nie odpowiada. Kolejka w bazie, cron co minutę, ponowienia z rosnącym odstępem, log z ID zamówienia i treścią odpowiedzi. Standard HTTP opisuje to jednoznacznie — RFC 9110: kod 503 i nagłówek Retry-After mówią, kiedy wrócić.
| Integracja | Typowy tryb | Co sprawdzić w zapytaniu ofertowym |
|---|---|---|
| Subiekt GT / nexo | Plikowy XML/CSV albo Sfera | Kierunek i częstotliwość synchronizacji, obsługa konfliktów stanów |
| Comarch Optima | API, pliki wymiany lub baza | Zakres danych: stany, ceny, kontrahenci, zamówienia, faktury |
| WF-Mag | Plikowy, baza Firebird | Czy potrzebne dokumenty magazynowe i faktury po stronie sklepu |
| InPost ShipX | REST API + Geowidget | Etykiety, punkty odbioru, statusy zdarzeń, zwroty |
| DPD / DHL | REST API | Format etykiet, środowisko testowe, limity zapytań |
| Płatności (P24, PayU, tpay, BLIK) | Webhooki | Podpis webhooka, czas wypłaty, płatności nieudane i ponowienia |
Migracja nie kończy się w chwili przełączenia DNS. Największe ryzyko ujawnia się w kolejnych dniach, gdy robot Google od nowa odkrywa strukturę sklepu. Dlatego mapę przekierowań przygotuj przed startem, nie po nim. Zasada jest jedna: jeden stary URL trafia na jeden nowy URL, który zwraca 200. Bez łańcuchów A → B → C i bez kierowania na 404 — to drugi najczęstszy błąd po pominięciu adresów z filtrami i paginacją. Dane do mapy zbierasz z trzech miejsc: eksportu z Search Console (raport Indeksowanie stron, 1000 wierszy na plik), logów serwera z ostatnich 90 dni oraz tabel PrestaShop — ps_product_lang, ps_category_lang, ps_cms_lang, ps_manufacturer, ps_supplier. Reguły trzymaj w wersjonowanym pliku konfiguracyjnym (.htaccess przy Apache, dyrektywa return 301 przy Nginx). Przy migracji używaj 301, nie 302 — semantykę trwałego przekierowania opisuje RFC 9110 i to ona przenosi sygnały rankingowe.
Wydajność po launchu rozliczaj liczbami z Core Web Vitals: LCP poniżej 2,5 s, INP poniżej 200 ms, CLS poniżej 0,1 — liczone dla 75. percentyla ruchu mobilnego.
Po stronie serwera: pełny cache stron dla gości, cache Smarty, kompresja obrazów do WebP/AVIF, lazy loading poza pierwszym ekranem i CDN dla statyków. W bazie sprawdź EXPLAIN na zapytaniach z slow query log (próg 1 s) — brakujący indeks na ps_product_lang i ps_category_product potrafi wydłużyć TTFB o kilkaset milisekund. Kolejność tych prac opisujemy szerzej przy wdrożeniach PrestaShop. Na koniec: zgłoszenie zmiany w Search Console, ponowne wysłanie sitemap i kontrola indeksacji po 7 oraz 30 dniach.
| Metryka | Próg (75. percentyl) | Co najczęściej poprawiać w PrestaShop |
|---|---|---|
| LCP | poniżej 2,5 s | obraz hero bez WebP/AVIF, brak priorytetu dla obrazu LCP, TTFB bez cache stron |
| INP | poniżej 200 ms | nadmiar skryptów w hooku displayHeader, ciężkie moduły dodatków, blokujący JS |
| CLS | poniżej 0,1 | baner cookie bez zarezerwowanego miejsca, obrazy bez width/height, fonty bez font-display: swap |
SLA to nie obietnica szybkiej odpowiedzi, tylko tabela zdefiniowanych zdarzeń. Ustal trzy progi i opisz je przykładami, inaczej każde zgłoszenie będzie „krytyczne”. Zapis w stylu „reagujemy szybko” nie daje ci nic — liczy się konkretna godzina i zakres dostępności wsparcia.
Kopie zapasowe: codziennie baza i pliki, retencja minimum 30 dni, kopia poza serwerem produkcyjnym. Najważniejsze: raz na kwartał wykonaj pełny test odtworzenia na stagingu i zapisz wynik (data, czas odtworzenia, czy sklep wystartował). Backup, którego nikt nie odtworzył, nie jest backupem — to plik zajmujący miejsce.
Aktualizacje PrestaShop, PHP i modułów planuj w oknach serwisowych poza szczytem sprzedaży, zawsze najpierw na stagingu i z przejściem scenariusza zakupu: koszyk, kupon, płatność, mail z potwierdzeniem, status w zamówieniu. Wymagania wersji PHP znajdziesz w dokumentacji PrestaShop — trzymanie sklepu na PHP po zakończeniu wsparcia to prosta droga do awarii modułu płatności. Monitoring obejmuje co najmniej: dostępność sklepu (status 200 i czas odpowiedzi), ważność certyfikatu SSL, działanie cronów, kolejkę mailową oraz czas odpowiedzi bazy.
Poza SLA zostają nowe funkcje, przebudowa szablonu, wprowadzanie treści i kampanie marketingowe. Zapisz to wprost — inaczej w trzecim miesiącu pojawi się prośba o „drobny slider” w ramach abonamentu. Jeśli szukasz wykonawcy do takiego modelu współpracy w oparciu o PrestaShop, sprawdź, czy ma oddzielną stawkę godzinową dla prac rozwojowych i czy godziny z pakietu przechodzą na kolejny miesiąc.
| Typ zgłoszenia | Przykład | Czas reakcji | Czas naprawy |
|---|---|---|---|
| Awaria krytyczna | sklep nie działa, błąd 500 przy składaniu zamówienia, brak dostępu do panelu | 1 h | 4 h (godz. 8:00–18:00) |
| Błąd utrudniający zakupy | jedna metoda płatności nie przechodzi, maile z potwierdzeniem nie dochodzą | 4 h | 1 dzień roboczy |
| Zgłoszenie drobne | literówka, zły kolor przycisku, przesunięty element na mobile | 1 dzień roboczy | do 5 dni roboczych |
Zdecydowana większość projektu — realnie 80–90% — odbywa się zdalnie. Zbieranie wymagań, konfiguracja sklepu, migracja danych, prace na szablonie, testy, wdrożenie na produkcję: to wszystko dzieje się na serwerach deweloperskich, do których dostęp masz przez przeglądarkę. Nie ma znaczenia, czy wykonawca siedzi w Szczecinie, czy 400 km dalej — znaczenie ma wyłącznie to, czy odbiera telefony i czy dowozi uzgodnione terminy.
Na miejscu warto spotkać się w trzech sytuacjach: warsztat startowy (mapowanie procesu zamówieniowego, rola integratora, sposób wystawiania faktur i dokumentów sprzedaży), odbiór przed launchem z osobami, które na co dzień obsługują sklep — magazynem i obsługą klienta, oraz przy nietypowych integracjach, np. drukarka etykiet albo stany magazynowe w wielu lokalizacjach. Dwa–trzy spotkania na cały projekt to norma, nie codzienność.
Model komunikacji ustal na starcie: jedno miejsce na zgłoszenia (wspólna tablica albo skrzynka — nie mail plus telefon plus Messenger równolegle), bezpośredni kontakt z deweloperem zamiast przekazywania przez handlowca, stałe godziny konsultacji (np. wtorek i czwartek 10:00–12:00) i krótki cotygodniowy raport z postępu.
Dostępy przekazuj wyłącznie przez menedżera haseł z linkiem jednorazowym albo zaszyfrowany plik — nigdy w treści maila. Zakładaj osobne konta dla wykonawcy, nie udostępniaj swoich. Po zakończeniu współpracy odbierz dostęp i zmień hasła.
W umowie pilnuj czterech punktów niezależnie od lokalizacji: zakres z listą wykluczeń, stawka za godzinę, własność kodu i szablonu (z uwzględnieniem licencji modułów) oraz warunki wyjścia — eksport bazy i plików, przekazanie domeny i repozytorium. Szerszy układ etapów znajdziesz w materiale o organizacji projektu wdrożenia i migracji PrestaShop.
| Etap projektu | Zdalnie | Na miejscu |
|---|---|---|
| Zbieranie wymagań, konfiguracja, migracja danych | tak | opcjonalnie |
| Szkolenie obsługi sklepu | tak (z nagraniem) | zalecane |
| Diagnoza nietypowej integracji (drukarka, magazyn) | częściowo | zalecane |
Brak decyzji o szablonie przed startem prac — projekt stoi, a wszyscy czekają na wybór wyglądu.
Jak wykryć: Po dwóch tygodniach od startu w dokumentacji projektu nadal widnieje „wybieramy między trzema szablonami”.
Jak naprawić: Ustaw twardy termin decyzji i wybieraj po liście funkcji (widoki listy, filtry, obsługa wariantów), nie po tym, który demo ładniej się otwiera. Szablon kupiony 3 tygodnie po starcie konfiguracji oznacza przepisanie kilku rzeczy.
Migracja bez mapy przekierowań 301 — po przełączeniu DNS stary ruch trafia w 404.
Jak wykryć: Nie istnieje plik z listą „stary URL → nowy URL”. Test przed launchem zwraca kody 404 na adresach, które wcześniej generowały ruch.
Jak naprawić: Zrób eksport adresów ze starego sklepu (sitemap + crawl), przygotuj mapę 301 i nową sitemapę XML. Przekierowania działają w warstwie HTTP — warto rozumieć, czym jest kod 301 zgodnie ze specyfikacją (RFC 9110), bo to nie jest kwestia uznaniowa: https://www.rfc-editor.org/rfc/rfc9110.html
Przenoszenie haseł klientów w formie jawnej albo eksport „wszystkiego, co się da”.
Jak wykryć: W eksporcie z bazy widzisz kolumny z hasłami czytelnymi lub ktoś prosi o wysłanie pliku z hasłami mailem.
Jak naprawić: Haseł jawnych nie przenosi się nigdy. W PrestaShop hasła są przechowywane w formie hashowanej — przenosi się hash i wymusza reset hasła przy pierwszym logowaniu. Każdą bazę z danymi klientów traktuj jak dokument, nie jak załącznik roboczy.
Start produkcji bez stagingu i bez testowego importu zamówień.
Jak wykryć: Nie ma osobnego środowiska testowego albo staging istnieje, ale nie przeprowadzono na nim zamówienia od początku do końca.
Jak naprawić: Postaw staging z kopią danych, przejdź pełną ścieżkę: koszyk → płatność → mail potwierdzający → status zamówienia → dokument sprzedaży. Dopiero potem przełączaj produkcję.
Dostępy przekazywane etapami, po fakcie — brak wiedzy, kto zarządza domeną i DNS.
Jak wykryć: Na pytanie „gdzie jest domena?” pada odpowiedź „chyba u naszego informatyka, sprawdzimy”.
Jak naprawić: Ustal rejestratora domeny, właściciela panelu DNS i osobę uprawnioną do zmiany rekordów, zanim wyznaczysz okno serwisowe. Brak dostępu do DNS to najczęstsze opóźnienie w dniu przełączenia.
Przenoszenie wszystkich zamówień sprzed 8 lat „na wszelki wypadek”.
Jak wykryć: Import ciągnie się dłużej niż zakładano, a dane w testach nie zgadzają się z produkcją — nikt nie wie, który stan jest prawdziwy.
Jak naprawić: Zaimportuj tylko zakres, który ma uzasadnienie: zwykle 12–24 miesiące zamówień albo wyłącznie dane wymagane przez przepisy i księgowość. Resztę zostaw jako archiwum poza sklepem.
Wdrożenie i migracja PrestaShop dla firmy ze Szczecina różnią się nie narzędziem, a ryzykiem: przy migracji dochodzi SEO, RODO i przełączenie DNS w oknie serwisowym. Realny harmonogram to 4–8 tygodni dla wdrożenia i zwykle 6–10 tygodni dla migracji z treściami. Największe opóźnienia nie wynikają z kodu, tylko z braku decyzji po stronie biznesu — szablonu, treści, dostępów i danych do integracji. Zamknij checklistę przed startem, a projekt skróci się o dni, nie o godziny.
Proste wdrożenie z gotowym szablonem i katalogiem do 500 produktów to zwykle 4–6 tygodni. Sklep z integracją ERP, wieloma metodami płatności i niestandardowymi funkcjami B2B schodzi na 8–12 tygodni. Harmonogram liczy się od momentu, w którym masz wszystkie dostępy i treści — nie od podpisania umowy.
Nie musi, jeśli mapa przekierowań 301 obejmuje wszystkie adresy generujące ruch, a nowa sitemap XML jest zgłoszona po przełączeniu. Spadek zwykle wynika z braku przekierowań albo ze zdublowanych treści po dwóch wersjach sklepu. Kontrola w 7. i 30. dniu po starcie pokazuje, czy wszystko działa — bez danych z Search Console nie da się tego rzetelnie ocenić: wytyczne Google dotyczące treści warto znać przy przenoszeniu opisów produktów.
Robocze przedziały to 40–80 godzin dla prostego wdrożenia, 60–150 godzin dla migracji z przeniesieniem treści i 150–300 godzin dla sklepu z integracją ERP. Kwota zależy od stawki za godzinę i zakresu, nie od tego, ile ktoś napisał w ofercie. Warto liczyć, że każda niestandardowa funkcja to osobna pozycja w kosztorysie.
Nie w formie jawnej — nigdy. Haseł nie eksportuje się i nie wysyła mailem. W PrestaShop przechowuje się hash hasła, więc po migracji klient loguje się starym hasłem albo wymusza się reset. Jeśli stary system nie pozwala przenieść hasha, ustawiasz procedurę resetu hasła i informujesz klientów przed przełączeniem.
Zwykle tak, ale w ograniczonym zakresie — najczęściej 12–24 miesiące. Zamówienia to dane osobowe, więc przenosisz tylko to, co ma podstawę: obsługę reklamacji, zwrotów i obowiązki księgowe. Zgody marketingowe trzeba przenieść razem z informacją, kiedy i na co zostały wyrażone — bez tego nie możesz legalnie wysyłać newslettera po migracji.
Dziś sensownym wyborem jest gałąź 8.x. Konkretne wymagania PHP i MySQL zmieniają się między wydaniami, więc sprawdzaj je w dokumentacji dla deweloperów przed wyborem hostingu, a nie po: PrestaShop Developer Documentation. Hosting powinien mieć SSH, możliwość wyboru wersji PHP i sensowne limity bazy danych — to warunki, których nie da się nadgonić po instalacji.
Gdy sklep działa stabilnie, ruch jest niewielki, a jedyny powód migracji to „bo tak wypada”. Gdy koszt miesięczny obecnego rozwiązania jest niższy niż koszt projektu, a brakuje funkcji, którą da się dołożyć wtyczką. Gdy nie masz treści ani danych gotowych do przeniesienia — wtedy migracja tylko przesuwa problem w czasie.
Jeśli chcesz przejść przez wdrożenie lub migrację PrestaShop bez tygodni oczekiwania na decyzje, możemy zacząć od przeglądu Twojej sytuacji i zakresu. Napisz do DropDigital — powiemy wprost, co da się zrobić w jakim terminie i czego potrzebujemy od Ciebie na wejściu. Zobacz też wdrożenia PrestaShop, jeśli chcesz najpierw sprawdzić zakres prac.