Drupal 10: koniec wsparcia, data EOL, ryzyka i plan aktualizacji

Koniec wsparcia Drupala 10 nastąpi 9 grudnia 2026 roku. Po tej dacie projekt Drupal przestanie publikować wydania tej wersji, w tym poprawki bezpieczeństwa. Twoja strona nie wyłączy się następnego dnia. Będzie nadal działać, ale na oprogramowaniu, którego twórcy już nie wspierają.

EOL działa trochę jak zakończenie aktualizacji telefonu. Urządzenie nadal się uruchamia, lecz każda kolejna wykryta luka zostaje z tobą. W przypadku serwisu internetowego dochodzą do tego moduły, PHP, integracje oraz wymagania działu bezpieczeństwa.

Jeśli odpowiadasz za serwis na Drupalu 8, 9 lub 10, pokażę ci, jak ocenić punkt startowy i wybrać sensowną drogę do Drupala 11. Nie będę tu powtarzał pełnej instrukcji technicznej. Skupię się na decyzjach, które trzeba podjąć przed rozpoczęciem prac. Szczegóły audytu, zakres prac i sposób przejścia do wdrożenia opisujemy na stronie audytu i wyceny aktualizacji Drupal 10 EOL.

Ostatnia aktualizacja: 11 września 2026. Najnowszym wydaniem linii Drupala 10 jest obecnie 10.6.16.

Ten artykuł opisuje serwisy zbudowane na architekturze wprowadzonej w Drupalu 8. Drupal 7 wymaga osobnego projektu migracyjnego, dlatego nie jest punktem wyjścia dla przedstawionej tu ścieżki aktualizacji.

W tym artykule:

• Kiedy Drupal 10 traci wsparcie?
• Czy używana linia Drupala 10 jest nadal wspierana?
• Czym różni się aktualizacja Drupala 8, 9 lub 10 od migracji z Drupala 7?
• Co zmieni się po EOL Drupala 10?
• Czy można czekać na Drupala 12?
• Jak wyznaczyć bezpieczny termin aktualizacji do Drupala 11?
• Jak przygotować jeden serwis, multisite lub portfolio stron?
• Kiedy wybrać aktualizację, stabilizację, modernizację albo przebudowę?
• Co powinien obejmować przegląd gotowości do Drupala 11?
• Co można zrobić w pierwszym tygodniu?
• Najczęstsze pytania o koniec wsparcia Drupala 10

Kiedy Drupal 10 traci wsparcie?

Wsparcie Drupala 10 zakończy się 9 grudnia 2026 roku. To data końca wsparcia (EOL). Oficjalny harmonogram wydań rdzenia Drupala wskazuje też, że Drupal 10.6 jest ostatnią linią wydań pośrednich tej wersji. Po dacie EOL nie powstaną kolejne wydania Drupala 10.

W tym samym tygodniu, który rozpocznie się 7 grudnia, zaplanowano wydanie Drupala 12.0.0 i Drupala 11.5.0. Łatwo więc dojść do wniosku, że najlepiej poczekać kilka dni i przejść od razu do Drupala 12. Tak to nie działa. Główne wersje aktualizuje się kolejno, dlatego z Drupala 10 trzeba najpierw przejść do Drupala 11.

Drupal 10 nie przestanie działać 10 grudnia 2026 roku. Zmiana polega na tym, że nowo wykryte podatności w rdzeniu Drupala 10 nie będą już otrzymywać poprawek od projektu Drupal.

Data EOL jest wspólna dla wszystkich. Twój rzeczywisty termin będzie jednak wcześniejszy. Musisz zostawić czas na testy, poprawki, akceptację biznesową, wdrożenie i sprawdzenie serwisu po aktualizacji.

Czy używana linia Drupala 10 jest nadal wspierana?

Często słyszę tylko: „mamy Drupala 10”. To za mało, żeby ocenić sytuację. Drupal 10.4, 10.5 i 10.6 nie mają dziś takiego samego statusu. Trzeba sprawdzić linię wydań pośrednich oraz dokładne wydanie poprawkowe.

