Migrarea Drupal este unul dintre acele proiecte care stau confortabil în planul trimestrului următor până când o dată le face urgente. Două date fac exact asta chiar acum, iar doar una dintre ele este încă în viitor.

Drupal 7 și-a pierdut suportul oficial pe 5 ianuarie 2025. Orice site care încă îl rulează funcționează de peste un an fără acoperire de securitate. Drupal 10 ajunge la sfârșitul vieții pe 9 decembrie 2026, în aceeași săptămână în care apare Drupal 12, după care nu mai primește nicio versiune, de niciun fel. Dacă sunteți pe una dintre aceste versiuni, întrebarea nu mai este dacă vă mutați, ci pe ce drum o luați și cât vă costă.

Unde vă aflați: de la Drupal 10 la Drupal 11 este o actualizare adevărată, același site adus la zi pe loc, de regulă în două până la șase săptămâni. De la Drupal 7 la Drupal 11 nu este deloc o actualizare; este o reconstrucție cu o migrare de conținut atașată și durează de obicei între trei și șase luni. Confuzia dintre cele două este cea mai scumpă greșeală din acest domeniu, pentru că site-urile Drupal 7 primesc ofertă ca pentru o actualizare și apoi depășesc bugetul de patru ori.

Două migrări foarte diferite

Cuvântul migrare acoperă două lucrări care nu au aproape nimic în comun în afară de nume.

De la Drupal 10 la 11 este o actualizare. Arhitectura rămâne aceeași. Entitățile, câmpurile, vizualizările și configurația trec mai departe. Munca ține în principal de gestionarea dependențelor: să vă asigurați că fiecare modul contribuit are o versiune compatibilă cu Drupal 11, să scoateți din codul propriu apelurile către interfețe marcate ca depășite și să treceți pe o versiune de PHP încă susținută. Este mai degrabă metodic decât dificil, iar un site bine întreținut se rezolvă în vreo două săptămâni.

De la Drupal 7 la Drupal 11 este o reconstrucție. Drupal 8 a rescris platforma pe componente Symfony, înlocuind interfața pentru module, stratul de teme și sistemul de configurație. Nimic nu trece automat în afară de conținut, iar și acela ajunge dincolo printr-un proces de migrare construit special, nu printr-un script de actualizare. Modulele dumneavoastră nu mai există, tema trebuie rescrisă în Twig, iar codul propriu trebuie reimplementat peste o arhitectură diferită.

Al doilea caz explică de ce site-urile Drupal 7 au rămas atât de mult pe loc. Formularea onestă este că nu actualizați un site, ci construiți unul nou și luați conținutul cu dumneavoastră.

Cât costă fiecare traseu de migrare Drupal

Cifrele de mai jos presupun tarife de agenție din Marea Britanie și un site de complexitate moderată. Complexitate înseamnă aici numărul de tipuri de conținut, de module contribuite și de module proprii, nu numărul de pagini.

Drupal 10 la 11, site bine întreținut. Două până la patru săptămâni, aproximativ 6.000 până la 15.000 de lire. Acesta este cazul fericit: modulele sunt la zi, codul propriu este puțin, iar grosul muncii este testarea.

Drupal 10 la 11, site neglijat. Patru până la opt săptămâni, aproximativ 15.000 până la 35.000 de lire. Aici blocajele sunt module contribuite fără versiune pentru Drupal 11, cod scris pentru interfețe care între timp au fost scoase și o versiune de PHP care trebuie și ea urcată. Fiecare modul abandonat devine o decizie: găsiți un înlocuitor, preluați dumneavoastră mentenanța sau reimplementați comportamentul lui.

Drupal 7 la Drupal 11. Trei până la șase luni, de obicei 40.000 până la 120.000 de lire și mai mult pentru site-uri mari sau puternic personalizate. Intervalul este larg pentru că este, de fapt, un buget de reconstrucție. Migrarea conținutului este adesea jumătatea mai mică; tema, funcționalitatea proprie și integrările formează jumătatea mai mare.

De la Drupal 7 către altă platformă. Uneori este răspunsul corect. Dacă motivul inițial pentru care ați ales Drupal nu se mai aplică, pentru că site-ul a devenit între timp o prezență de marketing cu un blog, atunci mutarea către ceva mai simplu poate costa mai puțin decât o migrare în interiorul Drupal și scade și costurile de întreținere ulterioare. Comparația noastră între WordPress și dezvoltarea la comandă arată unde trece linia, iar ghidul de dezvoltare web cu Drupal spune cinstit când Drupal nu este răspunsul.

De ce modulele contribuite vă decid calendarul

