Migracja hostingu bez przestoju nie zaczyna się w dniu przełączenia. Zaczyna się wtedy, gdy ktoś sprawdza, czy nowy serwer w ogóle potrafi obsłużyć stronę w takim samym rytmie jak stary: z tymi samymi wersjami PHP, tym samym limitem pamięci, identycznymi zadaniami cron, poprawnym certyfikatem SSL i bazą danych, która nie rozjedzie się po pierwszym zamówieniu złożonym w trakcie przenosin. Samo skopiowanie plików to najłatwiejszy fragment. Najwięcej problemów robią drobiazgi: zbyt wysokie TTL w DNS, brak testowego importu bazy, inne rozszerzenia PHP, niedziałająca poczta transakcyjna albo panel administracyjny, który zapisuje dane jeszcze po wykonaniu kopii.
Przygotowanie środowiska: najpierw zgodność, potem przenoszenie
Pierwsza decyzja jest prosta: nie migruje się strony na hosting, którego nie porównano ze starym środowiskiem. Nawet jeśli nowy pakiet wygląda lepiej w ofercie, praktyka szybko weryfikuje marketing. Trzeba sprawdzić nie tylko pojemność dysku i liczbę vCPU, ale też limity procesów, pamięć PHP, maksymalny czas wykonywania skryptu, wersję bazy danych, obsługę Redis/Memcached, limity inode, konfigurację poczty i dostęp do logów.
Minimalna lista kontroli przed migracją powinna obejmować:
- wersje technologii: PHP, MariaDB/MySQL, PostgreSQL, Node.js, Composer, WP-CLI, frameworki i rozszerzenia;
- zasoby serwera: CPU, RAM, I/O dysku, limity procesów, liczba jednoczesnych połączeń, limity zapytań do bazy;
- konfigurację aplikacji: zmienne środowiskowe, pliki
.env, ścieżki katalogów, uprawnienia, zadania cron; - DNS i domeny: rekordy A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, rekordy dla CDN;
- SSL: certyfikat, automatyczne odnawianie, przekierowanie HTTP→HTTPS, zgodność certyfikatu z domenami i subdomenami;
- pocztę: formularze kontaktowe, wiadomości systemowe, potwierdzenia zamówień, SMTP, logi wysyłki.
Największy priorytet mają backup i test odtworzenia. Kopia plików oraz bazy danych nic nie znaczy, dopóki nie została odtworzona w środowisku testowym. W projektach produkcyjnych trzeba wykonać próbny import bazy, sprawdzić kodowanie znaków, liczbę rekordów, integralność tabel i działanie logowania. Jeżeli backup przywraca się trzy godziny, a okno migracyjne trwa godzinę, to nie jest plan awaryjny, tylko złudzenie bezpieczeństwa.
Drugim priorytetem jest zamrożenie zmian, czyli ustalenie momentu, od którego stary system nie powinien przyjmować nowych zapisów albo musi synchronizować je z nowym środowiskiem. Przy zwykłej stronie firmowej wystarczy czasem krótki tryb maintenance. Przy sklepie internetowym wygląda to inaczej: zamówienia, płatności, konta klientów, koszyki i stany magazynowe nie mogą zniknąć między eksportem a przełączeniem DNS. Tam potrzebna jest replikacja, kolejka zdarzeń albo bardzo krótki, precyzyjnie zaplanowany freeze.
Przed właściwą migracją dobrze jest też obniżyć TTL rekordów DNS. Robi się to zwykle 24–48 godzin wcześniej, ustawiając niższą wartość, na przykład 300 sekund. Nie gwarantuje to natychmiastowej propagacji u każdego dostawcy internetu, ale skraca czas, w którym część użytkowników trafia jeszcze na stary serwer. Zmiana TTL pięć minut przed cutoverem prawie nic nie daje, bo wcześniejsza, wysoka wartość nadal może być trzymana w cache.
Checklista migracyjna: kolejność ma większe znaczenie niż ambicja
Dobra checklista migracji hostingu nie jest listą życzeń. To instrukcja wykonania, którą można przejść krok po kroku nawet wtedy, gdy coś zaczyna się sypać. Każde zadanie powinno mieć właściciela, status, warunek zakończenia i decyzję awaryjną. W przeciwnym razie podczas cutoveru zaczyna się zgadywanie: kto zmienia DNS, kto sprawdza płatności, kto patrzy w logi, kto podejmuje decyzję o rollbacku.
Najbardziej praktyczny układ checklisty to podział na cztery etapy.
1. Przed migracją
Na tym etapie przygotowuje się nowe środowisko, konta dostępowe, certyfikaty, repozytorium, backupy i testowy import danych. Trzeba też spisać zależności zewnętrzne: bramki płatności, API firm kurierskich, system fakturowy, CRM, narzędzia mailingowe, webhooki i integracje analityczne. To częsty błąd: strona po migracji działa, ale zamówienia nie wpadają do systemu magazynowego, bo webhook nadal wskazuje stary adres IP albo stary endpoint.
2. Próba generalna
Migracja testowa powinna być wykonana na kopii produkcji. Nie wystarczy wejść na stronę główną i kliknąć kilka podstron. Trzeba przejść najważniejsze ścieżki: logowanie, reset hasła, wysłanie formularza, złożenie zamówienia testowego, płatność w trybie sandbox, wyszukiwanie, generowanie dokumentów, panel administratora, upload plików i wysyłkę maili. Przy WordPressie dochodzą wtyczki cache, przekierowania, media, uprawnienia katalogów i zadania WP-Cron. Przy aplikacjach customowych — kolejki, workery, storage, konfiguracja .env i logowanie błędów.
3. Cutover
Właściwe przełączenie powinno mieć jasny scenariusz. Najpierw wykonuje się ostatnią synchronizację plików, potem eksport lub replikację bazy, następnie blokadę zapisu, test integralności, zmianę DNS albo przełączenie load balancera/CDN, a na końcu testy produkcyjne. W tym momencie nie wdraża się nowych funkcji, nie aktualizuje wtyczek „przy okazji” i nie poprawia starych błędów. Migracja ma przenieść stabilny stan, a nie mieszać trzy ryzyka naraz.
4. Po migracji
Po przełączeniu trzeba obserwować serwer, a nie tylko odświeżyć stronę w przeglądarce. Pierwsze godziny są krytyczne. Należy sprawdzić logi błędów, obciążenie CPU, wykorzystanie RAM, wolne zapytania SQL, błędy 404/500, kolejki maili, dostępność panelu admina, działanie płatności i komunikację z API. Monitoring powinien działać co najmniej kilka dni, bo część problemów wychodzi dopiero przy większym ruchu albo przy cyklicznych zadaniach uruchamianych raz na dobę.
Najważniejsza zasada: rollback musi być decyzją, nie dramatem. Przed migracją trzeba ustalić granicę: po ilu błędach, po jakim czasie niedostępności albo po jakim typie awarii wracamy na stare środowisko. Bez takiej granicy zespoły często brną dalej, bo „jeszcze jedna poprawka i ruszy”. To najkrótsza droga do długiego przestoju.
Strategie cutover: kiedy wybrać szybkie przełączenie, a kiedy migrację etapową
Nie każda strona potrzebuje tej samej strategii. Blog, strona firmowa, sklep z ruchem sezonowym i aplikacja SaaS 24/7 mają różne ryzyka. Dlatego strategia cutover powinna wynikać z tego, jak często zmieniają się dane i ile kosztuje błąd.
Big bang sprawdza się przy prostych stronach, które rzadko zapisują dane. Kopiujesz pliki, importujesz bazę, testujesz, zmieniasz DNS i obserwujesz. To szybka metoda, ale ma jedną wadę: jeżeli coś pójdzie źle, cały serwis jest dotknięty problemem. Dla małej strony wizytówkowej to akceptowalne. Dla sklepu w trakcie kampanii reklamowej — ryzykowne.
Parallel run, czyli równoległa praca starego i nowego środowiska, daje więcej kontroli. Nowy hosting działa obok starego, a ruch można przełączać stopniowo przez CDN, load balancer albo wybrane rekordy DNS. To dobre rozwiązanie dla serwisów, gdzie dostępność jest ważniejsza niż prostota operacji. Trzeba jednak pilnować danych. Jeżeli oba środowiska przyjmują zapisy, potrzebna jest synchronizacja albo jasna reguła, które środowisko jest źródłem prawdy.
Migracja etapowa ma sens przy dużych systemach: osobno panel klienta, osobno API, osobno media, osobno baza, osobno subdomeny. Pozwala ograniczyć skutki błędu, ale wymaga lepszej dokumentacji i kontroli zależności. Nie powinno się jej wybierać tylko dlatego, że brzmi profesjonalnie. Przy małym projekcie etapowanie potrafi niepotrzebnie wydłużyć proces i zwiększyć liczbę miejsc, w których można się pomylić.
W praktyce najbezpieczniej działa zasada: im więcej zapisów użytkowników, tym mniej miejsca na prosty eksport/import. Sklep, portal z kontami, platforma kursowa, system rezerwacji czy aplikacja z płatnościami powinny mieć plan na spójność danych. Może to być krótki freeze, replikacja bazy, synchronizacja plików przesłanych przez użytkowników albo czasowe wyłączenie tylko tych funkcji, które zapisują dane. Nie wszystko musi być zatrzymane. Czasem wystarczy zablokować koszyk i panel użytkownika na kilka minut, zostawiając publiczną część strony dostępną.
Po przełączeniu trzeba wykonać testy w konkretnej kolejności. Najpierw dostępność domeny i HTTPS. Potem logowanie, formularze, płatności, panel administracyjny i funkcje zapisujące dane. Dopiero później wydajność, cache, optymalizacja obrazów i porządki. Nie zaczyna się od kosmetyki, gdy nie wiadomo jeszcze, czy zamówienia wpadają do bazy.
FAQ
Czy da się przenieść hosting całkowicie bez przestoju?
Da się ograniczyć przestój do poziomu niezauważalnego dla większości użytkowników, ale nie zawsze da się go wyzerować. Wszystko zależy od typu serwisu, sposobu zapisu danych, DNS, cache po stronie użytkowników i możliwości synchronizacji między środowiskami.
Kiedy obniżyć TTL rekordów DNS przed migracją?
Najlepiej 24–48 godzin przed planowanym przełączeniem. Wartość 300 sekund jest często wystarczająca przy standardowych migracjach, ale trzeba sprawdzić, czy obecny operator DNS i infrastruktura domeny obsługują takie ustawienie poprawnie.
Co jest ważniejsze: szybkie przełączenie czy dokładne testy?
Dokładne testy. Szybkie przełączenie bez testu importu bazy, SSL, formularzy i płatności może skończyć się dłuższym przestojem niż spokojna migracja z krótkim oknem technicznym. Tempo ma znaczenie dopiero wtedy, gdy procedura jest sprawdzona.
Kiedy wykonać rollback na stary hosting?
Rollback trzeba uruchomić, gdy nowy serwer ma błąd krytyczny: nie działa logowanie, płatności, zapis danych, certyfikat SSL, panel administracyjny albo występują powtarzalne błędy 500. Decyzję należy podjąć według wcześniej ustalonej granicy, a nie po serii nerwowych prób naprawy na produkcji.
Zacznij od porównania starego i nowego środowiska oraz testowego odtworzenia backupu. To pierwszy filtr bezpieczeństwa. Jeżeli kopia nie wstaje poprawnie, baza ma błędy po imporcie albo nowy hosting nie ma wymaganych rozszerzeń, nie planuj cutoveru. Najpierw usuń tę jedną przeszkodę, bo wszystko później — DNS, monitoring, cache i optymalizacja — ma sens dopiero wtedy, gdy fundament działa bez zgadywania.
