Jak przenieść stronę na inny hosting

Przeniesienie strony na inny serwer to nie tylko techniczna migracja, ale i proces organizacyjny: plan, harmonogram, testy, a na końcu przełączenie ruchu. Dobrze przygotowana operacja pozwala ograniczyć przestój, zabezpieczyć dane i przy okazji zoptymalizować koszty hostingu. W tym poradniku znajdziesz uporządkowaną instrukcję: od inwentaryzacji zasobów i wykonania backupu, przez kopię plików i bazy, po ustawienie domenay oraz minimalizację downtime.

Plan i przygotowanie do przenosin

Określ zakres i cel

Zacznij od zdefiniowania, co dokładnie przenosisz i po co. Czy to cała witryna z panelem administracyjnym, sklep z płatnościami, a może aplikacja z kolejkami i zadaniami CRON? Czy zmieniasz wyłącznie serwer, czy także rejestratora domeny, dostawcę poczty lub CDN? Określ też oczekiwane korzyści: wyższa stabilność, lepsza wydajność, niższe koszty, wsparcie 24/7 lub geograficzne zbliżenie do odbiorców.

Inwentaryzacja komponentów

Spisz wszystko, co składa się na środowisko:

• Technologie: wersja PHP/Node/Python, serwer (Apache/Nginx), rozszerzenia (np. imagick, intl), narzędzia (Composer, npm).
• Usługi: bazy (MySQL/MariaDB/PostgreSQL), pamięć podręczna, kolejki, wyszukiwarka (Elasticsearch/OpenSearch), moduły płatności, dostawcy SMS/SMTP.
• Integracje: bramki płatnicze, ERP/CRM, systemy magazynowe, zewnętrzne API.
• Automatyzacje: CRON, skrypty deploy, webhooki, kopie zapasowe.
• Bezpieczeństwo: reguły WAF, listy dozwolonych IP, klucze i sekrety.

Zaplanowanie okna serwisowego

Ustal przedział czasowy na przenosiny. Wybierz moment o najmniejszym natężeniu ruchu, poinformuj interesariuszy i przygotuj plan awaryjny: cofnij zmianę adresów, przywróć dane z kopii, przestaw ruch z powrotem. Zdefiniuj kryteria sukcesu i checklistę startową oraz końcową. Przy projektach e‑commerce rozważ tymczasowe „zamrożenie treści” (wyłączenie rejestracji, zamówień, edycji) na etap przełączenia.

Przygotowanie zasobów na nowym serwerze

Utwórz konto, przestrzeń na pliki, konta baz, użytkowników, katalogi na logi i backupy. Zadbaj o zgodność wersji oprogramowania i rozszerzeń. Zaplanuj strukturę środowisk: produkcyjne, testowe/staging i ewentualnie developerskie, z osobnymi bazami i zasobami.

Kontrola nazw i stref

Zapisz aktualne rekordy DNS (A/AAAA, CNAME, MX, TXT dla SPF/DKIM/DMARC, SRV, NS). Zrób zrzut strefy, aby móc odtworzyć ją u nowego operatora lub powrócić do starego w razie potrzeby. Obniż TTL kluczowych rekordów (np. A/AAAA dla głównej domeny i www) na 300–600 sekund co najmniej 24–48 godzin przed przełączeniem, aby przyspieszyć propagację.

Pełna kopia danych

Wykonaj bieżący zrzut plików aplikacji, katalogu uploadów i repozytoriów. Zrób spójny zrzut baza danych (mysqldump/pg_dump) oraz zarchiwizuj go. Jeśli utrzymujesz pocztę na tym samym serwerze, rozważ migrację skrzynek: imapsync, kopie Maildir, a także wyeksportuj listy aliasów i przekierowań.

Bezpieczeństwo i certyfikaty

Sprawdź ważność certyfikatów SSL. Zaplanuj ich ponowne wystawienie na nowym serwerze (np. Let’s Encrypt) lub przeniesienie komercyjnych certyfikatów wraz z kluczem i łańcuchem poświadczeń. Zidentyfikuj klucze API, sekrety i hasła; przygotuj ich rotację po migracji.

Minimalizacja przestoju

Zaprojektuj strategię ograniczania downtime: tymczasowe TTL, równoległe środowisko testowe, wpis w pliku hosts do weryfikacji przed publikacją, freeze treści na ostatnią fazę migracji i przewidziany roll‑back. Dla dużych baz danych użyj replikacji lub etapowych zrzutów przyrostowych.

Kopiowanie plików i przenoszenie danych

