Migracja strony na nowy hosting w 2026: najpierw kopia i test, DNS dopiero na końcu

Najpierw ustal, co naprawdę trzeba przenieść

„Strona” może oznaczać dużo więcej niż katalog z plikami. Typowy serwis ma bazę danych, konfigurację PHP, zadania CRON, certyfikat, skrzynki pocztowe, rekordy DNS, cache, integracje zewnętrzne, formularze i mechanizmy wysyłki e-mail.

W WooCommerce dochodzą płatności, webhooki, harmonogramy, sesje klientów, zamówienia i często zewnętrzne integracje magazynowe.

W Joomla trzeba uwzględnić komponenty, moduły, szablon, rozszerzenia systemowe i zgodność wersji PHP oraz bazy danych.

Backup przed migracją musi być możliwy do odtworzenia

Sam fakt istnienia archiwum nie wystarcza. Potrzebujesz kopii plików i bazy danych, a przy bardziej złożonym serwisie również informacji o DNS, skrzynkach pocztowych i zadaniach CRON.

Przy aktywnym sklepie trzeba dodatkowo ustalić moment ostatniej synchronizacji bazy, żeby podczas migracji nie zgubić nowych zamówień ani zmian klientów.

Nowy hosting powinien być przygotowany przed kopiowaniem

Sprawdzam wersję PHP, wymagane rozszerzenia, limity pamięci, konfigurację bazy, możliwość uruchomienia CRON, obsługę HTTPS oraz mechanizmy cache.

Pliki i bazę kopiuj przed przełączeniem ruchu

Najbezpieczniejszy model to przygotowanie nowej kopii serwisu równolegle do starej.

Po imporcie bazy sprawdzam ścieżki, dane połączenia, prawa dostępu do plików, konfigurację CMS-a i zależności, które mogły odnosić się do starego serwera.

Nie wykonuję masowych zmian produkcyjnej bazy bez kopii i bez świadomości, jak konkretny CMS lub rozszerzenia przechowują dane.

Nową stronę przetestuj zanim zobaczą ją użytkownicy

Nowe środowisko można przetestować przed publiczną zmianą DNS, na przykład przez lokalne wskazanie domeny na nowy serwer lub bezpieczny mechanizm podglądu hostingu.

Dzięki temu testujesz serwis na nowej infrastrukturze, ale publiczny ruch nadal trafia do starego środowiska.

Zmiana hostingu strony nie może przypadkiem wyłączyć poczty

Domena może korzystać z WWW u jednego operatora, a z poczty u innego.

Przed zmianą nameserverów trzeba więc skontrolować wszystkie istotne rekordy DNS, w tym A/AAAA, CNAME, MX i rekordy TXT związane z pocztą.

Szczególnej kontroli wymagają SPF, DKIM i DMARC, ponieważ błędna migracja strefy DNS może pozostawić działające WWW, ale uszkodzić dostarczalność poczty.

Jeżeli URL-e się nie zmieniają, nie twórz niepotrzebnej migracji SEO

Przy czystej zmianie hostingu adresy stron, canonical i linkowanie wewnętrzne powinny pozostać takie same.

Nie ma powodu zmieniać slugów tylko dlatego, że serwis przenosi się na inny serwer.

Jeżeli równocześnie zmieniasz domenę, protokół albo strukturę URL, projekt staje się również migracją SEO. Wtedy potrzebna jest mapa stary URL → nowy URL, przekierowania i kontrola canonical.

Warstwę certyfikatu, szyfrowania i HTTPS szerzej opisuję w artykule HTTPS, TLS i certyfikat SSL na stronie internetowej .

Jeżeli po zmianach pojawia się problem z indeksacją, zobacz również: dlaczego strony nie widać w Google .

Przełączenie produkcyjne powinno mieć plan obserwacji

Po zmianie DNS nie zamykam od razu starego hostingu. Przez okres przejściowy oba środowiska mogą nadal otrzymywać ruch.

Po przełączeniu monitoruję odpowiedzi serwera, certyfikat, logi, formularze, pocztę, zamówienia, integracje oraz dostępność najważniejszych URL-i.

Stary hosting można wyłączyć dopiero wtedy, gdy nowe środowisko jest stabilne i nie ma już potrzeby szybkiego rollbacku.

Checklista migracji strony na nowy hosting

Data weryfikacji: 2 września 2026 r. Dokładny proces migracji zależy od CMS-a, hostingu, DNS, poczty, integracji i tego, czy zmieniają się adresy URL.