Co wziąć pod uwagę przy migracji do innego dostawcy hostingu

Migracja strony internetowej do nowego dostawcy hostingu jest jedną z najbardziej ryzykownych operacji infrastrukturalnych, jakie może podjąć właściciel witryny. Przeprowadzona prawidłowo skutkuje zerową utratą danych, pomijalnym przestojem i mierzalnie lepszą wydajnością. Przeprowadzona niedbale prowadzi do uszkodzonych baz danych, awarii DNS, spadków pozycji w wynikach wyszukiwania SEO i godzin awaryjnych prac naprawczych.

Ten przewodnik obejmuje każdą krytyczną fazę migracji hostingu — od audytu przed migracją i weryfikacji kompatybilności, przez mechanikę przełączenia DNS, aż po monitorowanie po migracji — z techniczną głębią wymaganą do przeprowadzenia jej bez incydentów.

Faza 1: Przeprowadź audyt obecnego środowiska hostingowego przed podjęciem jakichkolwiek działań

Najczęstszą przyczyną niepowodzenia migracji jest pominięcie dokładnego audytu istniejącego środowiska. Zanim ocenisz nowego dostawcę, potrzebujesz precyzyjnego inwentarza tego, co faktycznie uruchamiasz.

Profilowanie ruchu i zasobów

Pobierz dane o zasobach serwera z co najmniej 90 dni — nie tylko liczby odsłon stron. Istotne metryki to:

• Szczytowe jednoczesne połączenia — nie średni ruch, ale maksymalny pik, który serwer musi obsłużyć
• Zużycie pamięci na proces roboczy PHP lub proces aplikacji
• Wzorce I/O dysku — szczególnie istotne, jeśli uruchamiasz aplikację intensywnie korzystającą z bazy danych, jak WooCommerce lub niestandardowy CRM
• Wykorzystanie przepustowości — miesięczne sumy transferu w porównaniu z limitem obecnego planu

Jeśli Twój obecny host udostępnia cPanel lub Plesk, dane te są dostępne w sekcjach wykorzystania zasobów lub AWStats. Na Linux VPS uruchom następujące polecenie, aby uchwycić bazowy snapshot:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Ten wynik informuje, czy wąskim gardłem jest CPU, RAM czy dysk — co bezpośrednio określa, czy potrzebujesz większego planu współdzielonego, VPS, czy Serwera Dedykowanego.

Inwentaryzacja stosu oprogramowania

Udokumentuj każdy komponent swojego stosu z dokładnymi numerami wersji:

• Wersja PHP (np. 8.1, 8.2) i aktywne rozszerzenia (mbstring, curl, gd, imagick, redis)
• Wersja MySQL lub MariaDB i silnik przechowywania danych (InnoDB vs. MyISAM ma znaczenie dla narzędzi migracyjnych)
• Oprogramowanie serwera WWW: Apache, Nginx, LiteSpeed lub kombinacja z odwrotnym proxy
• Wszelkie skompilowane moduły, niestandardowe reguły .htaccess lub bloki lokalizacji nginx.conf
• Zadania cron — wyeksportuj je z crontab -l i udokumentuj osobno
• Typ certyfikatu SSL i wystawca (Let’s Encrypt, komercyjne CA, wildcard)

Pominięcie nawet jednego rozszerzenia PHP na serwerze docelowym może po cichu uszkodzić funkcjonalność, która ujawnia się dopiero przy określonych działaniach użytkownika — błąd, który jest notorycznie trudny do wyśledzenia po migracji.

Faza 2: Oceń i wybierz właściwy poziom hostingu

Wybór niewłaściwego poziomu hostingu to błąd strukturalny, który wymusza drugą migrację w ciągu kilku miesięcy. Dopasuj wyniki audytu do właściwej klasy infrastruktury.

Porównanie poziomów hostingu

