Supporto Drupal: cosa deve coprire un contratto

Quasi tutti quelli che cercano supporto Drupal possiedono già il sito. Lo hanno ereditato da un’agenzia che è andata oltre, o da uno sviluppatore che se n’è andato, e ora un aggiornamento è in ritardo, un modulo non invia più nulla, oppure è arrivato un avviso di sicurezza e nessuno sa dire se li riguarda. Quello che vogliono non è una pagina commerciale. È un capitolato: qual è il lavoro, cosa dice un contratto equo e quanto dovrebbe costare.

Questo è il senso dell’articolo: il lavoro di cui un sito Drupal ha davvero bisogno ogni mese, i fatti operativi che decidono se un contratto vale qualcosa e fasce di prezzo britanniche realistiche. Leggetelo con accanto la proposta di un fornitore, perché la parte utile è accorgersi a quali di queste domande la proposta non risponde.

Due cose rendono Drupal diverso dalla manutenzione generica di un sito. Gli avvisi di sicurezza seguono un calendario pubblicato, quindi la vostra finestra di esposizione è misurabile e può finire nel contratto. E un sito Drupal è un assemblaggio di moduli contribuiti con manutentori indipendenti, quindi qualcuno deve seguire per voi un bersaglio di aggiornamento in movimento.

Cosa deve coprire un contratto di supporto Drupal? Il monitoraggio degli avvisi di sicurezza che riguardano esattamente il vostro parco moduli, gli aggiornamenti di core e moduli contribuiti su un ciclo definito passando da uno staging, la prova che i backup si ripristinano davvero, il monitoraggio di disponibilità ed errori applicativi e un budget di modifica dichiarato per i piccoli lavori. Nel Regno Unito si va da circa £250 al mese per un sito vetrina semplice a £2,000 o più per uno complesso. Sotto quella soglia state comprando monitoraggio, non supporto.

Cosa significa davvero il supporto Drupal, mese dopo mese

Chiedete un preventivo a tre agenzie e riceverete tre pacchetti chiamati Essential, Business ed Enterprise, ognuno un elenco puntato di sostantivi. I sostantivi non sono il lavoro. Il lavoro è un insieme di attività ricorrenti che avvengono a calendario oppure non avvengono affatto, e l’esercizio utile è far descrivere ciascuna al fornitore come attività, con un responsabile e una frequenza.

Sono otto. Monitoraggio degli avvisi di sicurezza e applicazione delle patch. Aggiornamenti di core e moduli contribuiti. Aggiornamenti di dipendenze e versioni di piattaforma. Verifica dei backup e test di ripristino. Monitoraggio di disponibilità ed errori applicativi. Controlli sulle regressioni di prestazioni. Supporto redazionale. E un budget di modifica per i piccoli lavori che arrivano sempre.

Un contratto che nomina tutte e otto non è automaticamente buono, ma un contratto che ne nomina quattro è chiaramente incompleto, e le quattro che spariscono sono quasi sempre le stesse: test di ripristino, regressioni di prestazioni, aggiornamenti di piattaforma e budget di modifica. Sono quelle costose, ed è per questo che mancano.

Perché i nomi dei pacchetti nascondono il lavoro

“Ticket di supporto illimitati” non dice nulla su chi applica una patch di sicurezza del core il terzo mercoledì del mese. “Monitoraggio proattivo” non dice nulla su se un essere umano legge l’allarme alle due di notte o se resta in coda fino a lunedì. “Nei limiti del possibile” non dice proprio nulla.

Sostituite ogni formula con tre fatti: l’attività, la sua frequenza e il ruolo dichiarato che la esegue. Quasi tutte le pagine dei pacchetti si dissolvono sotto questo trattamento, e quelle che sopravvivono indicano i fornitori con cui vale la pena parlare.

La finestra delle patch è tutto il prodotto

Drupal pubblica le release di sicurezza a calendario, cosa insolita ed enormemente utile. Le release di sicurezza del core escono in una finestra il terzo mercoledì del mese , a partire dalle 1200 America/New York, cioè le 1600 o le 1700 UTC a seconda della stagione. I progetti contribuiti hanno una finestra di sicurezza ogni mercoledì , quindi gli avvisi sui contribuiti arrivano molto più spesso di quelli sul core, e a gruppi.