Na 11 września 2026 roku sytuacja wygląda tak:

Aktualne wydanie poprawkowe to Drupal 10.6.16, opublikowane 3 września 2026 roku. Ten numer może zmienić się wraz z kolejnym wydaniem, dlatego przed rozpoczęciem prac trzeba sprawdzić bieżącą listę wydań rdzenia Drupala.

Jeśli twój serwis działa na 10.4 albo 10.5, nie czekałbym z pracami do grudnia. Masz już dwa problemy: niewspieraną linię wydań pośrednich oraz zbliżający się koniec wsparcia całej wersji Drupal 10.

Czym różni się aktualizacja Drupala 8, 9 lub 10 od migracji z Drupala 7?

Migrację z Drupala 7 i aktualizację nowszych wersji często wrzuca się do jednego worka. To dwa różne projekty.

Najprościej porównać je do przeprowadzki i remontu. Przy Drupalu 7 budujesz nową instalację i przenosisz do niej treści, konfigurację oraz funkcje. Przy Drupalu 8, 9 lub 10 pracujesz na istniejącym systemie i przeprowadzasz go przez kolejne wersje.

Drupal 7 i Drupal 8 dzieli duża zmiana architektury oraz sposobu przechowywania danych i konfiguracji. Według oficjalnej dokumentacji migracji serwisu na Drupalu 7 nie aktualizuje się przez podmianę rdzenia. Trzeba przygotować nową instalację, przenieść treści i konfigurację przez Migrate API, odtworzyć integracje oraz zbudować motyw zgodny z nową wersją.

Od Drupala 8 działa ciągła ścieżka aktualizacji. Serwis zachowuje bazę danych i konfigurację. Zespół aktualizuje rdzeń i zależności, usuwa użycie wycofywanych API oraz uruchamia aktualizacje schematu bazy. Czasami oznacza to dużo pracy w modułach własnych, motywie lub integracjach, ale nie wymaga z definicji przenoszenia treści do nowego systemu.

Oficjalny opis procesu nie pozwala pominąć wersji głównej. Punkt wyjścia zmienia więc liczbę etapów:

Drupal 8 i 9 należą do tej samej rodziny architektonicznej co Drupal 10. Mają jednak przed sobą więcej etapów. Każdy z nich może wymagać innej wersji PHP, bibliotek i modułów.

Z tego powodu nie wyceniałbym przejścia z Drupala 8 albo 9 na podstawie prostego formularza. Najpierw trzeba zobaczyć kod, zależności i sposób wdrażania. Audyt serwisu na Drupalu 10 może dać wstępny przedział prac po zebraniu danych o kodzie i zależnościach. Dla starszych wersji potrzebna będzie analiza techniczna.

Co zmieni się po EOL Drupala 10?

Nie używałbym argumentu, że 10 grudnia strona przestanie działać, bo to nieprawda. Problem jest inny. Od tego dnia zespół utrzymujący serwis zostanie z niewspieraną wersją rdzenia i coraz trudniejszym zestawem zależności.

1. Bezpieczeństwo: nowa podatność w rdzeniu Drupala 10 może pozostać bez oficjalnej poprawki.
2. Audyt i wymagania firmy: używanie niewspieranego komponentu może utrudnić audyt bezpieczeństwa, ocenę dostawcy albo potwierdzenie zgodności z wewnętrzną polityką.
3. Zależności: PHP, biblioteki i moduły społecznościowe (contrib) będą rozwijać się dalej. Utrzymywanie starej gałęzi zacznie wymagać dodatkowych obejść.
4. Rozwój serwisu: pozornie mała funkcja może najpierw wymagać aktualizacji platformy i zależności.
5. Zakupy i ubezpieczenie: część organizacji oraz ubezpieczycieli wymaga korzystania ze wspieranego oprogramowania. Każda firma powinna sprawdzić własne warunki.
6. Koszt: projekt rozpoczęty pod presją zostawia mniej czasu na testy, wybór zamienników i spokojne wdrożenie.

