Migracja serwerów do kolokacji — praktyczny przewodnik krok po kroku dla polskich firm

Coraz więcej polskich firm — w tym podmioty objęte nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa — wyprowadza własne serwery z biurowych serwerowni do certyfikowanych centrów danych. Powodów jest wiele: rosnące koszty energii, presja na ciągłość biznesu, a po wejściu w życie KSC 2.0 (3 kwietnia 2026) także konkretne wymagania regulacyjne dotyczące zarządzania bezpieczeństwem informacji. Migracja nie musi być chaosem. Pod warunkiem, że poprowadzisz ją według procedury.

Poniżej praktyczna 7-krokowa checklista migracji do kolokacji — taka, jakiej używamy z klientami przeprowadzającymi sprzęt do naszego centrum danych w Olsztynie.

Krok 1: Audyt obecnego sprzętu i konfiguracji

Zanim w ogóle zaczniesz rozmawiać z dostawcami DC, zrób inwentaryzację:

• Sprzęt: pełna lista serwerów (model, generacja CPU, RAM, dyski, kontrolery RAID), urządzeń sieciowych, UPS-ów lokalnych, taśmotek.
• Konfiguracja sieciowa: schematy VLAN-ów, pul adresów IP, zasad firewalla, reguł NAT, tunele VPN.
• Zależności aplikacyjne: co od czego zależy, co musi startować w jakiej kolejności, gdzie są hardcoded’owane adresy IP w plikach konfiguracyjnych.

Ten etap często ujawnia, że część sprzętu jest po EOL-u producenta — i lepiej kupić nowe serwery niż wozić stary metal. Jeśli to twój przypadek, warto rozważyć serwery dedykowane zamiast kolokacji własnego sprzętu.

Krok 2: Wybór dostawcy i lokalizacji

Kryteria, na których nie warto oszczędzać:

• Zasilanie: dwutorowe, gwarantowane, z UPS-em i agregatem prądotwórczym.
• Klimatyzacja precyzyjna: stała temperatura i wilgotność, redundancja jednostek.
• Łączność: redundantne łącza operatorskie, najlepiej od dwóch niezależnych dostawców.
• Bezpieczeństwo fizyczne: całodobowa ochrona, kontrola dostępu, monitoring.
• Lokalizacja w Polsce: RODO + jurysdykcja krajowa to dziś nie ozdoba, lecz warunek brzegowy dla wielu klientów i regulatorów.
• Transparentny model rozliczeń: miesięczny abonament + osobna pozycja "energia" działa lepiej niż flat-rate, bo pozwala kontrolować rzeczywiste zużycie i optymalizować je.

Jeśli twoja dotychczasowa infrastruktura jest skoncentrowana w Warszawie, wybór centrum danych w innej lokalizacji bywa elementem strategii dywersyfikacji geograficznej — przydatnej szczególnie dla planów disaster recovery.

Krok 3: Plan techniczny migracji

Dwie ścieżki:

• Cold migration — wyłączasz serwery, transportujesz fizycznie, włączasz w docelowej szafie. Prosta logistycznie, ale wymaga dłuższego okna serwisowego (8–24 h zależnie od skali).
• Warm migration / replikacja — uruchamiasz w nowym DC repliki maszyn (np. przez VM-ware vSphere Replication, snapshoty hyperwizora, replikację baz danych), a w okienku tylko przełączasz ruch (cutover). Krótszy downtime, ale wyższy koszt i więcej rzeczy do zsynchronizowania.

Niezależnie od wyboru: pełny backup przed transportem, plan rollbacku, test rollbacku.

Krok 4: Logistyka transportu i instalacji

• Pakowanie w oryginalne opakowania lub specjalistyczne skrzynie antystatyczne.
• Etykietowanie KAŻDEGO kabla przed odłączeniem (port źródłowy, port docelowy).
• Zdjęcia każdej szafy przed demontażem — bezcenne przy odtwarzaniu.
• Lista osób z prawem wjazdu do nowego DC + procedura eskorty (większość operatorów, w tym my, wymaga awizacji z wyprzedzeniem).
• Check-listy włączania: kolejność zasilania, sprawdzenie LED-ów, smoke test przed włączeniem ruchu.

Krok 5: Sieć — najczęstszy punkt zapalny migracji

Tu zwykle gubi się najwięcej godzin:

• Adresacja IP: zachowujesz starą pulę (wymaga współpracy z operatorem) czy bierzesz nową od dostawcy DC? Druga opcja oznacza zmiany w DNS, w certyfikatach SSL, w hardcoded’owanych konfigach.
• DNS: rekordy A i PTR. Skróć TTL na kilka dni przed migracją do 60–300 s, by szybko propagować zmianę.
• Tunel VPN do biura: ustal, kiedy go przełączyć — przed czy po cutoverze ruchu produkcyjnego.
• Multihoming: profesjonalne DC oferuje BGP z więcej niż jednym ASN-em po stronie operatorów, co eliminuje ryzyko padnięcia całej kolokacji wraz z jednym ISP.