Dostępy i kanały transferu

Skonfiguruj bezpieczny dostęp: SFTP lub SSH. Tradycyjny FTP bywa dopuszczalny tylko w sieci zaufanej; preferuj SFTP/rsync/SSH. Przygotuj klucze, upewnij się, że limit jednoczesnych połączeń i prędkość transferu są wystarczające. W razie bardzo dużych wolumenów rozważ transfer bezpośredni między serwerami w tej samej chmurze lub import przez obiektowe storage.

Eksport i import bazy

MySQL/MariaDB: wykonaj spójny dump z blokadą tabel lub w trybie single‑transaction dla InnoDB, z pełnym metadanymi (procedury, eventy, wyzwalacze):

• mysqldump -h źródło -u user -p –routines –triggers –events –single-transaction –default-character-set=utf8mb4 baza > dump.sql
• mysql -h cel -u user -p -e „CREATE DATABASE baza CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;”
• mysql -h cel -u user -p baza < dump.sql

PostgreSQL: użyj pg_dump/pg_restore lub narzędzia do replikacji logicznej. Sprawdź kompatybilność wersji serwera. Po imporcie uruchom ANALYZE/REINDEX, aby zoptymalizować plany zapytań.

Kopia plików aplikacji i uploadów

Wypakuj i uporządkuj strukturę katalogów. Skopiuj publiczne zasoby (np. public_html), prywatne katalogi konfiguracyjne, pliki .env/wp-config.php, oraz katalogi z danymi użytkowników. Dla dużych drzew katalogów użyj rsync z weryfikacją sum kontrolnych:

• rsync -avz –delete –checksum user@stary:/var/www/app/ user@nowy:/var/www/app/

W przypadku milionów małych plików wydajniejsze bywa spakowanie tar/gzip po stronie źródła i rozpakowanie na celu. Po przeniesieniu wykonaj kontrolę integralności: porównaj rozmiary, liczbę plików oraz sumy md5/sha256.

Przeniesienie skrzynek pocztowych (opcjonalnie)

Jeśli e‑maile są hostowane razem z WWW i chcesz je przenieść, zsynchronizuj skrzynki IMAP (np. imapsync), odtwórz aliasy i rekordy MX. Zweryfikuj limity dostawcy, polityki antyspamowe i ewentualne listy RBL. Zdefiniuj SPF, DKIM i DMARC w nowej strefie DNS po przełączeniu.

Zarządzanie danymi dynamicznymi

Jeśli serwis generuje intensywne zapisy (zamówienia, komentarze), rozważ dwustopniową strategię: pełny dump, krótkie „zamrożenie” procesu publikacji, a tuż przed przełączeniem szybki zrzut różnicowy i import tylko zmian. W systemach z replikacją skonfiguruj replikę na nowy serwer i przełącz rolę master w oknie serwisowym.

Konfiguracja i testy na nowym środowisku

Struktura katalogów i uprawnienia

Umieść pliki w docelowych lokalizacjach (np. /var/www/app, public_html). Ustaw właścicieli i grupy zgodnie z użytkownikiem serwera www (www-data, apache, nginx). Skonfiguruj prawa 755 dla katalogów i 644 dla plików, z wyjątkami dla katalogów tymczasowych i uploadów, które wymagają zapisu. Uważaj na setgid/sticky bit w katalogach współdzielonych.

Konfiguracja serwera WWW

Apache: zweryfikuj .htaccess, moduły (rewrite, headers, expires, proxy), limity (LimitRequestBody), a także vhosty i SNI dla wielu domen. Nginx: popraw mapowania server_name, root, index, proxy_pass, fastcgi_param, reguły dla statycznych zasobów i przekierowań. Zapewnij kompresję gzip/br oraz HTTP/2 i ewentualnie HTTP/3 (QUIC) oraz ustawienia HSTS po wdrożeniu HTTPS.

Baza danych i połączenia

Utwórz użytkowników z ograniczonymi uprawnieniami, przypisz hasła i aktualizuj dane połączeniowe w konfiguracji aplikacji (.env, config.php). Sprawdź kodowanie (utf8mb4) i porównania (collation), strefy czasowe i tryby sql_mode. W systemach z ORM wykonaj migracje schematu (np. artisan migrate, doctrine:migrations).

Weryfikacja danych i spójności

Zweryfikuj, czy wszystkie tabele i indeksy zostały odtworzone, a liczba rekordów się zgadza. Przetestuj zapisy: utwórz testowego użytkownika, formularz kontaktowy, dodaj produkt do koszyka, zainicjuj testową płatność w trybie sandbox. Przejrzyj logi błędów PHP/serwera, aby wyłapać braki bibliotek i różnice w konfiguracji.