EOL nie oznacza automatycznego naruszenia prawa albo konkretnej normy. Zwiększa ryzyko. Jeśli musisz przedstawić temat zarządowi, pokaż datę, stan obecnej wersji, plan aktualizacji i sposób zabezpieczenia serwisu do czasu wdrożenia.

Jeśli bezpieczeństwo platformy wymaga szerszego przeglądu, zobacz też, jak podejść do bezpieczeństwa Drupala, aktualizacji i kontroli używanych modułów.

Czy można czekać na Drupala 12?

Nie polecam. Drupal 12 nie będzie bezpośrednią ścieżką aktualizacji dla serwisu na Drupalu 10. Główne wersje aktualizuje się kolejno, więc najpierw trzeba przygotować i wdrożyć Drupala 11. Serwis na Drupalu 8 lub 9 ma przed sobą odpowiednio trzy albo dwa etapy, zanim osiągnie wersję 11.

Wydanie Drupala 12 nie przedłuży wsparcia Drupala 10. Czekając do grudnia, skrócisz czas na poprawę kodu własnego, znalezienie zamienników dla modułów i testy procesów biznesowych. Możesz też trafić na firmowy okres zamrożenia wdrożeń pod koniec roku.

Praca wykonana teraz nie przepadnie. Gdy usuniesz wycofywane API, uporządkujesz zależności i poprawisz proces wdrożeniowy, następny upgrade będzie prostszy. Najpierw doprowadź jednak platformę do wspieranej wersji.

Przeczytaj także: Jak zaktualizować Drupala 8, 9 lub 10 do Drupala 11. Ten poradnik zawiera techniczną kolejność, kontrole modułów i przykłady pracy z Composerem.

Zakres zmian w kolejnej wersji opisujemy w artykule Drupal 11 – funkcje i plan rozwoju.

Jak wyznaczyć bezpieczny termin aktualizacji do Drupala 11?

9 grudnia to koniec wsparcia, a nie data rozpoczęcia projektu. Najprościej zacząć od ostatniego bezpiecznego okna produkcyjnego i policzyć plan wstecz.

Dla Drupala 8 i 9 ten termin już minął. W takim przypadku nie planujesz prac „przed EOL”. Planujesz możliwie szybkie wyjście z niewspieranej wersji, z osobnym etapem dla każdej wersji głównej.

Ja ułożyłbym harmonogram w takiej kolejności:

1. ustal produkcyjne okno wdrożenia i bufor na obserwację serwisu;
2. zarezerwuj czas na akceptację biznesową oraz testy regresji;
3. uwzględnij poprawki wynikające z testów;
4. zaplanuj aktualizację rdzenia, modułów, motywu i kodu własnego;
5. dodaj czas na przegląd gotowości oraz usunięcie blokerów;
6. potwierdź dostęp, budżet, osoby decyzyjne i właścicieli testów.

Nie podaję jednej liczby tygodni dla każdego projektu, bo byłaby to pozorna precyzja. Serwis z kilkoma modułami własnymi, działającym CI i testami będzie miał inną ścieżkę niż wielojęzyczny multisite z wieloma integracjami.

Zacznij wcześniej, jeśli masz:

• zamrożenie wdrożeń w listopadzie albo grudniu;
• osobny audyt bezpieczeństwa lub zgodności;
• moduły bez potwierdzonej wersji dla Drupala 11;
• dużo kodu własnego albo stary motyw;
• integracje z CRM, e-commerce, SSO lub automatyzacją marketingu;
• ograniczoną dostępność osób prowadzących testy akceptacyjne;
• kilka serwisów zależnych od wspólnego repozytorium.

Jak przygotować jeden serwis, multisite lub portfolio stron?

