A Drupal migráció azok közé a projektek közé tartozik, amelyek kényelmesen elüldögélnek a következő negyedév tervében, amíg egy dátum sürgőssé nem teszi őket. Most két dátum teszi ezt, és csak az egyik van még előttünk.

A Drupal 7 hivatalos támogatása 2025. január 5-én szűnt meg. Bármely oldal, amely még ezen fut, több mint egy éve biztonsági fedezet nélkül működik. A Drupal 10 támogatása 2026. december 9-én ér véget, ugyanazon a héten, amikor a Drupal 12 megjelenik, azt követően pedig semmilyen kiadást nem kap. Ha bármelyik verzión vagy, a kérdés már nem az, hogy lépj-e, hanem az, melyik utat választod és mennyibe kerül.

Hol tartasz: a Drupal 10-ről 11-re valódi frissítés, ugyanaz az oldal helyben frissítve, jellemzően két-hat hét. A Drupal 7-ről 11-re egyáltalán nem frissítés; ez újraépítés hozzácsatolt tartalommigrációval, és jellemzően három-hat hónap. A kettő összekeverése ezen a területen a legdrágább hiba, mert a Drupal 7-es oldalakat frissítésként árazzák be, aztán négyszeresen túlfutnak.

Két nagyon különböző migráció

A migráció szó két olyan munkát fed le, amelyek a néven kívül alig osztoznak valamiben.

A Drupal 10-ről 11-re frissítés. Az architektúra ugyanaz. Az entitásaid, mezőid, nézeteid és konfigurációd átjönnek. A munka nagyrészt függőségkezelés: gondoskodni arról, hogy minden közösségi modulnak legyen Drupal 11 kompatibilis kiadása, kitakarítani az elavult API-hívásokat az egyedi kódból, és támogatott PHP verzióra lépni. Ez inkább módszeres, mint nehéz, és egy jól karbantartott oldal két hét alatt megvan.

A Drupal 7-ről 11-re újraépítés. A Drupal 8 Symfony komponensekre írta át a platformot, lecserélve a modul API-t, a sablonozó réteget és a konfigurációs rendszert. Semmi nem jön át automatikusan a tartalmon kívül, és még az is célra épített migrációs folyamaton keresztül, nem frissítő szkripttel. A moduljaid már nem léteznek, a sablonodat Twigben kell újraírni, az egyedi kódodat pedig más architektúrára újra kell implementálni.

Ez a második eset a magyarázat arra, miért maradtak fenn ilyen sokáig Drupal 7-es oldalak. Az őszinte megfogalmazás az, hogy nem egy oldalt frissítesz, hanem újat építesz, és viszed magaddal a tartalmat.

Mibe kerül az egyes Drupal migrációs utak

Az alábbi számok brit ügynökségi díjakat és közepes összetettségű oldalt feltételeznek. Az összetettség itt a tartalomtípusok, közösségi modulok és egyedi modulok számát jelenti, nem az oldalak számát.

Drupal 10-ről 11-re, jól karbantartott oldal. Két-négy hét, nagyjából 6000 és 15 000 font között. Ez a szerencsés eset: a modulok naprakészek, az egyedi kód kevés, és a fő munka a tesztelés.

Drupal 10-ről 11-re, elhanyagolt oldal. Négy-nyolc hét, nagyjából 15 000 és 35 000 font között. Itt az akadályok a Drupal 11 kiadás nélküli közösségi modulok, az azóta eltávolított API-kra írt egyedi kód, és egy PHP verzió, amelynek szintén lépnie kell. Minden elhagyott modul döntéssé válik: találj helyettesítőt, vedd át a karbantartását, vagy implementáld újra a viselkedését.

Drupal 7-ről Drupal 11-re. Három-hat hónap, jellemzően 40 000 és 120 000 font között, nagy vagy erősen testreszabott oldalaknál több. A sáv azért széles, mert valójában újraépítési büdzsé. Maga a tartalommigráció gyakran a kisebbik fele; a sablon, az egyedi funkcionalitás és az integrációk a nagyobbik.

Drupal 7-ről másik platformra. Néha ez a helyes válasz. Ha az eredeti indok, amiért a Drupalt választották, már nem áll fenn, mert az oldal egyszerű marketingoldallá vált bloggal, akkor egy egyszerűbb platformra költözés kevesebbe kerülhet, mint a Drupalon belüli migráció, és utána csökkenti az üzemeltetési költséget is. A WordPress és az egyedi fejlesztés összehasonlításunk megmutatja, hol húzódik ez a határ, a Drupal webfejlesztési útmutató pedig őszintén megmondja, mikor nem a Drupal a válasz.

Miért a közösségi modulok döntik el az ütemtervet

Szinte minden Drupal frissítési becslés a contrib auditon áll vagy bukik, és ezt érdemes először elvégezni.

