Drupal 12: Che Cosa Cambia E Quando Spostarsi

Drupal 12 è previsto per la settimana del 7 dicembre 2026, e Drupal 10 raggiunge la fine del supporto il 9 dicembre 2026. Le due date stanno sulla stessa pagina del calendario dei rilasci del core di Drupal, a due righe di distanza, e quasi nessuno di chi gestisce un sito Drupal 10 le ha notate. La prima alpha della nuova major è stata taggata il 2 settembre 2026, quindi la forma del rilascio è ormai un fatto documentato e non una previsione.

Questa collisione è tutta la storia. L’arrivo di una major di solito non è urgente per chi gestisce un sito, perché si può restare un anno o due sulla major precedente mentre l’ecosistema recupera. Stavolta la major precedente smette di ricevere avvisi di sicurezza nella stessa settimana in cui esce quella nuova, e questo trasforma un evento tecnico in una scadenza con un risvolto di conformità.

Qui trovate il calendario così come lo pubblica drupal.org, che cosa cambia davvero nel codice, che cosa impongono all’hosting i nuovi requisiti minimi, i tre percorsi di aggiornamento realistici con le fasce di costo e un piano costruito a ritroso da dicembre. La parte rassicurante arriva subito: il salto di major in Drupal è soprattutto cancellazione, non reinvenzione.

Quando esce Drupal 12 e sono obbligato a spostarmi? Drupal 12.0.0 è previsto per la settimana del 7 dicembre 2026, rilasciato insieme a Drupal 11.5.0. Drupal 10 raggiunge la fine del supporto due giorni dopo, il 9 dicembre 2026, e da quel momento non viene emesso più alcun avviso di sicurezza. Un sito Drupal 11 ha davanti un aggiornamento piccolo. Un sito Drupal 10 deve prima passare da Drupal 11.4 o successiva, quindi il lavoro sono due salti e non uno.

Le due date che decidono i vostri prossimi sei mesi

I release manager pubblicano l’intero ciclo in anticipo, e quello attuale è insolitamente ordinato. Drupal 11.4.0 è uscito nella settimana del 29 giugno 2026, e quel rilascio ha chiuso il supporto di sicurezza sia per Drupal 11.2.x sia per Drupal 10.5.x. Il tag 12.0.0-alpha1 è partito il 2 settembre 2026. I requisiti per la beta dovevano essere completi entro l'11 settembre 2026, con 12.0.0-beta1 e 11.5.0-beta1 nella settimana del 14 settembre e le release candidate nella settimana del 9 novembre.

Poi la settimana del 7 dicembre fa tre cose insieme. Esce Drupal 12.0.0, esce accanto Drupal 11.5.0, e finisce il supporto di sicurezza per Drupal 11.3.x e Drupal 10.6.x. Due giorni dopo, il 9 dicembre 2026, Drupal 10 nel suo complesso raggiunge la fine del supporto e non ne verrà pubblicato più alcun rilascio.

Perché Drupal 10 e Drupal 12 arrivano nella stessa settimana

Questa è una politica, non una coincidenza. La panoramica del processo di rilascio stabilisce che le versioni major arrivano ogni due anni negli anni pari e che ogni major è supportata per almeno quattro anni, finché non sono uscite altre due major. Drupal 10.0.0 è uscito il 15 dicembre 2022. Drupal 11 è arrivato ad agosto 2024 e Drupal 12 arriva a dicembre 2026, che è la seconda major successiva, e nel frattempo sono passati quattro anni. Il conto alla rovescia è scaduto esattamente come previsto.

La stessa politica governa le minor. Ogni versione minor è supportata per un anno, con correzioni di bug e di sicurezza nei primi sei mesi e solo correzioni di sicurezza negli ultimi sei. Per questo oggi soltanto la 10.6.x riceve ancora avvisi, e per questo la 11.3.x perde la copertura nel momento in cui esce la 11.5.0.

Drupal 11 non si ferma quando comincia Drupal 12. Rilasciare la 11.5.0 nella stessa settimana avvia quella che la politica chiama fase di supporto a lungo termine: la major precedente mantiene una minor allineata alla stessa API, passa a un rilascio LTS di Symfony e riceve una minor di manutenzione ogni sei mesi, con un perimetro sempre più ridotto. Drupal.org non pubblica una data ferma di fine supporto per Drupal 11, ma la sua documentazione sulle estensioni deprecate indica un supporto fino alla metà o alla fine del 2028.