La conseguenza è che la vulnerabilità non è il rischio. Chiunque usi Drupal riceve la stessa vulnerabilità nello stesso istante, pubblicata alla luce del sole. Il rischio è l’intervallo fra la pubblicazione dell’avviso e la patch sul vostro sito di produzione, perché in quell’intervallo la falla è documentata, indicizzata e cercata da chi ha letto l’avviso più in fretta del vostro fornitore.

Ogni altra clausola di un contratto di supporto è decorazione accanto al numero di ore di quell’intervallo. La prima domanda a un fornitore è quindi aritmetica, non filosofia. Il terzo mercoledì del mese prossimo, a che ora una persona leggerà l’avviso, ed entro quando la patch sarà in produzione? “Entro il nostro SLA standard” non è una risposta.

Come Drupal valuta il rischio e cosa dovrebbe farne il vostro contratto

Ogni avviso Drupal porta un numero, e quel numero è lo strumento contrattuale più inutilizzato della piattaforma. Drupal valuta le vulnerabilità con il NIST Common Misuse Scoring System, NISTIR 7864 , producendo un punteggio da 0 a 25 su sei metriche: complessità di accesso, autenticazione, impatto sulla riservatezza, impatto sull’integrità, disponibilità di un exploit e diffusione del bersaglio.

Il punteggio corrisponde a cinque etichette pubblicate. Da 0 a 4 è Not Critical, da 5 a 9 è Less Critical, da 10 a 14 è Moderately Critical, da 15 a 19 è Critical e da 20 a 25 è Highly Critical. Quelle fasce sono pubbliche, stabili e non interpretabili da nessuna delle due parti.

Il che le renderebbe la spina dorsale naturale di uno SLA di supporto, e quasi nessuno le usa. Invece di inventare definizioni private di gravità che un fornitore potrà contestare in seguito, scrivete l’impegno di risposta direttamente contro il punteggio Drupal: Highly Critical corretto entro un numero di ore dichiarato, fuori orario compreso, Critical entro un giorno lavorativo, Moderately Critical nel ciclo pianificato successivo, il resto raggruppato. Nessuna parte può ridiscutere cosa significasse “urgente”, perché lo ha già deciso un terzo.

Highly Critical è un evento operativo diverso

Le release Highly Critical del core sono rare, e Drupal le tratta diversamente. Il team di sicurezza pubblica in anticipo un annuncio di servizio pubblico così che i proprietari dei siti possano organizzare una copertura. PSA-2026-05-18 ha fatto esattamente questo, avvertendo il 18 maggio 2026 di una release del core altamente critica prevista per mercoledì 20 maggio e riguardante tutti i rami supportati.

Quel preavviso è ciò attorno a cui il vostro contratto dovrebbe essere costruito, perché trasforma un’emergenza in un appuntamento. Un fornitore che conosce l’annuncio il lunedì e tiene una finestra di rilascio per il mercoledì gestisce un servizio di supporto. Un fornitore che lo scopre il giovedì gestisce una mailing list.

C’è anche una mitigazione da conoscere. Drupal Steward è un web application firewall a pagamento e distribuito globalmente, gestito dalla Drupal Association e dal team di sicurezza, che offre patching virtuale a livello di rete per le falle altamente critiche del core, così il sito resta protetto mentre l’aggiornamento viene testato. I prezzi sono pubblicati in dollari statunitensi e crescono col traffico: sotto i 20 dollari al mese per un sito che serve circa 1 milione di richieste HTTP, sotto i 100 dollari al mese oltre i 10 milioni. Compra tempo, non immunità, e un buon contratto dice chi paga.

Cosa non copre la politica sugli avvisi di sicurezza

Tre esclusioni nella politica su processo e permessi degli avvisi di sicurezza cambiano ciò che un contratto deve fare, e quasi tutti i contratti di supporto tacciono su tutte e tre.

Gli avvisi vengono emessi solo per le release stabili. Se un modulo del vostro sito gira in versione alpha, beta, release candidate o dev, per quel modulo non uscirà mai un avviso, e l’assenza di notizie non significa nulla. La copertura è inoltre a adesione volontaria per progetto anziché automatica, quindi un modulo contribuito non coperto può portarsi dietro una falla nota senza alcun canale di notifica.

Poi c’è quella che coglie tutti di sorpresa: non vengono emessi avvisi per le librerie esterne, nemmeno quando un progetto contribuito ne impone l’installazione. Una libreria JavaScript o PHP tirata dentro come dipendenza è un vostro problema, tracciato da voi, e nel feed di Drupal non comparirà.

La copertura può anche essere revocata

