Da Drupal 7 a Drupal 11: perché è una migrazione e non un aggiornamento

Drupal 7 è stato per oltre dieci anni la base di portali pubblici, siti universitari, riviste online e intranet. Il suo supporto è terminato il 5 gennaio 2025, ma molte installazioni sono ancora in produzione, spesso su un PHP altrettanto datato. Chi apre il progetto di aggiornamento scopre presto che non esiste un pulsante per passare a Drupal 11: dal punto di vista tecnico il nuovo sito è un’altra applicazione.

In questo articolo spieghiamo perché il passaggio da Drupal 7 alle versioni moderne è una migrazione, cosa si porta con la Migrate API e cosa va ricostruito, quali comandi si usano e perché il calendario di Drupal 12 rende urgente completare il lavoro su Drupal 11. Chiudiamo con un metodo per stimare il progetto prima di iniziare.

Due Drupal diversi

Con Drupal 8, nel 2015, il progetto ha riscritto il core. Il codice è passato a una struttura a oggetti basata su componenti Symfony e Composer, i template sono passati da PHPTemplate a Twig, la configurazione è uscita dal database per diventare esportabile in file, e quasi ogni API usata dai moduli è cambiata. Drupal 9, 10 e 11 sono evoluzioni di quella base: tra di loro si aggiorna sul posto, perché il codice rimuove le parti deprecate senza cambiare architettura.

Tra Drupal 7 e Drupal 11 invece cambiano lo schema del database, il formato dei moduli e quello dei temi. Il percorso ufficiale prevede di installare un Drupal 11 pulito e di importarvi contenuti e configurazione leggendo il vecchio database. Il sito Drupal 7 resta intatto e continua a funzionare finché il nuovo non è pronto.

Cosa fa la Migrate API

La Migrate API del core descrive ogni migrazione in tre parti: una source, che legge i dati dall’origine, una catena di process, che trasforma ogni valore, e una destination, che scrive le entità nel nuovo sito. I moduli Migrate Drupal e Migrate Drupal UI forniscono le migrazioni già pronte per Drupal 6 e 7: tipi di contenuto, campi, nodi con revisioni e traduzioni, utenti, ruoli, tassonomie, menu, file, alias degli URL e una parte della configurazione.

Il valore della Migrate API sta nella ripetibilità. Una migrazione si può eseguire, annullare e rieseguire quante volte serve, e tiene traccia degli identificativi già importati. Questo permette di lavorare per settimane sul nuovo sito, importare di nuovo i contenuti aggiornati poco prima del lancio e passare in produzione con dati freschi.

I comandi principali

Per i siti di una certa dimensione conviene lavorare da riga di comando con Drush e con il modulo contrib Migrate Upgrade, che genera le migrazioni come configurazione modificabile invece di eseguirle subito. Un flusso tipico sul nuovo Drupal 11:

# Moduli per generare, modificare e gestire le migrazioni
composer require drupal/migrate_upgrade drupal/migrate_plus drupal/migrate_tools
drush pm:enable migrate_drupal migrate_upgrade migrate_plus migrate_tools -y

# Genera le migrazioni leggendo il database Drupal 7, senza eseguirle
# (le credenziali sono di un utente con sola lettura sul vecchio database)
drush migrate-upgrade \
  --legacy-db-url=mysql://lettura:password@localhost/drupal7 \
  --legacy-root=/var/www/drupal7 \
  --configure-only

# Controlla l’elenco e lo stato delle migrazioni generate
drush migrate:status

# Esegue le migrazioni, poi le annulla se serve ripetere la prova
drush migrate:import --all
drush migrate:rollback --all

Le migrazioni generate finiscono nella configurazione del sito e si possono esportare, correggere e versionare insieme al codice. È qui che si sistemano i casi particolari: campi da unire, formati di testo da convertire, contenuti da escludere, riferimenti tra entità da ricostruire.

Cosa va ricostruito

La Migrate API trasferisce dati e struttura dei contenuti. Tutto ciò che è codice va invece rifatto, e di solito è la parte più consistente del progetto.

• Il tema: i file .tpl.php di Drupal 7 vanno riscritti come template Twig, e la logica che stava nei template va spostata in funzioni di preprocess o in moduli;
• i moduli personalizzati: vanno riscritti sulle API moderne, con classi, servizi, rotte e plugin al posto degli hook di Drupal 7, e con codice compatibile con PHP 8.3;
• le viste e i layout: le viste costruite con Views in Drupal 7 e le pagine composte con Panels o Context vanno ricreate, di solito con Views e Layout Builder del core;
• i moduli contrib: per ognuno va verificato se esiste una versione per Drupal 11 e se fornisce un percorso di migrazione dei propri dati. Alcuni moduli di Drupal 7 non hanno un successore diretto e vanno sostituiti da soluzioni diverse.