Quanti siti sono ancora fermi su Drupal 10

I numeri sono pubblici e non sono comodi. Le statistiche d’uso del core di drupal.org per la settimana che inizia il 23 agosto 2026 registrano 468.877 siti che dichiarano una versione del core. Di questi, 205.568 sono su un ramo qualsiasi di Drupal 10 e 168.857 su Drupal 11. Circa il 44 per cento della base installata che si dichiara usa la versione che a dicembre smette di ricevere avvisi.

Il numero più tagliente sta dentro quella cifra. Solo la 10.6.x ha ancora copertura di sicurezza, e la 10.6.x vale 139.911 di quei siti. I restanti 65.657 stanno su versioni dalla 10.0 alla 10.5, quindi girano già oggi, a settembre, su una minor non supportata, senza aspettare dicembre.

Questi conteggi arrivano da siti che si dichiarano volontariamente tramite il modulo Update Status, quindi la popolazione reale è più grande e pende nella stessa direzione. La lettura pratica è che moltissime organizzazioni proveranno a prenotare lo stesso lavoro nello stesso trimestre, e la capacità delle agenzie a ottobre e novembre sarà il vincolo, più del codice.

Che cosa significa davvero la fine del supporto per un sito Drupal

La fine del supporto non è un interruttore che rompe il sito. La vostra installazione Drupal 10 servirà pagine il 10 dicembre esattamente come l'8 dicembre. Quel che cambia è che il team di sicurezza di Drupal smette di pubblicare avvisi e patch per quel codice, quindi da quella data ogni vulnerabilità scoperta nel core di Drupal 10 resta aperta per sempre.

Il secondo effetto è più lento e fa più danni. La copertura di sicurezza di un modulo contribuito dipende dal fatto che il modulo abbia un rilascio stabile su un ramo del core supportato, quindi man mano che i manutentori abbandonano la compatibilità con Drupal 10, anche i moduli del vostro sito escono in silenzio dal processo degli avvisi. Nessuno vi avvisa quando succede. Semplicemente il modulo smette di comparire nei rilasci di sicurezza, e il rapporto degli aggiornamenti disponibili sul vostro sito continua a sembrare verde.

Il terzo effetto è che l’uscita diventa più cara quanto più aspettate. Un sito Drupal 10 aggiornato a novembre viene aggiornato contro un ramo del core mantenuto, con un percorso di aggiornamento funzionante. Lo stesso sito aggiornato a giugno dell’anno dopo è un progetto di recupero, perché i moduli contribuiti da cui dipende hanno avuto altri sei mesi per andare avanti senza di lui.

Cyber Essentials, assicurazioni e clausole contrattuali

Qui un CMS non supportato smette di essere una faccenda tecnica. I requisiti Cyber Essentials per l’infrastruttura IT v3.3 del NCSC, datati aprile 2026, stabiliscono che tutto il software presente sui dispositivi in perimetro deve essere licenziato e supportato, e deve essere rimosso dai dispositivi quando smette di essere supportato, oppure tolto dal perimetro tramite un sottoinsieme definito che blocchi ogni traffico da e verso Internet. Il controllo si applica a server, IaaS, PaaS e SaaS, quindi un’installazione Drupal su un server in perimetro rientra pienamente.

Un sito Drupal 10 pubblico non può essere isolato da Internet, quindi dopo il 9 dicembre 2026 le due risposte disponibili sono aggiornarlo oppure accettare che non superi quel controllo. Se la vostra organizzazione ha Cyber Essentials o Cyber Essentials Plus e lo rinnova ogni anno, è una domanda che vi verrà posta per iscritto alla prossima valutazione.

Attenzione a che cosa affermate oltre a questo. Se una specifica polizza cyber o un contratto con un cliente sia toccato dipende interamente dalla sua formulazione, e le clausole che contano di solito richiedono software supportato o versioni mantenute dal fornitore, invece di nominare Drupal. Leggete la vostra polizza e i vostri contratti quadro prima di dicembre e non dopo un incidente, perché quello è il momento economico per scoprirlo.

Che cosa cambia davvero in Drupal 12