Dziesięć domen nie musi oznaczać dziesięciu osobnych projektów. Mogą działać na jednej bazie kodu, na kilku instalacjach albo korzystać z Drupala jako headless CMS. Dlatego najpierw sprawdź architekturę, a dopiero potem licz strony.

W przypadku multisite zacząłbym od reprezentatywnego pilota. Nie zawsze będzie nim najmniejsza strona. Lepszym kandydatem jest serwis, który korzysta ze wspólnego kodu, ma typowe integracje i pozwoli sprawdzić proces bez narażania najważniejszej domeny.

Przy tej okazji sprawdź też sens biznesowy każdej strony. Czasem lepiej połączyć domeny, wycofać nieużywany serwis albo przenieść go do wspólnej platformy, niż aktualizować wszystko w obecnym kształcie.

Więcej o zależnościach między architekturą i domenami opisujemy w artykule Multisite, Domain Access czy headless – jak obsłużyć wiele domen w Drupalu?.

Kiedy wybrać aktualizację, stabilizację, modernizację albo przebudowę?

Koniec wsparcia często uruchamia długą listę pomysłów: nowy wygląd, poprawę UX, zmianę hostingu, porządki w treści i przebudowę integracji. Rozumiem tę pokusę. Skoro już ruszamy kod, chcemy załatwić wszystko naraz.

To zwykle utrudnia projekt. Najpierw oddziel prace potrzebne do przejścia na wspieraną wersję od zmian, które mogą poczekać.

Najczęściej wybrałbym aktualizację albo stabilizację z aktualizacją. Modernizację można zaplanować jako kolejny etap. Pełna przebudowa ma sens dopiero wtedy, gdy obecna architektura przestała pasować do celu serwisu albo naprawa starego systemu kosztowałaby więcej niż stworzenie nowej podstawy.

Co powinien obejmować przegląd gotowości do Drupala 11?

Dobry przegląd gotowości nie jest eksportem listy modułów. Ma odpowiedzieć na trzy pytania: czy platformę można bezpiecznie zaktualizować, co ją blokuje i ile pracy trzeba wykonać przed wdrożeniem.

Stan platformy

Najpierw potwierdź wersję rdzenia Drupala, PHP i bazy danych, model hostingu oraz zależności zarządzane Composerem. Oficjalna instrukcja aktualizacji dopuszcza jako punkt wyjścia wersję 10.3.0 lub nowszą. W praktyce przed projektem przeszedłbym na najnowsze wspierane wydanie 10.6.x.

Drupal 11 wymaga PHP 8.3.0 lub nowszego. Sprawdź aktualne wymagania PHP oraz wymagania bazy danych. Sama zgodność z Drupalem nie oznacza jeszcze, że używana wersja PHP nadal otrzymuje własne poprawki bezpieczeństwa.

Ryzyko zgodności

Każdy aktywny moduł społecznościowy (contrib) i motyw powinien mieć potwierdzoną ścieżkę do Drupala 11 albo zaakceptowany zamiennik. Upgrade Status pomoże znaleźć część problemów. Nie zastąpi jednak ręcznej weryfikacji modułów, poprawek, custom code i szablonów Twig pod kątem wycofywanych API.

Procesy krytyczne

Nie testuj wyłącznie tego, czy wyświetla się strona główna. Lista testów powinna wynikać z prawdziwego użycia serwisu. Zwykle obejmuje logowanie, formularze, wyszukiwanie, publikację treści, płatności, integracje, zadania cykliczne, SEO i mechanizmy zgód.

Gotowość do wydania

Potrzebujesz działających środowisk, kopii zapasowej, planu wycofania wdrożenia, monitoringu i osób odpowiedzialnych za akceptację. Sprawdź też, czy termin nie wchodzi w firmowy okres zamrożenia wdrożeń.

Decyzja i plan pracy

Na końcu powinieneś dostać konkret: listę blokerów, ich priorytety, zakres, przedział prac i rekomendowaną ścieżkę. Dopiero na tej podstawie można wybrać aktualizację wersji, stabilizację albo większą modernizację.

