Migracja sklepu PrestaShop to przenosiny „silnika” i „danych” na nowy serwer. Jeśli przeniesiesz tylko pliki albo tylko bazę, sklep najpewniej wstanie, ale coś zacznie się sypać: koszyk, płatności, maile albo integracje z kurierami. Najgorsze są błędy, które wychodzą dopiero po kilku godzinach, kiedy klienci już robią zakupy.
W tym artykule dostajesz checklistę z konkretnymi krokami. Co przygotować wcześniej, jak bezpiecznie „zamrozić” sklep na czas przenosin, co zrobić z modułami i cache, jak przełączyć SSL i domenę, oraz jak testować po migracji, żeby nie dowiedzieć się o problemie z pierwszego zgłoszenia klienta.
Jeśli dopiero wybierasz nowy hosting, nie strzelaj w ciemno. Sklep to nie blog. Liczy się stabilność, zasoby i to, czy da się sensownie ogarnąć crony i pocztę. Zajrzyj do porównania – Ranking hostingów.
Kiedy robić migrację i jak wybrać dobry termin
Migrację warto robić wtedy, gdy nowy hosting rozwiąże konkretny problem: sklep zwalnia, zdarzają się błędy 503/500, panel admina nie działa zbyt dobrze, importy się wywalają albo integracje nie wyrabiają. Sama chęć zmiany „bo taniej” często kończy się tym, że na nowym planie jest jeszcze gorzej.
Dobry termin to taki, kiedy masz najmniej zamówień. Nie zgaduj. Sprawdź w analityce albo w panelu zamówień, w jakich godzinach i dniach masz spadek sprzedaży. U niektórych sklepów to noc, u innych środek dnia, bo ruch jest z reklam odpalanych wieczorem.
Jeśli zastanawiasz się, czy zostać na hostingu współdzielonym czy iść w VPS, przeczytaj wpis PrestaShop: hosting współdzielony vs hosting VPS. To pomoże Ci zrozumieć, gdzie zwykle zaczynają się ograniczenia i czego oczekiwać po zmianie.
Co przygotować przed migracją?
Najpierw spisz, co masz w sklepie i co może „zaskoczyć” po przenosinach. W PrestaShop najczęściej psują się moduły. Szczególnie:
- płatności,
- kurierzy i wysyłki,
- faktury,
- marketplace’y,
- feedy produktowe,
- integracje z ERP/CRM.
Zrób listę modułów krytycznych i zanotuj ich wersje. Jeśli któryś moduł ma licencję (klucz), upewnij się, że wiesz, gdzie się go aktywuje. Po migracji czasem trzeba „kliknąć” ponownie aktywację.
Sprawdź dostępy: panel hostingu, baza (phpMyAdmin), FTP/SFTP, panel DNS domeny (tam zmienisz rekordy). Bardzo częsty problem w migracji to nie technologia, tylko „nie mam dostępu do DNS” albo „nie pamiętam, gdzie jest stara konfiguracja”.
Kopie zapasowe: co zgrać i jak sprawdzić, czy backup jest OK
Backup ma sens tylko wtedy, gdy da się go odtworzyć. Dlatego zrób kopie i sprawdź je, zanim ruszysz z przełączeniem domeny. Jeśli chcesz to ogarnąć bardziej systemowo (jak długo trzymać kopie, co mają obejmować), pomocny jest poradnik: Kopie zapasowe w hostingu. Jak wybrać backup, który działa?.
Co musisz mieć:
- zrzut bazy danych (SQL),
- pliki sklepu (szczególnie
modules,themes,override,img), .htaccessi pliki konfiguracyjne,- zapisane rekordy DNS (żeby w razie czego odtworzyć).
Dobrze zrobić dwa backupy:
- roboczy — wcześniej, do postawienia kopii sklepu na nowym hostingu,
- finalny — tuż przed przełączeniem, gdy sklep jest już „zamrożony”.
Nowy hosting pod PrestaShop: PHP, baza, limity i poczta
Na nowym hostingu sprawdź przede wszystkim zgodność wersji. Jeśli teraz sklep działa na konkretnej wersji PHP, nie zmieniaj jej „przy okazji”, bo utrudnisz sobie diagnozę. Najpierw przenieś sklep, potem ewentualnie aktualizuj PHP.
Zwróć uwagę na limity: czas wykonywania skryptów, pamięć PHP, limit uploadu. W PrestaShop to wychodzi przy imporcie produktów, generowaniu miniaturek i przy większych zapytaniach do bazy.
Crony są obowiązkowe w większości sklepów. Po migracji musisz je odtworzyć na nowym hostingu, bo inaczej przestaną działać feedy i synchronizacje. Jeśli chcesz szybko odświeżyć temat, zajrzyj do wpisu: Cron w PrestaShop: wysyłki, feedy, aktualizacje stanów – jak ustawić?.
I poczta: po migracji test maili transakcyjnych to mus, bo brak maili oznacza natychmiastowe zgłoszenia klientów.
Przeniesienie plików sklepu: co jest krytyczne, a co można pominąć
Pliki przenosisz na nowy hosting, ale pilnujesz, żeby nic nie zginęło po drodze. Krytyczne katalogi to:
modules(moduły),themes(motyw),override(nadpisania),img(zdjęcia produktów).
Jeśli po migracji brakuje zdjęć albo część produktów wygląda nietypowo, to zwykle problem z transferem img. Transfer plików przez FTP bywa zrywany i wtedy masz „prawie wszystko”, ale nie do końca.
Cache aplikacji zwykle i tak czyścisz, więc nie ma sensu przenosić go 1:1. Ważniejsze jest, żeby sklep miał poprawne uprawnienia do zapisu (bo inaczej nie zapisze cache, logów albo miniaturek).
Jeśli chcesz zobaczyć ogólną logikę przenosin (nie tylko sklepu), możesz podeprzeć się wpisem: Migracja strony między hostingami krok po kroku.
Przeniesienie bazy danych: jak nie zgubić zamówień i klientów
Baza danych musi być przeniesiona w dobrym momencie. Jeśli zrobisz zrzut bazy, gdy klienci nadal składają zamówienia, to część zamówień „zostanie” na starym hostingu.
Dlatego poprawnie powinno to wyglądać tak:
- włączasz tryb konserwacji (żeby nikt nie kupował w trakcie),
- robisz finalny zrzut bazy,
- importujesz bazę na nowy hosting,
- dopiero potem przełączasz DNS.
Jeśli baza jest duża, eksport/import przez przeglądarkę (phpMyAdmin) może się wywalić. Objawy niedokończonego importu to losowe błędy w adminie, brak części danych albo błędy SQL. Po imporcie zawsze sprawdź:
- liczbę zamówień,
- ostatnie zamówienie (numer i data),
- kilka produktów i wariantów,
- czy da się dodać produkt do koszyka.
Cache po migracji: co wyczyścić, żeby sklep nie wariował
Po migracji cache potrafi pokazywać stare elementy strony albo trzymać skompilowane szablony niepasujące do nowego środowiska. Dlatego po przeniesieniu:
- czyścisz cache PrestaShop,
- czyścisz cache Smarty,
- odświeżasz stronę w trybie incognito.
Jeśli masz cache na poziomie serwera albo CDN, na czas testów warto go ograniczyć lub wyłączyć dla koszyka i checkout. Inaczej możesz testować „z cache”, a nie realne działanie sklepu.
CDN to temat na etap po migracji. Jeśli chcesz go wdrożyć sensownie, zajrzyj do: CDN w hostingu: kiedy ma sens, ile kosztuje i jak wpływa na TTFB oraz Core Web Vitals.
SSL i DNS: jak przełączyć domenę bez chaosu
Najlepiej obniżyć TTL na DNS dzień lub dwa wcześniej. Dzięki temu przełączenie szybciej zadziała u użytkowników. Jeśli tego nie zrobisz, też się uda — tylko część osób będzie dłużej trafiać na starą wersję.
SSL przygotuj na nowym hostingu wcześniej. Po przełączeniu sprawdź, czy:
- strona otwiera się po HTTPS,
- nie ma pętli przekierowań,
- nie ma mieszanej treści (część plików po HTTP).
Jeśli w przeglądarce widzisz ostrzeżenia, to znak, że gdzieś w motywie/modułach zostały twarde linki do http://.
Testy po migracji: co sprawdzić krok po kroku
To jest najważniejsza część. Nie testuj „na oko”, tylko przejdź krytyczną ścieżkę klienta.
Najlepszy zestaw testów po przełączeniu:
- otwórz stronę główną i kilka produktów,
- dodaj produkt do koszyka,
- przejdź do checkout,
- spróbuj przejść przez płatność (test/produkcyjnie zależnie od możliwości),
- sprawdź w panelu administracyjnym, czy zamówienie się pojawiło,
- sprawdź, czy doszły maile (klient + admin),
- sprawdź działanie cronów (czy uruchamiają się zadania).
Na koniec ustaw monitoring. Nawet jeśli od razu jest OK, problemy wychodzą po pierwszym większym ruchu albo po kilku godzinach. Jeśli chcesz podejść do tego rozsądnie, przeczytaj wpis o Uptime hostingu.
FAQ – Najczęściej zadawane pytania
W większości przypadków tak, ale ta przerwa może być krótka. Jeśli przygotujesz kopię sklepu wcześniej na nowym hostingu, to „wyłączenie” dotyczy tylko etapu finalnego: zrzut bazy i przełączenie DNS. To może być kilkanaście–kilkadziesiąt minut, a nie pół nocy.
Bez przerwy ryzykujesz niespójne dane, czyli dokładnie to, czego chcesz uniknąć.
Po imporcie bazy porównaj liczbę zamówień i sprawdź ostatnie zamówienie: numer i datę. Zrób też testowe zamówienie po przełączeniu i upewnij się, że pojawia się w panelu.
Najpierw sprawdź konfigurację modułu płatności (tryb test/produkcyjny, adresy powrotu, klucze). Potem sprawdź, czy nie zmienił się adres sklepu w ustawieniach PrestaShop oraz czy SSL działa poprawnie (bramki płatności są na to wrażliwe).
Bo zmieniło się środowisko: limity zasobów, konfiguracja serwera, sposób obsługi cache, a czasem nawet to, jak działa baza. Najpierw porównaj czasy odpowiedzi (TTFB) i sprawdź, czy nie dostajesz błędów 5xx przy obciążeniu.
To prawie zawsze problem z transferem katalogu img. Przy dużej liczbie plików transfer potrafi się przerwać albo pominąć część plików. Wtedy część produktów ma zdjęcia, część nie.
Rozwiązanie: ponów transfer img i porównaj rozmiary/katalogi. Jeśli hosting ma narzędzia do synchronizacji, użyj ich, bo są mniej podatne na przerwania niż klasyczne FTP.
30-letnia pasjonatka informatyki, która świat serwerów i hostingów zna od podszewki. Wierzy, że technologia powinna ułatwiać życie, a nie je komplikować. Żyje w ciągłym ruchu – jeśli akurat nie konfiguruje nowej usługi, prawdopodobnie pakuje plecak na kolejną wyprawę w nieznane.
Dodaj komentarz