Molto poco, e questa è la risposta onesta e utile. Le note di rilascio della 12.0.0-alpha1 lo dicono chiaramente: la 12.0.x sarà quasi identica alla 11.5.x, tranne per il fatto che il codice deprecato viene rimosso, inclusi interi moduli deprecati, che le dipendenze passano a nuove versioni major e che i requisiti di sistema salgono. Per ogni altra modifica, le note vi rimandano al ramo 11.5.x.

Ci sono alcuni veri cambiamenti di comportamento che vale la pena conoscere. L’algoritmo predefinito di hashing delle password passa ad argon2id, con bcrypt disponibile tramite i parametri del kernel dove argon2 manca. Il robots.txt del core ora blocca le pagine dei risultati di ricerca che portano parametri di query, cosa che impedisce ai motori di scansionare combinazioni sfaccettate infinite, e i siti con un robots.txt personalizzato devono aggiungere quelle regole a mano. HTMX, che il core già include, passa dalla versione 2 alla versione 4 per la beta1.

Ce n’è un altro facile da perdere. Ospitare Drupal direttamente su Windows in produzione è deprecato in Drupal 12, sul presupposto che non esista un ambiente di test Windows automatizzato e che pochi sviluppatori ci provino. Windows resta supportato per lo sviluppo locale. Se avete la produzione su Windows, è una decisione di hosting da prendere nei prossimi mesi, non una modifica al codice.

Le estensioni che escono dal core

Drupal sposta da anni i moduli più stretti fuori dal core verso progetti contribuiti, e Drupal 12 prosegue su quella strada. Le note della alpha1 elencano come rimossi Ban, Contact, Field Layout, History, Settings Tray, Shortcut e Telephone, insieme al tema Stable 9. Anche il plugin di campo Text with Summary si è spostato in un modulo contribuito a sé. Ban era stato deprecato già nella 11.3, Contact, Field Layout, History e Telephone nella 11.4, e Settings Tray, Shortcut e Text with Summary nella 11.5.

Due di questi sorprenderanno. Shortcut e Settings Tray sono funzioni amministrative che moltissimi team editoriali usano ogni giorno senza pensarle come opzionali, e Settings Tray in particolare regge la configurazione dei blocchi in pagina su cui i redattori contano.

La meccanica di come si gestisce la cosa conta più dell’elenco. La mossa corretta è aggiungere la versione contribuita ai requisiti Composer prima di aggiornare, non disinstallare il modulo. Disinstallare distrugge la configurazione dell’estensione, e la scoperta dei moduli in Drupal guarda nel core per ultimo, quindi appena il progetto contribuito è presente Drupal usa semplicemente quello. Notate anche che Drush può aggirare gli avvisi di update.php sulle estensioni mancanti, per cui il problema emerge dopo, come errori nel rapporto di stato.

Perdere Migrate Drupal è il cambiamento che pesa di più

I moduli Migrate Drupal e Migrate Drupal UI vengono rimossi in Drupal 12 e, a differenza degli altri, non vengono spostati in un progetto contribuito. Drupal 12 mantiene l’API Migrate e i plugin di destinazione per il Drupal moderno, ma non mantiene i plugin sorgente per Drupal 6 e Drupal 7.

Rileggete la frase se avete un sito Drupal 7. Lo strumento che legge un database Drupal vecchio e lo scrive in uno moderno esiste in Drupal 11 e non esiste in Drupal 12. L’indicazione di drupal.org è esplicita: i siti su Drupal 6 o Drupal 7 che intendono usare l’API di migrazione devono continuare a migrare verso Drupal 11, e poi usare il normale processo di aggiornamento per passare da Drupal 11 a Drupal 12.

Questo trasforma un’intenzione vaga in un vincolo di sequenza rigido. Una ricostruzione Drupal 7 che atterri dopo la fine del supporto di Drupal 11 dovrà o scriversi i propri plugin sorgente, o ripristinare un core più vecchio per eseguire la migrazione in un ambiente usa e getta, o esportare e reimportare i contenuti per altre vie. Tutte e tre costano più che fare la migrazione verso Drupal 11 finché Drupal 11 è un obiettivo attuale e mantenuto. La nostra guida a costi, opzioni e scadenze di una migrazione Drupal descrive in dettaglio la forma di quel lavoro.

I nuovi requisiti minimi delle dipendenze

Una versione major è il punto in cui a Drupal è concesso alzare i requisiti di piattaforma, e Drupal 12 usa quella concessione su tutta la linea. Questi minimi sono la parte dell’aggiornamento su cui non si tratta, perché vengono imposti al momento dell’installazione.