Kluczowa zasada decyzyjna: Jeśli Twoja aplikacja wymaga określonej konfiguracji puli PHP-FPM, połączeń przez gniazdo Redis, niestandardowych przepisań Nginx lub jakiegokolwiek procesu demona, hosting współdzielony jest architektonicznie niekompatybilny. Potrzebujesz co najmniej VPS z dostępem root.

Dla witryn WordPress lub Joomla o umiarkowanym ruchu, VPS z cPanel zapewnia znajomy interfejs panelu sterowania przy zachowaniu izolacji i wydajności maszyny wirtualnej.

Kryteria oceny dostawcy

Poza twierdzeniami marketingowymi, oceniaj dostawców na podstawie tych weryfikowalnych czynników technicznych:

• SLA dostępności z klauzulami kar finansowych — SLA na poziomie 99,9% bez odszkodowania jest bez znaczenia
• Ocena poziomu centrum danych (Tier III lub Tier IV dla obciążeń produkcyjnych)
• Redundancja sieci — BGP multi-homing, wielu dostawców upstream
• Typ pamięci masowej — NVMe SSD vs. SATA SSD vs. dysk talerzowy (różnice w opóźnieniach są znaczące)
• Polityka tworzenia kopii zapasowych — częstotliwość, okres przechowywania, czy kopie zapasowe są przechowywane poza siedzibą
• SLA czasu odpowiedzi wsparcia — rozróżnij między czasem pierwszej odpowiedzi a czasem rozwiązania

Faza 3: Utwórz i zweryfikuj kompletną kopię zapasową

Żadna migracja nie powinna się rozpocząć bez zweryfikowanej, możliwej do przywrócenia kopii zapasowej. „Zweryfikowana” oznacza, że faktycznie przetestowałeś przywracanie — nie tylko potwierdziłeś, że plik kopii zapasowej istnieje.

Co musi zawierać kompletna kopia zapasowa

• Pliki katalogu głównego WWW — cały katalog dokumentów, w tym ukryte pliki takie jak .htaccess i .env
• Wszystkie bazy danych — wyeksportowane jako zrzuty .sql, nie tylko kopia plików katalogu bazy danych
• Dane e-mail — jeśli korzystasz z Hostingu E-mail powiązanego z Twoją domeną, wyeksportuj skrzynki pocztowe przed jakimikolwiek zmianami DNS
• Zadania cron — crontab -l > crontab_backup.txt
• Certyfikaty SSL i klucze prywatne — jeśli używasz certyfikatu komercyjnego, wyeksportuj pełny łańcuch
• Pliki konfiguracyjne serwera — /etc/nginx/, /etc/apache2/, /etc/php/, niestandardowe ustawienia my.cnf

Wykonywanie eksportu bazy danych

Dla MySQL/MariaDB użyj mysqldump z opcjami zapewniającymi pełną wierność:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

Flaga --single-transaction jest krytyczna dla tabel InnoDB — wykonuje spójny snapshot bez blokowania tabel, co oznacza, że Twoja działająca witryna nadal obsługuje żądania podczas zrzutu.

Weryfikacja integralności kopii zapasowej

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Kopia zapasowa, której przywracania nie przetestowałeś, nie jest kopią zapasową — to fałszywe poczucie bezpieczeństwa.

Faza 4: Zweryfikuj kompatybilność na serwerze docelowym

Przed przeniesieniem danych produkcyjnych uruchom nowe środowisko i zweryfikuj kompatybilność przy użyciu podejścia stagingowego.

Weryfikacja wersji PHP i rozszerzeń

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Porównaj ten wynik z inwentarzem z Fazy 1. Każde brakujące rozszerzenie musi zostać zainstalowane przed migracją, nie po niej.

Sprawdzenie kompatybilności bazy danych

W przypadku migracji z MySQL 5.7 do MySQL 8.0 (częsty scenariusz) należy mieć świadomość następujących zmian powodujących niezgodność:

