Drupal 7 co dalej: nowa strona, migracja do Drupal 11 czy inny CMS?

Drupal 7 co dalej to pytanie, które w 2026 roku nadal zadaje sobie wiele organizacji. Oficjalne wsparcie Drupal 7 zakończyło się 5 stycznia 2025 roku, ale sporo stron nadal działa na tej wersji. Decyzja nie sprowadza się już do aktualizacji CMS-a. Często chodzi o wybór platformy, modelu treści i sposobu utrzymania strony na kolejne lata.

W tym artykule:

• Co oznacza koniec wsparcia Drupal 7?
• Dlaczego migracja z Drupal 7 do Drupal 11 nie jest zwykłą aktualizacją?
• Jakie wymagania pojawiły się od czasu budowy wielu stron na Drupal 7?
• Kiedy Drupal 11 lub Drupal CMS będzie najlepszym wyborem?
• Kiedy wystarczy techniczna migracja 1:1?
• Kiedy warto rozważyć inny CMS?
• Czy Astro albo static site generator może zastąpić CMS?
• Czy można zostać na Drupal 7 jeszcze przez jakiś czas?
• Co przygotować przed wyceną migracji lub nowej strony?
• Jak przedstawić warianty zarządowi?
• Jaka jest najlepsza decyzja po Drupal 7?

Co oznacza koniec wsparcia Drupal 7?

Drupal 7 zakończył oficjalne wsparcie 5 stycznia 2025 roku. Oznacza to, że ta wersja nie jest już standardowo rozwijana i nie otrzymuje oficjalnych aktualizacji bezpieczeństwa w tym samym modelu co wspierane wersje Drupala.

W praktyce problem jest większy niż sama data w kalendarzu. Strona może nadal działać, redaktorzy mogą dodawać aktualności, formularze mogą wysyłać wiadomości, a użytkownik z zewnątrz może nie widzieć żadnej różnicy. Ryzyko pojawia się pod spodem: w starym PHP, niewspieranych modułach, przestarzałym hostingu, braku aktualizacji bezpieczeństwa i rosnącym koszcie znalezienia osób, które dobrze znają Drupal 7.

Dlatego pytanie nie brzmi już tylko: „czy musimy coś zrobić?”. Bardziej praktyczne pytanie brzmi: „co chcemy mieć zamiast obecnej strony przez następne 5-10 lat?”.

W wielu organizacjach, szczególnie w sektorze publicznym, edukacji, usługach komunalnych, bankach lokalnych i firmach z długą historią strony, Drupal 7 jest nadal elementem codziennej pracy. To nie jest temat historyczny. To realny problem decyzyjny, który często wraca dopiero wtedy, gdy pojawia się audyt bezpieczeństwa, wymogi WCAG, problem z hostingiem albo decyzja o nowej stronie www.

Czytaj też: jak się przygotować na Drupal 7 end of life

Dlaczego migracja z Drupal 7 do Drupal 11 nie jest zwykłą aktualizacją?

W przypadku Drupal 7 słowo „migracja” bywa mylące. W wielu systemach aktualizacja oznacza podniesienie wersji, poprawienie kilku modułów i wdrożenie zmian. Przy Drupal 7 przejście do Drupal 11 jest czymś innym.

Drupal 7 i Drupal 11 różnią się architekturą, sposobem budowania modułów, systemem szablonów, wymaganiami hostingowymi i narzędziami developerskimi. Motyw graficzny z Drupal 7 zwykle trzeba przebudować. Custom moduły trzeba przepisać, zastąpić albo usunąć. Część funkcji, które kiedyś wymagały modułów dodatkowych, jest dziś dostępna w rdzeniu lub w dojrzałym ekosystemie nowych modułów. Część starych modułów nie ma już sensownej ścieżki aktualizacji.

Najprościej powiedzieć tak: przejście z Drupal 7 do Drupal 11 jest bardziej przeprowadzką do nowego budynku niż remontem jednego pokoju.

To nie jest zła wiadomość. To oznacza, że projekt można potraktować nie jako „łatanie starej strony”, ale jako budowę nowej strony na stabilnym silniku, z migracją tych treści, adresów URL, plików i funkcji, które nadal mają wartość.