PHP 8.5, e nulla di più vecchio

Drupal 12 richiede PHP 8.5. La tabella dei requisiti PHP mostra Drupal 12.0 che supporta PHP 8.5 e rifiuta tutto ciò che sta sotto, mentre Drupal 11.3 e 11.4 accettano 8.3, 8.4 e 8.5. Quella sovrapposizione è la vostra rotta di migrazione: portate il sito a PHP 8.5 mentre è ancora su Drupal 11.4, verificate che si comporti bene, e solo dopo cambiate versione di Drupal.

Il requisito è generoso, non punitivo. PHP 8.5 è uscito il 20 novembre 2025, e la pagina delle versioni supportate su php.net fissa il supporto attivo al 31 dicembre 2027 e quello di sicurezza al 31 dicembre 2029. Atterrare lì compra tre anni prima che questa conversazione torni.

Database e Symfony

I requisiti del server di database per Drupal 12 sono MySQL 8.0 o successiva, MariaDB 10.11 o successiva, PostgreSQL 18 o successiva, e SQLite 3.45 con l’estensione json1. I siti PostgreSQL dovrebbero verificare quel minimo con particolare cura, perché le note della alpha1 dicono PostgreSQL 19 mentre la pagina dei requisiti e il codice dell’installer dicono entrambi 18. Ricontrollate alla beta1 prima di prenotare lavoro sul database.

Sotto il cofano, Symfony passa da 7.4 a 8.1 e Guzzle da 7 a 8. Viene tolto il supporto a diverse major più vecchie di librerie, fra cui doctrine/lexer 2, egulias/email-validator 3 e guzzlehttp/psr7 2. Il codice su misura che tipizza direttamente classi Symfony è il punto in cui questo si vede.

Che cosa impongono i requisiti minimi al vostro hosting

Il salto di MariaDB è quello che coglie impreparati gli hosting condivisi e gestiti. Drupal 11 accetta MariaDB 10.6, la cui manutenzione della community si è chiusa il 6 luglio 2026 secondo la politica di manutenzione di MariaDB, quindi un sito Drupal 11 può oggi stare del tutto legittimamente su un motore di database non supportato. Drupal 12 alza il minimo a 10.11, che è mantenuta fino al 16 febbraio 2028. Se il vostro hosting non offre già oggi PHP 8.5 e MariaDB 10.11, il trasloco deve avvenire prima del cambio di Drupal, e quel riordino è ciò che trasforma un lavoro di due settimane in uno di due mesi. La nostra nota su che cosa fa girare bene Drupal copre il lato piattaforma.

Perché il modello di deprecazione rende Drupal 12 gestibile

Ecco il meccanismo che a quasi nessun proprietario di sito è mai stato spiegato, ed è la ragione per cui le major di Drupal non fanno più paura. La politica sugli aggiornamenti continui impegna il core su una promessa semplice: la prossima versione major ha la stessa API pubblica dell’ultima minor della major precedente. Le API nuove si aggiungono nelle minor, quelle vecchie vengono segnate come deprecate nelle minor, e la cancellazione avviene solo al confine di major.

La conseguenza pratica merita di essere detta in chiaro. Se il vostro codice su misura e i vostri moduli contribuiti girano su Drupal 11.5 senza avvisi di deprecazione, girano su Drupal 12. L’aggiornamento smette di essere una riscrittura e diventa un innalzamento di dipendenze più un aggiornamento del database, perché tutto ciò che si sarebbe rotto vi era già stato segnalato mesi prima come un avviso che potevate sistemare con calma.

È anche il motivo per cui le note di rilascio dicono di aggiornare prima alla 11.4 o successiva, e raccomandano con forza la 11.5. Il percorso di aggiornamento del database dai rilasci precedenti alla 11.4.0 è stato tolto del tutto da Drupal 12, quindi un sito sulla 11.3 o precedente non ha alcuna via verso la 12 finché non risale il ramo 11. Non è un consiglio, è un percorso di codice che non esiste.

Gli strumenti che segnalano le deprecazioni