Krok 6: Aspekty prawne i compliance

• Aneks do umów z klientami dotyczących powierzenia przetwarzania danych — zmiana lokalizacji infrastruktury to zmiana podwykonawcy w rozumieniu RODO.
• Umowa powierzenia z dostawcą DC — must-have, zwłaszcza jeśli przetwarzasz dane osobowe.
• W kontekście KSC 2.0 / NIS2: dokumentacja procedur ciągłości działania, opis kontroli dostępu, warunki SLA i czasów reakcji wsparcia. Dostawca DC dostarcza ci to "z półki" — taniej, niż dorabiać samodzielnie.
• Definicja odpowiedzialności: co robi twój zespół, co robi DC, kto kogo informuje o awariach, jak wygląda eskalacja.

Krok 7: Testy po migracji i pierwsze 30 dni

• Smoke testy w pierwszych 24 h: dostęp do każdego systemu, wydajność (porównanie z baseline’em), kopia zapasowa, replikacja off-site, działające alerty.
• Po 7 dniach: review parametrów wydajnościowych, sprawdzenie czy nic nie buforuje błędów (zapełniający się log).
• Po 30 dniach: pełny review SLA z dostawcą, czas reakcji wsparcia, ewentualne korekty konfiguracji.

Podsumowanie

Migracja serwerów do kolokacji to projekt na 2–8 tygodni — w zależności od skali i tego, czy idziesz w cold migration, czy w replikację z cutoverem. Improwizacja kosztuje: przedłużający się downtime, problemy z siecią, niedoróbki w dokumentacji compliance.

Najwięcej zyskasz, jeśli wybierzesz partnera, który da ci nie tylko miejsce w szafie, ale też transparentny katalog usług, 24/7 wsparcie techniczne i jurysdykcję w Polsce. Sprint Data Center robi takie migracje od lat — napisz do nas lub zadzwoń pod 89 522 12 20, ułożymy harmonogram pod twoją infrastrukturę.

FAQ – najczęściej zadawane pytania o migrację serwerów do kolokacji

Ile trwa migracja serwerów do centrum danych?

Dla kilku serwerów i prostej sieci — od 2 tygodni planowania + jedno okno serwisowe (8–24 h cold migration). Dla średniej infrastruktury (kilkanaście maszyn, replikacja, integracje z aplikacjami) — typowo 6–8 tygodni od kick-offu do cutoveru. Złożona migracja wieloetapowa może trwać kilka miesięcy.

Czy mogę zachować dotychczasowe adresy IP po przeprowadzce?

Czasem tak, czasem nie. Jeśli twoje pule IP są przypisane do twojej organizacji (PI — provider independent), można je przenieść między operatorami. Jeśli adresy pochodzą od starego ISP (PA — provider aggregatable), z reguły dostajesz nowe pule od dostawcy DC i konfigurujesz NAT lub re-adresację. To trzeba przedyskutować z dostawcą zanim podpiszesz umowę.

Czy musimy wymienić sprzęt, czy bierzemy stary do kolokacji?

Decyduje TCO i wsparcie producenta. Sprzęt po EOL bez aktywnego support contractu w nowoczesnym DC jest ryzykiem — przy awarii nie ma kogo dzwonić. Dla starszych serwerów często bardziej opłaca się zamówić serwery dedykowane u dostawcy DC i zmigrować dane, zamiast wozić metal.

Kto odpowiada za bezpieczeństwo danych po migracji — my czy dostawca DC?

Odpowiedzialność za przetwarzane dane (RODO) zawsze spoczywa na administratorze, czyli na tobie. Dostawca DC występuje jako podmiot przetwarzający (procesor) — w ramach umowy powierzenia odpowiada za bezpieczeństwo fizyczne, infrastrukturę zasilania i klimatyzacji, kontrolę dostępu. Twoja firma odpowiada za konfigurację systemów, aktualizacje i kontrolę dostępu logicznego. W kontekście NIS2 / KSC 2.0 oba poziomy muszą być udokumentowane.

Jaki jest realny koszt migracji poza miesięcznym abonamentem za 1U?

Koszty jednorazowe: transport sprzętu, ewentualna usługa rack&stack po stronie DC, konfiguracja sieci, zmiany DNS i SSL, czas pracy zespołu IT po obu stronach. Dla pojedynczych serwerów — kilka tysięcy złotych. Dla pełnej szafy z replikacją i krótkim cutoverem — typowo kilkadziesiąt tysięcy. Warto policzyć ROI względem oszczędności na energii i infrastrukturze biurowej (klimatyzacja, UPS, agregat) — w naszym doświadczeniu projekt zwraca się w 12–24 miesiącach.