Środowisko testowe i wpis hosts

Zanim przełączysz ruch publiczny, sprawdź serwis przez tymczasową domenę operatora lub wpis w pliku hosts, aby wymusić rozwiązywanie nazwy na adres nowego serwera wyłącznie na twoim komputerze. Dzięki temu możesz przetestować całość bez wpływu na użytkowników produkcyjnych.

• Windows: C:\Windows\System32\drivers\etc\hosts
• macOS/Linux: /etc/hosts
• Format: 203.0.113.10 twojadomena.pl www.twojadomena.pl

Po testach pamiętaj o usunięciu wpisu, aby po przełączeniu używać publicznej rozdzielczości DNS.

Warstwa sesji, pamięci i kolejek

Skonfiguruj sesje i pamięć podręczną (np. Redis/Memcached), a także workers i kolejki. Sprawdź, czy klucze są rozdzielone per środowisko, by uniknąć kolizji. Oczyść i zainicjalizuj cache, utwórz zadania CRON do regularnego odświeżania oraz zapewnij nadzór nad procesami.

HTTPS i polityka bezpieczeństwa

Wystaw certyfikat, skonfiguruj łańcuch i szyfry, wymuś przekierowanie HTTP→HTTPS. Dodaj nagłówki bezpieczeństwa (CSP, X‑Frame‑Options, X‑Content‑Type‑Options, Referrer‑Policy), a ciasteczkom ustaw flagi Secure i SameSite. W aplikacjach obrotu środkami włącz dodatkowe logi audytowe i mechanizmy anty‑fraud.

Przełączenie ruchu i kontrola powdrożeniowa

Finalny zrzut różnic i freeze

W wąskim oknie serwisowym zatrzymaj edycję treści i transakcji, zrób szybki zrzut różnicowy bazy, zaimportuj go na nowym serwerze, przelicz dane wtórne (cache, indeksy, miniatury). Pozwoli to ograniczyć utratę wpisów między pełnym a końcowym zrzutem.

Aktualizacja rekordów DNS

Zmień rekordy A/AAAA lub CNAME na nowe IP. Jeżeli przenosisz też pocztę, zaktualizuj MX oraz zapisy TXT dla SPF, DKIM i DMARC. Dzięki obniżonemu TTL propagacja powinna być szybka. Monitoruj, z jakich adresów IP napływa ruch (logi serwera, narzędzia analityczne), aby wychwycić klientów korzystających jeszcze ze starej rozdzielczości.

Równoległe utrzymanie starego środowiska

Utrzymaj stary serwer przez 48–72 godziny w trybie read‑only lub z przekierowaniem 301 na nowy adres. Zbierz logi błędów i statystyki, aby porównać zachowanie. Dla sklepów rozważ chwilowe blokowanie składania zamówień na starym środowisku, aby uniknąć rozjazdu danych.

Testy funkcjonalne i wydajnościowe

Przeprowadź checklistę po przełączeniu: logowanie, rejestracja, koszyk, płatności, formularze, wysyłka e‑mail, generowanie PDF, API i webhooki, ładowanie zasobów statycznych, responsywność. Zmierz TTFB i czasy odpowiedzi, sprawdź obciążenie CPU/RAM/dysku, konfigurację opcache/JIT oraz wykorzystanie CDN. Uruchom testy smoke i, jeśli masz, zautomatyzowane testy E2E.

SEO i przekierowania

Zweryfikuj mapę witryny, robots.txt, kanonikalne adresy URL, przekierowania 301/308 oraz statusy 404. Upewnij się, że sygnały hreflang i alternatywne wersje językowe działają. Zgłoś adres nowej witryny w narzędziach dla webmasterów i zaktualizuj pliki sitemaps, jeżeli adresy się zmieniały.

Monitorowanie i alerty

Skonfiguruj monitoring dostępności (uptime) i metryk aplikacyjnych, zestaw alertów na przekroczenia czasów odpowiedzi, błędy 5xx/4xx, wzrost błędów JS w przeglądarkach i problemy z bazą. Dodaj dashboard z logami aplikacji i serwera oraz reguły retencji.

Rotacja sekretów i porządki

Po stabilizacji zmień hasła i klucze dostępu, usuń zbędne konta techniczne, wyczyść zbędne pliki tymczasowe, backupy robocze i stare crontaby. Zaktualizuj dokumentację infrastruktury i diagramy połączeń.