Due progetti fanno il lavoro, ed entrambi sono mantenuti oggi. Upgrade Status è lo scanner che copre tutto il sito. Lo installate sul sito da cui state aggiornando, non su quello verso cui aggiornate, perché le API deprecate devono esistere perché lo strumento possa trovarne le chiamate. Verifica se il vostro ambiente soddisfa i requisiti di sistema della prossima major, incrocia i vostri progetti contribuiti con gli aggiornamenti disponibili, esegue PHPStan per l’uso di API PHP deprecate, e legge i template Twig, i file info.yml, composer.json e le chiavi di configurazione deprecate. Il rilascio 5.0.0-alpha3, del 2 luglio 2026, dichiara compatibilità con Drupal 10.4, 11 e 12.

Classifica anche ciò che trova, ed è la parte che fa risparmiare denaro. I problemi vengono divisi fra quelli che una macchina può correggere e quelli che richiedono una persona, così potete valutare la metà manuale prima di impegnarvi su una data. Gira sotto Drush come upgrade_status:analyze, e il suo output JSON in formato Code Climate si innesta in GitLab CI.

Drupal Rector è l’altra metà. Riscrive le deprecazioni correggibili meccanicamente nei vostri moduli e temi su misura, con l’opzione --dry-run per vedere prima il diff. La versione 1.1.2 è uscita il 7 agosto 2026. Con i due insieme, uno sviluppatore competente produce una relazione di prontezza difendibile per un sito di media dimensione in due o tre giorni.

Percorso uno: da Drupal 11 a Drupal 12

Se siete su Drupal 11.4 o 11.5 con moduli contribuiti aggiornati, è un lavoro piccolo. La guida ufficiale all’aggiornamento è quasi tutta comandi Composer: richiedere i metapacchetti della versione 12 con --no-update, togliere ogni requisito esplicito di drupal/core, lanciare composer update --dry-run, poi eseguirlo sul serio e applicare gli aggiornamenti del database con drush updatedb.

Il lavoro vero sta ai due lati. Prima: eseguire Upgrade Status, aggiungere i sostituti contribuiti di ogni estensione del core rimossa che usate davvero, e confermare che l’hosting offra PHP 8.5. Dopo: aspettatevi che ogni file di scaffold del core sia cambiato, .htaccess compreso, quindi ogni personalizzazione fatta su quei file va riapplicata con intenzione invece che unita alla cieca.

Quando una dipendenza si rifiuta di risolversi, composer why-not drupal/core ^12 nomina il blocco. Permettere due major di un modulo in composer.json, per esempio "^6.1 || ^7.0", è il modo standard per fare da ponte a un progetto in mezzo alla transizione. Se vi serve un modulo che ha una patch funzionante ma nessun rilascio taggato, l’endpoint Composer Drupal Lenient esiste esattamente per questo ed è ancora mantenuto.

Percorso due: da Drupal 10 a Drupal 12 sono due salti

Non esiste un aggiornamento diretto da Drupal 10 a Drupal 12. La documentazione di Upgrade Status lo dice esplicitamente, e la rimozione del percorso di aggiornamento del database precedente alla 11.4 lo impone. Si va da Drupal 10.6 a Drupal 11.4 o 11.5, si verifica il sito, e da lì si va a Drupal 12.

Pianificato bene, non è il doppio del lavoro. Il salto da Drupal 10 a Drupal 11 porta quasi tutto il rischio, perché è lì che vivono i problemi di compatibilità dei moduli contribuiti ed è lì che il codice su misura incontra le API rimosse. Il secondo salto è quello piccolo descritto sopra. I team che provano a comprimere entrambi in un’unica finestra di cambiamento di solito non riescono più a dire quale dei due ha rotto qualcosa.

La sequenza che funziona è fare il salto a Drupal 11 adesso, tenere il sito su 11.4 o 11.5 per diverse settimane in modo che il comportamento reale di redazione e traffico faccia emergere le stranezze, e prendere Drupal 12 nel nuovo anno, una volta che i moduli contribuiti avranno taggato rilasci stabili. Che il primo salto avvenga prima di dicembre è ciò che conta, perché è il salto che vi toglie da codice non supportato.

Percorso tre: Drupal 7 o 8 è una ricostruzione, non un aggiornamento

Tutto ciò che è più vecchio di Drupal 9 è un esercizio diverso. Drupal 7 ha raggiunto la fine del supporto il 5 gennaio 2025 e Drupal 6 a febbraio 2016. Nessuno dei due si aggiorna sul posto, perché precedono del tutto l’architettura moderna. Si migrano, cioè si costruisce un sito nuovo su Drupal attuale e i contenuti vi vengono spostati con l’API Migrate. Un sito Drupal 8 tecnicamente ha una via sul posto, ma passa per quattro major consecutive e ogni modulo contribuito deve sopravvivere a ciascuna, quindi di norma conviene trattare anche quello come una ricostruzione.