La copertura di sicurezza non è permanente. PSA-2026-07-22 ha tolto la copertura al modulo QA Accounts perché privilegia la facilità d’uso rispetto alla sicurezza ed è pensato solo per siti non raggiungibili da internet.

Ecco la forma del rischio. Un modulo installato anni fa sotto copertura può perderla in silenzio, e sul vostro sito non cambia nulla che ve lo dica. Tenere un inventario di ogni progetto installato con il suo stato di copertura e la sua stabilità di release è vero lavoro ricorrente, e va messo per iscritto nel contratto.

Gli aggiornamenti di dipendenze e piattaforma sono lavoro di supporto

La voce più spesso esclusa da un contratto di supporto Drupal è quella che alla fine decide se il sito sopravvive. I requisiti di piattaforma di Drupal si muovono, e si muovono a scatti che richiedono un cambio di hosting anziché un composer update.

Su PHP, Drupal 10 richiede almeno PHP 8.1 , mentre Drupal 11 impone PHP 8.3 come minimo dalla 11.1. Il supporto a PHP 8.5 è arrivato in Drupal 11.3, e Drupal 12.0 supporta soltanto PHP 8.5. Quest’ultimo dettaglio pesa più di quanto sembri: un sito che oggi sta comodo su PHP 8.1 è a due spostamenti di piattaforma forzati da Drupal 12.

I requisiti di database si sono mossi altrettanto. Drupal 11 richiede MySQL 8.0 o successivo, MariaDB 10.6 o successivo, PostgreSQL 16 o successivo, oppure SQLite 3.45 o successivo. Drupal 10 accettava MySQL 5.7.8, MariaDB 10.3.7 e PostgreSQL 12. Un hosting gestito che serve ancora MySQL 5.7 è un blocco sul percorso di aggiornamento, non un dettaglio, e la nostra nota su cosa fa girare bene Drupal spiega verso cosa spostarsi.

La fine vita di Drupal 10 è già un problema di contratto

Drupal 10 arriva a fine vita il 9 dicembre 2026 , e Drupal 12 esce nella stessa settimana, a partire dal 7 dicembre 2026. Anche il supporto di sicurezza per i rami 11.3.x e 10.6.x finisce in quel momento. A settembre 2026 i rami che ricevono release di sicurezza sono 11.4.x, 11.3.x e 10.6.x.

Letto contro il calendario, fa circa tre mesi. Qualsiasi sito Drupal 10 senza un piano di aggiornamento quotato a settembre 2026 passerà dicembre o pagando un sovrapprezzo d’urgenza o girando senza supporto, e la seconda opzione dovrebbe essere una decisione presa deliberatamente e non per inerzia.

Un contratto che vale il suo prezzo dovrebbe aver già prodotto quattro cose: un rapporto sullo stato dell’aggiornamento, una scansione del codice deprecato nei moduli su misura e nel tema, una verifica di compatibilità di ogni modulo contribuito con Drupal 11 e 12 e una stima scritta. Se il vostro fornitore non ne ha prodotta nessuna, quello è il verdetto. La nostra analisi di costi, opzioni e scadenze della migrazione Drupal espone cosa comporta il lavoro, e la stessa pianificazione sta dentro i nostri progetti di sviluppo di siti web .

I backup non valgono nulla finché un ripristino non è testato

Quasi ogni contratto di supporto Drupal promette backup. Pochissimi promettono un ripristino, e la distinzione è tutto il valore della voce. L’NCSC lo dice chiaramente nella sua guida per le piccole organizzazioni: una volta fatto il backup , dovete sapere come ripristinarlo e verificare che contenga tutto ciò che conta.

Un ripristino Drupal ha tre pezzi mobili, e i backup parziali falliscono sul secondo con noiosa regolarità. Servono il database, le cartelle dei file pubblici e privati e la configurazione. Un backup che prende il database ma non la cartella dei file ripristina un sito con i contenuti intatti e senza immagini, che a uno script di monitoraggio sembra un sito funzionante e a un cliente sembra un disastro.

Chiedete un test di ripristino datato, eseguito in un ambiente usa e getta, con una nota scritta di quanto è durato e cosa mancava. Una volta a trimestre è una frequenza ragionevole per la maggior parte dei siti. Se un fornitore non ne ha mai fatto uno, non conosce il proprio tempo di recupero, e nemmeno voi.

Monitoraggio di disponibilità ed errori, e cosa misura davvero la disponibilità

