Przejdź do treści

Migracja strony na nowy hosting bez przestoju: checklista (WordPress, poczta, DNS)

Jak przenieść stronę i pocztę na nowy hosting bez przerwy w działaniu: inwentaryzacja, TTL, test przez plik hosts, rekordy MX, SPF, DKIM, DMARC i lista kontrolna.

Bartosz Ogrodowicz 8 min czytania

Wentylatory serwerów w serwerowni
› spis treści
  1. Kiedy migracja ma sens
  2. Inwentaryzacja przed migracją
  3. Obniżenie TTL z wyprzedzeniem
  4. Kopia i przeniesienie: pliki i baza
  5. Test nowego serwera przez plik hosts
  6. Poczta: MX, SPF, DKIM, DMARC i migracja skrzynek
  7. Przełączenie DNS i SSL
  8. Checklista po migracji
  9. Typowe wpadki
  10. Checklista
  11. Najczęstsze pytania
  12. Podsumowanie

Migracja strony na nowy hosting rzadko psuje się przy kopiowaniu plików. Psuje się na rzeczach, o których nikt nie pamiętał: zadaniu cron uruchamianym raz w tygodniu, skrzynce pocztowej księgowej, rekordzie DKIM albo formularzu, który wysyłał maile przez funkcję serwera. Strona po przeniesieniu „działa”, a problem wychodzi po tygodniu.

Prowadziłem m.in. planowaną migrację redakcyjnego serwisu Smart Business Magazine między dostawcami hostingu - z testem na środowisku roboczym i przełączeniem bez przerwy w działaniu. Swoją stronę it-art.pl przeniosłem z WordPressa na statyczne Astro. Poniżej kolejność, w jakiej robię takie przeniesienia, i lista rzeczy do sprawdzenia.

Kiedy migracja ma sens

Zmiana hostingu ma sens, gdy:

  • strona regularnie zwalnia lub pada, a hosting nie oferuje sensownego rozwiązania,
  • serwer nie pozwala na aktualną wersję PHP albo bazy danych,
  • brakuje podstaw: kopii zapasowych poza serwerem, dostępu SSH, środowiska testowego,
  • support odpowiada po dniach, a nie godzinach,
  • przebudowujesz stronę i i tak zmienia się technologia.

Jeśli problemem jest wolna strona, najpierw sprawdź, czy winny jest serwer, czy ciężki motyw i nadmiar wtyczek. Przeniesienie WordPressa na inny serwer nie naprawi źle zbudowanej strony.

Inwentaryzacja przed migracją

Zanim cokolwiek skopiujesz, spisz, co faktycznie działa na starym hostingu. Na liście powinny się znaleźć:

  • Pliki strony - cały katalog, łącznie z uploadami, plikami .htaccess, wp-config.php i katalogami spoza WordPressa (stare landing pages, pliki weryfikacyjne, feedy).
  • Baza danych - nazwa, użytkownik, wersja MySQL/MariaDB, kodowanie znaków.
  • Poczta - lista skrzynek, aliasów, przekierowań i ich rozmiar.
  • DNS - pełny eksport strefy: rekordy A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, weryfikacje Google, Microsoft, Facebooka). Zrób zrzut ekranu albo eksport, zanim cokolwiek zmienisz.
  • Zadania cron - systemowe, ustawione w panelu hostingu, i to, czy WordPress korzysta z WP-Cron, czy z prawdziwego crona.
  • SSL - czy certyfikat to Let’s Encrypt, czy kupiony, i kiedy wygasa.
  • Dostępy - panel starego i nowego hostingu, panel rejestratora domeny, FTP/SSH, administrator WordPressa, Google Search Console, Analytics.

Osobno sprawdź, gdzie jest zarejestrowana domena i kto zarządza jej DNS. To trzy różne rzeczy: rejestrator, serwery DNS i hosting. Zmiana hostingu nie wymaga przeniesienia domeny do innego rejestratora. Przeniesienie domeny (transfer) to osobna operacja, którą lepiej zrobić w innym terminie niż migrację.