Sorold fel az oldal által használt összes közösségi modult, majd ellenőrizd mindegyiknél, van-e a célverzióval kompatibilis stabil kiadás. Amit találsz, négy csoportba esik. Egyeseknek van kompatibilis kiadásuk, és nem kell velük semmit tenni. Egyeseknek van kiadásjelöltjük vagy foltjuk a hibalistában, amelyet Composerrel alkalmazhatsz. Egyeseket elhagytak, és keresned kell helyettesítőt, át kell venned a modult, vagy egyedi kóddal kell pótolnod a funkcióját. Néhányat pedig beolvasztottak a Drupal magba, ami a gyakorlat kellemes meglepetése.

Ez az audit egy homályos projektet megszámlálhatóvá alakít. Amíg nincs kész, minden árajánlat találgatás, és az a szállító, aki nélküle ad fix árat, vagy erősen ráteszi a bizonytalanságot, vagy éppen változtatási kéréseket készül benyújtani.

Ugyanez a logika érvényes az egyedi modulokra, más eszközzel. A Drupal elavulást vizsgáló eszközkészlete átnézi az egyedi kódot, és jelenti az eltávolított vagy eltávolításra ítélt API-k hívásait, ami a „van egy kis egyedi kódunk” mondatot fájlok és sorszámok konkrét listájává alakítja.

Mi szokott valójában elromlani

Néhány hibaminta szinte minden Drupal migrációban visszatér.

Konfigurációs elcsúszás a környezetek között. Ha a változtatásokat közvetlenül az éles adminfelületen végezték, nem pedig konfigurációs fájlokba exportálták, akkor a teszt környezeted nem hű másolat, és a tesztelésed kevesebbet ér, mint hiszed. Ezt migráció közben felfedezni gyakori, és mindig időbe kerül.

Tartalom, amely soha nem volt annyira strukturált, mint mindenki hitte. A Drupal 7-es oldalak gyakran olyan módon halmoztak fel tartalmat, amit senki nem dokumentált: más célra átrepurpozált mezők, egy taxonómia szótár, amely munkafolyamat-állapot szerepét tölti be, törzsmezőkbe másolt HTML beágyazott stílusokkal. A migráció mindezt egyszerre hozza felszínre, és minden eset döntést kíván valakitől, aki tudja, mire való a tartalom.

Média- és fájlkezelés. A Drupal médiakezelése a Drupal 7 után jelentősen megváltozott. A fájlok, képstílusok és beágyazott médiák ritkán feleltethetők meg egy az egyben, és a nagy médiatárral rendelkező oldalaknak külön kell erre költségvetést tervezniük ahelyett, hogy a tartalommigrációval járó ingyenes ráadásnak vennék.

URL- és SEO-folytonosság. Ez az a pont, amely az üzletet rontja, nem az ütemtervet. Ha az URL-álnevek átirányítás nélkül változnak, elveszíted azt a helyezést, amelyet a régi oldal kiérdemelt. Minden migrációhoz kell teljes URL-leltár, átirányítási térkép és indulás utáni ellenőrzés. A webhely migrálása forgalomvesztés nélkül című útmutatónk ezt a folyamatot részletesen tárgyalja, és a platformváltásra ugyanúgy érvényes, mint a domainváltásra.

Többnyelvű tartalom. Ha az oldal több nyelven fut, számíts arra, hogy a migráció lényegesen tovább tart. A nyelvkezelést a Drupal 7 után újraépítették, és a fordított tartalom, a fordított konfiguráció és a nyelvspecifikus URL-minták mind külön figyelmet igényelnek.

Hogyan ütemezd a munkát

A sorrend többet számít, mint a legtöbb csapat gondolná, és az elrontása újramunkát okoz.

Kezdd a contrib és az egyedi kód auditjával, még mindenféle becslés előtt. Aztán vidd az oldalt támogatott PHP verzióra és a jelenlegi fő verziójának legfrissebb kiadására, mert ez a zaj egy egész kategóriáját eltávolítja a tényleges frissítésből. Csak ezután próbáld meg a fő verziólépést.

Építsd az új környezetet a régi mellé ahelyett, hogy helyben frissítenél. Így lesz hol ismételten tesztelni a tartalommigrációt, amire szükséged lesz, mert a migrációkat sokszor lefuttatják, mielőtt egyszer élesben lefutnának.

Kezeld a tartalommigrációt kódként. A Drupal migrációs keretrendszere lehetővé teszi, hogy konfigurációban definiáld a migrációkat és újra lefuttasd őket, vagyis visszaállíthatsz, igazíthatsz a leképezésen és mehetsz újra. Azok a csapatok, amelyek az új oldalon kézzel javítják a tartalmat a migrációs definíció javítása helyett, végül képtelenek lesznek újrafuttatni, és onnantól egyetlen tartalmi változás a régi oldalon kézi összeegyeztetéssé válik.

