La migrazione Drupal è uno di quei progetti che resta comodamente nel piano del trimestre successivo finché una data non lo rende urgente. Due date lo stanno facendo adesso, e solo una è ancora nel futuro.

Drupal 7 ha perso il supporto ufficiale il 5 gennaio 2025. Qualsiasi sito che lo esegua ancora sta andando avanti senza copertura di sicurezza da oltre un anno. Drupal 10 arriva a fine vita il 9 dicembre 2026, la stessa settimana in cui esce Drupal 12, dopodiché non riceve più alcuna release. Se sei su una delle due versioni, la domanda non è più se muoversi ma quale strada prendere e quanto costerà.

Dove ti trovi: da Drupal 10 a Drupal 11 è un vero aggiornamento, lo stesso sito aggiornato sul posto, tipicamente da due a sei settimane. Da Drupal 7 a Drupal 11 non è affatto un aggiornamento; è una ricostruzione con una migrazione di contenuti annessa, e richiede tipicamente da tre a sei mesi. Confondere le due cose è l’errore più costoso di questo ambito, perché i siti Drupal 7 vengono quotati come aggiornamenti e poi sforano di un fattore quattro.

Due migrazioni molto diverse

La parola migrazione copre due lavori che non condividono quasi nulla oltre al nome.

Da Drupal 10 a 11 è un aggiornamento. L’architettura è la stessa. Entità, campi, viste e configurazione passano. Il lavoro è soprattutto gestione delle dipendenze: assicurarsi che ogni modulo contribuito abbia una release compatibile con Drupal 11, ripulire le chiamate ad API deprecate dal codice su misura e passare a una versione di PHP supportata. È metodico più che difficile, e un sito ben mantenuto si chiude in una quindicina di giorni.

Da Drupal 7 a Drupal 11 è una ricostruzione. Drupal 8 ha riscritto la piattaforma su componenti Symfony, sostituendo l’API dei moduli, il livello dei temi e il sistema di configurazione. Nulla passa automaticamente tranne i contenuti, e anche questi tramite un processo di migrazione costruito apposta anziché uno script di aggiornamento. I tuoi moduli non esistono più, il tema va riscritto in Twig e il codice su misura va reimplementato su un’architettura diversa.

Quel secondo caso spiega perché i siti Drupal 7 sono rimasti così a lungo. La formulazione onesta è che non stai aggiornando un sito, ne stai costruendo uno nuovo portandoti dietro i contenuti.

Quanto costa ogni percorso di migrazione Drupal

Le cifre qui sotto presuppongono tariffe di agenzia britannica e un sito di complessità moderata. Complessità qui significa numero di tipi di contenuto, moduli contribuiti e moduli su misura, non numero di pagine.

Drupal 10 a 11, sito ben mantenuto. Da due a quattro settimane, all’incirca 6.000-15.000 sterline. È il caso felice: i moduli sono aggiornati, il codice su misura è poco e il grosso del lavoro è il collaudo.

Drupal 10 a 11, sito trascurato. Da quattro a otto settimane, all’incirca 15.000-35.000 sterline. Qui gli ostacoli sono moduli contribuiti senza release per Drupal 11, codice scritto contro API poi rimosse e una versione di PHP che deve anch’essa spostarsi. Ogni modulo abbandonato diventa una decisione: trovare un sostituto, assumerne la manutenzione o reimplementarne il comportamento.

Drupal 7 a Drupal 11. Da tre a sei mesi, comunemente 40.000-120.000 sterline e oltre per siti grandi o molto personalizzati. La forbice è ampia perché in realtà è un budget di ricostruzione. La migrazione dei contenuti è spesso la metà più piccola; tema, funzionalità su misura e integrazioni sono la metà più grande.

Da Drupal 7 a un’altra piattaforma. A volte è la risposta giusta. Se il motivo originario della scelta di Drupal non vale più, perché il sito è diventato un semplice sito vetrina con un blog, allora passare a qualcosa di più semplice può costare meno di una migrazione interna a Drupal e ridurre i costi di esercizio successivi. Il nostro confronto fra WordPress e sviluppo su misura indica dove sta quella linea, e la guida allo sviluppo web con Drupal è onesta su quando Drupal non è la risposta.

Perché i moduli contribuiti decidono i tuoi tempi

