Jak przeniesc sklep na nowy hosting bez przestoju

Obniz TTL rekordow DNS na 300 sekund 1-2 dni przed migracja
Zrob pelna kopie plikow i bazy zanim ruszysz cokolwiek na nowym serwerze
Najpierw uruchom i przetestuj sklep na subdomenie nowego hostingu
DNS przelaczaj w oknie najmniejszego ruchu, nie w piatek po poludniu
Po przelaczeniu zaktualizuj webhooki platnosci, inaczej statusy zamowien stana
[/dwb_keytakeaways]

Dlaczego migracja sklepu budzi strach i niepotrzebnie

Przeniesienie sklepu na nowy hosting brzmi jak operacja na otwartym sercu: jeden zly ruch i sprzedaz stoi, klienci widza bialy ekran, a zamowienia gina. W praktyce migracja jest powtarzalna i bezpieczna, jesli robisz ja w odpowiedniej kolejnosci i niczego nie kasujesz po drodze. Stary sklep zostawiasz wlaczony az do samego konca, a nowy budujesz i testujesz obok, na subdomenie. Klient nic nie zauwaza, bo caly czas korzysta ze starego serwera.

Najwazniejsza zasada brzmi: nie wylaczasz starego, dopoki nowy nie dziala w 100%. Migracja to nie jest przenosiny mieszkania, gdzie najpierw oprozniasz stare. To raczej zbudowanie kopii w nowym miejscu i przelaczenie ruchu dopiero wtedy, gdy kopia jest sprawdzona. Stary sklep usuwasz dopiero po kilku dniach stabilnej pracy nowego.

Realnym ryzykiem nie jest sama strona ani baza danych. Najwiekszym zagrozeniem sa zamowienia, ktore klienci zlozyli w starym sklepie w trakcie kopiowania. O tym piszę osobno, bo to wlasnie ten szczegol odrznia migracje udana od takiej, po ktorej szukasz zaginionych zamowien w dwoch bazach naraz.

Przygotowanie: co zrobic zanim cokolwiek ruszysz

Dobra migracja w 80% to przygotowanie. Im wiecej ustalisz przed startem, tym mniej decyzji podejmujesz pod presja, gdy ruch jest juz przelaczany. Zanim dotkniesz nowego serwera, przejdz przez kilka rzeczy.

• Sprawdz nowy hosting: ta sama lub wyzsza wersja PHP (najlepiej 8.3), to samo lub wieksze srodowisko bazy, limit rozmiaru pliku i pamieci PHP dopasowany do sklepu. Sklep na PHP 8.3 nie ruszy poprawnie na serwerze z PHP 7.4.
• Zapisz wszystkie dostepy: panel starego i nowego hostingu, SFTP, baza danych, panel domeny i DNS, panele bramek platnosci. Brak dostepu do DNS w kluczowym momencie potrafi zablokowac cala migracje.
• Zrob inwentaryzacje: lista wtyczek, wersja WordPress i WooCommerce, integracje (kurierzy, faktury, newsletter), zewnetrzne skrypty. Cos, o czym zapomnisz teraz, odezwie sie po przelaczeniu.
• Wybierz okno migracji: pora najmniejszego ruchu, zwykle noc lub wczesny ranek w dzien roboczy. Nigdy w piatek wieczorem, bo jak cos pojdzie nie tak, naprawiasz w weekend bez wsparcia hostingu.

Kopia plikow i bazy danych

Sercem sklepu sa dwie rzeczy: pliki (motyw, wtyczki, wgrane zdjecia produktow w katalogu uploads) oraz baza danych (produkty, zamowienia, klienci, ustawienia). Migracja to przeniesienie obu tych warstw na nowy serwer w sposob, ktory nic nie pogubi.

Przy malym i srednim sklepie najprosciej uzyc wtyczki migracyjnej. Przy wiekszym sklepie z ciezka baza i tysiacami zdjec lepiej sprawdza sie kopia reczna, bo wtyczki maja limity rozmiaru paczki, ktore latwo przekroczyc.