• Zestaw znaków utf8mb3 jest przestarzały; kolumny mogą wymagać jawnych deklaracji zestawu znaków
• Zachowanie GROUP BY uległo zmianie — zapytania działające w 5.7 mogą nie działać w 8.0 bez dostosowania trybu ONLY_FULL_GROUP_BY
• NO_ZERO_DATE jest domyślnie włączony w trybie ścisłym, który odrzuca pola dat zawierające 0000-00-00

Przetestuj swój zrzut SQL na docelowej wersji MySQL przed przełączeniem ruchu produkcyjnego.

Tłumaczenie konfiguracji serwera WWW

W przypadku migracji z Apache do Nginx (częsty scenariusz przy przejściu na VPS zoptymalizowany pod kątem wydajności), reguły .htaccess nie są automatycznie tłumaczone. Typowe konwersje:

Przekierowanie Apache .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Odpowiednik Nginx w bloku server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Pominięcie tego tłumaczenia jest jedną z najczęstszych przyczyn błędów 404 i pętli przekierowań po migracji.

Faza 5: Wykonaj migrację z minimalizacją przestoju

Strategiczny wybór okna migracyjnego

Przeanalizuj Google Analytics lub logi serwera, aby zidentyfikować okno najniższego ruchu — zazwyczaj między 02:00 a 05:00 w strefie czasowej głównej grupy odbiorców, we wtorek lub środę. Unikaj piątków; jeśli coś pójdzie nie tak, opcje wsparcia znacznie się zawężają w weekend.

Przepływ pracy migracji z podejściem staging-first

1. Wskaż subdomenę na nowy serwer (np. staging.example.com) używając rekordu A, bez dotykania produkcyjnego DNS
2. Przenieś wszystkie pliki i bazy danych na nowy serwer
3. Zaktualizuj ciąg połączenia z bazą danych aplikacji, aby wskazywał na nową bazę danych
4. Zmodyfikuj lokalny plik /etc/hosts, aby rozwiązywał domenę produkcyjną na IP nowego serwera — pozwala to przetestować pełną konfigurację produkcyjną bez wpływu na aktywnych użytkowników:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Przeprowadź pełny test funkcjonalny — każdy formularz, przepływ płatności, system logowania, endpoint API i przesyłanie mediów
2. Uruchom testy wydajnościowe używając ab (Apache Benchmark) lub wrk:

ab -n 1000 -c 50 https://example.com/

1. Dopiero po pomyślnym przejściu wszystkich testów przejdź do przełączenia DNS

Konfiguracja certyfikatu SSL

Upewnij się, że certyfikat SSL jest zainstalowany i zweryfikowany na nowym serwerze przed przełączeniem DNS. Jeśli używasz Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

Jeśli używasz certyfikatu komercyjnego od dostawcy takiego jak dostępni przez Certyfikaty SSL, zainstaluj pełny łańcuch certyfikatów (certyfikat + pośrednie CA + główne CA), aby uniknąć błędów walidacji łańcucha na starszych klientach.

Faza 6: Przełączenie DNS — najbardziej technicznie wrażliwy krok

Propagacja DNS jest powszechnie źle rozumiana. Liczba 48 godzin to maksymalny czas w najgorszym przypadku, a nie typowy czas trwania. W praktyce większość resolverów respektuje wartość TTL zmienianego rekordu.

Redukcja TTL przed przełączeniem

Co najmniej 24–48 godzin przed oknem migracji zmniejsz TTL rekordów A i CNAME do 300 sekund (5 minut):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Oznacza to, że po zaktualizowaniu rekordu do nowego IP, stara wartość z pamięci podręcznej wygasa w ciągu 5 minut dla większości resolverów — nie 48 godzin. Jest to najskuteczniejsza technika minimalizowania okna propagacji DNS.

Aktualizacja serwerów nazw vs. rekordów A

Istnieją dwa różne podejścia do przełączenia DNS:

• Zmiana tylko rekordów A (przy zachowaniu tych samych autorytatywnych serwerów nazw): Propagacja następuje zgodnie z TTL rekordu. Najszybsze podejście, jeśli rejestrator domeny umożliwia bezpośrednie zarządzanie rekordami.
• Zmiana serwerów nazw (wskazanie na DNS nowego hosta): TTL serwerów nazw wynosi zazwyczaj 24–48 godzin i nie jest pod Twoją bezpośrednią kontrolą. To podejście zajmuje więcej czasu.

