SQL Server 2016 już bez poprawek, Windows Server 2016 od stycznia 2027 — plan migracji dla działu IT

W wielu polskich firmach wciąż pracują serwery postawione w 2016 lub 2017 roku. Działają stabilnie, użytkownicy nie narzekają — więc kolejny rok budżetowy mija bez decyzji o wymianie. Problem w tym, że od pewnego momentu „stabilnie" i „bezpiecznie" przestają oznaczać to samo. Dla systemów z rocznika 2016 ten moment właśnie nadszedł.

Dwie daty, które trzeba mieć w kalendarzu

Microsoft publikuje cykl życia swoich produktów w oficjalnym wykazie Microsoft Lifecycle. Dla dwóch systemów wciąż bardzo popularnych w polskich serwerowniach wygląda on tak:

• SQL Server 2016 — rozszerzone wsparcie zakończyło się 15 lipca 2026 r. Jeśli masz dziś w produkcji instancję z 2016 roku, to działa ona już bez standardowych poprawek bezpieczeństwa.
• Windows Server 2016 — rozszerzone wsparcie kończy się 13 stycznia 2027 r. Zostało niecałe pół roku (źródło: learn.microsoft.com, wykaz Microsoft Lifecycle).

Dla SQL Servera 2016 Microsoft udostępnia płatny program Extended Security Updates, rozpisany na trzy kolejne roczne okresy. To jednak bufor, a nie rozwiązanie: kupujesz czas na migrację, nie odsuwasz jej.

Koniec wsparcia nie oznacza, że system przestaje działać — nie wyświetla ostrzeżenia i nie blokuje logowania. Po prostu każda nowa podatność wykryta po tej dacie zostaje w nim na zawsze, a informacja o niej jest jawna i dostępna również dla atakujących.

Dlaczego „działa, więc zostawiamy" przestaje być strategią

Techniczne ryzyko jest oczywiste: niezałatana podatność w systemie operacyjnym albo w silniku bazy danych to prosta droga do przejęcia serwera i do ransomware. Ale coraz częściej pierwszy sygnał alarmowy przychodzi z działu compliance.

Ustawa o krajowym systemie cyberbezpieczeństwa, wdrażająca do polskiego prawa dyrektywę NIS2, wymaga od podmiotów kluczowych i ważnych systematycznego zarządzania ryzykiem i podatnościami. Świadome utrzymywanie w produkcji systemu, który z definicji nie może już zostać załatany, jest trudne do obronienia przed audytorem — a pytanie „czy całe oprogramowanie produkcyjne jest objęte wsparciem producenta?" pojawia się dziś w większości kwestionariuszy bezpieczeństwa dla dostawców. Jeśli dopiero układasz sobie ten temat, zacznij od naszego wpisu o obowiązkach wynikających z NIS2 i ustawy o KSC.

Inwentaryzacja: zacznij od tego, co naprawdę masz

Migracji nie zaczyna się od zamówienia sprzętu, tylko od arkusza. Zanim podejmiesz decyzję, zbierz dla każdego serwera:

• wersję systemu i poziom aktualizacji — łącznie z maszynami wirtualnymi, o których wszyscy zapomnieli;
• role serwera — kontroler domeny, serwer plików, serwer aplikacji, terminal, baza danych;
• wersje instancji SQL wraz z poziomem zgodności baz i sortowaniem (collation);
• aplikacje i ich macierz wsparcia — czy dostawca Twojego systemu ERP lub aplikacji branżowej w ogóle certyfikuje nowszy Windows Server;
• licencje — co masz, w jakim modelu i co trzeba dokupić przy zmianie wersji;
• wiek sprzętu — jeśli maszyna też jest z 2016 roku, migracja systemu i wymiana sprzętu to jedna decyzja, nie dwie.

Dobrym punktem wyjścia jest przegląd konfiguracji według listy kontrolnej z naszego wpisu o audycie bezpieczeństwa serwera dedykowanego.