Obniżenie TTL z wyprzedzeniem

TTL mówi, jak długo serwery DNS na świecie mogą trzymać w pamięci odpowiedź o Twojej domenie. Jeśli rekord A ma TTL 86400 sekund (24 godziny), po zmianie adresu IP część użytkowników przez dobę będzie trafiać na stary serwer.

Dlatego co najmniej dobę-dwie przed planowanym przełączeniem - a dokładniej: z wyprzedzeniem nie mniejszym niż obecny TTL - obniżam TTL rekordów, które będą się zmieniać (A, AAAA, MX, ewentualnie CNAME www) do 300 sekund. Po migracji i kilku dniach stabilnej pracy można go z powrotem podnieść.

Jeśli zmieniasz całe serwery DNS (rekordy NS), na czas propagacji masz mniejszy wpływ. Bezpieczniej najpierw przenieść strefę DNS, poczekać, a dopiero potem zmieniać adresy.

Kopia i przeniesienie: pliki i baza

Kolejność jest prosta, ale łatwo coś pominąć:

  1. Pełna kopia zapasowa starej strony (pliki + baza) zapisana poza serwerem. To jest plan B, jeśli coś pójdzie nie tak.
  2. Skopiowanie plików na nowy serwer - przez SSH (rsync) albo, gdy go nie ma, przez archiwum i FTP.
  3. Eksport bazy (mysqldump lub phpMyAdmin) i import na nowym serwerze.
  4. Aktualizacja wp-config.php: nazwa bazy, użytkownik, hasło, host bazy.

Jeśli domena się nie zmienia, w bazie WordPressa nic więcej nie trzeba poprawiać. Jeśli zmienia się domena albo protokół (np. z http na https), trzeba podmienić adresy w bazie. Nie robi się tego zwykłym REPLACE w SQL - WordPress i wtyczki trzymają część ustawień w danych serializowanych, gdzie zapisana jest długość tekstu. Zmiana adresu na dłuższy lub krótszy psuje takie wpisy. Bezpieczny sposób to WP-CLI:

wp search-replace 'https://stara-domena.pl' 'https://nowa-domena.pl' --all-tables --dry-run

Najpierw z --dry-run, potem bez tej flagi. Podobnie działają wtyczki do migracji.

Od skopiowania bazy do przełączenia DNS na starej stronie nie powinno się nic zmieniać - trzeba ustalić „zamrożenie treści” albo ponownie zsynchronizować bazę tuż przed przełączeniem. Przy serwisie redakcyjnym, gdzie artykuły pojawiają się codziennie, to jeden z ważniejszych punktów planu.

Test nowego serwera przez plik hosts

To krok, który pozwala sprawdzić stronę na nowym serwerze, zanim zobaczy ją ktokolwiek inny. Plik hosts na Twoim komputerze ma pierwszeństwo przed DNS, więc możesz „przekierować” domenę na nowy adres IP tylko u siebie.

Plik znajduje się w /etc/hosts (Linux, macOS) lub C:\Windows\System32\drivers\etc\hosts (Windows, edycja jako administrator). Wpis wygląda tak:

203.0.113.10   twojadomena.pl
203.0.113.10   www.twojadomena.pl

Przeglądarka otworzy wtedy stronę z nowego serwera, choć dla reszty świata nic się nie zmieniło. Sprawdzam podstrony, logowanie do panelu, formularze, wyszukiwarkę, koszyk, jeśli jest. Certyfikat może jeszcze nie działać - to normalne, jeśli nowy serwer wystawia go dopiero po zmianie DNS.

Po testach usuń wpis - zapomniany to częsty powód sytuacji „u mnie działa, a u klienta nie”.

Poczta: MX, SPF, DKIM, DMARC i migracja skrzynek

Poczta to osobna pułapka. Jeśli maile zostają u dotychczasowego dostawcy (np. Google Workspace, Microsoft 365), przy migracji strony nie ruszasz rekordów MX - wystarczy pilnować, żeby nie zgubić ich przy przenoszeniu strefy DNS.