Quasi ogni stima di aggiornamento Drupal vive o muore sull’audit dei moduli contribuiti, ed è la prima cosa da fare.

Elenca ogni modulo contribuito usato dal sito, poi verifica per ciascuno l’esistenza di una release stabile compatibile con la versione di destinazione. Quello che troverai ricade in quattro gruppi. Alcuni hanno una release compatibile e non richiedono nulla. Alcuni hanno una release candidate o una patch nella coda delle issue che puoi applicare via Composer. Alcuni sono stati abbandonati, e devi trovare un sostituto, adottare tu il modulo o sostituirne la funzione con codice su misura. E alcuni sono stati assorbiti nel core di Drupal, che è la sorpresa piacevole dell’esercizio.

Quell’audit converte un progetto vago in uno calcolabile. Finché non è fatto, ogni preventivo è una congettura, e un fornitore che ti dà un prezzo fisso senza averlo svolto o sta caricando parecchio o sta per aprire una serie di richieste di variazione.

La stessa logica vale per i moduli su misura, con uno strumento diverso. Gli strumenti di deprecazione di Drupal analizzano il codice su misura e segnalano le chiamate ad API rimosse o in via di rimozione, il che trasforma “abbiamo un po’ di codice su misura” in un elenco preciso di file e numeri di riga.

Cosa va storto davvero

Alcune modalità di guasto ricorrono in quasi ogni migrazione Drupal.

Deriva di configurazione fra ambienti. Se le modifiche sono state fatte direttamente nell’amministrazione di produzione anziché esportate in file di configurazione, il tuo ambiente di staging non è una copia fedele e i tuoi collaudi valgono meno di quanto pensi. Scoprirlo a metà migrazione è comune e costa sempre tempo.

Contenuti mai strutturati quanto tutti credevano. I siti Drupal 7 hanno spesso accumulato contenuti in modi che nessuno ha documentato: campi riutilizzati per altro, un vocabolario di tassonomia che fa il lavoro di uno stato di workflow, HTML incollato nei campi corpo con stili inline. Una migrazione fa emergere tutto insieme, e ogni caso richiede una decisione da qualcuno che sappia a cosa serve quel contenuto.

Gestione di media e file. La gestione dei media in Drupal è cambiata parecchio dopo Drupal 7. File, stili immagine e media incorporati raramente si mappano uno a uno, e i siti con grandi librerie multimediali dovrebbero preventivare questa voce specificamente anziché darla per inclusa nella migrazione dei contenuti.

Continuità di URL e SEO. È il punto che danneggia il business anziché il calendario. Se gli alias URL cambiano senza redirect, perdi il posizionamento che il vecchio sito si era guadagnato. Ogni migrazione richiede un inventario completo degli URL, una mappa dei redirect e una verifica dopo il lancio. La nostra guida su come migrare un sito senza perdere traffico tratta il processo nel dettaglio, e vale per i cambi di piattaforma tanto quanto per i cambi di dominio.

Contenuti multilingue. Se il sito funziona in più lingue, aspettati che la migrazione richieda molto più tempo. La gestione delle lingue è stata ricostruita dopo Drupal 7, e contenuti tradotti, configurazione tradotta e schemi di URL per lingua richiedono ciascuno attenzione propria.

Come sequenziare il lavoro

L’ordine conta più di quanto la maggior parte dei team immagini, e sbagliarlo produce rilavorazioni.

Parti dall’audit dei moduli contribuiti e del codice su misura, prima di qualsiasi stima. Poi porta il sito su una versione di PHP supportata e sull’ultima release della sua versione maggiore attuale, perché questo elimina un’intera categoria di rumore dall’aggiornamento vero e proprio. Solo allora tenta il salto di versione maggiore.

Costruisci il nuovo ambiente accanto al vecchio anziché aggiornare sul posto. Così hai un luogo dove ripetere la migrazione dei contenuti, cosa che ti servirà, perché le migrazioni vengono eseguite molte volte prima di essere eseguite una volta sul serio.

Tratta la migrazione dei contenuti come codice. Il framework di migrazione di Drupal permette di definire le migrazioni in configurazione e rieseguirle, il che significa che puoi azzerare, correggere la mappatura e ripartire. I team che sistemano i contenuti a mano nel nuovo sito anziché correggere la definizione della migrazione finiscono per non poterla più rieseguire, e da lì una singola modifica di contenuto nel vecchio sito diventa una riconciliazione manuale.