Cztery ścieżki wyjścia

1. Aktualizacja w miejscu (in-place upgrade)

Najszybsza na papierze i najbardziej ryzykowna w praktyce. Nie wymaga nowego sprzętu, ale przenosi cały bagaż konfiguracyjny sprzed dekady, a w razie niepowodzenia zostawia niedziałające środowisko produkcyjne bez łatwej drogi powrotu. Rozsądna tylko dla systemów niekrytycznych, z przetestowaną wcześniej kopią.

2. Migracja równoległa na nowy serwer

Standard w środowiskach produkcyjnych. Budujesz czyste środowisko obok istniejącego, przenosisz dane i role, testujesz przy działającym starym systemie, a przełączenie jest krótkie i odwracalne. Wymaga chwilowego utrzymywania dwóch maszyn — i dlatego model wynajmu wypada tu korzystniej niż zakup.

3. Extended Security Updates jako bufor — tylko dla SQL Servera

Jeśli aplikacja jest twardo związana z SQL Server 2016, a jej dostawca dopiero pracuje nad wsparciem nowszej wersji, ESU pozwala dojechać do momentu, w którym migracja stanie się możliwa. Traktuj to jako pozycję w harmonogramie z konkretną datą końcową, nie jako stan docelowy.

4. Zmiana modelu utrzymania

Jeśli maszyna i tak idzie do wymiany, wybór między serwerem dedykowanym a kolokacją własnych urządzeń jest tańszy do przeprowadzenia teraz niż za trzy lata. O tym, jak policzyć koszt licencji przy takiej zmianie, pisaliśmy we wpisie o dopłatach do Windows Server, SQL i panelu.

Harmonogram, który mieści się do stycznia

Do 13 stycznia 2027 roku zostało pięć miesięcy roboczych. To wystarczy, o ile nie zaczniesz w grudniu:

• wrzesień — inwentaryzacja, potwierdzenie macierzy wsparcia u dostawców aplikacji, decyzja o ścieżce dla każdego serwera;
• październik — decyzja budżetowa, zamówienie zasobów, przygotowanie środowiska testowego;
• listopad — budowa nowego środowiska, migracja danych testowych, testy wydajności i testy odtworzeniowe;
• grudzień — migracja produkcyjna w oknie serwisowym, praca równoległa obu środowisk;
• styczeń — wyłączenie starego systemu, bezpieczne wycofanie nośników, aktualizacja dokumentacji i rejestru ryzyk.

Krytyczne przełączenie wypada w grudniu — w środku okresu, w którym większość firm ma zamrożenie zmian. Jeśli u Ciebie obowiązuje freeze, cały harmonogram trzeba przesunąć o miesiąc do przodu, czyli zacząć teraz.

Co po stronie data center realnie skraca migrację

Kilka elementów oferty Sprint Data Center jest tu praktycznych:

• Instalacja dowolnego systemu przez zdalne zarządzanie IPMI — nowe środowisko budujesz samodzielnie, bez czekania na technika; do wyboru są dystrybucje Linux (Ubuntu, Debian, CentOS, FreeBSD) oraz Windows Server.
• Brak opłat za start usługi i za migrację między maszynami fizycznymi oraz brak umów terminowych — nie płacisz kary za to, że przez miesiąc utrzymujesz dwa środowiska równolegle. Siedmiodniowy okres próbny wystarcza, żeby sprawdzić, czy aplikacja w ogóle wstaje na nowej wersji systemu.
• Umowa SLA i całodobowa linia techniczna — zgodnie z warunkami SLA uszkodzony element lub cały serwer zostaje wymieniony do 6 godzin.
• Pakiety administracyjne — jeśli zespół nie ma rąk do migracji, w abonamencie mieszczą się m.in. aktualizacje systemu, monitoring usług, polityka backupu, analiza logów i odtwarzanie systemu po awarii. Dostępna jest też jednorazowa usługa przeniesienia danych pomiędzy serwerami oraz podstawowy audyt bezpieczeństwa, sprawdzający m.in. aktualność zainstalowanego systemu. Usługi te realizowane są wyłącznie na usługach kupionych w SDC, a dostęp root pozostaje po stronie SDC — więcej w naszym wpisie o administrowaniu serwerem dedykowanym.