1. Kopia plikow: pobierz przez SFTP caly katalog WordPress, ze szczegolnym naciskiem na folder wp-content (tam siedza motyw, wtyczki i uploads). Pomijasz cache i pliki tymczasowe.
2. Kopia bazy: zrob eksport bazy danych przez phpMyAdmin lub Adminer do pliku SQL. To pelna fotografia produktow, zamowien i klientow z konkretnej chwili.
3. Kopia bezpieczenstwa starego sklepu: zanim cokolwiek zmienisz, miej dzialajacy backup, ktory pozwoli wrocic do punktu wyjscia. To Twoja siatka asekuracyjna.

Test na subdomenie: najwazniejszy krok

Tego kroku nie wolno pomijac. Zanim przelaczysz domene na nowy serwer, uruchamiasz na nim sklep pod adresem technicznym, na przyklad test.twojadomena.pl albo subdomenie udostepnionej przez hosting. Dzieki temu testujesz dzialajacy sklep na docelowym serwerze, ale prawdziwy ruch wciaz idzie na stary.

Na subdomenie przechodzisz cala sciezke klienta i administratora, tak jakbys byl kupujacym i wlascicielem naraz:

• Strona glowna, lista kategorii, karta produktu, wyszukiwarka, koszyk.
• Przejscie do kroku platnosci (bez finalizacji prawdziwej platnosci, bo bramka jeszcze celuje w stary adres).
• Logowanie do panelu, podglad listy zamowien, edycja produktu, wyslanie maila testowego.
• Czy laduja sie obrazy produktow, czy nie ma bledow 404 i czy logi serwera sa czyste.

Jesli sklep stawia sie pod adresem subdomeny, czesto trzeba podmienic adres w bazie (z domeny docelowej na subdomene) na czas testow, a po przelaczeniu wrocic do docelowej. To rutyna, ale latwo o tym zapomniec i wtedy sklep przekierowuje sam na siebie.

DNS, TTL i SSL: techniczne przelaczenie

Gdy sklep dziala na subdomenie, zostaje samo przelaczenie ruchu. Robi sie to przez zmiane rekordow DNS, najczesciej rekordu A (adres IP) i ewentualnie CNAME dla www. Wskazujesz domene na adres IP nowego serwera i od tej chwili nowy ruch zaczyna trafiac na nowy hosting.

Tu wraca temat TTL. Jesli obnizyles go wczesniej do 300 sekund, propagacja jest praktycznie natychmiastowa: w kilka minut wiekszosc ruchu jest juz na nowym serwerze. Jesli zapomniales i TTL stoi na 24 godzin, przez dobe czesc klientow trafia jeszcze na stary sklep, a czesc na nowy, co przy aktywnej sprzedazy jest proszeniem sie o rozjazd zamowien.

Druga rzecz to SSL. Na nowym serwerze certyfikat musi byc wystawiony dla Twojej domeny, zanim przelaczysz DNS, albo zaraz po. Wiekszosc hostingow daje darmowy Let's Encrypt, ktory wystawia sie automatycznie, gdy domena juz wskazuje na serwer. Pilnuj, zeby sklep nie zostal nawet na chwile bez waznego SSL, bo przegladarki pokaza ostrzezenie i klienci ucieka.

Okno przelaczenia bez przestoju i zamowienia w locie

To jest moment, w ktorym rozstrzyga sie, czy migracja byla bezbledna. Sama strona nie zniknie, bo stary serwer dziala az do wygasniecia TTL. Problem to zamowienia zlozone w starym sklepie pomiedzy momentem kopii bazy a momentem przelaczenia DNS. Te zamowienia sa w starej bazie, ale nie ma ich w nowej.

Sa dwa sprawdzone sposoby, zeby tego uniknac:

1. Tryb konserwacji na czas okna: na kilkanascie minut, w nocy, wlaczasz informacje o krotkiej przerwie technicznej, robisz koncowy eksport bazy, wgrywasz na nowy serwer i przelaczasz DNS. Zero zamowien w locie, bo sklep na chwile nie przyjmuje nowych.
2. Koncowy zrzut bazy tuz przed przelaczeniem: jesli nie chcesz wylaczac sklepu, robisz druga, swieza kopie bazy bezposrednio przed zmiana DNS i to ona laduje na nowym serwerze. Skracasz okno, w ktorym zamowienia moglyby wpasc tylko do starej bazy, do minut.

Dla wiekszosci sklepow w skali malego i sredniego ruchu wystarczy przelaczenie w nocy z koncowym zrzutem bazy. Przy duzym sklepie z ciaglym ruchem warto na te kilkanascie minut wlaczyc tryb konserwacji, bo pewnosc, ze zadne zamowienie nie zginie, jest warta krotkiej przerwy o trzeciej w nocy.

Webhooki platnosci i integracje po przelaczeniu

Klucze API bramek platniczych przenosza sie razem z baza, wiec po migracji platnosci formalnie dzialaja. Co sie nie przenosi automatycznie, to webhooki, czyli adresy, pod ktore Przelewy24, PayU, Tpay czy Stripe wysylaja powiadomienie o zaksiegowanej platnosci. Jesli zmienil sie serwer lub certyfikat SSL, te powiadomienia moga przestac dochodzic, platnosc przejdzie, ale status zamowienia w sklepie sie nie zaktualizuje.

Po przelaczeniu domeny wejdz w panel kazdej bramki i sprawdz adres webhooka. Zwykle wystarczy potwierdzic, ze wskazuje on na poprawny adres sklepu z waznym SSL. To samo dotyczy innych integracji odbierajacych dane z zewnatrz: systemy kurierskie, fakturowanie, integracje z hurtowniami. Wszystko, co laczy sie ze sklepem po adresie URL, trzeba zweryfikowac.

Checklist po migracji

Gdy ruch jest juz na nowym serwerze, nie konczysz pracy. Pierwsze godziny i pierwszy dzien to czas weryfikacji, czy nic nie zostalo po drodze. Oto lista, ktora przechodzę przy kazdej migracji.

Po kilku dniach stabilnej pracy nowego sklepu mozesz spokojnie wylaczyc stary serwer i podniesc TTL z powrotem do wyzszej wartosci. Wczesniej go nie kasuj, bo to Twoja jedyna siatka asekuracyjna, gdyby cos wyszlo dopiero po dluzszym czasie.

Najczestsze pulapki przy migracji

Po wielu przeniesionych sklepach widze, ze bledy powtarzaja sie w kilku miejscach. Wiekszosc da sie ominac, jesli wiesz o nich wczesniej.

• Zapomniany TTL: przelaczenie DNS przy TTL 24h oznacza dobe rozjazdu ruchu miedzy stary i nowy serwer.
• Zamowienia w locie: kopia bazy rano, przelaczenie po poludniu, a zamowienia z tych godzin zostaja tylko w starej bazie.
• Stary adres w bazie: po przeniesieniu w bazie zostaja stare adresy URL, sklep przekierowuje sam na siebie albo laduje zasoby ze starego serwera.
• Webhooki nieaktualizowane: platnosci przechodza, ale statusy zamowien stoja, bo bramka wysyla powiadomienia pod stary adres.
• Brak SSL przez chwile: certyfikat nie zdazyl sie wystawic na nowym serwerze, klienci widza ostrzezenie i ucieka.
• Skasowany stary serwer od razu: usuniecie zrodla dzien po migracji zostawia Cie bez planu B, gdy problem wyjdzie pozniej.

Jesli planujesz przeniesienie sklepu i nie chcesz ryzykowac utraty zamowien, w DawidWeb robie migracje regularnie: pelna kopia plikow i bazy, test na subdomenie, przelaczenie DNS w oknie najmniejszego ruchu, weryfikacja SSL i aktualizacja webhookow platnosci, zeby zamowienia ksiegowaly sie same od pierwszej minuty. Strony i sklepy buduje i przenosze od 1800 zl, jestem Partnerem Shoper, mam za soba ponad 120 projektow, a wycene konkretnej migracji dostajesz w 24 godziny.