Dlatego w rozmowach z klientami warto rozdzielić kilka pojęć:

• Aktualizacja: podniesienie wersji w ramach podobnej architektury.
• Migracja: przeniesienie danych, treści i części konfiguracji do nowego systemu.
• Redesign: zmiana wyglądu i doświadczenia użytkownika.
• Rebuild: przebudowa strony lub aplikacji na nowej architekturze.
• Replatforming: zmiana platformy, np. z Drupala na WordPress, headless CMS albo setup statyczny.

W projekcie po Drupal 7 często występuje kilka z tych rzeczy jednocześnie.

Czytaj też: Drupal 7 vs Drupal 11 - jak zmienił się ten system i jego funkcjonalności

Jakie wymagania pojawiły się od czasu budowy wielu stron na Drupal 7?

Wiele stron na Drupal 7 powstawało 10-15 lat temu. Wtedy wymagania wobec strony internetowej były często prostsze. Strona miała prezentować informacje, mieć kilka formularzy, listę aktualności, pliki do pobrania i panel redakcyjny. Dziś ten sam typ strony musi spełniać znacznie więcej oczekiwań.

Najczęstsze nowe wymagania to:

• Dostępność cyfrowa i WCAG - szczególnie ważne dla sektora publicznego, uczelni, instytucji, spółek komunalnych i organizacji obsługujących szeroką grupę użytkowników.
• Zgody cookies i prywatność - baner cookies, zgody analityczne i marketingowe, zgodność z RODO i ePrivacy.
• Mobile-first i RWD - strona musi działać wygodnie na telefonie, nie tylko „jakoś się skalować”.
• Core Web Vitals i wydajność - szybkość ładowania, stabilność layoutu, optymalizacja obrazów, cache i CDN wpływają na SEO oraz doświadczenie użytkownika.
• Bezpieczeństwo panelu CMS - mocniejsze hasła, 2FA, ograniczenie dostępu do panelu, captcha i ochrona przed brute force.
• Nowe wymagania SEO - przekierowania 301, schema.org, metadane, struktura nagłówków, indeksowalność, canonicale i monitoring Search Console.
• Analityka i konwersje - GA4, GTM, mierzenie formularzy, kampanii, zdarzeń i integracja z CRM.
• Lepszy UX redakcyjny - biblioteka mediów, komponenty, workflow publikacji, wersjonowanie, moderacja i prostsza praca redaktorów.
• Bezpieczne formularze - walidacja, antyspam, zgody, powiadomienia, bezpieczne przechowywanie zgłoszeń.
• Proces DevOps - staging, backupy, deployment, monitoring, SSL, logi i plan awaryjny.
• Integracje - CRM, newsletter, mapy, płatności, systemy wewnętrzne, API, wyszukiwarka, profil zaufany albo inne narzędzia branżowe.
• Treści operacyjne - komunikaty pilne, pasek awarii, status usług, alerty dla mieszkańców albo klientów.

To wszystko sprawia, że nowa strona w 2026 roku bywa bardziej złożona niż strona budowana w czasach Drupal 7. Jednocześnie mamy dziś narzędzia, których wtedy nie było.

AI i LLM mogą przyspieszyć analizę treści, tworzenie pierwszych wersji struktury informacji, mapowanie pól migracyjnych, generowanie dokumentacji, QA, testy regresji i przygotowanie prototypów. Nie zdejmują odpowiedzialności z zespołu, ale skracają część pracy analitycznej i developerskiej.

W samym ekosystemie Drupala pojawił się też Drupal CMS, czyli gotowy starter dla nowych projektów. W czasach Drupal 7 często zaczynało się od surowej instalacji i ręcznego składania modułów. Dziś można startować z bardziej kompletnym zestawem funkcji, co daje więcej opcji przy budowie nowej strony i może skrócić drogę od decyzji do działającego prototypu.

Wniosek jest prosty: jeśli obecna strona na D7 ma 10+ lat, migracja bez przeglądu nowych wymagań może tylko przenieść stary problem do nowej technologii.

Kiedy Drupal 11 lub Drupal CMS będzie najlepszym wyborem?