C’è un ampio scarto fra un server che risponde e un sito che funziona, e Drupal ci sta dentro in pieno. Un errore fatale PHP, un limite di memoria esaurito, una connessione al database fallita o una ricostruzione della cache rotta producono tutti una pagina che un controllo ingenuo legge come successo, oppure un semplice 500 che nessuno sta osservando.

Il monitoraggio misurato sul server vi dice che la macchina risponde. Il monitoraggio misurato sull’applicazione richiede una pagina vera, segue i redirect e verifica che il contenuto atteso sia presente nella risposta. Sono prodotti diversi con prezzi diversi, e una proposta che dice “monitoraggio della disponibilità” senza dire quale sta descrivendo il più economico dei due.

Sotto c’è il log di Drupal. Il rapporto dei messaggi recenti e il log degli errori PHP sono il posto dove un cron che fallisce, una funzione deprecata o un modulo che solleva eccezioni a ogni richiesta compariranno molto prima che si lamenti un visitatore. Qualcuno deve leggerli a cadenza fissa. Il nostro pezzo sugli SLA di disponibilità che significano qualcosa spiega come le percentuali si traducono in minuti ammessi.

Leggere con occhio critico uno SLA di supporto Drupal

Quasi tutti gli SLA di supporto sono scritti per essere firmati anziché usati, e vengono firmati perché vengono letti in fretta. Tre clausole portano quasi tutto il peso, e leggerle con attenzione richiede dieci minuti.

Il tempo di risposta non è il tempo di risoluzione

Uno SLA che promette risposta in due ore di solito promette che qualcuno prenderà in carico il ticket entro due ore. Non promette che qualcuno guardi il vostro sito. I fornitori seri si impegnano su un obiettivo di risoluzione, o come minimo su un obiettivo di diagnosi e soluzione temporanea, con il tempo di correzione indicato a parte.

Dove il lavoro davvero non si può racchiudere in un tempo, un contratto onesto lo dice e si impegna invece a uno sforzo continuo fino alla risoluzione. Quello è un impegno vero. “Risposta in due ore” da sola è l’impegno a mandare un’email.

Le definizioni di gravità decidono tutto

Ogni SLA ha una tabella di gravità, e di solito è il fornitore ad assegnarla. Ecco la scappatoia. Se la definizione di Priorità 1 è “sito non disponibile”, allora un pagamento che fallisce per un terzo dei clienti è Priorità 3 e viene guardato la settimana prossima.

Scrivete le definizioni attorno all’impatto sul business anziché allo stato tecnico, e mettete esempi concreti nel contratto: un passaggio di pagamento che fallisce, un login amministrativo irraggiungibile, un modulo di contatto rotto sulla pagina delle richieste. Poi concordate chi assegna la gravità e come si contesta un’assegnazione.

Le ore di copertura non sono l’orario di ufficio

“Orario di ufficio” e “copertura” indicano cose diverse e vengono spesso usate una per l’altra. La copertura è il periodo in cui il cronometro corre e qualcuno è obbligato ad agire. Se la copertura va dalle 09:00 alle 17:30 nei giorni lavorativi, un avviso pubblicato alle 1700 UTC di un mercoledì di dicembre viene preso in carico il mattino dopo nella migliore delle ipotesi.

Per Drupal in particolare, notate che la finestra di sicurezza del core apre alle 1600 o alle 1700 UTC. Un fornitore britannico con copertura fino alle 17:30 è strutturalmente sul bordo, quindi gli accordi fuori orario per gli avvisi Highly Critical vanno nominati a parte e quotati.

Cosa conta come incidente e cosa è escluso

La sezione delle esclusioni è il punto in cui un contratto diventa silenziosamente più economico di quanto sembri. Le esclusioni comuni sono del tutto ragionevoli prese singolarmente e irragionevoli in combinazione: guasti dell’hosting di terzi, problemi causati dal personale del cliente, difetti in moduli non installati dal fornitore, qualsiasi cosa legata a un tema a pagamento e qualsiasi cosa che il fornitore classifichi come modifica anziché come guasto.

L’ultima è il filo tagliente. Se una correzione richiede un cambio di configurazione, e i cambi di configurazione sono fatturabili, allora quasi ogni guasto può essere riclassificato nella colonna fatturabile. Chiedete direttamente come il fornitore distingue un guasto da una modifica, e chiedete due esempi di ciascuno dal suo lavoro recente.

Verificate anche cosa succede con i terzi. Quando la colpa è del gateway di pagamento, del connettore CRM o dell’hosting, il fornitore coordina la soluzione oppure il ticket si chiude come fuori perimetro? Il coordinamento è lavoro vero e vale la spesa, ma solo se il contratto dice che avviene.