Najczęstsze problemy i scenariusze specjalne

Różnice w środowisku wykonawczym

Typowe kłopoty wynikają z innych wersji PHP, brakujących rozszerzeń lub odmiennych ustawień php.ini (memory_limit, max_execution_time, upload_max_filesize). Uzupełnij brakujące moduły, urealnij limity i dopasuj konfigurację OPcache oraz JIT. Dla Node/Python dopilnuj wersji runtime, zależności i kompilacji natywnych modułów.

WordPress i serializowane dane

Przy zmianie adresów URL w WordPressie użyj narzędzi obsługujących serializację (WP‑CLI: wp search-replace) zamiast prostego find/replace. Po migracji przepłucz cache, zregeneruj miniatury, sprawdź permalinki, cron WP i wtyczki bezpieczeństwa. Dla WooCommerce zaplanuj freeze zamówień na czas przełączenia oraz synchronizację webhooków.

Frameworki PHP: Laravel, Symfony

Zaktualizuj .env, uruchom artisan key:generate (jeżeli to nowe środowisko), cache:clear, config:cache, route:cache. Wykonaj migracje i seedy, odtwórz storage:link, skonfiguruj queue:work jako usługę systemową. W Symfony zbuduj cache:warmup, ustaw APP_ENV/APP_DEBUG, zainstaluj zależności przez Composer z właściwymi flagami platformy.

Sklepy i platformy złożone

Magento: przestaw tryb na maintenance, wykonaj setup:upgrade, di:compile, static:content:deploy, oczyść var/cache i var/generation, przeprowadź reindeksy. PrestaShop: uaktualnij konfigurację bazy, regeneruj htaccess, wyczyść cache Smarty, sprawdź uprawnienia katalogów img, cache, themes.

Aplikacje z pamięcią, kolejkowaniem i wyszukiwarką

Przenosząc Redis/Elasticsearch, zweryfikuj kompatybilność wersji i parametry (np. wielkość heap dla JVM). Ustaw restart‑policy dla usług, zasady trwałości danych (AOF/RDB), snapshoty i monitoring opóźnień. Zadbaj o izolację przestrzeni nazw, aby środowiska nie wchodziły sobie w drogę.

CDN, reverse‑proxy i WAF

Jeśli korzystasz z CDN lub reverse‑proxy (np. Cloudflare), sprawdź tryb SSL „Full (strict)”, zaktualizuj rekordy, polityki cache, reguły Page Rules oraz limity firewall. W razie błędów certyfikatu rozważ certyfikat origin i weryfikację łańcucha.

Poczta i deliverability

Po migracji poczty oceń reputację nowego IP, skonfiguruj SPF (unikaj zbyt długich łańcuchów „include”), podpis DKIM, politykę DMARC (np. p=quarantine w fazie przejściowej), a następnie raporty RUA/RUF. Monitoruj odbicia i listy blokujące. Zadbaj o poprawny PTR (reverse DNS).

Błędy po przełączeniu

• 500/502: różnice w PHP, brak rozszerzeń, złe uprawnienia lub błędny upstream w Nginx.
• 403: uprawnienia plików, reguły deny w .htaccess/nginx, SELinux/AppArmor.
• 404: brakujące przepisy rewrite lub złe ścieżki do dokumentu głównego.
• Problemy z uploadem: upload_max_filesize, post_max_size, client_max_body_size, limitRequestBody.
• Wydajność: brak opcache, compress/br, HTTP/2/3, niepoprawna konfiguracja CDN, zimne cache.

Strategie wycofania i retencja

Przed zmianą przygotuj możliwość szybkiego powrotu: zapisana kopia strefy DNS, snapshot bazy, archiwum plików, zapisane konfiguracje w systemie kontroli wersji. Zdefiniuj okres utrzymania starego środowiska, aby móc odzyskać dane w razie nieoczekiwanych usterek wykrytych po kilku dniach.

Checklisty operacyjne

• Przygotowanie: inwentaryzacja, zgodność wersji, dostęp do repozytoriów i paneli, plan komunikacji.
• Dane: kompletny backup plików, bazy, ewentualnie poczty; test odtworzenia.
• Konfiguracja: vhosty, HTTPS, nagłówki, CRON, kolejki, monitoring, logi.
• Testy przed przełączeniem: funkcjonalność, wydajność, bezpieczeństwo, SEO.
• Przełączenie: freeze, dump różnicowy, aktualizacja DNS, walidacja, monitorowanie.
• Po: rotacja sekretów, porządki, dokumentacja, szkolenie zespołu wsparcia.