Aproape orice estimare de actualizare Drupal trăiește sau moare pe inventarul modulelor contribuite, iar acesta este primul lucru care merită făcut.

Listați fiecare modul contribuit folosit de site, apoi verificați pentru fiecare dacă există o versiune stabilă compatibilă cu versiunea țintă. Ce veți găsi se împarte în patru grupe. Unele au o versiune compatibilă și nu cer nimic. Unele au o versiune candidat sau un petic în coada de tichete, pe care îl puteți aplica prin Composer. Unele au fost abandonate, iar aici trebuie să găsiți un înlocuitor, să adoptați dumneavoastră modulul sau să îi înlocuiți funcția cu cod propriu. Iar unele au fost absorbite în nucleul Drupal, ceea ce este surpriza plăcută a exercițiului.

Inventarul acesta transformă un proiect vag într-unul care se poate număra. Până nu este făcut, orice ofertă este o presupunere, iar un furnizor care vă dă preț fix fără el fie a încărcat serios marja, fie se pregătește să vină cu cereri de modificare.

Aceeași logică se aplică și modulelor proprii, cu o unealtă diferită. Instrumentele Drupal pentru cod depășit scanează codul propriu și raportează apelurile către interfețe scoase deja sau programate pentru scoatere, ceea ce transformă un vag avem ceva cod propriu într-o listă precisă de fișiere și numere de linie.

Ce se strică în practică

Anumite moduri de eșec revin în aproape fiecare migrare Drupal.

Devierea configurației între medii. Dacă modificările au fost făcute direct în interfața de administrare de producție în loc să fie exportate în fișiere de configurație, mediul de testare nu este o copie fidelă, iar testele valorează mai puțin decât credeți. Descoperirea acestui lucru la mijlocul migrării este obișnuită și costă întotdeauna timp.

Conținut care nu a fost niciodată atât de structurat pe cât credea toată lumea. Site-urile Drupal 7 au acumulat frecvent conținut în feluri pe care nu le-a documentat nimeni: câmpuri folosite pentru cu totul altceva, un vocabular de taxonomie care ține locul unei stări de flux editorial, HTML lipit în câmpurile de corp cu stiluri inline cu tot. O migrare scoate totul la suprafață dintr-odată, iar fiecare caz cere o decizie de la cineva care știe la ce servește conținutul respectiv.

Gestionarea fișierelor și a media. Modul în care Drupal tratează fișierele media s-a schimbat considerabil după Drupal 7. Fișierele, stilurile de imagine și media încorporată rareori se potrivesc unu la unu, iar site-urile cu biblioteci mari de imagini ar trebui să bugeteze special acest capitol, nu să presupună că vine gratuit odată cu conținutul.

Continuitatea adreselor și a poziționării în căutare. Acesta este punctul care lovește afacerea, nu calendarul. Dacă aliasurile de adresă se schimbă fără redirecționări, pierdeți pozițiile pe care vechiul site le-a câștigat. Fiecare migrare are nevoie de un inventar complet de adrese, o hartă de redirecționări și o verificare după lansare. Ghidul nostru despre mutarea unui site fără pierderea traficului tratează procesul în detaliu și se aplică schimbărilor de platformă la fel de bine ca schimbărilor de domeniu.

Conținut multilingv. Dacă site-ul funcționează în mai multe limbi, așteptați-vă ca migrarea să dureze considerabil mai mult. Tratarea limbilor a fost reconstruită după Drupal 7, iar conținutul tradus, configurația tradusă și tiparele de adrese pe limbă cer fiecare atenție separată.

Cum să ordonați lucrările

Ordinea contează mai mult decât se așteaptă majoritatea echipelor, iar greșirea ei produce muncă refăcută.

Începeți cu inventarul modulelor contribuite și al codului propriu, înaintea oricărei estimări. Apoi duceți site-ul pe o versiune de PHP susținută și pe ultima versiune a ramurii majore actuale, pentru că asta scoate o categorie întreagă de zgomot din actualizarea propriu-zisă. Abia după aceea încercați pasul de versiune majoră.

Construiți noul mediu alături de cel vechi, în loc să actualizați pe loc. Așa aveți unde să repetați migrarea conținutului, ceea ce vă va trebui, pentru că migrările se execută de multe ori înainte să fie executate o dată la adevărat.

Tratați migrarea conținutului ca pe cod. Cadrul de migrare din Drupal vă lasă să definiți migrările în configurație și să le rulați din nou, ceea ce înseamnă că puteți reseta, ajusta corespondențele și porni iarăși. Echipele care repară conținutul de mână în site-ul nou în loc să repare definiția migrării ajung să nu o mai poată rula, iar de acolo o singură modificare de conținut în site-ul vechi devine o reconciliere manuală.

