Migrare un sito Drupal a WordPress con un freelance

Come migrare un sito Drupal a WordPress con un freelance: un piano per il passaggio di contenuti e funzionalità

La migrazione da Drupal a WordPress non consiste semplicemente nel trasferire le pagine. I siti Drupal si basano spesso su tipi di contenuto, tassonomie, campi, permessi e moduli che non hanno equivalenti diretti in WordPress. Se questi dettagli vengono trascurati, il nuovo sito può sembrare completo, ma i filtri di ricerca potrebbero non funzionare, gli autori potrebbero non essere più indicati e i file multimediali potrebbero scollegarsi dai contenuti.

Un freelance può occuparsi del lavoro, ma anche il proprietario del sito deve prendere decisioni chiare. Prima di chiederti come migrare un sito da Drupal a WordPress, prepara un inventario dei contenuti, individua le funzionalità che le persone usano davvero e stabilisci come dovranno differire i due sistemi dopo il lancio. In questo modo avrai un piano verificabile, invece di una vaga istruzione come «trasferisci tutto»; potrai inoltre valutare se affidarti a un freelance per migrazione Drupal WordPress con esperienza nella gestione dei dati e dei flussi editoriali.

1. Associa i tipi di contenuto Drupal alle strutture WordPress

Per prima cosa, elenca i tipi di contenuto Drupal e i campi associati a ciascuno. Un articolo di attualità potrebbe includere titolo, sommario, testo, autore, data di pubblicazione, argomento e immagine principale. Una pagina prodotto potrebbe avere campi diversi ed essere collegata a una categoria o a un fornitore. Il freelance ha bisogno di questo inventario prima di scegliere le strutture WordPress: è il primo passo per mappare contenuti Drupal in WordPress in modo coerente.

I nodi Drupal possono diventare articoli o pagine standard di WordPress, ma alcuni contenuti meritano un tipo di contenuto personalizzato. Per esempio, un elenco di organizzazioni con un archivio e campi dedicati ai profili è in genere più chiaro come tipo di contenuto «Organizzazione» che come insieme di pagine ordinarie. Le tassonomie possono diventare categorie WordPress o tassonomie personalizzate, a seconda del loro utilizzo. Una tabella di corrispondenza campo per campo rende visibili queste scelte.

Non dare per scontato che due campi con lo stesso nome funzionino allo stesso modo. Un campo Drupal che consente più valori potrebbe richiedere una configurazione WordPress diversa da quella necessaria per un campo che ne memorizza uno solo; inoltre, una data con fuso orario potrebbe richiedere una regola di conversione esplicita. Segnala alcuni esempi di valori insoliti, così il freelance potrà testarli invece di procedere per supposizioni.

Includi nella mappatura anche gli URL. Se un articolo Drupal si trova attualmente all’indirizzo /news/community-update, decidi se WordPress manterrà lo stesso percorso o lo reindirizzerà a uno nuovo. Un foglio di calcolo con tipo di contenuto di origine, struttura di destinazione, campi, regole per le tassonomie e gestione degli URL sarà un riferimento utile per entrambe le parti durante i test.

2. Decidi cosa ricostruire, sostituire o non trasferire

I moduli Drupal spesso supportano flussi di lavoro specifici. Copiare la funzionalità visibile non basta se è importante anche il processo che la rende possibile. Elenca i moduli e le funzioni personalizzate attualmente utilizzati dal sito, quindi indica chi dipende da ciascuno. L’accesso riservato ai membri, una coda di approvazione editoriale e la ricerca con filtri sfaccettati possono richiedere tre soluzioni WordPress diverse.

Suddividi ogni elemento in una di queste tre categorie: ricostruirlo in WordPress, sostituirlo con uno strumento disponibile oppure non trasferirlo. Per esempio, potrebbe non essere necessario migrare un vecchio calendario di eventi senza appuntamenti futuri. Un elenco pubblico ancora molto consultato potrebbe invece richiedere una soluzione alternativa con campi ricercabili. Se il nuovo flusso editoriale non consente di riprodurre i passaggi richiesti da un processo di approvazione personalizzato, potrebbe essere necessario svilupparlo.