Drupal 11 albo Drupal CMS ma najwięcej sensu wtedy, gdy strona nie jest tylko prostą wizytówką. Jeśli organizacja potrzebuje struktury treści, uprawnień, formularzy, wielu ról, bezpieczeństwa, workflow redakcyjnego, wielojęzyczności, integracji i długoterminowego rozwoju, Drupal pozostaje bardzo mocnym wyborem.

To ważne szczególnie dla organizacji, które nie chcą za chwilę robić kolejnego replatformingu. Dobrze zaprojektowany Drupal może służyć jako stabilny backend przez 5-10 lat. Frontend i warstwę wizualną można odświeżać częściej, np. co 2-5 lat, żeby dopasować stronę do nowych trendów UX, kampanii marketingowych, mobile i dostępności. Nie każda zmiana wyglądu musi oznaczać wymianę całego CMS-a.

Drupal sprawdza się szczególnie, gdy potrzebujesz:

• złożonych typów treści i pól,
• wielu ról redakcyjnych,
• workflow publikacji,
• integracji z innymi systemami,
• wielojęzyczności,
• stabilnego API,
• silnego modelu uprawnień,
• wysokich wymagań bezpieczeństwa,
• długiego cyklu życia platformy,
• możliwości rozbudowy strony w aplikację lub portal.

Nieprzypadkowo Drupal jest używany przez banki, rządy, uczelnie, instytucje publiczne i duże organizacje. Nie dlatego, że jest najprostszym CMS-em do każdej strony, ale dlatego, że jest solidnym silnikiem dla systemów, które muszą być stabilne, bezpieczne i łatwe do rozbudowy.

W przypadku organizacji podobnych do spółek komunalnych rozsądny wariant często brzmi: nowa strona na Drupal 11 lub Drupal CMS, z migracją wartościowych treści, zachowaniem ważnych adresów URL, poprawą WCAG, uporządkowaniem formularzy, dodaniem cookies i przemyśleniem funkcji operacyjnych, takich jak pasek awarii.

Kiedy wystarczy techniczna migracja 1:1?

Nie każda organizacja potrzebuje pełnego redesignu. Czasem celem jest głównie bezpieczne przeniesienie strony z Drupal 7 na wspieraną wersję, przy minimalnych zmianach wyglądu.

Taki wariant ma sens, gdy:

• budżet jest ograniczony,
• obecny wygląd jest akceptowalny,
• strona ma konkretne funkcje, które trzeba zachować,
• zespół chce przede wszystkim pozbyć się ryzyka EOL,
• projekt ma być szybki i możliwie przewidywalny,
• nie ma potrzeby projektowania nowego UX.

W praktyce nawet taki wariant nie jest „kliknięciem aktualizacji”. Trzeba uzgodnić listę funkcji, które migrujemy, treści, które zostają, moduły, które zastępujemy, oraz elementy, których nie warto już odtwarzać.

Techniczna migracja 1:1 może być dobrym mostem, jeśli organizacja chce uporządkować ryzyko, ale nie ma jeszcze gotowości na pełny projekt nowej strony. Trzeba tylko jasno powiedzieć, że wtedy część problemów UX, treści i designu zostaje na później.

Kiedy warto rozważyć inny CMS?

Drupal nie musi być najlepszą odpowiedzią dla każdej strony po Drupal 7. Czasem obecny serwis był kiedyś zbudowany na Drupalu, bo był to dobry wybór w tamtym momencie, ale dzisiejsze potrzeby są dużo prostsze.

Jeśli strona ma kilka typów treści, rzadkie aktualizacje, prosty panel redakcyjny, brak złożonych ról i niewiele integracji, warto porównać Drupala z innymi systemami.

Przykładowe opcje:

• WordPress - duży ekosystem, prosty panel, ogromna liczba wykonawców, dobry wybór dla prostych stron marketingowych i contentowych.
• Craft CMS - CMS skoncentrowany na treściach, z dopracowanym modelem contentu.
• TYPO3 - system silny w DACH, enterprise i części sektora publicznego.
• Joomla - klasyczny full-stack CMS dla prostszych stron i organizacji z istniejącym know-how.
• Wagtail - CMS oparty o Python/Django, ciekawy dla zespołów z kompetencjami Python.
• Umbraco - opcja dla organizacji pracujących w ekosystemie .NET i Microsoft.
• Strapi, Directus, Payload - systemy headless/API-first, gdy frontend ma być osobną aplikacją.
• Ghost - system dla publikacji, newsletterów i prostych serwisów treściowych.