Végül tervezz tartalmi zárlatot a vége felé, és tartsd rövidre. A hosszú zárlatok arra késztetik a szerkesztőket, hogy megkerüljenek, ami épp azt az elcsúszást hozza létre, amit el akartál kerülni.

Érdemes teljesen elhagyni a Drupalt?

Jogos kérdés, és őszinte választ érdemel, nem védekezőt.

Maradj a Drupalon, ha az okok, amiért választottad, még állnak: összetett tartalommodellezés, finom jogosultságok, többnyelvű követelmények, komoly szerkesztői munkafolyamat, vagy akadálymentesítési és közszférabeli kötelezettségek. A Drupal mindezekben valóban erős, és a frissítési út innentől stabil, kiszámítható kétéves fő kiadási ciklussal.

Fontold meg a váltást, ha az oldal eltávolodott ezektől az igényektől. Rengeteg Drupal 7-es oldal ma a gyakorlatban marketingoldal hírekkel és kapcsolatfelvételi űrlappal. Ennek Drupalon belüli migrálása azt jelenti, hogy újraépítési árat fizetsz olyan képességért, amelyet már nem használsz.

A döntésnek a tartalommodellen és a szerkesztői terhelésen kell múlnia, nem azon, melyik platformot kedveli a fejlesztőd. Ha senki nem tudja megfogalmazni, mit tesz érted a Drupal, amit egy egyszerűbb platform ne tudna, az önmagában információ.

Legyen audit, mielőtt árajánlatot kérsz

A Mecanik a Drupal frissítéseket és migrációkat a webfejlesztési szolgáltatásaink részeként kezeli. A contrib és az egyedi kód auditjával kezdünk, mert ez az, ami egy nyitott végű projektet rögzített hatókörré alakít, és akkor is megéri, ha utána máshová viszed a munkát.

Drupal 10-es oldalaknál az ésszerű lépés most megtervezni a Drupal 11-re váltást, nem novemberben, amikor mindenki más is ezt teszi. Drupal 7-es oldalaknál a biztonsági helyzet önmagában érv. Ha a szűk keresztmetszet a kapacitás és nem a szakértelem, a Drupal fejlesztő felvételéről szóló útmutatónk elmondja, mit keress.

Mondd el, melyik verzión vagy és nagyjából hány közösségi és egyedi modult használ az oldal, és megmondjuk, a fenti utak közül valójában melyikkel nézel szembe.

Kapcsolódó bejegyzések: Legacy PHP modernizáció: 2026-os útmutató , Symfony vs Laravel 2026: melyik PHP keretrendszer? , API-biztonság: hogyan védj meg egy nyilvános API-t , Orvosi és egészségügyi webfejlesztés az Egyesült .

Gyakran ismételt kérdések

Mikor szűnik meg a Drupal 10 támogatása? A Drupal 10 támogatása 2026. december 9-én ér véget, ugyanazon a héten, amikor a Drupal 12 megjelenik. Azt követően semmilyen kiadást nem kap, biztonsági javítást sem, tehát bármely oldal, amely rajta marad, támogatás nélkül fut.

Mennyibe kerül egy Drupal migráció? A Drupal 10-ről 11-re frissítés jól karbantartott oldalon jellemzően 6000 és 15 000 font között van, elhanyagolt modulok és egyedi kód esetén 15 000 és 35 000 közé emelkedik. A Drupal 7-ről 11-re újraépítés tartalommigrációval, és rendszerint 40 000 és 120 000 font között vagy afölött van.

Miért sokkal drágább a Drupal 7-ről 11-re lépés? Mert nem frissítés. A Drupal 8 Symfony komponenseken építette újra a platformot, lecserélve a modul API-t, a sablonozó réteget és a konfigurációs rendszert. A modulokat cserélni kell, a sablonokat Twigben újraírni, az egyedi kódot újraimplementálni, a tartalmat pedig célra épített migráció hozza át.

Mennyi ideig tart a Drupal 10-ről 11-re frissítés? Két-négy hét olyan oldalnál, amelynek közösségi moduljai naprakészek és egyedi kódja kevés, és négy-nyolc hét ott, ahol elhagyott modulokat vagy eltávolított API-kat kell megkerülni. Az előzetes közösségi modul audit teszi megbízhatóvá a becslést.

Migrálhatok inkább Drupalról WordPressre? Néha ez a helyes döntés, különösen ott, ahol egy Drupal 7-es oldal egyszerű marketingoldallá vált összetett tartalommodellezés, finom jogosultságok és többnyelvű igények nélkül. A döntést a tartalommodellre és a szerkesztői terhelésre alapozd, ne platformpreferenciára.