I tre modelli di contratto, confrontati onestamente

Quasi ogni accordo di supporto Drupal ha una di tre forme, e ciascuna è una risposta sensata a una situazione diversa. L’errore è comprare una forma aspettandosi il comportamento di un’altra.

Ore fisse al mese

Comprate un blocco di ore, diciamo 8 o 16, e il fornitore le applica a ciò che chiedete. È trasparente, è facile da confrontare fra preventivi e si adatta a un’organizzazione con un flusso costante di piccole modifiche e qualcuno all’interno in grado di dare priorità.

Il suo punto debole è che la manutenzione compete con le funzionalità sullo stesso monte ore. In un mese pieno il patching di sicurezza perde in silenzio contro la landing page della campagna, perché chi spende le ore ha una scadenza e la patch non sembra tale. Se comprate questo modello, riservate nel contratto stesso una quota di ore alla manutenzione.

Correzioni illimitate più modifiche a preventivo

Il fornitore assorbe manutenzione e piccole correzioni per un canone mensile fisso, e tutto ciò che supera una soglia concordata viene quotato a parte. È il modello che quasi tutte le agenzie spingono, e per un sito stabile con un proprietario nervoso è davvero la risposta giusta, perché converte un rischio variabile in una riga fissa di budget.

Il suo punto debole è il confine. “Piccola correzione” resta indefinita finché qualcuno non ne ha bisogno, e la soglia si sposta a seconda di come va il mese. Pretendete una definizione scritta, idealmente un limite di tempo come tutto ciò che sta sotto i 30 minuti, e un rapporto mensile che mostri cosa è stato assorbito.

Puro consuntivo

Nessun contratto, una tariffa giornaliera e lavoro quando lo chiedete. È la scelta onesta per un sito a basso rischio con un proprietario che davvero seguirà gli aggiornamenti, e per organizzazioni con competenze interne che hanno bisogno di aiuto specialistico occasionale anziché di copertura.

Il suo punto debole è che non accade mai nulla di proattivo, perché nessuno è pagato per guardare. Il consuntivo fa anche pessima coda: competete con i clienti a contratto per gli stessi ingegneri, quindi in una brutta giornata la risposta si misura in settimane anziché in ore.

Il problema degli incentivi nel supporto a forfait

Il supporto a forfait ha un problema strutturale di cui nessuno nel settore parla volentieri. Se il fornitore viene pagato uguale a prescindere da quante ore consuma un sito, allora ogni ora spesa sul vostro sito riduce il suo margine, e il comportamento commercialmente razionale è spenderne il meno possibile.

Di solito non si manifesta come trascuratezza. Si manifesta come preferenza per la correzione rapida invece che giusta, per il soffocamento di un sintomo invece che la ricerca di una causa, e per il rinvio dell’aggiornamento di modulo che costerebbe una giornata di test di regressione. Si manifesta anche nella direzione opposta sui piani economici, dove il canone torna solo se il sito non viene davvero mai toccato.

Il contrappeso è un obbligo di rendicontazione. Un rapporto mensile con ore consumate, aggiornamenti applicati, avvisi valutati e ticket chiusi rende il consumo visibile a entrambe le parti, e trasforma un cliente non redditizio in una conversazione anziché in un lento decadimento del servizio. Ogni fornitore che crede nel modello lo accetterà. Un fornitore che resiste vi sta dicendo a cosa serve davvero il modello.

Come si presenta il buon lavoro sul piano operativo

Tre pratiche tecniche separano un fornitore Drupal capace di tenere il vostro sito in sicurezza da uno che improvvisa. Nessuna è esotica, e su tutte e tre è facile fare domande.

Composer, oppure niente

La documentazione di Drupal è netta sul mescolare i metodi di aggiornamento e avverte che i siti possono incontrare problemi critici se gli aggiornamenti con Composer vengono combinati con altri approcci, e che una volta che Composer gestisce un modulo deve gestire anche il core. Un fornitore che carica ancora cartelle di moduli via FTP prima o poi cancellerà una directory vendor da cui dipendeva un modulo contribuito.

Chiedete se composer.json e composer.lock stanno nel controllo di versione e se Composer gira in produzione oppure viene distribuito l’artefatto costruito. Entrambe le risposte possono essere giuste. Non avere una risposta non può esserlo.

Uno staging che corrisponde alla produzione