Przeczytaj także: Aktualizacja wersji Drupala – przygotowanie, konkretne kroki i typowe wyzwania.

Co można zrobić w pierwszym tygodniu?

W pierwszym tygodniu nie zaczynałbym od pytania kilku agencji o cenę. Bez informacji o kodzie każda szybka wycena będzie zgadywaniem.

Zacznij od zebrania danych:

1. Sprawdź dokładną wersję rdzenia Drupala i porównaj ją z aktualnymi wydaniami.
2. Potwierdź wersję PHP, bazy danych i model hostingu.
3. Uruchom Upgrade Status na aktualnej kopii serwisu.
4. Wyeksportuj listę modułów contrib, modułów własnych, motywów i poprawek.
5. Zapisz integracje oraz procesy krytyczne dla użytkowników i redakcji.
6. Sprawdź dostęp do repozytorium, środowiska testowego, kopii zapasowej i planu wycofania wdrożenia.
7. Dla Drupala 10 ustal ostatnie bezpieczne okno produkcyjne przed 9 grudnia 2026 roku. Dla Drupala 8 lub 9 wybierz najbliższy termin, który pozwoli przeprowadzić wszystkie etapy i testy.
8. Wybierz następny krok: własny przegląd, zewnętrzną ocenę gotowości albo przygotowanie backlogu aktualizacji.

Po tych ośmiu krokach nadal nie będziesz znać dokładnego kosztu. Będziesz jednak wiedzieć, czego brakuje do podjęcia decyzji.

Jeśli nie znasz stanu kodu lub zależności, możesz zacząć od audytu gotowości do Drupala 11. Po przejrzeniu serwisu otrzymasz listę blokerów, plan upgrade’u i wycenę prac dopasowaną do obecnej wersji. Realizację upgrade’u wyceniamy osobno, po audycie.

Po aktualizacji potrzebna będzie dalsza obsługa wydań, podatności i incydentów. Zobacz, jak działa utrzymanie i wsparcie Drupala.

Najczęstsze pytania o koniec wsparcia Drupala 10

Poniżej zebrałem krótkie odpowiedzi na pytania, które najczęściej pojawiają się przy planowaniu aktualizacji. Szczegóły nadal będą zależeć od kodu, modułów, infrastruktury i sposobu wdrażania.

Czy Drupal 10 jest nadal wspierany?

Tak, ale wyłącznie linia Drupala 10.6.x i tylko do 9 grudnia 2026 roku. Wsparcie Drupala 10.5.x zakończyło się wraz z wydaniem Drupala 11.4.0 1 lipca 2026 roku. Starsze linie również nie są wspierane. Podczas przygotowań do Drupala 11 serwis powinien działać na najnowszym wydaniu 10.6.x.

Czy Drupal 8 lub 9 można zaktualizować do Drupala 11?

Tak, ale nie bezpośrednio. Serwis na Drupalu 8 musi przejść kolejno do wersji 9, 10 i 11. Serwis na Drupalu 9 przechodzi najpierw do wersji 10, a dopiero potem do 11. Nie można pominąć wersji głównej, ponieważ Drupal usuwa starsze aktualizacje schematu bazy i konfiguracji.

Kiedy dokładnie kończy się wsparcie Drupala 10?

Koniec wsparcia Drupala 10 (EOL) nastąpi 9 grudnia 2026 roku. Po tej dacie projekt Drupal nie będzie publikował kolejnych wydań tej wersji, w tym poprawek bezpieczeństwa. Organizacja powinna wyznaczyć wcześniejszy termin produkcyjny, który pozostawi czas na testy i stabilizację.

Co stanie się z serwisem po EOL?

Serwis nie wyłączy się automatycznie. Nadal może obsługiwać użytkowników, ale będzie działał na niewspieranej wersji rdzenia. Nowe podatności w Drupalu 10 mogą pozostać bez oficjalnych poprawek, a utrzymanie zgodności z bibliotekami, PHP i modułami będzie coraz trudniejsze.