Per stimare il progetto conviene partire dall’elenco dei moduli abilitati sul sito Drupal 7, che si ottiene con drush pm-list --status=enabled sulla versione di Drush in uso con quel sito, e classificarli in tre gruppi: moduli del core, moduli contrib con una versione moderna, moduli personalizzati o senza successore. Il terzo gruppo determina gran parte dei tempi.

Il calendario: perché completare su Drupal 11

Le date del calendario dei rilasci di drupal.org a ottobre 2026 sono queste: Drupal 11.4 è uscito a fine giugno 2026 e riceve correzioni di sicurezza fino ad aprile 2027, Drupal 10 arriva a fine vita il 9 dicembre 2026, e Drupal 12 è pianificato per la settimana del 7 dicembre 2026.

Il punto che riguarda direttamente chi è ancora su Drupal 7 è un altro. Il modulo Migrate Drupal UI è deprecato da Drupal 11.3 e sarà rimosso in Drupal 12, senza un sostituto. Il piano discusso dal progetto prevede la stessa sorte per le sorgenti di migrazione da Drupal 6 e 7 contenute in Migrate Drupal, mentre la Migrate API generale resta nel core. In pratica il percorso ufficiale da Drupal 7 è garantito per tutta la vita di Drupal 11: chi migra adesso deve arrivare su Drupal 11 e poi aggiornare a Drupal 12 con calma, come un normale aggiornamento.

C’è anche PHP. Drupal 11 richiede almeno PHP 8.3 e, secondo la tabella dei requisiti attuale, Drupal 12 richiederà PHP 8.5. Il nuovo sito va quindi progettato su un server moderno, mentre il vecchio Drupal 7 continua a girare sul suo PHP fino al lancio.

URL, file e contenuti: i dettagli che contano

Alcuni aspetti, se trascurati, si scoprono solo dopo il lancio:

1. gli URL: gli alias vengono migrati, ma i percorsi generati da viste, filtri e moduli particolari no. Prima del lancio serve un elenco degli URL più visitati e un controllo puntuale, con reindirizzamenti permanenti per quelli che cambiano;
2. i file: la migrazione copia i file pubblici e privati se il percorso del vecchio sito è leggibile; i file referenziati direttamente nel testo dei contenuti vanno controllati a parte;
3. i formati di testo: i formati di Drupal 7 che permettevano PHP o HTML completo vanno ripensati, per ragioni di sicurezza e di compatibilità con l’editor CKEditor 5 del core moderno;
4. gli utenti: le password vengono migrate e gli utenti possono accedere con le credenziali di prima, ma ruoli e permessi vanno rivisti, perché molti permessi hanno cambiato nome o significato.

Mentre il nuovo sito è in costruzione

Una migrazione da Drupal 7 richiede di solito mesi, e nel frattempo il vecchio sito resta pubblico. La Drupal Association ha attivato un programma di supporto esteso per Drupal 7 con fornitori commerciali, pensato per chi non riesce a migrare in tempo. Per la parte del server, se Drupal 7 gira su un ramo di PHP in End of Life, il backport delle patch di sicurezza di PHP chiude le vulnerabilità note del motore senza toccare l’applicazione. A queste misure si aggiungono quelle di base: accesso amministrativo limitato, moduli inutilizzati disattivati e rimossi, copie di sicurezza verificate.

Il vecchio sito va protetto, il nuovo va costruito: sono due lavori paralleli.

Come impostare il progetto

Un progetto ordinato procede in questo modo: inventario di moduli, tipi di contenuto, viste e integrazioni; prova di migrazione dei soli contenuti su un Drupal 11 pulito, per misurare quanto passa senza interventi; scelta dei moduli sostitutivi e sviluppo del tema; personalizzazione delle migrazioni per i casi particolari; migrazione finale con un breve blocco delle modifiche sul vecchio sito; lancio con reindirizzamenti e monitoraggio degli errori 404. Le stesse fasi valgono, con strumenti diversi, per gli altri CMS, come raccontiamo nell’articolo su come migrare un CMS a PHP 8. Se vuoi una stima sul tuo sito, scrivici indicando versione di Drupal 7, di PHP e numero di moduli attivi.

Riassumendo

Drupal 7 è fuori supporto dal 5 gennaio 2025 e il passaggio a Drupal 11 è una migrazione: si installa un sito nuovo su PHP 8.3 o superiore e ci si portano i dati con la Migrate API, che sposta contenuti, utenti, tassonomie, menu, file e alias in modo ripetibile. Tema, moduli personalizzati, viste e layout vanno invece ricostruiti, e sono la parte che determina i tempi. L’interfaccia di migrazione è deprecata da Drupal 11.3 e le migrazioni da Drupal 7 non saranno più nel core di Drupal 12, atteso a dicembre 2026: per questo la migrazione va completata su Drupal 11. Nel frattempo il sito Drupal 7 va protetto, a partire da PHP e dagli accessi amministrativi.