Migracja strony na inny hosting brzmi jak „przenoszę pliki i gotowe”, ale w praktyce najwięcej problemów robią drobiazgi: źle ustawiony DNS, certyfikat SSL, brakujące rekordy poczty, niezgodna wersja PHP albo baza danych, która importuje się „do połowy”. Efekt bywa taki, że strona działa u Ciebie, a użytkownicy widzą błąd, bo część ruchu wciąż trafia na stary serwer.
Drugi częsty kłopot to przestój. Nie chcesz, żeby sklep przestał przyjmować zamówienia, a formularze kontaktowe wpadały w czarną dziurę. Dlatego kluczowe nie jest samo przeniesienie, tylko kolejność działań: przygotowanie nowego środowiska, testy na adresie tymczasowym, a dopiero potem przełączenie DNS w sposób, który minimalizuje downtime.
W tym poradniku przeprowadzę Cię przez migrację krok po kroku: od przygotowania planu, przez backup i przeniesienie plików oraz bazy, aż po DNS, SSL i checklistę testów po przełączeniu. Pokazuję też, gdzie najczęściej popełnia się błędy i jak je szybko naprawić bez paniki.
Jeśli dopiero wybierasz nowe miejsce na stronę, warto zacząć od dwóch rzeczy: kryteriów wyboru usługi i porównania ofert. Sprawdź porady dotyczące tego, jak wybrać hosting, a później przejrzyj opcje w rankingu hostingów. Migracja to stresujący moment, więc naprawdę pomaga, gdy nowe środowisko jest przewidywalne.
Kiedy migracja ma sens i jak wybrać nowe miejsce na stronę
Migracja ma sens nie tylko wtedy, gdy hosting „padł”. Często powodem jest rosnący ruch, wolniejsze działanie strony, ograniczenia w panelu, brak sensownych kopii albo frustracja związana z supportem. Zanim ruszysz, nazwij problem: czy chcesz przyspieszyć stronę, zwiększyć niezawodność, uprościć obsługę, czy np. ogarnąć pocztę i bezpieczeństwo w jednym miejscu. Od tego zależy, co uznasz za udany efekt migracji.
Jeśli dopiero wybierasz nowego dostawcę, nie opieraj się na jednym parametrze. W migracji liczy się też codzienna obsługa: czy panel pozwoli Ci szybko dodać domenę, włączyć SSL, utworzyć bazę, podejrzeć logi i wykonać odtworzenie. To element, który potrafi skrócić awarię z godzin do minut, dlatego warto go traktować jak część „jakości hostingu”.
Jeśli przenosisz WordPressa, rozważ usługę dopasowaną do WP, bo często oznacza to wygodniejsze narzędzia i ustawienia pod CMS. Zobacz, jak wygląda hosting WordPress i oceń, czy ułatwi Ci migrację (np. gotowe instalatory, prostsze SSL, łatwiejsze odtworzenie).
Na koniec: sprawdź, czy Twój plan migracji uwzględnia pocztę. Jeśli domena obsługuje skrzynki na hostingu, przeprowadzka strony może „przy okazji” wywrócić maile, jeśli nie przeniesiesz rekordów MX i powiązanych ustawień. Lepiej założyć to z góry niż ratować sytuację po fakcie.
Plan migracji bez przestoju
Najważniejsza zasada migracji bez stresu brzmi: najpierw przygotuj i przetestuj nowe środowisko, dopiero potem przełącz DNS. Wiele przestojów bierze się z tego, że ktoś przenosi pliki, importuje bazę, a potem od razu zmienia rekord A – i dopiero wtedy okazuje się, że na nowym serwerze brakuje rozszerzenia PHP, nie działa wysyłka maili albo certyfikat SSL jeszcze nie jest gotowy.
Drugi filar to TTL, czyli czas, przez jaki serwery DNS pamiętają odpowiedź. Jeśli Twoje rekordy mają TTL ustawiony na kilka godzin, część użytkowników będzie trafiać na stary serwer długo po przełączeniu. Żeby skrócić ten okres, sensownie jest obniżyć TTL wcześniej (np. dzień przed migracją), a po zakończeniu wrócić do wyższej wartości.
Warto też wybrać okno przełączenia: porę, w której masz najmniejszy ruch i możesz przez godzinę-dwie pilnować sytuacji. To nie musi być noc, ale dobrze, żebyś nie robił migracji „w środku dnia”, jeśli wiesz, że wtedy wpadają zamówienia albo leady z kampanii.
W migracji strony dynamicznej (sklep, serwis z formularzami, panel klienta) pojawia się dodatkowy problem: co z danymi, które wpadają w trakcie przełączenia. Tu często działa prosta strategia: minimalizujesz okno zmian, robisz finalny eksport bazy tuż przed zmianą DNS i możliwie szybko przełączasz domenę. To nie jest zero-jedynkowe, ale pozwala realnie ograniczyć straty.
Jeśli zastanawiasz się, czy lepiej przenosić stronę www czy od razu migrować też WordPressa na środowisko pod WP, pomocne jest zrozumienie różnicy usług, w tym kontekście warto znać różnice – Hosting www vs hosting WordPress. Ta różnica często wychodzi właśnie przy migracjach i awariach.
Backup i punkt powrotu: jak się zabezpieczyć?
Migracja bez solidnego backupu to proszenie się o kłopoty. Nawet jeśli jesteś ostrożny, jedna pomyłka w bazie lub nadpisanie plików potrafi zepsuć stronę w sposób, który odkryjesz dopiero po przełączeniu DNS. Backup jest Twoim pasem bezpieczeństwa: pozwala wrócić do stanu sprzed migracji albo odtworzyć brakujące elementy.
Najpierw ustal, co backup ma obejmować: pliki strony (w tym uploady), bazę danych, pliki konfiguracyjne (np. wp-config.php), a jeśli dotyczy — także pocztę i konfiguracje powiązane z domeną. W praktyce najszybciej wykoleja się migracja, gdy ktoś bierze „archiwum strony”, ale zapomina o bazie albo eksportuje ją z niewłaściwej bazy/użytkownika.
Drugi krok to sensowna organizacja kopii. Zrób backup przed startem, a potem drugi „finalny” tuż przed przełączeniem DNS (zwłaszcza, jeśli strona jest dynamiczna). Każdą kopię nazwij datą i godziną, żeby nie zgadywać, która jest „ta właściwa”, gdy zacznie się presja czasu.
Trzeci element to miejsce przechowywania. Jeśli backup leży tylko na tym samym hostingu, który właśnie zmieniasz, to przy problemie możesz stracić zarówno stronę, jak i kopię. W idealnym scenariuszu trzymasz backup także poza hostingiem (np. lokalnie lub w chmurze), choćby jako warstwę awaryjną.
Jeżeli chcesz podejść do tematu porządnie i zrozumieć, co w backupach hostingu bywa pułapką (retencja, offsite, realne odtwarzanie), zajrzyj do tekstu Kopie zapasowe w hostingu. Jak wybrać backup, który działa?. Przy migracji to wiedza, która realnie oszczędza nerwy.
Przygotowanie nowego hostingu: PHP, baza, katalogi, poczta i panel
Najczęstszy błąd w przygotowaniu nowego hostingu to założenie, że „wszystko będzie takie samo”. A nie będzie. Różnice w wersji PHP, limitach pamięci, ustawieniach serwera, a nawet w domyślnej strukturze katalogów potrafią wywołać błędy, których nie widać na pierwszy rzut oka. Dlatego zanim wgrasz dane, przygotuj środowisko i sprawdź zgodność.
Zacznij od podstaw: utwórz domenę (lub domenę tymczasową/subdomenę), załóż bazę danych i użytkownika, sprawdź dostęp do phpMyAdmin (albo innego narzędzia), a jeśli masz możliwość – włącz SSH. Następnie ustaw wersję PHP zgodną z Twoją stroną i dopasuj podstawowe limity (pamięć, rozmiar uploadu, czas wykonywania). W WordPressie i sklepach to często robi różnicę między „działa” a „białą stroną”.
Kolejny krok to panel. Różne panele inaczej nazywają te same funkcje (edytor DNS, menedżer plików, backupy, logi). Jeśli już wiesz, że będziesz musiał przeklikać kilka ustawień i szybko reagować w trakcie migracji, panel, który jest czytelny, jest po prostu tańszy w użyciu. Jeśli chcesz zrozumieć, gdzie panele pomagają, a gdzie dokładają roboty, przyda się wiedza z wpisu Panel hostingu: co ułatwia pracę, a co generuje koszty?.
Nie pomijaj poczty. Nawet jeśli „teraz przenoszę tylko stronę”, to w praktyce domena ma zwykle rekordy MX, SPF/DKIM/DMARC, czasem aliasy. Jeśli u nowego dostawcy poczta ma działać inaczej (albo zostaje u starego), musisz to uwzględnić w DNS, żeby nie zrobić sobie przerwy w mailach.
Na koniec przygotuj miejsce na testy: najlepiej tak, byś mógł otworzyć stronę na nowym hostingu przed przełączeniem DNS. Najczęściej robi się to przez adres tymczasowy lub wpis w pliku hosts u siebie. Dzięki temu testujesz logowanie, formularze i koszyk, zanim ktokolwiek z zewnątrz zobaczy nową wersję.
Przenoszenie plików: co skopiować, jak nie zepsuć uprawnień i ścieżek
W plikach strony najważniejsze są trzy rzeczy: kompletność, struktura katalogów i uprawnienia. Kompletność oznacza, że kopiujesz nie tylko kod, ale też wszystkie uploady, cache (jeśli potrzebujesz), pliki .htaccess i pliki konfiguracyjne. Brak katalogu z mediami to klasyk: strona „działa”, ale bez obrazków – i dopiero użytkownicy to zgłaszają.
Wybór metody transferu zależy od rozmiaru i Twoich narzędzi. FTP/SFTP jest ok dla mniejszych stron, ale przy dużych uploadach bywa wolne i podatne na przerwania. Jeśli masz SSH, rsync potrafi oszczędzić dużo czasu i pozwala dociągnąć tylko brakujące pliki po pierwszym kopiu. Niezależnie od metody, po zakończeniu porównaj liczbę plików lub rozmiar katalogów, żeby nie odkryć braków po przełączeniu.
Uważaj na uprawnienia i właściciela plików. Po przeniesieniu na nowy serwer czasem pliki mają inne prawa dostępu, a wtedy CMS nie może zapisywać uploadów, aktualizacje wtyczek się wywracają albo cache nie działa. To typowy objaw: nie da się wgrać obrazka, a panel wyrzuca błąd zapisu. Wtedy sprawdzasz uprawnienia katalogów (najczęściej uploadów) i porównujesz je z tym, jak wyglądało to na starym hostingu.
Jeśli przenosisz WordPressa lub sklep, zwróć uwagę na ścieżki i pliki konfiguracyjne, które zawierają odwołania do konkretnej domeny lub katalogu. W WordPressie domena jest głównie w bazie, ale czasem wtyczki trzymają ścieżki w ustawieniach. Dlatego „tylko pliki” prawie nigdy nie wystarczają – potrzebujesz spójnego przeniesienia plików i bazy.
Dobrą praktyką jest też wyczyszczenie cache po stronie nowego serwera (albo przynajmniej jego regeneracja), bo przeniesione pliki cache potrafią trzymać stare ścieżki i wywoływać dziwne zachowania. To drobiazg, który często oszczędza czas.
Migracja bazy danych: eksport, import, duże tabele i typowe błędy
Baza danych to serce większości stron. Przy migracji liczy się nie tylko to, czy eksport/import „przejdzie”, ale czy przeniesiesz ją w całości i bez błędów. Najprostsza droga to eksport w phpMyAdmin i import na nowym hostingu, ale przy większych bazach możesz trafić na limity (rozmiar pliku, czas wykonywania, przerwania).
Zacznij od eksportu: wybierz właściwą bazę, ustaw eksport w formacie SQL i upewnij się, że eksport obejmuje strukturę i dane. Jeśli masz sklep albo serwis z dużą liczbą rekordów, rozważ eksport w częściach (np. wybrane tabele osobno) albo metodę przez konsolę, jeśli masz SSH. W wielu przypadkach problemem nie jest sama baza, tylko limity narzucone przez panel.
Przy imporcie zwróć uwagę na kodowanie i silnik bazy. Objawy problemów z kodowaniem są dość charakterystyczne: polskie znaki „krzaki”, tytuły wpisów z pytajnikami, źle wyświetlane opisy produktów. Wtedy sprawdzasz ustawienia kodowania w bazie i to, w jakim kodowaniu został zrobiony eksport. Lepiej to wyłapać w testach przed przełączeniem DNS niż po fakcie.
Kolejny obszar to dane wrażliwe na czas: zamówienia, rejestracje, formularze. Jeśli strona jest aktywna, a Ty zrobisz eksport rano i przełączysz DNS wieczorem, stracisz to, co wpadło w międzyczasie. Dlatego w planie migracji warto mieć „finalny eksport” tuż przed przełączeniem i możliwie krótkie okno zmian.
Po imporcie nie zakładaj, że „skoro nie ma błędu, to jest OK”. Wejdź do panelu CMS, sprawdź liczbę wpisów/produktów, wykonaj wyszukiwanie, otwórz kilka losowych podstron. W sklepach sprawdź koszyk i proces zamówienia w trybie testowym. W WordPressie sprawdź media i kilka wpisów z obrazkami, bo tu często wychodzą braki.
DNS krok po kroku: A/AAAA, CNAME, MX, TTL i testy przed przełączeniem
DNS to miejsce, gdzie najłatwiej o chaos, bo zmiany nie działają „wszędzie naraz”. Kluczowe rekordy dla strony to zwykle A (IPv4) i czasem AAAA (IPv6). Jeśli Twoja domena ma też subdomeny (np. sklep., panel., api.), upewnij się, że wiesz, które rekordy są potrzebne i czy wszystkie mają trafić na nowy serwer.
Najbezpieczniejszy scenariusz to testy przed przełączeniem. Zanim zmienisz rekordy, sprawdź stronę na nowym hostingu po adresie tymczasowym albo przez wpis w pliku hosts. Dzięki temu weryfikujesz, czy strona działa w nowym środowisku, zanim ktokolwiek zacznie na nie trafiać przez domenę.
Kiedy przygotujesz się do przełączenia, wróć do TTL: jeśli obniżyłeś go dzień wcześniej, propagacja powinna być szybsza. W momencie zmiany pamiętaj też o rekordach pobocznych: www jako CNAME lub osobny rekord A, rekordy dla poczty (MX) oraz ewentualne rekordy TXT (np. weryfikacje usług, SPF/DKIM/DMARC). Niby to „nie dotyczy strony”, ale dotyczy domeny – a domena jest wspólna.
Jeśli zmieniasz DNS-y (serwery nazw) na dostawcę hostingu, a nie tylko rekord A, upewnij się, że przenosisz całą strefę DNS. To najczęstsza przyczyna „nagle nie działa poczta / weryfikacja / subdomena”: ktoś przeniósł tylko stronę, ale zgubił część rekordów w nowym DNS.
Na koniec przygotuj prosty sposób weryfikacji: sprawdź domenę z kilku źródeł (np. telefon na LTE + komputer na Wi-Fi), bo możesz trafić na sytuację, gdzie u Ciebie już działa nowy serwer, a część świata wciąż widzi stary. To normalne przy DNS, dlatego warto przez jakiś czas trzymać stary hosting aktywny (przynajmniej na czas propagacji) i nie kasować niczego od razu po przełączeniu.
SSL po migracji: certyfikat, przekierowania, mieszana treść i HSTS
Po migracji SSL to drugi najczęstszy „blokujący” problem po DNS. Najprostszy scenariusz: po przełączeniu domeny na nowy serwer włączasz certyfikat (np. Let’s Encrypt) w panelu i ustawiasz przekierowanie HTTP → HTTPS. Ale w praktyce są dwa haczyki: domena musi już wskazywać na nowy serwer (żeby walidacja zadziałała) i musisz pamiętać o wszystkich wariantach domeny (z www i bez).
Przekierowania to kolejna rzecz, którą łatwo zepsuć. Jeśli na starym serwerze miałeś reguły w .htaccess, a na nowym ich nie przeniesiesz, możesz dostać pętlę przekierowań albo brak przekierowania. Objaw: przeglądarka kręci w kółko, a komunikat mówi o zbyt wielu przekierowaniach. Wtedy sprawdzasz, czy nie dublujesz przekierowań w kilku miejscach (panel + .htaccess + ustawienia CMS).
Mieszana treść (mixed content) pojawia się, gdy strona ładuje zasoby po HTTP, mimo że działa na HTTPS. Objawy: kłódka „ostrzeżenie”, brak części obrazków, problemy z czcionkami lub skryptami. Najczęściej winne są twardo wpisane adresy w treści lub w ustawieniach wtyczek. Rozwiązanie zwykle obejmuje aktualizację adresów w bazie i czyszczenie cache.
Uważaj na HSTS, jeśli było włączone wcześniej. HSTS wymusza HTTPS w przeglądarce i potrafi utrudnić diagnozę w momencie, gdy SSL jeszcze nie działa poprawnie na nowym serwerze. Jeśli masz wątpliwości, najpierw doprowadź do stabilnego działania HTTPS, a dopiero potem wracaj do twardszych wymuszeń.
Po uruchomieniu SSL zrób szybki test: strona główna, logowanie, formularz, koszyk (jeśli jest), oraz kilka podstron. Jeśli coś zniknęło lub blokuje się w konsoli przeglądarki, to bardzo często jest właśnie mieszana treść albo błędny redirect.
Najczęstsze błędy i jak je naprawić
Przełączenie DNS zanim nowy serwer jest gotowy.
Objaw: po zmianie rekordu A strona sypie błędami, a Ty na szybko „dopinasz” PHP, bazę, uprawnienia. Naprawa: cofnij DNS na chwilę (jeśli musisz), dokończ przygotowanie i wróć do przełączenia dopiero po testach na adresie tymczasowym/hosts. Najlepiej traktować DNS jako ostatni krok, nie pierwszy.
Zbyt wysokie TTL i długie „rozjechanie” ruchu między starym i nowym serwerem.
Objaw: jedni widzą starą wersję, inni nową; formularze wpadają w różne miejsca; w sklepie rozjeżdżają się dane. Naprawa: obniż TTL przed migracją (z wyprzedzeniem), a w trakcie propagacji utrzymuj stary serwer aktywny. Jeśli masz stronę dynamiczną, zaplanuj finalny eksport bazy tuż przed przełączeniem.
Niepełny backup albo brak finalnego zrzutu bazy.
Objaw: po migracji brakuje części treści, zamówień lub ustawień, mimo że „wszystko się skopiowało”. Naprawa: odtwórz brakujące elementy z backupu lub wykonaj ponowny eksport/import bazy (finalny) i zsynchronizuj pliki. Jeśli chcesz uporządkować podejście do kopii, pomocny będzie wpis – Kopie zapasowe w hostingu. Jak wybrać backup, który działa?.
Błędne rekordy DNS poza stroną: MX/TXT/weryfikacje usług.
Objaw: strona działa, ale nagle nie dochodzą maile albo usługi przestają się weryfikować. Naprawa: porównaj starą i nową strefę DNS rekord po rekordzie. Jeśli zmieniałeś serwery nazw, upewnij się, że przeniosłeś całą strefę, nie tylko rekord A dla domeny.
Problemy z SSL: pętla przekierowań, brak certyfikatu na www lub mieszana treść.
Objaw: „zbyt wiele przekierowań”, ostrzeżenia przeglądarki, brak części zasobów. Naprawa: sprawdź, czy nie masz jednocześnie wymuszenia HTTPS w panelu i w .htaccess, włącz certyfikat dla wariantu domeny z www i bez, a przy mieszanej treści zaktualizuj adresy w bazie i wyczyść cache.
Różnice w wersji PHP i limitach, które ujawniają się dopiero po przełączeniu.
Objaw: biała strona, błędy 500, niedziałające wtyczki, problemy z uploadem. Naprawa: dopasuj wersję PHP i limity do wymagań strony, sprawdź logi błędów w panelu. Warto też pamiętać, że typ usługi (www vs WordPress) może zmieniać domyślne ustawienia.
Po migracji: monitoring, uptime i kontrola SEO
Po przełączeniu DNS nie kończysz pracy. Pierwsze 24-48 godzin to czas, kiedy wychodzą rzeczy takie jak: brakujący rekord, nietypowa subdomena, problem z cronem, a czasem różnice w cache. Dlatego warto mieć prostą checklistę kontroli: strona główna, kilka podstron, logowanie, formularze, koszyk, wysyłka maila, panel admina, upload pliku, oraz sprawdzenie logów błędów.
Druga rzecz to monitoring. Nawet podstawowy monitoring uptime daje Ci informację, czy strona jest dostępna i czy po migracji nie ma losowych przerw. Jeśli chcesz podejść do tego sensownie (SLA, realna weryfikacja, jak nie dać się złapać na marketing), zajrzyj do wpisu o uptime hostingu. To dobry system wczesnego ostrzegania po przeprowadzce.
Trzeci obszar to SEO. Migracja hostingu sama w sobie nie musi szkodzić, ale przestoje, błędy 5xx, problemy z przekierowaniami i mieszana treść mogą odbić się na widoczności. Po migracji sprawdź, czy adresy działają na HTTPS, czy nie ma masowych błędów 404, i czy prędkość nie spadła. W kontekście tego, jak hosting wpływa na pozycjonowanie i na co patrzeć praktycznie, pomocny będzie wpis hosting a SEO.
Na koniec: daj sobie czas na „sprzątanie”. Kiedy masz pewność, że wszystko działa, możesz podnieść TTL z powrotem, uporządkować rekordy DNS, a dopiero potem myśleć o wyłączeniu starego hostingu. Najgorsze, co możesz zrobić, to skasować stare konto w dniu migracji – bo wtedy odbierasz sobie możliwość szybkiego ratunku.
FAQ – Najczęściej zadawane pytania
Sama operacja skopiowania plików i bazy bywa szybka, ale całość zależy od przygotowania, testów i DNS. Najczęściej najwięcej czasu zajmuje przygotowanie nowego środowiska oraz propagacja DNS po przełączeniu. Jeśli obniżysz TTL wcześniej i przetestujesz stronę przed zmianą rekordów, migracja jest krótsza i spokojniejsza.
Dla stron statycznych bywa to bliskie ideału. Dla stron dynamicznych (sklep, logowania, formularze) „zero przestoju” jest trudne, bo w trakcie przełączenia część użytkowników może trafić jeszcze na stary serwer. Da się jednak mocno ograniczyć ryzyko: obniżyć TTL, przetestować nowy serwer wcześniej i zrobić finalny eksport bazy tuż przed przełączeniem.
Często wystarczy zmiana rekordu A/AAAA, jeśli nie chcesz ruszać strefy DNS. Zmiana serwerów nazw oznacza przeniesienie całej strefy DNS do innego miejsca, co jest bardziej podatne na pomyłki (MX, TXT, subdomeny). Jeśli nie masz powodu, zacznij od prostszego wariantu.
Zwykle najpierw pliki, potem baza, a na końcu drobne korekty w konfiguracji. Przy stronach dynamicznych często robisz wstępny import bazy do testów, a przed przełączeniem DNS wykonujesz finalny eksport/import, żeby zminimalizować utratę danych.
Najczęściej winne są różnice w konfiguracji PHP, cache, sesjach, albo brakujące rozszerzenia. Czasem problemem są też ciasteczka i wymuszenie HTTPS, jeśli SSL jest źle ustawiony. Warto sprawdzić logi błędów i wykonać test w trybie incognito.
Nie rób tego w dniu przełączenia. Zostaw stary hosting aktywny co najmniej na czas propagacji DNS i pierwszych testów (często 24–48 godzin), a w praktyce dłużej, jeśli chcesz mieć pewność, że nic nie zostało pominięte. Dopiero gdy ruch jest stabilnie na nowym serwerze i wszystko działa, planuj wyłączenie.
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