Warto skorzystać też z porównania CMS Battle, gdzie zestawiono 15 platform CMS, 110 funkcji i 24 kategorie. Taki materiał pomaga przejść z rozmowy „który CMS lubimy?” do rozmowy „który CMS najlepiej pasuje do naszych wymagań?”.

Zmiana CMS-a nie usuwa jednak pracy migracyjnej. Nadal trzeba przenieść treści, pliki, media, formularze, URL-e, metadane, analitykę i logikę redakcyjną. Jeśli stara strona ma historię w Google, przekierowania 301 i zachowanie widoczności SEO są obowiązkowe niezależnie od technologii.

Czy Astro albo static site generator może zastąpić CMS?

Coraz częściej alternatywą dla klasycznego CMS-a jest strona statyczna lub hybrydowa, np. na Astro, Next.js, Hugo albo Eleventy. Takie podejście może mocno przyspieszyć budowę i uprościć utrzymanie.

Zalety są konkretne: świetna wydajność, mniejsza powierzchnia ataku, prostszy hosting, mniej backendu, tańsze skalowanie i dobry wynik Core Web Vitals. Dla stron, które są głównie informacyjne i rzadko aktualizowane, może to być bardzo sensowny kierunek.

Trzeba jednak uczciwie powiedzieć o kompromisie. Tworzenie treści w takim modelu często nie jest tak wygodne jak w klasycznym CMS-ie. Redaktor może pracować na plikach Markdown lub MDX, pull requestach, GitHubie, GitLabie albo z pomocą osoby technicznej. Dla zespołu developerskiego to wygodne i szybkie. Dla redakcji, która przez lata pracowała w panelu CMS, może być to bariera.

Można to złagodzić przez headless CMS albo panel redakcyjny typu Tina, Decap, Sanity lub Contentful. Wtedy redaktorzy dostają wygodniejszy interfejs, a frontend nadal może być szybki i nowoczesny. Tylko wtedy wraca część złożoności, którą statyczna strona miała usunąć.

Dlatego Astro i podobne systemy warto rozważyć, ale nie jako domyślną odpowiedź na każdy problem po Drupal 7. Najpierw trzeba sprawdzić, kto będzie aktualizował treści, jak często, jak wygląda proces akceptacji i czy organizacja akceptuje workflow treści oparty o Git.

Czy można zostać na Drupal 7 jeszcze przez jakiś czas?

Czasem organizacja nie ma budżetu, decyzji zarządu albo czasu na natychmiastową migrację. Wtedy można przygotować plan etapowy. Ważne, żeby nie mylić go ze strategią docelową.

Minimalny plan powinien obejmować:

• aktualną kopię plików i bazy,
• test odtworzenia backupu,
• przegląd bezpieczeństwa,
• ograniczenie dostępu do panelu administracyjnego,
• sprawdzenie wersji PHP i hostingu,
• listę krytycznych modułów i formularzy,
• monitoring dostępności,
• plan awaryjny,
• termin decyzji o migracji lub replatformingu.

Można też rozważyć extended support dla Drupal 7, jeśli organizacja potrzebuje czasu. Jednym z przykładów jest D7Security, czyli nieoficjalna inicjatywa niezależna od Drupal.org, która zapewnia rozszerzone wsparcie dla wybranych modułów i motywów Drupal 7 oraz publikuje nowe wydania dla projektów, które nie mogą już wrócić do wsparcia na Drupal.org.

To może być praktyczny most bezpieczeństwa dla organizacji, które nie są gotowe na migrację od razu. Nie należy jednak traktować tego jako strategii docelowej. D7Security, płatne wsparcie legacy albo inne opcje LTS pomagają kupić czas, ale nie odpowiadają na pytanie, jaka platforma ma obsługiwać stronę przez kolejne lata.

Najgorszy wariant to zostawić Drupal 7 bez planu, bez backupu, bez osoby odpowiedzialnej i bez terminu decyzji. Wtedy ryzyko rośnie po cichu.

Co przygotować przed wyceną migracji lub nowej strony?

