Przeniesienie PrestaShop na nowy hosting: plan przełączenia DNS i danych

e-Commerce, PrestaShop
Migracja bez utraty ciągłości

Przeniesienie PrestaShop na nowy hosting

Bezpieczne przeniesienie PrestaShop na nowy hosting wymaga dwóch kopii danych: tej użytej do przygotowania nowego serwera oraz danych powstałych między jej wykonaniem a przełączeniem ruchu. Zmiana DNS jest tylko jednym etapem. Najważniejsze jest zaplanowanie momentu, w którym sklep przestaje przyjmować nowe zmiany, a aktualna baza, pliki i konfiguracja trafiają na nową infrastrukturę.

Plan powinien chronić zamówienia, konta klientów, produkty, obrazy, konfigurację płatności oraz połączenia z ERP i marketplace. Nie wystarczy, że strona główna otwiera się na nowym adresie IP.

Kolejność prac

Etap Cel Warunek przejścia dalej
Inwentaryzacja Spisać wersję PHP, PrestaShop, moduły, zadania, domeny i usługi zewnętrzne. Wiadomo, co musi działać po przełączeniu.
Kopia i środowisko odbiorowe Odtworzyć pliki oraz bazę poza produkcją. Test nie wysyła e-maili, nie pobiera płatności i nie uruchamia integracji produkcyjnych.
Odbiór Sprawdzić katalog, koszyk, dostawę, płatność testową, konto oraz integracje. Lista krytycznych scenariuszy jest zakończona.
Przełączenie Zablokować zmiany na krótki czas, wykonać końcowy eksport i uruchomić nową wersję. Nowa baza zawiera dane z okresu przełączenia.
Obserwacja Sprawdzić logi, zamówienia, adresy HTTPS i procesy zewnętrzne. Jest potwierdzenie działania oraz plan wycofania.

DNS należy traktować jako element planu

Rekordy domeny trzeba przygotować przed oknem przełączenia, ale nie zakładać, że każdy użytkownik zobaczy zmianę w tej samej chwili. Dlatego przez okres propagacji stara i nowa infrastruktura muszą mieć jasno określoną rolę. Certyfikat HTTPS, adres kanoniczny, przekierowania i poczta nie mogą zostać przypadkiem rozdzielone między dwa miejsca.

Przed zmianą zapisujemy aktualne rekordy DNS i sposób powrotu do poprzedniej konfiguracji. Dzięki temu wycofanie nie jest improwizacją.

Najczęstsza luka: dane z dnia migracji

Przywrócenie starej kopii po dniu sprzedaży może cofnąć zamówienia i dane klientów. Dlatego końcowy etap obejmuje wstrzymanie zmian na tyle krótko, aby zrobić końcową synchronizację, a potem sprawdzić ostatnie numery zamówień, płatności i statusy.

Jeżeli integracja nie ma bezpiecznego trybu odtworzenia, planujemy jej zatrzymanie i kontrolowane wznowienie, zamiast pozwolić dwóm serwerom przetwarzać te same zdarzenia.

Lista odbiorowa po przełączeniu

  1. Adresy HTTP kierują do HTTPS, a ważne podstrony mają właściwe canonicale.
  2. Produkt prosty i kombinacja mają cenę, stan oraz zdjęcia.
  3. Koszyk, dostawa i płatność działają w kontrolowanym scenariuszu.
  4. Ostatnie zamówienia i konta klienta są obecne w nowej bazie.
  5. Połączenia z ERP, Allegro, kurierami i pocztą działają tylko z nowej instalacji.
  6. Logi nie pokazują błędów połączeń, uprawnień ani brakujących plików.

To odbiór techniczny, który uzupełnia zwykłe oglądanie strony w przeglądarce.

Migrację prowadzimy etapami

Panther przygotowuje środowisko serwerowe, kopię odbiorową oraz plan przełączenia dopasowany do sklepu. W ZUT Uszczelnienia istotna jest ciągłość danych katalogowych i ERP, a CarpMaster pokazuje sklep z połączeniami do Allegro. W takich przypadkach najpierw ustalamy właściciela danych i testy, a dopiero później zmianę DNS.

Powiązany poradnik

Środowisko testowe sklepu opisuje, jak oddzielić płatności, e-maile i integracje przed odbiorem migracji.