Jeśli poczta przenosi się razem z hostingiem, do zrobienia są cztery rzeczy:

  • MX - wskazuje serwer, który odbiera pocztę dla domeny.
  • SPF - rekord TXT z listą serwerów uprawnionych do wysyłki z domeny. Może być tylko jeden rekord SPF na domenę, więc dopisujesz nowy serwer do istniejącego, a nie dodajesz drugi:
v=spf1 include:_spf.nowy-hosting.pl include:_spf.google.com ~all
  • DKIM - klucz publiczny w DNS, którym serwer podpisuje wysyłane maile. Nowy serwer pocztowy ma własny klucz, więc trzeba go wygenerować i dodać rekord, zwykle pod nazwą typu selektor._domainkey.
  • DMARC - rekord TXT pod _dmarc, który mówi serwerom odbiorców, co robić z mailami niespełniającymi SPF/DKIM. Na start bezpieczne jest v=DMARC1; p=none; rua=mailto:adres@twojadomena.pl.

Sama zawartość skrzynek nie przeniesie się przez zmianę MX. Trzeba ją skopiować - najczęściej przez IMAP, narzędziem typu imapsync albo mechanizmem importu nowego dostawcy. Robię to dwa razy: pierwsza synchronizacja przed przełączeniem, druga po kilku dniach, bo w trakcie propagacji część wiadomości może jeszcze trafić na stary serwer. Stare skrzynki zostawiam aktywne do tego momentu.

Przełączenie DNS i SSL

Gdy test przez hosts przeszedł, a TTL jest już niski, zmieniasz rekordy A/AAAA (i MX, jeśli trzeba) na nowe adresy. Przy TTL 300 sekund większość ruchu przechodzi na nowy serwer w ciągu kilku-kilkunastu minut, choć pojedyncze sieci mogą trzymać stare odpowiedzi dłużej.

Certyfikat Let’s Encrypt w standardowej walidacji HTTP da się wystawić dopiero wtedy, gdy domena wskazuje na nowy serwer. Część hostingów pozwala na walidację przez DNS albo import istniejącego certyfikatu - warto to ustalić wcześniej, żeby uniknąć kilku minut z ostrzeżeniem w przeglądarce. Przez kilka dni po przełączeniu stary hosting powinien jeszcze działać - nie wypowiadaj go w dniu migracji.

Strona główna serwisu smart-magazine.pl po migracji

Checklista po migracji

Po przełączeniu sprawdzam kolejno:

  • Formularze - wysyłam testowe zgłoszenie i sprawdzam, czy dochodzi i nie ląduje w spamie.
  • Maile transakcyjne - reset hasła, potwierdzenie zamówienia, powiadomienia. Jeśli strona wysyła przez funkcję mail() serwera, na nowym hostingu może to działać inaczej. Lepiej skonfigurować wysyłkę przez SMTP.
  • Crony - czy zadania zostały odtworzone i faktycznie się uruchamiają.
  • Przekierowania - reguły z .htaccess lub konfiguracji serwera, przekierowanie na https i na wersję z www lub bez.
  • Search Console - czy usługa jest zweryfikowana (weryfikacja przez plik lub meta tag mogła się zgubić), czy nie rosną błędy. Przy zmianie domeny - narzędzie zmiany adresu i przekierowania 301 ze starych adresów.
  • Wydajność - czas odpowiedzi serwera i wyniki PageSpeed w porównaniu ze stanem sprzed migracji.
  • Kopie zapasowe - czy na nowym serwerze w ogóle są ustawione.

Typowe wpadki

Te sytuacje widuję najczęściej:

  • Zmiana serwerów DNS bez przeniesienia wszystkich rekordów - znikają poczta albo weryfikacje usług.
  • Dwa rekordy SPF albo brak DKIM na nowym serwerze - maile lądują w spamie.
  • Podmiana domeny w bazie zwykłym SQL i rozsypane ustawienia motywu czy widżetów.
  • Wypowiedzenie starego hostingu w dniu migracji, zanim przeniesiono pocztę i zanim propagacja się zakończyła.
  • Różna wersja PHP na nowym serwerze i niekompatybilna wtyczka.

