Una migrazione sito web viene quasi sempre pianificata come un problema tecnico e valutata su un unico indicatore, il traffico organico prima e dopo. È legittimo ed è anche il più presidiato: esiste una disciplina intera dedicata alla governance della migrazione e alla protezione del traffico organico, e questo articolo non ritorna su quel terreno.
Guarda invece i tre rischi che nessuno mette a piano perché non appartengono a un reparto solo: i contenuti che spariscono senza che nessuno abbia deciso di eliminarli, i dati e le integrazioni che si interrompono in silenzio, e le settimane in cui l'organizzazione lavora con un sito a metà.
Key takeaways
- Le perdite di una migrazione si dividono in recuperabili e definitive: le seconde riguardano quasi sempre i contenuti e i contatti raccolti nella finestra di transizione.
- La decisione su che cosa non migra è editoriale e va firmata, non subita.
- Il guasto più costoso è silenzioso: un modulo che risponde correttamente al visitatore e non scrive nulla nel sistema di gestione dei contatti.
- I reindirizzamenti vanno mantenuti almeno un anno, e i controlli non finiscono con il lancio.
Che cosa si perde davvero in una migrazione sito web
Le perdite si distribuiscono su quattro categorie. I contenuti: pagine, documenti scaricabili, versioni linguistiche che non arrivano dall'altra parte. I dati: contatti raccolti mentre i moduli erano fuori uso, tracciamenti interrotti, consensi non trasferiti. Le integrazioni: collegamenti verso il sistema di gestione dei contatti, i gestionali, gli strumenti di prenotazione. Il tempo di lavoro: le settimane in cui il marketing non pubblica.
La distinzione che conta è fra perdita recuperabile e perdita definitiva. Una pagina non migrata si ripubblica. Un contatto che ha compilato un modulo mentre il collegamento era rotto non torna: ha già ricevuto un silenzio e ha continuato la valutazione altrove. Lo stesso vale per i consensi: se la base giuridica non viene trasferita insieme al contatto, il dato esiste ma non è utilizzabile.
Contenuti: che cosa migra, che cosa si archivia, chi decide
L'inventario dei contenuti va fatto prima del progetto. Serve un elenco con quattro attributi per riga: traffico ricevuto, conversioni generate, valore commerciale dichiarato da chi lo usa, obblighi di conservazione. Le prime due colonne si estraggono, le altre due si chiedono.
Il criterio di dismissione nasce dall'incrocio. Una pagina senza traffico e senza conversioni si archivia; una che il commerciale invia regolarmente a un prospect no, e nessuna analisi di dati lo avrebbe rilevato. I documenti scaricabili meritano una verifica a parte: sono spesso collegati da email e campagne attive, e un file che cambia indirizzo interrompe un percorso ancora alimentato.
Il caso più delicato riguarda le lingue. Chi ha dovuto creare un sito web internazionale sa che non tutte hanno lo stesso grado di aggiornamento. In una migrazione l'asimmetria va dichiarata nel piano sito web: scegliere se tradurre il mancante o ridurre il perimetro linguistico è una decisione di posizionamento su quel mercato, non una scelta tecnica da lasciare a chi esegue il trasferimento.
La decisione di dismettere ha bisogno di una firma. Quando non ce l'ha, si trasforma in una selezione implicita fatta da chi esegue la migrazione, sulla base di criteri tecnici che nessuno ha discusso. È il modo più comune in cui un'azienda perde contenuti a cui teneva.
Dati e integrazioni: dove si rompe il collegamento con il CRM
La superficie di rischio cresce con la maturità digitale dell'azienda: nel 2025 il 28,51% delle imprese europee usava un CRM e il 46,45% un ERP (Fonte), e ogni sistema collegato è un punto in cui la migrazione può interrompere un flusso.
| Elemento | Come si rompe | Segnale che il guasto è avvenuto | Controllo prima del go-live |
|---|---|---|---|
| Moduli di contatto | Mappatura dei campi non replicata | Invii che non compaiono nel CRM | Invio di prova per ogni modulo, verificato a destinazione |
| Tracciamenti e consensi | Codice non riportato o consenso non collegato | Attribuzione azzerata, contatti senza base giuridica | Verifica del consenso registrato su un contatto reale |
| Aree riservate | Utenze non migrate o password non valide | Richieste di assistenza in aumento | Accesso di prova con utenze esistenti |
| Prenotazioni e assistenza | Codice di incorporamento obsoleto | Calendario vuoto senza motivo | Prenotazione di prova completata |
| Feed e integrazioni verso terzi | Indirizzo di origine cambiato | Sistemi a valle fermi al giorno della migrazione | Chiamata di prova su ogni integrazione attiva |
Il guasto silenzioso: un modulo che risponde 200 e non scrive nulla nel CRM
È il caso peggiore perché non produce nessun errore visibile. Il visitatore compila, riceve la conferma, il server risponde correttamente e il dato non arriva a destinazione. Nessun avviso, nessuna dashboard che segnali qualcosa, e il calo di contatti attribuito alla stagionalità.
Il controllo che lo intercetta è procedurale, non tecnico: per ogni modulo un invio di prova con un indirizzo tracciabile, verificato sul record creato nel sistema di destinazione e non sulla pagina di conferma. Conoscere il significato dei codici di stato che il server restituisce aiuta a capire perché: una risposta corretta non dice nulla su ciò che è successo dopo.
Continuità operativa: il piano per la finestra di transizione
La finestra di transizione comincia con il congelamento delle pubblicazioni e finisce quando i controlli post-lancio sono chiusi. Va dichiarata in anticipo, con data di inizio e durata stimata: è il periodo in cui il marketing non pubblica e il commerciale deve sapere che i contatti in arrivo vanno verificati a mano.
Quattro decisioni vanno prese prima. Chi verifica, con una lista di controlli assegnata per nome e non per reparto. Chi decide il ripristino, con l'autorità di farlo senza convocare una riunione. Chi comunica ai clienti in caso di disservizio prolungato, e su quale canale. Quale canale alternativo raccoglie i contatti se i moduli restano fuori uso.
Il criterio di ripristino merita una riga a parte. Scritto prima è una soglia oggettiva: se dopo un tempo definito una funzione essenziale non è ripristinata, si torna indietro. Deciso durante, diventa una discussione fra persone che hanno lavorato settimane al lancio. Il pubblico, del resto, è già stato preparato, perché le attività di lancio si pianificano prima: e questo alza il costo di un ripristino improvvisato.
I controlli dei primi trenta giorni dopo la migrazione sito web
Il primo giorno si verificano le funzioni che producono contatti: ogni modulo, ogni prenotazione, ogni area riservata, con prove reali e verifica a destinazione. La prima settimana si confrontano i contatti raccolti al giorno con la media dei tre mesi precedenti: uno scarto persistente è un guasto, non una fluttuazione. Al trentesimo giorno si riprende l'inventario e si verifica che ogni riga marcata come "migra" abbia un indirizzo raggiungibile. Questa sequenza post go live è la parte che viene tagliata più spesso, perché arriva quando il gruppo di lavoro si è sciolto: assegnarla per nome, con una data, è l'unico modo per non perderla.
Sui tempi conviene avere aspettative realistiche. Google dichiara che per un sito di medie dimensioni servono alcune settimane o più perché i nuovi indirizzi sostituiscano i vecchi nei risultati, di più per i siti grandi, e raccomanda di mantenere i reindirizzamenti almeno un anno, il tempo necessario a trasferire tutti i segnali (Fonte). Una migrazione non si chiude al lancio: si chiude quando i controlli smettono di rilevare scarti.
Gli indicatori di continuità da tenere sotto osservazione sono quattro: contatti raccolti al giorno rispetto alla baseline, tasso di errore dei moduli, tempo di risposta al primo contatto, numero di indirizzi che restituiscono errore. Sono gli stessi che dicono, a fine progetto, se la migrazione è costata qualcosa oltre al budget. Nei progetti di replatforming Digital360 Connect assegna questi controlli prima del go-live, insieme al criterio di ripristino.
Conclusione
Il rischio di una migrazione non sta nel trasferimento dei file, sta nelle decisioni che nessuno prende in tempo: che cosa non migra, chi verifica che i dati arrivino, chi ha l'autorità di fermare il lancio. Tre documenti brevi, da scrivere prima.
FAQ: rischi della migrazione di un sito aziendale
Quali rischi comporta la migrazione di un sito web aziendale?
Quattro: contenuti che non arrivano a destinazione, dati e consensi non trasferiti, integrazioni interrotte verso i sistemi a valle, contatti persi nella finestra di transizione. Solo i primi due sono recuperabili.
Quanto dura la fase di rischio dopo una migrazione di un sito web?
I controlli sulle funzioni che producono contatti si chiudono entro il primo giorno; il riassestamento nei risultati di ricerca richiede alcune settimane per un sito di medie dimensioni, di più per i siti grandi.
Come si verifica che i moduli continuino ad alimentare il CRM dopo la migrazione?
Con un invio di prova per ogni modulo, verificato sul record creato a destinazione e non sulla pagina di conferma: una risposta corretta del server non dimostra che il dato sia arrivato.
Per quanto tempo vanno mantenuti i redirect dopo una migrazione?
Google raccomanda di mantenerli il più a lungo possibile, in generale almeno un anno, perché è il tempo necessario a trasferire tutti i segnali ai nuovi indirizzi.