Per ogni funzionalità da mantenere, chiedi al freelance di descrivere la soluzione proposta e i suoi limiti. Se la sostituzione modifica chi può aggiornare i contenuti o il modo in cui i visitatori li trovano, documenta il cambiamento prima di iniziare lo sviluppo. «Funziona come Drupal» non è un criterio di accettazione utile; «gli editor possono inviare un articolo per la revisione senza pubblicarlo» sì.

Distingui le funzioni indispensabili dalle preferenze. Questo aiuta a tenere sotto controllo l’ambito del progetto quando un modulo Drupal non ha un equivalente diretto e dà al proprietario la possibilità di approvare un processo più semplice. Per approfondire come scegliere tra un singolo professionista e un team, consulta È meglio assumere un freelance?.

3. Prepara un campione rappresentativo per la migrazione

Prima di trasferire l’intero database, chiedi al freelance di migrare un piccolo campione che includa contenuti di tipo diverso. Una pagina semplice permette di verificare i campi di base e gli URL. Un articolo con molte tassonomie mette alla prova le assegnazioni dei termini e la gerarchia. Un contenuto ricco di media serve a testare file immagine, didascalie e contenuti incorporati. Se il sito ha un tipo di contenuto speciale, includine almeno un esempio.

Il campione dovrebbe essere abbastanza ampio da includere casi diversi, ma sufficientemente ridotto da consentire al proprietario o all’editor di controllare ogni elemento. Concordate quali contenuti di origine usare e cosa significhi «corretto» per ciascuno. Per esempio, il campione di articoli potrebbe dover mantenere l’autore originale, due termini tematici, una data di aggiornamento e un allegato scaricabile.

Confronta il risultato in WordPress con Drupal, non soltanto con un modello grafico. Verifica che i contenuti siano modificabili, che i filtri delle tassonomie restituiscano gli elementi attesi e che i media compaiano nel posto giusto. Una pagina può sembrare a posto anche se i relativi termini mancano dal database. Correggere la mappatura dopo un test campione costa molto meno che scoprire lo stesso errore su migliaia di record.

Chiedi al freelance di annotare i problemi emersi durante il test e le modifiche apportate di conseguenza alla mappatura. Questo documento sarà la prima versione delle note di migrazione e impedirà che, al momento del passaggio di consegne, ci si affidi soltanto alla memoria.

4. Definisci le regole per la revisione dei contenuti e il passaggio di consegne editoriale

La migrazione non è il momento giusto per prendere decisioni editoriali senza documentarle. Stabilisci in anticipo come gestire bozze obsolete, pagine duplicate, valori di campo non supportati e contenuti da rivedere. Una regola pratica potrebbe essere migrare per impostazione predefinita i contenuti pubblicati e inserire le bozze in un elenco separato da revisionare; la scelta esatta dipende dal processo di pubblicazione del sito.

È importante stabilire chi decide come gestire i duplicati. Il freelance può segnalare i record con titoli o URL uguali, ma spetta a un editor decidere se unirli, eliminarli o conservarli. Due pagine Drupal con titoli simili potrebbero contenere informazioni diverse: una pulizia automatica rischierebbe di eliminare materiale utile. Tieni un registro delle decisioni con l’URL di origine, l’azione scelta e l’editor responsabile.

Definisci anche come gestire i contenuti multimediali incorporati. Alcuni contenuti Drupal potrebbero rimandare a file archiviati in una posizione legacy o includere un video tramite il codice di un vecchio provider. Decidi se il freelance deve copiare il file, sostituire il contenuto incorporato o segnalarlo per la revisione editoriale. I valori di campo non supportati vanno segnalati, non eliminati senza avviso: un dato mancante potrebbe riguardare un prodotto, un profilo o un’informativa legale.

Concorda chi controllerà i contenuti migrati e come verranno segnalate le eccezioni. Per esempio, il freelance può preparare un foglio di calcolo con i record che non hanno un’immagine, mentre l’editor fornisce le sostituzioni prima del lancio. Un passaggio di consegne ben definito tiene distinto il lavoro tecnico di migrazione dall’approvazione editoriale.

5. Verifica i dati migrati, non solo l’aspetto delle pagine

