Wdrożenie PrestaShop od zera i migracja z innego systemu to dwa różne projekty: inny zakres prac, inny czas i inne ryzyko. W Krasnobrodzie i okolicy najczęściej trafiamy na firmy, które sprzedają jednocześnie B2B i B2C i potrzebują sklepu, który wytrzyma kilkaset zamówień miesięcznie bez przestojów. Ten tekst to część organizacyjna: pokazujemy typowe błędy, listę rzeczy do sprawdzenia przed startem i odpowiedzi na pytania, które klienci zadają najczęściej. Sam opis usługi i zakres prac znajdziesz na stronie wdrożeń i migracji PrestaShop Krasnobród. Jeśli szukasz gotowej checklisty do przekazania zespołowi — czytaj dalej.
Wdrożenie od zera to postawienie nowego sklepu: instalujemy PrestaShop, konfigurujemy strefy, waluty i podatki (VAT, WDT, OSS), zakładamy grupy klientów (B2C na cenach brutto, B2B na netto z progami rabatowymi), budujemy strukturę kategorii, atrybutów i kombinacji, ustawiamy metody dostawy i płatności, wgrywamy szablon, podłączamy integracje: płatności, kurierów, fakturowanie, ERP. Katalog produktów wypełniasz od początku — nie ma czego przenosić. Ryzyko leży tu w konfiguracji: źle ustawiony próg darmowej dostawy albo błędna stawka VAT na produkcie cyfrowym potrafi kosztować więcej niż całe wdrożenie.
Migracja to przeniesienie istniejącego sklepu. Mamy dwa warianty: z innej platformy (WooCommerce, Shoper, IdoSell, sklep pisany na zamówienie) oraz ze starej wersji PrestaShop (1.6 albo 1.7 na 8.x). Do przeniesienia są produkty z kombinacjami, zdjęcia i przypisania, klienci z historią zamówień, treści CMS, adresy URL, a przede wszystkim przekierowania 301 ze starych adresów. Tu ryzyko dotyczy danych i widoczności w Google, nie wyglądu sklepu.
W Krasnobrodzie i okolicy trafiamy najczęściej na firmy handlowo-produkcyjne, które łączą sprzedaż B2B i B2C. Lokalny partner bywa potrzebny, gdy trzeba zrobić import z pliku wygenerowanego przez ERP, ustalić ceny kontraktowe dla kilkudziesięciu odbiorców albo usiąść z pracownikiem magazynu i zweryfikować stany. Reszta projektu spokojnie idzie zdalnie, na środowisku testowym. Zakres obu typów projektów opisujemy w sekcji wdrożeń i migracji PrestaShop Krasnobród.
| Aspekt | Wdrożenie od zera | Migracja |
|---|---|---|
| Punkt startowy | Pusta instalacja, katalog tworzony od zera | Istniejący sklep i dane do przeniesienia |
| Główne ryzyko | Błędna konfiguracja podatków, dostaw, procesu B2B | Utrata danych i spadek pozycji w Google |
| Co decyduje o czasie | Liczba integracji i modułów | Jakość i spójność danych ze starego systemu |
| Największy obowiązek klienta | Decyzje o procesie sprzedaży | Dostarczenie eksportu i dostępów |
Migracja ma sens, gdy obecny sklep blokuje sprzedaż lub koszty rosną szybciej niż obroty. Konkretne sygnały:
ROI licz na własnych danych, nie na obietnicach. Zbierz trzy liczby: roczny koszt obecnego rozwiązania, liczbę porzuconych koszyków z powodu błędu płatności lub dostawy (jest w Analytics) oraz jednorazowy koszt migracji. Jeśli pierwsze dwie pozycje w 12 miesiącach nie przebijają trzeciej, migracja to wydatek bez uzasadnienia.
Kiedy lepiej zostać na obecnym systemie? Gdy sklep działa stabilnie, masz wsparcie i przewidywalne koszty, robisz mniej niż około 100 zamówień miesięcznie i nie sprzedajesz B2B z indywidualnymi cenami. Nie startuj też w szczycie sezonu — przenosiny w październiku lub listopadzie to proszenie się o kłopoty. Zaplanuj je na styczeń. Kryteria decyzyjne i typowe pułapki zebraliśmy też w materiale o organizacji wdrożeń i migracji PrestaShop dla firm.
| Sygnał | Próg do sprawdzenia | Wniosek |
|---|---|---|
| Czas ładowania karty produktu (mobile) | powyżej 3 s | Migracja lub przebudowa frontu |
| Roczny koszt abonamentu i prowizji | wyższy niż szacowany koszt utrzymania PrestaShop | Policz ROI przed decyzją |
| Dostęp do danych i API | brak eksportu, brak API do ERP | Migracja |
| Skala sprzedaży | poniżej ok. 100 zamówień miesięcznie | Zostań, jeśli wszystko działa |
Typowy projekt dla MŚP to 2–6 tygodni i 5–10 godzin zaangażowania po stronie klienta — na decyzje i testy, nie na pisanie treści czy wgrywanie zdjęć.
Od firmy potrzebujemy: dostępów do hostingu i DNS, SSH lub FTP, bazy i panelu starego sklepu, eksportu produktów z cenami i stanami, zdjęć, logo, dokumentów prawnych, kluczy API, kont w Analytics i Search Console oraz listy osób z uprawnieniami w panelu.
| Etap | Czas | Zaangażowanie klienta |
|---|---|---|
| Audyt i wymagania | 2–4 dni | 2–3 h: decyzje o zakresie |
| Hosting i środowisko testowe | 1–2 dni | 1 h: dostępy |
| Instalacja i konfiguracja bazowa | 2–3 dni | 1 h: dane firmy, podatki |
| Szablon | 2–5 dni | 1–2 h: akceptacja wyglądu |
| Moduły, integracje, import danych | 5–10 dni | 2–3 h: dane, klucze API |
| Testy | 3–5 dni | 2–3 h: zamówienia testowe |
| Start | 1 dzień | 1 h: potwierdzenie |
Migracja to nie „przepisanie” sklepu, tylko przeniesienie danych i zachowanie adresów URL. W PrestaShop 8 masz dwa narzędzia: import CSV (Parametry zaawansowane → Import) oraz WebService API, jeśli dane mają synchronizować się cyklicznie. Kolejność ma znaczenie: najpierw kategorie i cechy, potem produkty, na końcu kombinacje, zdjęcia i stany magazynowe.
Dwie rzeczy zaskakują klientów najbardziej. Pierwsza: hasła klientów. W PrestaShop są hashowane (bcrypt), więc nie przeniesiesz ich w czytelnej formie. Standard to wymuszony reset hasła przy pierwszym logowaniu plus mailing z linkiem. Druga: historia zamówień. Przenosimy ją zwykle jako dokumenty archiwalne ze zmapowanymi statusami — nie odtwarzamy płatności ani nie generujemy ponownie faktur. Część firm zostawia w sklepie 12 miesięcy wstecz, starsze dane trafiają do PDF-ów i backupu.
| Dane | Jak przenosimy | Na co uważać |
|---|---|---|
| Kategorie i cechy | CSV / WebService | Importować przed produktami, inaczej produkty wylądują bez kategorii |
| Produkty i kombinacje | CSV / WebService | Zewnętrzne ID musi być stałe, żeby kolejny import aktualizował, a nie duplikował |
| Klienci | CSV / WebService | Hasła do resetu, sprawdzić grupy cenowe B2B i przypisane rabaty |
| Zamówienia historyczne | Import archiwalny | Mapowanie statusów 1:1, brak ponownego naliczania płatności |
| Opinie o produktach | Moduł opinii lub import z systemu zewnętrznego | Sprawdzić, czy szablon w ogóle wyświetla opinie produktowe |
Kolejność integracji jest zawsze ta sama: najpierw płatności, potem kurierzy, na końcu ERP. Powód jest praktyczny — bez działającej płatności nie przetestujesz zamówienia end-to-end.
Kurierzy. InPost przez ShipX API (Paczkomaty 24/7 i kurier, etykiety, zwroty, statusy przesyłek), DPD przez DPD Web API (etykiety PDF/ZPL, protokoły przekazania), DHL przez DHL Parcel Poland / DHL24. Do każdego potrzebujesz osobnych danych dla środowiska testowego — bez tego „testy” robisz na prawdziwych przesyłkach i płacisz za nie.
Płatności. Przelewy24, PayU i Stripe mają oficjalne moduły do PrestaShop. Najczęstszy błąd, jaki widzimy: status zamówienia zmienia się po powrocie klienta na stronę sklepu, a nie po notyfikacji (webhook/IPN) z bramki. Efekt — klient zapłacił, zamknął kartę, a zamówienie wisi jako nieopłacone. Sprawdź też zwroty i zwroty częściowe.
ERP. Subiekt GT/nexo, Comarch ERP Optima, WAPRO. Wymiana dotyczy stanów, cen, zamówień, faktur i numeracji dokumentów. Subiekt to zwykle pliki wymiany (eXML/Sfery), Comarch — API Optima. Każde mapowanie pola trzeba potwierdzić na realnych danych, nie na trzech testowych produktach.
Własny moduł czy płatna wtyczka. Płatna wtyczka to 200–600 zł jednorazowo albo abonament, wprowadzenie 2–6 h. Własny moduł to 20–60 h pracy, ale masz kontrolę nad kodem. Przy dostawcy, który zmienia API raz na dwa lata, wtyczka bywa ryzykiem — czekasz na aktualizację autora. Testy robimy w sandboxie, a potem na produkcji na 5–10 zamówieniach za symboliczną kwotę. Kontekst organizacyjny całego procesu opisujemy w materiale o wdrożeniach i migracjach PrestaShop w Krasnobrodzie.
Wycena opiera się na liczbie godzin, nie na cenniku z sufitu. Robimy rozpoznanie (ile produktów, ile kombinacji, jakie integracje, kto dostarcza treści), szacujemy godziny, a potem rozliczamy faktycznie przepracowane — z raportem. Stawka: 120–200 zł/h netto. 120 zł to prace konfiguracyjne i importy, 200 zł to praca deweloperska, np. własny moduł do ERP.
Widełki z naszych projektów: proste wdrożenie (szablon, płatności, jeden kurier, do 300 produktów) to 40–80 h. Migracja z innego systemu to 60–150 h. Przykład z życia: przejście z WooCommerce z 1500 produktami, dwiema grupami cenowymi B2B, InPostem, DPD, Przelewy24 i Subiektem — realnie 90–120 h, czyli 13 500–24 000 zł netto.
Ukryte koszty, o które nikt nie pyta na pierwszym spotkaniu:
Realny budżet roczny po starcie sklepu: 3000–10 000 zł netto, poza pracą nad rozwojem. Na liczbę godzin najbardziej wpływa liczba kombinacji (500 produktów × 8 wariantów to 4000 SKU, nie 500), liczba integracji, to czy przenosimy historię zamówień i czy treści oraz zdjęcia dostarcza klient. Szczegółowe stawki i sposób rozliczania znajdziesz w materiale o cenniku wdrożeń i migracji PrestaShop w Zamościu.
| Zakres | Godziny | Koszt netto przy 120–200 zł/h |
|---|---|---|
| Proste wdrożenie (szablon, płatności, 1 kurier, do 300 produktów) | 40–80 h | 4 800–16 000 zł |
| Migracja z innego systemu + SEO (mapowanie URL, 301, GSC) | 60–150 h | 7 200–30 000 zł |
| Własny moduł integracyjny (ERP, nietypowy dostawca) | 20–60 h | 2 400–12 000 zł |
Brak środowiska staging to najczęstszy powód, dla którego wdrożenie PrestaShop ciągnie się tygodniami. Jeśli wykonawca nie pokaże Ci adresu kopii sklepu (zabezpieczonej hasłem, ustawionej na noindex), każda zmiana ląduje od razu na produkcji — także w środku dnia sprzedażowego. Pytanie kontrolne przed podpisaniem umowy: pokaż staging i opisz, jak przenosicie na produkcję bazę i pliki.
Druga pułapka: moduły i motywy pisane pod starsze gałęzie PrestaShop. Moduł korzystający ze starych hooków albo szablon bez aktualizacji od dwóch lat działa poprawnie do momentu wejścia na wersję 8.x. Poproś o listę modułów z numerami wersji i oświadczenie, czy wspierają docelową wersję — weryfikację oprzyj na dokumentacji dla deweloperów PrestaShop.
Trzecia: przekierowania i duplikaty treści. Migracja bez mapy 301 zostawia dwie wersje tych samych adresów (http i https, www i bez, z ukośnikiem i bez) oraz puste wejścia z Google. Minimum przed startem: eksport adresów ze starego sklepu, mapowanie ich na nowe, jeden kanoniczny adres, przekierowania 301 (nie 302), osobno obsłużone paginacja i parametry filtrów.
Czwarta: spadek wydajności po migracji. Najczęściej winny jest tańszy hosting współdzielony, brak OPcache i Redis, zbyt niski memory_limit w PHP oraz baza bez indeksów po imporcie. Piąta: płatności i kurierzy, które przestają działać po zmianie domeny, bo moduły mają wpisane na sztywno adresy powrotu i webhooki. Szósta, najbardziej kosztowna: brak backupu i planu rollback. Wymagaj kopii bazy i plików, kopii poza serwerem produkcyjnym, snapshotu VPS oraz obniżenia TTL DNS do 300 s na dobę przed startem. Powrót na stary sklep musi być możliwy w godzinę, nie w tydzień.
| Ryzyko | Sygnał ostrzegawczy przed startem | Test do wykonania |
|---|---|---|
| Brak środowiska staging | Wykonawca nie podaje adresu kopii testowej | Wgraj zmianę na staging, sprawdź blokadę hasłem i noindex |
| Niekompatybilne moduły i szablony | Moduł bez aktualizacji od 2 lat, wsparcie tylko dla 1.6 | Test koszyka i płatności na staging w docelowej wersji |
| Błędy przekierowań i duplikaty | Brak mapy starych URL-i | Crawl 500 adresów po imporcie i porównanie z listą starych linków |
| Spadek wydajności | Hosting współdzielony, brak cache | Pomiar TTFB i LCP na staging przed importem i po nim |
| Płatności i kurierzy po zmianie domeny | Adresy powrotu i webhooki wpisane na sztywno | Transakcja testowa w sandboxie po przełączeniu domeny |
| Brak backupu i planu rollback | Kopię robi się przy okazji | Odtworzenie kopii na osobnym serwerze i sprawdzenie sklepu |
Wdrożenie kończy się w momencie, gdy sklep przyjmuje zamówienia, ale projekt trwa dalej. W umowie opieki zapisz cztery rzeczy: czas reakcji, czas naprawy, zakres monitoringu i sposób rozliczania prac. Bez definicji awarii krytycznej zapisy o czasie reakcji są bezużyteczne. Sensowna definicja obejmuje: sklep nie przyjmuje zamówień, nie działa płatność, nie działa panel administracyjny albo strona zwraca błędy 5xx. Dla takiego zdarzenia ustalasz reakcję np. do 4 godzin w dni robocze 8:00–16:00 i naprawę do 24 godzin. Drobne poprawki — tekst, zdjęcie, reguła dostawy — idą w kolejce 2–3 dni roboczych.
Monitoring powinien objąć dostępność sklepu (sprawdzenie co minutę), certyfikat SSL, kolejkę e-maili oraz płatności: testowa transakcja w sandboxie raz na godzinę wykryje problem szybciej niż pierwszy klient. Backup to baza i pliki codziennie, retencja 30 dni i kopia poza serwerem produkcyjnym. Odtworzenie testowe rób raz na kwartał — kopia, której nigdy nie odtworzono, nie jest kopią. Aktualizacje bezpieczeństwa wdrażaj najpierw na stagingu, a potem w oknie serwisowym, np. 2:00–5:00.
Sprawdź też, z kim realnie rozmawiasz. Jeśli zgłoszenia przyjmuje handlowiec, a naprawia podwykonawca z innego miasta, każda godzina opóźnienia mnoży się przez dwóch pośredników. W umowie wskaż kanał zgłoszeń i osobę prowadzącą. Model rozliczeń wybierz świadomie: abonament godzinowy (np. pula 5 godzin miesięcznie z przenoszeniem niewykorzystanych na kolejny miesiąc) działa przy nieregularnych zmianach, abonament stały — gdy potrzebujesz przewidywalnego kosztu. Układ kosztów wdrożenia i opieki opisujemy w materiale o cenie i organizacji wdrożenia PrestaShop w Zamościu.
| Zapis w umowie | Przykładowa wartość | Co daje w praktyce |
|---|---|---|
| Czas reakcji na zgłoszenie | 4 h w dni robocze 8:00–16:00 | Wiesz, kiedy ktoś realnie zajmie się sprawą |
| Czas naprawy błędu krytycznego | do 24 h od potwierdzenia awarii | Sklep nie stoi kilka dni po cichu |
| Definicja awarii krytycznej | brak zamówień, brak płatności, błędy 5xx | Blokuje spory o to, co jest pilne |
| Backup | baza + pliki codziennie, retencja 30 dni, kopia poza serwerem | Ryzyko utraty danych schodzi z właściciela firmy |
| Aktualizacje bezpieczeństwa | minimum raz w miesiącu, okno serwisowe 2:00–5:00 | Łatki nie są wdrażane w godzinach sprzedaży |
| Rozliczenie prac | abonament godzinowy lub stawka stała | Koszt jest przewidywalny w budżecie miesięcznym |
Poniższą listę możesz wydrukować i odklikać z wykonawcą. Punkt, którego nie da się potwierdzić dokumentem albo testem, traktuj jako niezrobiony.
noindex oraz opisany proces publikacji na produkcję.Za akceptację odpowiada właściciel lub osoba wyznaczona w firmie — nie wykonawca. Bez pisemnego potwierdzenia każdego etapu nie ma dowodu, że sklep działa. Firmy z Krasnobrodu, Zwierzyńca i Tomaszowa Lubelskiego najczęściej pytają nas o wdrożenia i migracje PrestaShop w Krasnobrodzie. Kontakt znajdziesz na dropdigital.pl — napisz, ile masz produktów, skąd migrujesz i ilu pracowników obsługuje zamówienia, a odpowiemy zakresem i terminem.
| Etap | Kto akceptuje | Dowód odbioru |
|---|---|---|
| Zakres i mapa przekierowań 301 | Właściciel firmy | Podpisana lista starych i nowych adresów |
| Środowisko staging | Klient + deweloper | Adres testowy z blokadą hasłem |
| Import danych | Osoba wskazana przez firmę | Zestawienie: liczba produktów, klientów, zamówień |
| Płatności i kurierzy | Właściciel sklepu | Zamówienie testowe z potwierdzeniem mailowym |
| Start produkcyjny | Właściciel sklepu | Pisemna akceptacja i zrzut z Search Console |
| Przekazanie i szkolenie | Osoba obsługująca zamówienia | Nagranie szkolenia i lista przekazanych dostępów |
Start bez środowiska staging — wszystkie testy wykonywane od razu na produkcji.
Jak wykryć: Zapytaj, pod jakim adresem będą testy przed oficjalnym startem. Jeśli odpowiedź brzmi „na docelowej domenie”, stagingu nie ma.
Jak naprawić: Postaw kopię sklepu na subdomenie (np. test.twojadomena.pl) z osobną bazą i blokadą indeksacji, a produkcję uruchom dopiero po testach.
Zakup szablonu i modułów przed audytem wersji PrestaShop i PHP.
Jak wykryć: Otwórz kartę modułu i sprawdź trzy rzeczy: datę ostatniej aktualizacji, wspierane wersje PrestaShop i wymaganą wersję PHP.
Jak naprawić: Najpierw audyt wersji i lista potrzebnych funkcji, potem zakup. Moduły, których nie użyjecie w pierwszym roku, zostawcie poza projektem — to mniej rzeczy do aktualizacji.
Brak mapy przekierowań 301 przy migracji z innej platformy lub starej wersji.
Jak wykryć: Po starcie weź 20–30 starych adresów produktów i kategorii, wklej je w przeglądarkę i sprawdź kod odpowiedzi. 404 zamiast 301 oznacza brak mapowania. Sam mechanizm przekierowań opisuje dokumentacja HTTP w MDN.
Jak naprawić: Plik z mapowaniem stary URL → nowy URL przygotuj przed startem i wgraj go dokładnie w momencie przełączenia domeny. Nie zostawiaj tego na później — Google szybko zapamiętuje 404.
Brak kopii zapasowej i planu rollback przed przełączeniem domeny.
Jak wykryć: Zapytaj wprost: kiedy powstaje ostatnia kopia bazy i plików, gdzie leży i ile trwa jej przywrócenie.
Jak naprawić: Przed startem: pełna kopia bazy i plików, zrzut strefy DNS i ustalony czas powrotu do starej wersji, jeśli coś zawiedzie. Bez tego każda awaria zamienia się w wielogodzinny przestój sprzedaży.
Płatności i kurierzy testowane dopiero po zmianie domeny.
Jak wykryć: Sprawdź, czy przed startem wykonano testową transakcję w trybie sandbox i wygenerowano przynajmniej jedną testową etykietę nadawczą.
Jak naprawić: Testy sandbox przed startem, a potem 2–3 prawdziwe zamówienia na małych kwotach z realną wysyłką. Dopiero wtedy uznaj integracje za działające.
Projekt bez osoby decyzyjnej po stronie firmy.
Jak wykryć: Policz, ile dni roboczych mija od wysłania szablonu, treści lub cennika do akceptacji. Powyżej 3 dni to sygnał ostrzegawczy.
Jak naprawić: Wyznacz jedną osobę decyzyjną i zarezerwuj jej 5–10 godzin na cały projekt: decyzje, akceptacje i testy. Przy dwóch osobach decyzyjnych projekt wydłuża się o tygodnie.
Wdrożenie PrestaShop bez przygotowania kończy się najczęściej opóźnieniem i poprawkami po starcie, a migracja bez mapy przekierowań — spadkiem ruchu w Google. Najprostszy sposób, żeby tego uniknąć, to staging, kopia zapasowa i plan rollback ustalone jeszcze przed pierwszym dniem prac. Druga rzecz to czas po stronie firmy: 5–10 godzin na decyzje i testy jest realne, ale trzeba go zaplanować z wyprzedzeniem. Reszta — moduły, integracje, przekierowania — rozkłada się na etapy i jest do ogarnięcia w 2–6 tygodni.
Typowy projekt dla MŚP zamyka się w 2–6 tygodniach. Prostsze wdrożenie z gotowym szablonem i dwiema integracjami to często 2–3 tygodnie, a sklep z indywidualnym szablonem, integracją ERP i wieloma metodami dostawy — 5–6 tygodni. Największym hamulcem nie jest praca techniczna, tylko czas oczekiwania na treści i akceptacje po stronie firmy.
Wtedy, gdy obecna platforma limituje rozwój: brakuje funkcji B2B (ceny indywidualne, grupy klientów, faktury), sklep wolno się ładuje, a koszty utrzymania rosną szybciej niż sprzedaż. Sensownym progiem jest sytuacja, w której miesięczne koszty starego rozwiązania przewyższają koszt migracji rozłożony na 12–24 miesiące. Jeśli obecny system działa, ma wsparcie i nie blokuje rozwoju, migracja bez wyraźnego powodu zwykle się nie zwraca — kryteria rozpisaliśmy w tekście wdrożeń i migracji PrestaShop Zamość dla firmy.
Nie, jeśli migracja jest zaplanowana. Kluczowe elementy to mapa przekierowań 301, zachowanie meta title i description, poprawne adresy canonical oraz aktualna sitemap. Po starcie trzeba pilnować raportu 404 i indeksacji w Google Search Console przez kilka tygodni. Zasady budowania treści pod użytkownika opisuje dokumentacja Google Search Central, a dane strukturalne dla sklepu — galeria danych strukturalnych Google. Kolejność prac przy takim projekcie rozpisaliśmy w materiale o wdrożeniach i migracjach PrestaShop Szczebrzeszyn.
Produkty, kategorie, klientów i zamówienia przenosi się standardowo przez eksport i import lub dedykowany skrypt migracyjny. Opinie bywają problematyczne, bo każdy moduł opinii trzyma je w innym formacie — wymaga to zwykle osobnego mapowania. Przed startem warto ustalić, co przenosicie i czego świadomie nie przenosicie, żeby nie skończyć z pustą bazą klientów po przełączeniu.
Nasza wycena opiera się na liczbie godzin, nie na cenniku z sufitu. Orientacyjnie: proste wdrożenie to 40–80 godzin, migracja z innej platformy 60–150 godzin, a stawka wynosi 120–200 zł/h netto w zależności od specjalizacji. Do tego dochodzą koszty zewnętrzne: hosting lub VPS, płatny szablon, moduły i licencje. Szczegóły i strukturę wyceny znajdziesz w materiale o cenniku wdrożeń i migracji PrestaShop.
Potrzebne będą: dostęp do hostingu lub panelu serwera, do domeny i strefy DNS, do bazy danych obecnego sklepu oraz do panelu Google Search Console. Dodatkowo dane firmowe do etykiet nadawczych, eksport produktów z obecnego systemu, regulamin i polityka prywatności oraz klucze API od operatorów płatności i kurierów. Brak któregokolwiek z tych elementów wydłuża projekt, bo blokuje kolejny etap.
PrestaShop wymaga aktualizacji — moduły, szablon i sama platforma zmieniają się kilka razy w roku. Bez opieki pierwsza poważniejsza aktualizacja potrafi zepsuć układ szablonu albo wyłączyć płatności. W umowie warto ustalić zakres: aktualizacje, kopie zapasowe, monitoring działania i czas reakcji na zgłoszenie. Bez zapisanego SLA nie ma podstaw, żeby wymagać konkretnego czasu naprawy.
Jeśli chcesz sprawdzić, czy w Twoim przypadku potrzebne jest wdrożenie, czy tylko uporządkowanie obecnego sklepu, napisz do nas — powiemy wprost, co ma sens. Wycenę przygotowujemy na podstawie liczby godzin, więc od razu zobaczysz, z czego wynika cena.