Il costo è dominato da tutto ciò che non è contenuto. Il tema viene ricostruito, i moduli su misura vengono riscritti contro un’API completamente diversa, e le integrazioni vengono ricollegate. Per nostra esperienza la migrazione dei contenuti in sé è di solito la metà più piccola del budget, che è l’opposto di quel che si aspetta chi chiede un preventivo, ed è la ragione per cui inquadriamo questi progetti come sviluppo di siti web e non come aggiornamenti.

Per questi siti la scadenza di dicembre agisce diversamente ma morde comunque, per via della rimozione di Migrate Drupal. Il vostro obiettivo deve essere Drupal 11, non Drupal 12, e Drupal 11 è supportato fino alla metà o alla fine del 2028 secondo la documentazione di drupal.org. Questo dà a chi ha un sito Drupal 7 una finestra reale, ma è una finestra con una fine netta, e cominciare nel 2028 una ricostruzione di sei mesi per centrare un obiettivo nel 2028 non è un piano.

Quanto costa ogni percorso nel Regno Unito

Queste sono stime interne dalla nostra produzione, non tariffe pubblicate, e l’ampiezza di ogni fascia dipende quasi solo dalla salute dei moduli contribuiti, non dalla dimensione del sito. Le agenzie britanniche fatturano da 600 a 900 sterline al giorno per questo lavoro. Un aggiornamento da Drupal 11 a 12 su un sito mantenuto sono da tre a otto giorni test inclusi, che si collocano fra 2.000 e 6.000 sterline. Se lo stesso sito ha moduli contribuiti fermi, mettete in conto due o quattro settimane e da 6.000 a 12.000 sterline.

Un sito Drupal 10 paga entrambi i salti. Ben mantenuto, il salto da Drupal 10 a 11 costa da 6.000 a 15.000 sterline e il salto a Drupal 12 aggiunge da 2.000 a 6.000 sterline, quindi da 8.000 a 21.000 sterline in totale su quattro o otto settimane. Trascurato, il solo primo salto va da 15.000 a 35.000 sterline e il totale atterra fra 17.000 e 41.000 sterline. Una ricostruzione Drupal 7 dura da tre a sei mesi e costa di solito da 40.000 a 120.000 sterline, di più per siti grandi o molto personalizzati.

L’audit dei moduli contribuiti che fissa la vostra data

I progetti di aggiornamento raramente muoiono sul core. Muoiono sul quattordicesimo modulo dell’elenco, quello che nessuno ricorda di avere installato, che non ha un rilascio compatibile con la prossima major e ha un manutentore che ha scritto l’ultima volta nel 2023. Fate questo audit prima di impegnarvi su una data, perché è l’audit che produce la data.

Lanciate Upgrade Status, esportate il rapporto, poi dividete i vostri moduli in quattro secchi. Il primo sono i progetti con un rilascio stabile che supporta la major di destinazione, e non costano nulla. Il secondo sono i progetti con una patch o un rilascio di sviluppo nella coda delle issue, che costano un po’ di lavoro di integrazione e portano il rischio che la patch non arrivi mai. Il terzo sono i progetti con una issue aperta e nessuna patch, per i quali qualcuno deve scriverla. Il quarto sono i progetti senza alcuna attività.

Il quarto secchio fissa i vostri tempi, e la sua dimensione è conoscibile oggi invece che a novembre. Un sito con trenta moduli contribuiti e nulla nel quarto secchio è un lavoro lineare. Lo stesso sito con quattro moduli nel quarto secchio è un altro incarico con un altro budget, e la differenza fra quei due preventivi è una giornata di scansione.

Che cosa fare con un modulo abbandonato

Ci sono quattro opzioni oneste e quella giusta dipende da che cosa fa il modulo. Rimuoverlo, se la funzione che offre non serve più, cosa vera più spesso di quanto i team si aspettino dopo qualche anno di deriva editoriale. Sostituirlo con un progetto mantenuto che fa lo stesso lavoro, accettando la migrazione di configurazione che ne deriva.