Infine, pianifica un blocco dei contenuti verso la fine e tienilo breve. I blocchi lunghi spingono i redattori ad aggirarti, producendo esattamente la deriva che volevi evitare.

Conviene lasciare del tutto Drupal?

È una domanda legittima e merita una risposta onesta anziché difensiva.

Resta su Drupal quando valgono ancora i motivi per cui l’hai scelto: modellazione dei contenuti complessa, permessi granulari, requisiti multilingue, flussi editoriali pesanti, oppure obblighi di accessibilità e di settore pubblico. Drupal resta davvero forte su tutti questi punti e il percorso di aggiornamento è ormai stabile, con un ciclo di versione maggiore prevedibile ogni due anni.

Valuta di spostarti quando il sito si è allontanato da quelle esigenze. Molti siti Drupal 7 sono oggi, di fatto, un sito vetrina con news e un modulo di contatto. Migrare quello all’interno di Drupal significa pagare prezzi da ricostruzione per capacità che non usi più.

La decisione deve poggiare sul modello dei contenuti e sul carico editoriale, non sulla piattaforma che preferisce il tuo sviluppatore. Se nessuno sa articolare cosa stia facendo Drupal per te che una piattaforma più semplice non potrebbe fare, quello è già un dato.

Fai l’audit prima di chiedere un preventivo

Mecanik segue aggiornamenti e migrazioni Drupal nell’ambito dei nostri servizi di sviluppo web . Partiamo dall’audit dei moduli contribuiti e del codice su misura, perché è ciò che trasforma un progetto aperto in un perimetro definito, e vale la pena averlo anche se poi porti il lavoro altrove.

Per i siti Drupal 10 la mossa sensata è pianificare il passaggio a Drupal 11 adesso anziché a novembre, quando lo faranno tutti. Per i siti Drupal 7 la posizione di sicurezza è già di per sé l’argomento. Se il vincolo è la capacità anziché la competenza, la nostra guida su come assumere uno sviluppatore Drupal spiega cosa cercare.

Dicci su quale versione sei e all’incirca quanti moduli contribuiti e su misura usa il sito, e ti diremo quale dei percorsi sopra stai realmente affrontando.

Post correlati: Modernizzazione PHP legacy: guida 2026 , Symfony vs Laravel nel 2026: quale framework PHP? , Sicurezza delle API: proteggere un’API pubblica , Sviluppo di siti web medici e sanitari nel Regno Unito 2026 .

Domande frequenti

Quando termina il supporto per Drupal 10? Drupal 10 arriva a fine vita il 9 dicembre 2026, la stessa settimana in cui esce Drupal 12. Dopo quella data non riceve più alcuna release, comprese le correzioni di sicurezza, quindi qualsiasi sito che vi resti sta girando senza supporto.

Quanto costa una migrazione Drupal? Un aggiornamento da Drupal 10 a 11 su un sito ben mantenuto costa tipicamente 6.000-15.000 sterline, che salgono a 15.000-35.000 dove moduli e codice su misura sono trascurati. Da Drupal 7 a Drupal 11 è una ricostruzione con migrazione dei contenuti e va comunemente dai 40.000 ai 120.000 sterline o più.

Perché da Drupal 7 a Drupal 11 costa tanto di più? Perché non è un aggiornamento. Drupal 8 ha ricostruito la piattaforma su componenti Symfony, sostituendo l’API dei moduli, il livello dei temi e il sistema di configurazione. I moduli vanno sostituiti, i temi riscritti in Twig e il codice su misura reimplementato, con i contenuti portati tramite una migrazione costruita apposta.

Quanto dura un aggiornamento da Drupal 10 a 11? Da due a quattro settimane per un sito con moduli contribuiti aggiornati e poco codice su misura, e da quattro a otto settimane dove occorre aggirare moduli abbandonati o API rimosse. È l’audit dei moduli contribuiti a monte a rendere affidabile la stima.

Posso migrare da Drupal a WordPress invece? A volte è la scelta giusta, in particolare quando un sito Drupal 7 è diventato un semplice sito vetrina senza modellazione complessa dei contenuti, permessi granulari o esigenze multilingue. Basa la decisione sul tuo modello di contenuti e sul carico editoriale anziché sulla preferenza di piattaforma.