Czy można pominąć Drupala 11 i poczekać na Drupala 12?

Nie. Aktualizacje głównych wersji Drupala prowadzi się kolejno. Serwis na Drupalu 10 trzeba najpierw przenieść do Drupala 11. Czekanie na Drupala 12 nie przedłuży wsparcia Drupala 10 i ograniczy czas dostępny na testy oraz usunięcie blokerów.

Czy Drupal 10.6 jest ostatnią linią Drupala 10?

Tak. Drupal 10.6.0 jest ostatnim wydaniem pośrednim Drupala 10. Linia 10.6.x pozostaje objęta wsparciem bezpieczeństwa do 9 grudnia 2026 roku. Kolejne wydania pojawią się w razie potrzeby, dlatego przed publikacją lub rozpoczęciem prac należy sprawdzić najnowszą wersję na Drupal.org.

Jak wcześnie rozpocząć aktualizację do Drupala 11?

Termin zależy od kodu, modułów, testów, integracji i firmowego kalendarza wdrożeń. Policz plan wstecz od ostatniego bezpiecznego okna produkcyjnego przed 9 grudnia. Jeśli masz multisite, dużo custom code, nieznane zależności albo listopadowe zamrożenie wdrożeń, zacznij wcześniej.

Czy aktualizacja do Drupala 11 wymaga przebudowy interfejsu?

Nie w każdym przypadku. Dobrze utrzymany serwis może przejść aktualizację wersji bez zmiany wyglądu. Przebudowę interfejsu można prowadzić jako osobny cel, gdy obecny frontend, UX albo architektura wymagają zmian. Łączenie obu zakresów bez diagnozy zwiększa ryzyko opóźnienia.

Jak przygotować multisite do EOL Drupala 10?

Zacznij od inwentaryzacji repozytoriów, domen, konfiguracji, modułów i właścicieli biznesowych. Następnie wybierz reprezentatywny serwis pilotażowy, przygotuj wspólny zestaw testów i zaplanuj kolejne fale wdrożeń. Kolejność powinna wynikać z zależności oraz ryzyka, a nie wyłącznie z wielkości strony.

Co sprawdzić przed planowaniem aktualizacji?

Najpierw potwierdź wersję rdzenia Drupala, PHP i bazy danych. Zbierz listę modułów, motywów, kodu własnego, poprawek i integracji. Sprawdź też dostęp do repozytorium, środowiska testowego, kopii zapasowej i planu wycofania wdrożenia.

Czy wiesz, co może zablokować przejście twojego Drupala 8, 9 lub 10 do wersji 11?

Widzieliśmy już projekty, w których sam numer wersji mówił bardzo mało o rzeczywistym zakresie prac. Gdy przejęliśmy utrzymanie platformy Exide Group, serwis działał na bardzo wczesnej wersji Drupala 8. Kod zastany utrudniał aktualizacje i testy.

Najpierw uporządkowaliśmy kod. Później zaktualizowaliśmy platformę i moduły, wdrożyliśmy Composera oraz przygotowaliśmy środowiska testowe i proces ciągłej integracji. Nie był to projekt przejścia do Drupala 11, ale dobrze pokazuje, dlaczego starszej wersji 8 lub 9 nie powinno się wyceniać w ciemno.

Jeśli chcesz ustalić blokery, zakres i bezpieczne okno wdrożenia przed końcem wsparcia Drupala 10, zacznij od audytu gotowości do Drupala 11. Po przejrzeniu kodu, modułów i infrastruktury twojego serwisu przygotujemy listę blokerów, plan upgrade’u i wycenę prac dopasowaną do punktu startowego: Drupala 8, 9 albo 10. Jeśli zdecydujesz się powierzyć nam realizację, przygotujemy osobną ofertę na wdrożenie.