Preferuj aktualizacje rekordów A, gdy to możliwe. Zarządzaj DNS swojej domeny przez panel Rejestracji Domen, aby mieć bezpośrednią kontrolę na poziomie rekordów.

Utrzymywanie starego serwera aktywnego podczas propagacji

Nie anuluj ani nie wyłączaj starego planu hostingowego natychmiast po przełączeniu DNS. Utrzymuj go przez co najmniej 72 godziny. Podczas propagacji część użytkowników nadal będzie rozwiązywać stary IP — te żądania muszą być nadal obsługiwane. Przedwczesne wyłączenie starego serwera powoduje rzeczywistą awarię dla tych użytkowników.

Faza 7: Monitorowanie i walidacja po migracji

Monitorowanie dostępności i wydajności

Skonfiguruj zewnętrzne monitorowanie dostępności natychmiast po przełączeniu DNS — nie po tym, gdy uznasz, że propagacja jest zakończona. Narzędzia do wdrożenia:

• UptimeRobot lub Better Uptime — sprawdzenia HTTP(S) co 1–5 minut z wielu lokalizacji geograficznych
• Google Search Console — obserwuj raporty Coverage i Core Web Vitals pod kątem anomalii przez 7 dni po migracji
• New Relic lub Datadog — monitorowanie wydajności na poziomie aplikacji, jeśli Twoja aplikacja tego wymaga

Identyfikacja i rozwiązywanie błędów po migracji

Natychmiast po migracji przeprowadź crawl nowej witryny używając Screaming Frog lub mirroru wget:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Typowe problemy po migracji i ich przyczyny:

Naprawianie zakodowanych na stałe adresów URL w bazach danych WordPress

Częsty i subtelny problem: WordPress przechowuje adres URL witryny w bazie danych, a wiele motywów i wtyczek przechowuje bezwzględne adresy URL w danych serializowanych. Po migracji do nowej domeny lub protokołu uruchom:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

Flaga --precise poprawnie obsługuje dane serializowane PHP, które naiwne zastępowanie ciągów znaków uszkadza.

Faza 8: Anuluj stary plan hostingowy

Anuluj stary plan dopiero po potwierdzeniu wszystkich poniższych warunków:

• Propagacja DNS jest zakończona (zweryfikuj za pomocą dig +trace example.com z wielu lokalizacji)
• Monitorowanie dostępności wykazuje 100% dostępność przez co najmniej 72 kolejne godziny
• Brak błędów 404 ani uszkodzonych linków wykrytych w logach crawla
• Dostarczanie e-maili działa prawidłowo na nowym serwerze
• Analityka pokazuje normalne wzorce ruchu bez anomalnych spadków
• Posiadasz lokalną kopię wszystkich plików kopii zapasowych niezależną od obu dostawców hostingu

Techniczna lista kontrolna kluczowych wniosków

Użyj tego jako listy kontrolnej wykonania migracji:

Przed migracją

• [ ] Wyeksportowano 90-dniową bazę wykorzystania zasobów (CPU, RAM, I/O, przepustowość)
• [ ] Udokumentowano pełny stos oprogramowania z dokładnymi numerami wersji
• [ ] Zmniejszono TTL DNS do 300 sekund co najmniej 24 godziny przed przełączeniem
• [ ] Utworzono i przetestowano pełną kopię zapasową (pliki + bazy danych + zadania cron + e-mail)
• [ ] Zweryfikowano wersję PHP i wszystkie wymagane rozszerzenia na serwerze docelowym
• [ ] Przetłumaczono reguły .htaccess na format Nginx w przypadku zmiany serwera WWW
• [ ] Zainstalowano i zweryfikowano certyfikat SSL na nowym serwerze przed zmianą DNS