Prenderne in carico la manutenzione, che in Drupal è un’opzione vera e meno intimidatoria di come suona. Drupal.org ha una procedura documentata per diventare manutentore di un progetto non supportato, e per un modulo piccolo da cui la vostra attività dipende, adottarlo può costare meno che sostituirlo. Il costo è ricorrente invece che una tantum, quindi mettetelo a budget con onestà.

Oppure reimplementare il comportamento in un modulo su misura limitato a ciò che usate davvero. Un modulo contribuito risolve il caso generale per tutti, mentre a voi di solito serve una fetta stretta. Reimplementare quella fetta contro le API attuali è spesso un lavoro di due giorni contro un porting di due settimane, e toglie la dipendenza per sempre. La nostra guida su come assumere uno sviluppatore Drupal spiega come valutare qualcuno proprio su questo tipo di giudizio.

Una tabella di marcia a ritroso dal 9 dicembre 2026

Partite dalla data finale e il piano si scrive da sé. Entro fine settembre, lanciate Upgrade Status contro Drupal 12 su una copia della produzione e mettete i quattro secchi su carta. È un esercizio di due o tre giorni ed è l’unico documento che permetta di valutare onestamente tutto il resto.

Entro metà ottobre, confermate che il vostro hosting sappia dare PHP 8.5 e i minimi di database, e avviate il trasloco se non ci riesce. Decidete anche le questioni sui moduli contribuiti, perché ognuna porta con sé un tempo di attesa. Entro inizio novembre, su un sito Drupal 10 l’aggiornamento a Drupal 11.4 o 11.5 deve essere completo, con il sito che gira in produzione sul nuovo ramo.

Entro inizio dicembre state guardando il rilascio della 12.0.0 invece di reagirvi. Se a quel punto siete su Drupal 11, prendete Drupal 12 a gennaio o febbraio 2027, quando i progetti contribuiti avranno taggato rilasci stabili. Non c’è alcun premio per aggiornare nella settimana del rilascio, e Drupal 11.5 resterà supportata. Il premio è per non essere su Drupal 10 quando gli avvisi si fermano.

Quanto costa non fare nulla

Il costo diretto è che ogni vulnerabilità del core di Drupal divulgata dopo il 9 dicembre 2026 resta aperta sul vostro sito per sempre. La storia degli avvisi di Drupal comprende esecuzioni di codice da remoto abbastanza gravi da essere sfruttate entro poche ore dalla pubblicazione, e un CMS senza patch su un IP pubblico viene trovato dalle scansioni automatiche, non da un attaccante mirato che ha scelto voi.

I costi indiretti arrivano prima e di solito sono più grandi. Non superare il controllo sul software supportato in una valutazione Cyber Essentials può incidere sull’ammissibilità a contratti che richiedono la certificazione, cosa comune negli appalti pubblici britannici. I moduli contribuiti smettono di rilasciare correzioni per il vostro ramo. E l’aggiornamento stesso diventa più caro ogni mese, perché la distanza fra la vostra base di codice e l’ecosistema mantenuto cresce senza che nessuno tocchi nulla.

C’è anche un costo più silenzioso. Un sito che nessuno può aggiornare tende a diventare un sito che nessuno può cambiare, e il lavoro sulle funzionalità si ferma perché ogni modifica andrebbe scritta contro un’API che sta sparendo. È così che un sito Drupal di cinque anni diventa una ricostruzione invece che un aggiornamento. Se state pesando questa decisione, la nostra guida allo sviluppo web con Drupal è un punto di partenza migliore di un preventivo.

Due ragioni legittime per aspettare

Aspettare è difendibile in due situazioni, e solo se aspettate di proposito. La prima è che siete già su Drupal 11.4 o 11.5. Quei rami sono supportati, sono la rampa di lancio prevista per Drupal 12, e non c’è alcun vantaggio a prendere una major nuovissima nelle sue prime settimane mentre i progetti contribuiti stanno ancora taggando rilasci. Aspettare il primo trimestre del 2027 è la scelta professionale, non quella pigra.

La seconda è un sito Drupal 7 con una ricostruzione già finanziata e in calendario. Migrare Drupal 7 dentro Drupal 11 e poi subito dentro Drupal 12 è movimento sprecato. Atterrate su Drupal 11, fatelo girare, e prendete Drupal 12 più avanti come manutenzione ordinaria.