Uno staging con una versione di PHP diversa, una versione di database diversa o un insieme di moduli diverso non testa nulla di utile. Il senso dello staging è lasciare che una patch di sicurezza fallisca dove non costa denaro, e ci riesce solo se i due ambienti coincidono sugli assi che si rompono.

Chiedete come lo staging viene rinfrescato dalla produzione, ogni quanto, e se contiene una copia anonimizzata dei contenuti reali. Uno staging con tre nodi di prova non rivelerà l’aggiornamento che rompe una vista su 40.000 righe.

La configurazione nel controllo di versione

Drupal tiene la configurazione nel database per impostazione predefinita, e il sistema di gestione della configurazione esiste per esportarla in file che si possono committare, rivedere e importare in un altro ambiente. Un team che lo usa può riprodurre le impostazioni del sito in modo deterministico. Un team che non lo usa clicca fra le schermate di amministrazione in produzione e spera.

Questo è il segnale più chiaro in una conversazione con un fornitore. Chiedete come una modifica fatta in staging arriva in produzione. Se la risposta è una descrizione anziché una pausa, il resto della conversazione di solito va bene.

Se non sanno descrivere il rilascio, la risposta è quella

Non c’è un modo educato di dirlo. Un fornitore che non sa descrivere, in un minuto senza fretta, come il codice passa dalla macchina di uno sviluppatore al vostro sito in produzione vi sta dicendo che i rilasci sono improvvisati. I rilasci improvvisati sono il motivo per cui le patch di sicurezza slittano: nessuno vuole eseguire la procedura manuale rischiosa un mercoledì sera.

La clausola di uscita che nessuno legge

Prima o poi cambierete fornitore, e la clausola che regola quel momento viene scritta mentre sono tutti cordiali e letta quando non lo è più nessuno. Dovrebbe dire quattro cose con chiarezza.

Di chi è il codice, moduli su misura e lavoro sul tema compresi, e con quale licenza. Dove sta il repository e come si trasferisce l’accesso. Che un export completo di database, file e configurazione verrà fornito in un formato dichiarato entro un numero dichiarato di giorni lavorativi. E che DNS, hosting e credenziali dei servizi di terzi vengono consegnati anziché trattenuti.

Il modo in cui va storta di solito non è la malafede. È un fornitore che ospita il vostro sito sul proprio account, tiene l’unica copia del repository e impiega sei settimane a rispondere perché non siete più un cliente pagante. Chiedete la clausola di uscita prima di firmare, e trattate ogni reticenza come un’informazione.

Drupal 7: fine vita, supporto esteso e lo scarto fra i due

Il supporto di sicurezza di Drupal 7 è finito il 5 gennaio 2025 . La comunità ha smesso di produrre patch, e l’enorme ecosistema di moduli contribuiti che rendeva utile Drupal 7 ha smesso di essere mantenuto insieme a esso.

La Drupal Association gestisce un Extended Security Support Provider Program, e HeroDevs e Tag1 Consulting ne sono i fornitori certificati. Comprare quel supporto è una decisione legittima per un’organizzazione che davvero non può migrare quest’anno, ed è nettamente meglio di niente.

Quello che non fa è rendere il sito sicuro nel senso ordinario. Un fornitore commerciale corregge le vulnerabilità che trova o che gli vengono segnalate, secondo un proprio calendario, per il parco moduli che ha accettato di coprire. Non ripristina il processo pubblico degli avvisi, non copre ogni modulo contribuito che vi capita di avere installato e non si estende alle librerie esterne da cui quei moduli dipendono. Il supporto esteso è un modo controllato di far girare una piattaforma non supportata, e un contratto di supporto non è sinonimo di sicurezza.

Se a settembre 2026 siete su Drupal 7, il consiglio onesto è spendere i soldi nella migrazione anziché in affitto. La nostra guida 2026 allo sviluppo web con Drupal descrive la piattaforma per com’è, e il dettaglio sul processo degli avvisi sta nella nostra nota su sicurezza Drupal, avvisi e rischio reale .

Il supporto redazionale e il budget di modifica

Due voci vengono spremute fuori dai contratti di supporto perché sono difficili da delimitare, ed entrambe sono quelle che i clienti notano davvero.

Supporto redazionale significa qualcuno che sappia aggiungere un tipo di contenuto, riparare una vista che ha smesso di filtrare bene, riformare un redattore dopo un cambio di personale o capire perché uno stile immagine taglia i volti. È poco drammatico e molto frequente, e un contratto che ne è privo produce un cliente che smette di chiedere e comincia ad aggirare il sito.