Podczas migracji

• [ ] Przeniesiono pliki przy użyciu rsync z weryfikacją sumy kontrolnej (rsync -avz --checksum)
• [ ] Zaimportowano bazę danych i zweryfikowano, że liczba wierszy odpowiada źródłu
• [ ] Przetestowano pełną funkcjonalność witryny przez nadpisanie /etc/hosts przed zmianą DNS
• [ ] Zaktualizowano pliki konfiguracyjne aplikacji (host bazy danych, dane uwierzytelniające, adres URL witryny)

Po migracji

• [ ] Zewnętrzne monitorowanie dostępności aktywne w ciągu 5 minut od przełączenia DNS
• [ ] Stary serwer utrzymywany przez co najmniej 72 godziny po przełączeniu
• [ ] Zakończono pełny crawl witryny; wszystkie błędy 404 i uszkodzone linki rozwiązane
• [ ] Zakodowane na stałe adresy URL poprawione w bazie danych (szczególnie dla WordPress)
• [ ] Google Search Console monitorowane przez 7 dni po migracji
• [ ] Stary plan hostingowy anulowany dopiero po potwierdzeniu wszystkich powyższych punktów

Często zadawane pytania

Jak długo faktycznie trwa propagacja DNS i czy można ją przyspieszyć?

Czas propagacji DNS jest określony przez wartość TTL zmienianego rekordu, a nie stałe okno 48 godzin. Jeśli zmniejszysz TTL rekordu A do 300 sekund co najmniej 24 godziny przed migracją, większość resolverów pobierze nowy IP w ciągu 5–10 minut od zmiany. Liczba 48 godzin dotyczy zmian delegacji serwerów nazw, których TTL jest poza Twoją kontrolą.

Czy migracja do nowego hosta zaszkodzi moim pozycjom w wyszukiwarce Google?

Prawidłowo wykonana migracja bez przestoju, z zachowaną strukturą URL i ważnym SSL nie ma negatywnego wpływu na SEO. Pozycje mogą tymczasowo spaść, jeśli nowy serwer jest wolniejszy, jeśli adresy URL zmieniają się bez właściwych przekierowań 301 lub jeśli witryna jest niedostępna podczas crawlowania. Monitoruj raporty Coverage i Core Web Vitals w Google Search Console przez 14 dni po migracji.

Jaki jest najbezpieczniejszy sposób przenoszenia dużych baz danych bez uszkodzenia danych?

Użyj mysqldump z flagą --single-transaction dla tabel InnoDB, aby zapewnić spójny snapshot bez blokad tabel. Przenieś plik zrzutu przez SSH używając scp lub rsync zamiast phpMyAdmin, który ma limity rozmiaru pliku i ograniczenia timeout powodujące ciche obcinanie dużych baz danych.

Czy muszę ponownie instalować certyfikat SSL po migracji?

Tak. Certyfikaty SSL są powiązane z kluczem prywatnym serwera, który znajduje się na oryginalnym serwerze. Musisz albo ponownie wydać certyfikat na nowym serwerze (bezpłatnie dla Let’s Encrypt), albo wyeksportować klucz prywatny i łańcuch certyfikatów ze starego serwera i zainstalować je na nowym. Upewnij się, że certyfikat jest w pełni zweryfikowany przed aktualizacją DNS, aby HTTPS działało natychmiast po przełączeniu.

Jak sprawdzić, czy migracja jest zakończona przed anulowaniem starego planu?

Uruchom dig +trace example.com @8.8.8.8 i dig +trace example.com @1.1.1.1, aby potwierdzić, że zarówno resolwery Google, jak i Cloudflare zwracają IP nowego serwera. Sprawdzaj monitorowanie dostępności przez 72 kolejne godziny czystych odpowiedzi. Przeprowadź crawl witryny pod kątem błędów 404 i zweryfikuj dostarczanie e-maili. Dopiero po pomyślnym przejściu wszystkich tych kontroli bezpieczne jest zamknięcie starego konta hostingowego.