Bez podstawowych danych każda wycena będzie zgadywaniem. Przed rozmową z wykonawcą warto przygotować krótki pakiet informacji.

Najważniejsze elementy to:

• adres obecnej strony,
• informacja o wersji Drupal 7,
• kopia plików i bazy danych,
• lista najważniejszych typów treści,
• lista formularzy,
• lista integracji,
• informacja o językach,
• liczba redaktorów i ról,
• wymagania WCAG, RODO i cookies,
• lista treści do zachowania,
• lista treści do usunięcia,
• najważniejsze URL-e z ruchu organicznego,
• przykłady stron, które podobają się wizualnie,
• budżet orientacyjny,
• oczekiwany termin uruchomienia.

W przypadku starszych stron bardzo dobrym pierwszym krokiem jest audyt. Nie musi to być ogromny dokument. Często wystarczy krótka analiza: co mamy, co warto przenieść, co można usunąć, gdzie są ryzyka i jakie są możliwe warianty.

Czytaj też: aktualizacja wersji Drupal vs. migracja - przygotowanie, kroki i typowe wyzwania

Jak przedstawić warianty zarządowi?

Zarząd zwykle nie potrzebuje pełnej listy modułów. Potrzebuje decyzji, ryzyka, kosztu, terminu i konsekwencji. Dlatego zamiast jednej odpowiedzi „migracja kosztuje X”, lepiej pokazać kilka wariantów.

Taka tabela pomaga oddzielić rozmowę o technologii od rozmowy o celu. Celem nie jest „mieć Drupal 11”. Celem jest mieć bezpieczną, wygodną, dostępną i rozwijalną stronę, która odpowiada realnym potrzebom organizacji.

Jeśli przebudowa jest już na stole, warto najpierw przejść decyzję przez ramę modernizacji etapami - zobacz: Nie przebudowuj, ewolucjonuj.

Jaka jest najlepsza decyzja po Drupal 7?

Nie ma jednej odpowiedzi dla wszystkich. Każda organizacja powinna podjąć decyzję według swoich wymagań: skali strony, liczby redaktorów, wymagań WCAG, budżetu, bezpieczeństwa, SEO, integracji, częstotliwości publikacji i planów rozwoju.

Dla prostej strony marketingowej dobrym wyborem może być WordPress, Astro albo inny lżejszy system. Dla serwisu publikacyjnego może wystarczyć Ghost. Dla zespołu .NET sensowny może być Umbraco. Dla API-first może pasować Strapi, Directus albo Payload.

Jeśli jednak organizacja potrzebuje stabilnego backendu, zaawansowanego modelu treści, uprawnień, formularzy, workflow, wielojęzyczności, integracji i bezpieczeństwa, Drupal 11 lub Drupal CMS jest bardzo mocnym kierunkiem. Daje szansę na zbudowanie platformy, której nie trzeba będzie za chwilę wymieniać.

To jest szczególnie ważne po doświadczeniu z Drupal 7. Jeśli dziś zbudujesz nową stronę na stabilnym backendzie, możesz przez kolejne lata odświeżać frontend, projekt graficzny, komponenty i kampanie bez wymiany całego silnika. Backend może zostać, a warstwa wizualna może dojrzewać razem z organizacją.

Właśnie dlatego Drupal jest wybierany przez banki, rządy, uczelnie i duże instytucje. Nie dlatego, że jest najprostszy do każdej małej strony, ale dlatego, że jest solidny, bezpieczny, łatwy do rozbudowy i sprawdzony w środowiskach, gdzie stabilność ma znaczenie.

Potrzebujesz decyzji, co zrobić ze stroną na Drupal 7?

Jeśli Twoja strona nadal działa na Drupal 7, nie zaczynaj od pytania „ile kosztuje migracja?”. Zacznij od krótkiej analizy: co warto zachować, co usunąć, co przebudować i jaki system najlepiej pasuje do kolejnych lat.

Możemy pomóc przygotować taką analizę i porównać realne warianty: techniczną migrację, nową stronę na Drupal 11 lub Drupal CMS, zmianę CMS-a, Astro/static site albo etapowanie. Skontaktuj się z nami przez formularz kontaktowy Droptica, a pomożemy dobrać bezpieczną ścieżkę dla Twojej strony.