Il budget di modifica è l’altra metà. Ogni sito accumula una coda di piccoli lavori: un campo su un modulo, un redirect dopo lo spostamento di una pagina, un cambio di chi riceve le richieste. Dichiarare per quella coda una dotazione mensile in ore è ciò che le impedisce di diventare un progetto d’emergenza trimestrale. Da due a quattro ore al mese sono realistiche per un sito piccolo, 8 o 16 per uno molto attivo.

Quanto costa il supporto Drupal nel Regno Unito

I numeri qui sotto sono nostre stime interne per il 2026, basate sul lavoro delle agenzie britanniche e non su un’indagine pubblicata. Presuppongono un fornitore che svolga le otto attività descritte sopra, non un abbonamento di monitoraggio con una casella di supporto attaccata.

In prosa: un piccolo sito vetrina sta attorno a £250 a £600 al mese, che comprano il monitoraggio degli avvisi, un ciclo mensile di patch, la verifica dei backup e un’ora o due di modifiche. Un sito medio con integrazioni sta sui £700 a £1,800, perché ogni integrazione aggiunge una superficie di regressione da ritestare dopo ogni aggiornamento del core. Un sito complesso o multilingue con moduli su misura parte da circa £2,000 e arriva a £6,000 o più.

Gli accordi di solo monitoraggio, in cui il fornitore osserva gli avvisi e vi dice cosa vi riguarda senza rilasciare nulla, stanno più in basso, sui £250 a £450 al mese. Accanto alle tariffe giornaliere delle agenzie britanniche, £600 a £900, un contratto da £1,500 compra circa due giornate di un ingegnere. Il dettaglio sulle tariffe sta nella nostra nota su tariffe, competenze e selezione di uno sviluppatore Drupal , e il quadro di budget più ampio in costo della manutenzione software .

Cosa sposta un sito da una fascia alla successiva

L’istinto è prezzare il supporto sul traffico, e il traffico è quasi irrilevante. Un sito che serve 200.000 visite al mese con venti moduli e nessuna integrazione costa meno da assistere di uno che ne serve duemila con un connettore CRM, un gateway di pagamento e una migrazione su misura.

Tre cose guidano davvero il costo. Il numero di moduli, perché ogni modulo contribuito è un flusso di avvisi da seguire e un rischio di compatibilità a ogni aggiornamento del core. Il numero di integrazioni, perché ognuna è un contratto esterno che può cambiare sotto di voi e un test di regressione da rieseguire. E il volume redazionale, perché una redazione attiva genera a ritmo costante domande di supporto, cambi di permessi e ritocchi al modello dei contenuti.

Il codice su misura è il moltiplicatore su tutte e tre. Un sito con 12.000 righe di codice di moduli propri richiede una scansione delle deprecazioni e un giro di regressione a ogni release minore, cioè una giornata di lavoro che un sito solo contribuito non ha. Da lì viene la fascia alta, ed è il lavoro che ai nostri progetti di sviluppo software viene di solito chiesto di assorbire.

Domande da fare a un potenziale fornitore

Sei domande, e le risposte che dovrebbero preoccuparvi.

Su quale versione di Drupal e di PHP gira il nostro sito adesso, e qual è il percorso di aggiornamento? Una risposta che richiede di andare a controllare va bene. Una risposta che arriva una settimana dopo no. Come scoprite che un avviso di sicurezza ci riguarda? “Monitoriamo drupal.org” è debole; un inventario dei moduli per sito è la risposta che volete.

Descrivetemi il vostro processo di rilascio. L’esitazione qui è il segnale negativo più forte dell’intera conversazione. Quando avete ripristinato per l’ultima volta questo sito da un backup? “Facciamo backup giornalieri” non è una risposta. Cosa è escluso dal contratto, e come decidete se qualcosa è un guasto o una modifica? E infine: se ce ne andiamo, cosa riceviamo e in quanto tempo?

Cosa succede quando non c’è un contratto

È una sequenza più che un avvertimento, e procede più o meno allo stesso ritmo su ogni sito Drupal senza assistenza.

Per i primi mesi non succede nulla, ed è questo il problema, perché insegna a tutti che nulla deve succedere. Fra il sesto e il dodicesimo mese l’arretrato di aggiornamenti supera il punto in cui gli aggiornamenti smettono di essere sicuri uno alla volta, perché un modulo ora richiede un core più recente, che richiede un PHP più recente, che l’hosting non offre. Applicare una patch è diventato un progetto.