Un controllo visivo può individuare problemi di impaginazione, ma non conferma che tutti i campi e le relazioni siano stati trasferiti correttamente. Confronta i record Drupal e WordPress per titoli, testo, valori dei campi, assegnazioni delle tassonomie, autori, date e collegamenti ai media. Scegli verifiche adatte al modello dei contenuti del sito, senza limitarti a controllare la homepage.

Quando possibile, usa esportazioni o query al database per confrontare il numero di record e alcuni campi selezionati. Se tra gli elementi da migrare ci sono 240 eventi Drupal, il rapporto di migrazione dovrebbe indicare il numero di record trasferiti oppure elencare le esclusioni specifiche; non dare per scontato che il totale coincida senza verificarlo. Se il numero finale non è ancora noto, segnalalo come dato da verificare anziché inventare un obiettivo.

Verifica le relazioni anche nell’interfaccia WordPress pubblicata. Apri un archivio di tassonomia e controlla che contenga un articolo assegnato al relativo termine. Controlla anche l’archivio degli autori, se l’autorialità è importante per la navigazione. Apri diversi contenuti ricchi di media e assicurati che le immagini o gli allegati siano collegati ai record corretti, non soltanto presenti da qualche parte nella libreria multimediale.

Documenta le eccezioni con dettagli sufficienti per intervenire: identificativo di origine, URL di destinazione, problema, responsabile e stato. Una nota come «alcune immagini non sono corrette» è difficile da gestire. Indicare l’articolo interessato e l’immagine mancante fornisce al freelance e all’editor un compito concreto.

6. Pianifica il passaggio al nuovo sito tenendo conto delle modifiche ai contenuti

Mentre il freelance prepara WordPress, i contenuti potrebbero continuare a cambiare. Prima di avviare la migrazione, scegli se bloccare temporaneamente i contenuti o gestire un trasferimento finale delle modifiche. Nel primo caso, gli editor smettono di pubblicare su Drupal per un periodo concordato, durante il trasferimento finale e le verifiche. Con il secondo metodo, il freelance importa i contenuti iniziali e poi trasferisce i record creati o modificati nel frattempo.

Il blocco delle modifiche è più facile da spiegare, ma può creare problemi a una redazione o un’organizzazione molto attiva. Il trasferimento finale permette di continuare a pubblicare, ma richiede un metodo affidabile per individuare i record modificati ed evitare duplicati. Chiedi chi terrà traccia delle modifiche, quando verrà eseguita l’ultima importazione e come saranno verificate le modifiche apportate durante il passaggio.

Prepara una lista di controllo per il lancio con verifiche specifiche: importazione finale completata, pagine prioritarie esaminate, reindirizzamenti testati, moduli inviati con esito positivo e responsabili dei contenuti avvisati. Se un elemento essenziale non funziona, stabilisci se il lancio deve essere rinviato o se esiste una soluzione alternativa approvata. La decisione va presa prima che arrivi la pressione del giorno del lancio.

7. Completa la consegna di accessi e documentazione e predisponi il ripristino

Al momento della consegna, verifica che il freelance abbia fornito gli script di migrazione, la mappatura dei campi, il registro delle eccezioni e le istruzioni per eseguire eventuali importazioni finali. Chiedi anche note sui tipi di contenuto personalizzati, sulle tassonomie, sulle attività pianificate e su eventuali passaggi manuali necessari a chi si occuperà del sito in futuro. Uno script senza istruzioni potrebbe essere difficile da riutilizzare se tra qualche mese sarà necessario correggere il sito.

Controlla anche gli accessi agli account. Elimina gli account temporanei o riduci i permessi non più necessari, e cambia le credenziali se sono state condivise per la migrazione. Assegna la responsabilità dell’amministrazione di WordPress a una persona specifica, così il sito non dipenderà dall’account personale di un ex collaboratore.

Essere pronti a un ripristino significa conservare una copia di Drupal che possa essere ripristinata e sapere chi può intervenire se il nuovo sito presenta un problema grave al lancio. Concorda dove si trova il backup, chi è responsabile del ripristino e quali condizioni lo rendono necessario. Non eliminare il vecchio sito solo perché WordPress è online: conservalo finché non saranno superate le verifiche concordate e il team non avrà confermato che i contenuti e i flussi di lavoro importanti funzionano come previsto.