Checklista

  1. Zrób pełną kopię plików i bazy, zapisaną poza serwerem.
  2. Wyeksportuj całą strefę DNS i zapisz ją.
  3. Spisz skrzynki pocztowe, aliasy i przekierowania.
  4. Spisz zadania cron i ustawienia SSL.
  5. Zbierz dostępy: oba hostingi, rejestrator, WordPress, Search Console.
  6. Sprawdź wersję PHP i bazy na nowym serwerze.
  7. Obniż TTL zmienianych rekordów do 300 s z wyprzedzeniem co najmniej równym obecnemu TTL.
  8. Skopiuj pliki i bazę, zaktualizuj wp-config.php.
  9. Przy zmianie domeny użyj wp search-replace, najpierw z --dry-run.
  10. Przetestuj stronę na nowym serwerze przez plik hosts.
  11. Wykonaj pierwszą synchronizację skrzynek pocztowych.
  12. Przygotuj rekordy MX, SPF (jeden), DKIM i DMARC.
  13. Ustal zamrożenie treści lub zsynchronizuj bazę tuż przed przełączeniem.
  14. Zmień rekordy DNS i wystaw certyfikat SSL.
  15. Przetestuj formularze i maile transakcyjne.
  16. Odtwórz i sprawdź crony, przekierowania i kopie zapasowe.
  17. Sprawdź Search Console i wydajność.
  18. Po kilku dniach zrób drugą synchronizację poczty, podnieś TTL i dopiero wtedy wypowiedz stary hosting.

Najczęstsze pytania

Ile trwa migracja strony na nowy hosting?

Kopiowanie małej strony firmowej to zwykle kwestia godzin. Cały proces, z obniżeniem TTL, testami i drugą synchronizacją poczty, rozkłada się na kilka dni - głównie czekania.

Czy przy zmianie hostingu muszę przenosić domenę?

Nie. Domena może zostać u obecnego rejestratora - zmieniasz tylko rekordy DNS albo serwery DNS. Przeniesienie domeny do innego rejestratora to osobna operacja i lepiej nie łączyć jej z migracją strony.

Czy migracja zaszkodzi pozycjom w Google?

Jeśli domena i adresy podstron się nie zmieniają, a strona działa przez cały czas, sama zmiana serwera nie powinna mieć znaczenia. Ryzyko pojawia się przy zmianie domeny lub struktury adresów bez przekierowań 301 i przy dłuższej niedostępności strony.

Czy da się przenieść stronę bez żadnej przerwy?

Tak, jeśli stary serwer działa do końca propagacji, nowy jest przetestowany przez plik hosts, a TTL obniżono wcześniej. Najtrudniej jest przy stronach, gdzie treści lub zamówienia przybywają cały czas - tam kluczowe jest zaplanowanie momentu synchronizacji bazy.

Podsumowanie

Migracja strony na nowy hosting bez przestoju to głównie kwestia przygotowania: pełnej inwentaryzacji, niskiego TTL, testu przez plik hosts i potraktowania poczty jako osobnego zadania. Samo przełączenie trwa wtedy kilka minut.

Migracja to też dobry moment na uporządkowanie aktualizacji, kopii i monitoringu. Co powinna obejmować stała opieka, opisałem w artykule Opieka nad stroną internetową - co powinna obejmować. Jeśli chcesz przenieść stronę i pocztę bez nerwów albo oddać komuś stałą opiekę nad serwerem i WordPressem, zobacz opiekę nad stroną - 250 zł brutto miesięcznie.

› kontakt

Zaczynamy od rozmowy

15 minut, bez zobowiązań. Powiesz, co chcesz zrobić - powiem, czy to dla mnie i ile mniej-więcej kosztuje.

albo napisz: bartosz@it-art.pl