Quel che non è difendibile è restare su Drupal 10 senza un piano prenotato. Se è il vostro caso, la posizione minima accettabile entro fine settembre è un rapporto di scansione, un ramo di destinazione con un nome e una data sul calendario. Tutto il resto può muoversi. Se volete quella valutazione fatta da chi l’ha già condotta, il nostro team di sviluppo software esegue audit di versione come lavoro a perimetro fisso.

Da dove iniziare

Fate prima la scansione. Quasi ogni cattivo preventivo di aggiornamento Drupal esistente è stato prodotto senza, ed è il motivo per cui tanti sbagliano in entrambe le direzioni. Due o tre giorni di output di Upgrade Status e Drupal Rector vi dicono in quale delle cinque fasce di costo qui sopra vi trovate davvero, e quel singolo numero cambia la conversazione con il vostro consiglio più di qualunque discorso generale sulle versioni major.

Mecanik esegue questi audit e gli aggiornamenti che ne seguono, su siti Drupal 10 che hanno dicembre davanti e su siti Drupal 11 che pianificano un passaggio più tranquillo nel 2027. Il lavoro sui moduli su misura, le integrazioni e la pulizia delle deprecazioni stanno con la nostra pratica di sviluppo software, mentre una ricostruzione o un cambio di hosting appartiene allo sviluppo di siti web. Se è la sicurezza il motivo per cui questo tema è finito sulla vostra scrivania, partite dalla nostra nota sugli avvisi di sicurezza Drupal e il rischio reale, e se durante un cambio di versione la preoccupazione è il traffico organico, l’articolo sulla configurazione SEO tecnica di Drupal spiega che cosa proteggere.

Domande frequenti

Quando esce Drupal 12 e quando finisce il supporto di Drupal 10? Drupal 12.0.0 è previsto per la settimana del 7 dicembre 2026, rilasciato insieme a Drupal 11.5.0, e Drupal 10 raggiunge la fine del supporto il 9 dicembre 2026. Entrambe le date sono pubblicate nel calendario dei rilasci del core di Drupal. Nella stessa settimana finisce il supporto di sicurezza per i rami minori 11.3.x e 10.6.x. Drupal 12.0.0-alpha1 è stato taggato il 2 settembre 2026.

Posso aggiornare direttamente da Drupal 10 a Drupal 12? No. Il percorso di aggiornamento del database dai rilasci precedenti a Drupal 11.4.0 è stato rimosso da Drupal 12, quindi un sito Drupal 10 deve prima passare a Drupal 11.4 o successiva e poi a Drupal 12. Drupal.org raccomanda la 11.5.0 o superiore prima del cambio di major. Pianificatelo come due salti, con il salto da Drupal 10 a 11 che porta quasi tutto il rischio e il costo.

Quali sono i requisiti di sistema di Drupal 12? Drupal 12 richiede PHP 8.5 e abbandona il supporto a PHP 8.4 e versioni precedenti. I minimi di database sono MySQL 8.0, MariaDB 10.11, PostgreSQL 18 e SQLite 3.45 con l’estensione json1. Symfony passa a 8.1 e Guzzle a 8.0. Ospitare Drupal direttamente su Windows in produzione è deprecato, anche se Windows resta supportato per lo sviluppo locale.

Che cosa c’è davvero di nuovo in Drupal 12 rispetto a Drupal 11.5? Quasi nulla, ed è voluto. Le note di rilascio della alpha1 affermano che la 12.0.x è quasi identica alla 11.5.x, a parte il codice deprecato rimosso, le major delle dipendenze aggiornate e i requisiti di sistema alzati. I cambiamenti di comportamento da segnalare sono argon2id come algoritmo predefinito di hashing delle password, HTMX che passa alla versione 4 e un robots.txt del core che blocca le pagine dei risultati di ricerca con parametri di query.

Quanto costa un aggiornamento a Drupal 12 nel Regno Unito? Su un sito Drupal 11 mantenuto, da tre a otto giorni di lavoro alle tariffe tipiche delle agenzie britanniche, da 600 a 900 sterline al giorno, quindi circa da 2.000 a 6.000 sterline. Un sito Drupal 10 paga entrambi i salti e atterra fra 8.000 e 21.000 sterline se ben mantenuto e fra 17.000 e 41.000 sterline se trascurato. Una ricostruzione Drupal 7 dura da tre a sei mesi e costa di solito da 40.000 a 120.000 sterline. Sono stime interne, non tariffe pubblicate.