În fine, planificați o înghețare a conținutului spre final și țineți-o scurtă. Înghețările lungi îi împing pe redactori să vă ocolească, ceea ce produce exact devierea pe care încercați să o evitați.

Ar trebui să părăsiți complet Drupal?

Este o întrebare legitimă și merită un răspuns onest, nu unul defensiv.

Rămâneți pe Drupal atunci când motivele pentru care l-ați ales încă țin: modelare complexă a conținutului, permisiuni fine, cerințe multilingve, flux editorial greu sau obligații de accesibilitate și de sector public. Drupal rămâne cu adevărat puternic la toate acestea, iar drumul de actualizare de aici încolo este stabil, cu un ciclu previzibil de versiune majoră la doi ani.

Luați în calcul mutarea atunci când site-ul s-a îndepărtat de acele nevoi. Multe site-uri Drupal 7 sunt astăzi, în practică, o prezență de marketing cu știri și un formular de contact. Migrarea a ceva de genul acesta în interiorul Drupal înseamnă să plătiți prețuri de reconstrucție pentru capacități pe care nu le mai folosiți.

Decizia ar trebui să depindă de modelul de conținut și de volumul editorial, nu de platforma preferată de dezvoltatorul dumneavoastră. Dacă nimeni nu poate articula ce face Drupal pentru dumneavoastră și o platformă mai simplă nu ar putea face, asta spune deja destul.

Faceți inventarul înainte de a cere ofertă

Mecanik se ocupă de actualizări și migrări Drupal ca parte din serviciile noastre de dezvoltare web . Începem cu inventarul modulelor contribuite și al codului propriu, pentru că el transformă un proiect deschis într-un domeniu de lucru fix, și merită avut chiar dacă apoi duceți lucrarea în altă parte.

Pentru site-urile Drupal 10 mișcarea rezonabilă este să planificați pasul către Drupal 11 acum, nu în noiembrie, când o va face toată lumea. Pentru site-urile Drupal 7 situația de securitate este deja argumentul. Dacă limita dumneavoastră este capacitatea, nu priceperea, ghidul nostru despre angajarea unui dezvoltator Drupal explică la ce să vă uitați.

Spuneți-ne pe ce versiune sunteți și cam câte module contribuite și proprii folosește site-ul, iar noi vă spunem cu care dintre traseele de mai sus aveți de-a face în realitate.

Articole similare: Modernizare PHP legacy: ghid 2026 , Symfony vs Laravel în 2026: ce framework PHP alegi , Securitatea API: cum protejezi un API public , Dezvoltarea site-urilor medicale și de sănătate în Regatul .

Întrebări frecvente

Când se încheie suportul pentru Drupal 10? Drupal 10 ajunge la sfârșitul vieții pe 9 decembrie 2026, în aceeași săptămână în care apare Drupal 12. După acea dată nu mai primește nicio versiune, inclusiv corecții de securitate. Orice site rămas pe el rulează, practic, fără suport.

Cât costă o migrare Drupal? O actualizare de la Drupal 10 la 11 pe un site bine întreținut costă de regulă între 6.000 și 15.000 de lire. Suma urcă la 15.000 până la 35.000 de lire acolo unde modulele și codul propriu au fost neglijate. De la Drupal 7 la Drupal 11 este o reconstrucție cu migrare de conținut și ajunge frecvent la 40.000 până la 120.000 de lire sau mai mult.

De ce este atât de scump de la Drupal 7 la Drupal 11? Pentru că nu este o actualizare. Drupal 8 a reconstruit platforma pe componente Symfony, înlocuind interfața pentru module, stratul de teme și sistemul de configurație. Modulele trebuie înlocuite, temele rescrise în Twig și codul propriu reimplementat, iar conținutul este adus printr-un proces de migrare construit special.

Cât durează o actualizare de la Drupal 10 la 11? Două până la patru săptămâni pentru un site ale cărui module contribuite sunt la zi și al cărui cod propriu este puțin. Ajunge la patru până la opt săptămâni acolo unde trebuie ocolite module abandonate sau interfețe scoase. Inventarul modulelor contribuite făcut la început este cel care face estimarea de încredere.

Pot migra de la Drupal la WordPress în loc? Uneori aceasta este alegerea corectă, în special când un site Drupal 7 a devenit o simplă prezență de marketing, fără modelare complexă a conținutului, fără permisiuni fine și fără nevoi multilingve. Bazați decizia pe modelul de conținut și pe volumul editorial, nu pe preferința de platformă.