Poi il sito esce del tutto dal supporto di piattaforma, e una modifica del browser o di PHP rompe qualcosa di visibile. La riparazione ora comincia da un aggiornamento che nessuno aveva messo a budget, quotato come lavoro d’emergenza, e le parti del sito senza documentazione vengono ricostruite anziché riparate. Se lungo la strada avviene una violazione e sono coinvolti dati personali, l’ICO si aspetta la notifica entro 72 ore da quando ne siete venuti a conoscenza, quando è probabile un rischio per i diritti e le libertà delle persone, ed è una scadenza che si rispetta con log e backup che avete oppure no.

Il conto del recupero vale immancabilmente diverse volte il contratto che l’avrebbe evitato, e la differenza non è la manodopera. È che il lavoro pianificato avviene di martedì con un piano di rollback, e il lavoro d’emergenza di domenica senza.

Definire bene il perimetro prima di firmare

Il senso di tutto questo non è rendervi diffidenti verso i fornitori. È rendere significativo il confronto fra due proposte, perché oggi quasi tutti i preventivi di supporto Drupal sono inconfrontabili per costruzione: parole diverse, esclusioni diverse e nessuna definizione condivisa di cosa sia il lavoro mensile.

Prendete le otto attività, le fasce di rischio Drupal, i tre modelli di contratto e le sei domande, e metteteli contro quello che avete sulla scrivania. Ciò che sopravvive è una proposta vera.

Mecanik assiste siti Drupal nell’ambito del nostro lavoro di sviluppo di siti web e sviluppo software , e il primo incarico è di solito un inventario anziché una riparazione, perché quasi tutti i siti che arrivano da noi non sanno dire quali dei loro moduli siano ancora coperti dal feed degli avvisi di sicurezza .

Domande frequenti

Cosa dovrebbe includere un contratto di supporto Drupal? Otto attività: monitoraggio degli avvisi di sicurezza contro il vostro parco moduli esatto, aggiornamenti di core e moduli contribuiti su un ciclo definito, aggiornamenti di dipendenze e piattaforma PHP, verifica dei backup con ripristini testati, monitoraggio di disponibilità ed errori applicativi, controlli sulle regressioni di prestazioni, supporto redazionale e un budget di modifica dichiarato in ore. Un contratto che ne nomina solo quattro è incompleto, e le quattro che di solito mancano sono i test di ripristino, i controlli di prestazioni, gli aggiornamenti di piattaforma e il budget di modifica.

Quanto costa al mese il supporto Drupal nel Regno Unito? Come stima interna per il 2026, un piccolo sito vetrina costa circa £250 a £600 al mese, un sito medio con una o due integrazioni £700 a £1,800, e un sito complesso multilingue con moduli su misura £2,000 a £6,000. Gli accordi di solo monitoraggio stanno sui £250 a £450. Rispetto alle tariffe giornaliere delle agenzie britanniche di £600 a £900, un contratto da £1,500 compra circa due giornate di un ingegnere.

Quando Drupal pubblica le patch di sicurezza? Le release di sicurezza del core Drupal escono in una finestra il terzo mercoledì del mese, a partire dalle 1200 America/New York, cioè le 1600 o le 1700 UTC a seconda della stagione. I progetti contribuiti hanno una finestra di sicurezza ogni mercoledì. Le release del core altamente critiche sono precedute da un annuncio di servizio pubblico, così i proprietari dei siti possono organizzare in anticipo una copertura.

Il supporto esteso di Drupal 7 equivale a essere sicuri? No. Il supporto di sicurezza di Drupal 7 è finito il 5 gennaio 2025, e la Drupal Association certifica HeroDevs e Tag1 Consulting nell’ambito del suo Extended Security Support Provider Program. Quei fornitori correggono ciò che coprono, secondo un proprio calendario, per un parco moduli concordato. Non ripristina il processo pubblico degli avvisi, non copre ogni modulo contribuito che avete installato e non si estende alle librerie esterne.

Quando Drupal 10 arriva a fine vita? Drupal 10 arriva a fine vita il 9 dicembre 2026, nella stessa settimana in cui esce Drupal 12, a partire dal 7 dicembre 2026. Il supporto di sicurezza per i rami 11.3.x e 10.6.x finisce nello stesso momento. Drupal 12 supporta soltanto PHP 8.5, quindi i siti su versioni di PHP più vecchie hanno bisogno di un cambio di hosting prima dell’aggiornamento, non dopo.