Pięć błędów, które kosztują najwięcej

1. Migracja aplikacji „jeden do jednego" bez sprawdzenia dostawcy. Nowszy Windows Server bywa nieobsługiwany przez starsze wersje oprogramowania branżowego — o tym trzeba wiedzieć we wrześniu, nie w grudniu.
2. Pominięcie poziomu zgodności bazy i sortowania. Baza przeniesiona z SQL Server 2016 potrafi działać wolniej albo inaczej porównywać teksty, jeśli poziom zgodności i collation nie zostaną świadomie ustawione.
3. Zapomniany kontroler domeny. Poziom funkcjonalny domeny i lasu to osobny projekt, którego nie da się zrobić „przy okazji" w oknie serwisowym.
4. Brak planu wycofania. Jeśli nie wiesz, jak w ciągu godziny wrócić do starego środowiska, nie masz planu migracji, tylko nadzieję.
5. Start w grudniu. Najgorszy możliwy termin: urlopy, zamrożenie zmian i szczyt sprzedaży w jednym miesiącu.

Podsumowanie

Koniec wsparcia dla SQL Server 2016 już nastąpił, a Windows Server 2016 dołączy do niego 13 stycznia 2027 roku. To nie jest awaria do gaszenia — to termin, który można spokojnie obsłużyć, jeśli zacznie się od inwentaryzacji jeszcze we wrześniu. Najtańsza migracja to ta zaplanowana, przeprowadzona równolegle i przetestowana przed przełączeniem.

Jeśli przy okazji wymiany chcesz zmienić model utrzymania, sprawdź ofertę serwerów dedykowanych albo napisz do nas przez formularz kontaktowy — pomożemy dobrać konfigurację pod role i aplikacje, które migrujesz.

FAQ – najczęściej zadawane pytania o koniec wsparcia Windows Server 2016

Czy po 13 stycznia 2027 roku Windows Server 2016 przestanie działać?

Nie. System będzie działał dalej, uruchamiał się i obsługiwał aplikacje tak jak wcześniej. Zmienia się tylko to, że Microsoft nie będzie już wydawał dla niego standardowych poprawek bezpieczeństwa — każda nowa podatność wykryta po tej dacie pozostanie w systemie na stałe.

Czy mogę zrobić aktualizację w miejscu zamiast migracji na nowy serwer?

Technicznie tak, ale w środowisku produkcyjnym to najbardziej ryzykowna ścieżka. Aktualizacja w miejscu przenosi całą starą konfigurację, a w razie niepowodzenia zostawia niedziałający serwer bez szybkiej drogi powrotu. Migracja równoległa pozwala testować nowe środowisko przy działającym starym i skrócić okno przestoju do minut.

Czy Extended Security Updates rozwiązuje problem?

Tylko częściowo i tylko tam, gdzie program jest dostępny — dla SQL Server 2016 Microsoft rozpisał go na trzy kolejne roczne okresy. To płatny bufor, który daje czas na migrację, gdy dostawca aplikacji nie wspiera jeszcze nowszej wersji. Nie zwalnia z zaplanowania docelowej zmiany.

Od czego zacząć, jeśli nie wiem, ile mam takich serwerów?

Od inwentaryzacji: spis wszystkich maszyn fizycznych i wirtualnych, wersji systemów, ról i wersji instancji SQL. Dopiero na tej podstawie da się ocenić, które serwery wymagają migracji, a które wystarczy zaktualizować. Jeśli brakuje zasobów, taki przegląd można zlecić w ramach pakietów administracyjnych.

Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.