Due mesi fa un cliente mi ha chiamato di lunedi mattina. Tono che conosco bene: quello di chi ha fatto qualcosa nel weekend e adesso si pente. Aveva deciso di migrare le email aziendali da solo, da un hosting condiviso a Google Workspace. Risultato: 14 caselle email inaccessibili, i record DNS del dominio puntavano al vecchio provider per la posta e al nuovo per il sito, e quattro anni di email archiviate erano spariti nel passaggio. Il lunedi mattina i suoi 14 dipendenti hanno acceso il PC e non avevano piu la posta.
Questa storia la racconto perche e il modo in cui il 90% delle migrazioni email fai-da-te finisce. Non sempre cosi drammaticamente, ma con qualche danno: email perse, ore di downtime, allegati che non si aprono, risposte dei clienti che finiscono nel vuoto per giorni.
In questo articolo ti spiego come si fa una migrazione email aziendale senza perdere dati, con tempi reali e tool concreti. Lo faccio perche queste migrazioni le gestisco ogni mese, e le cose che possono andare storte le ho viste tutte.
Quando una PMI deve migrare le email (e quando puo aspettare)
Non tutte le migrazioni sono urgenti. Prima di muovere qualsiasi cosa, devi capire se il tuo caso richiede una migrazione adesso o se puoi pianificarla con calma.
Devi migrare subito se:
- Il tuo provider chiude o ti ha comunicato la dismissione del servizio. Succede piu spesso di quanto pensi, soprattutto con piccoli hosting italiani che decidono di non offrire piu il servizio email. Ti danno 30 giorni di preavviso e tu devi muoverti.
- Stai avendo problemi ricorrenti di deliverability. Le tue email finiscono regolarmente nello spam dei clienti? Se il tuo provider ha un IP in blacklist e non riesce a risolvere, migrare e l'unica soluzione reale.
- Hai subito un incidente di sicurezza. Account compromessi, accessi non autorizzati, phishing partito dalle tue caselle. In questi casi la migrazione a un provider con autenticazione a due fattori e policy di sicurezza serie non e un lusso -- e una necessita.
Puoi pianificare con calma se:
- Stai crescendo e il provider attuale non scala. L'hosting ti offre caselle da 1 GB e ne hai bisogno di 50 GB? E un problema reale, ma puoi pianificare la migrazione in 4-6 settimane senza fretta.
- Vuoi passare a Google Workspace o Microsoft 365. Se il servizio attuale funziona, puoi prendere il tempo necessario per fare le cose bene. Ho scritto un confronto dettagliato tra Google Workspace e Microsoft 365 che ti aiuta a decidere.
- Fusione o acquisizione. Due aziende che si uniscono devono consolidare i sistemi email. Qui la pianificazione e tutto: servono settimane, non giorni.
I rischi reali della migrazione fai-da-te
Lo dico senza mezzi termini: la migrazione email e l'operazione piu sottovalutata nell'IT delle PMI. Sembra semplice -- "sposto le email da A a B" -- ma ci sono almeno quattro modi in cui puo andare storto.
Perdita di dati. E il rischio numero uno. Se non fai un backup completo prima di iniziare, e qualcosa va storto durante il trasferimento, le email sono perse. Non "temporaneamente inaccessibili". Perse. E come ho spiegato nell'articolo sugli obblighi di conservazione delle email aziendali, alcune di quelle email devi conservarle per legge per 10 anni.
Downtime prolungato. I record DNS hanno un tempo di propagazione. Quando cambi i record MX per puntare al nuovo provider, ci vogliono da 1 a 48 ore perche la modifica si propaghi globalmente. Durante quel periodo, alcune email arrivano al vecchio server e alcune al nuovo. Se non gestisci questa finestra correttamente, perdi messaggi.
DNS mal configurati. Questo e l'errore che vedo piu spesso. Cambi i record MX ma dimentichi SPF. Oppure aggiorni SPF ma non configuri DKIM sul nuovo provider. Risultato: le tue email partono dal nuovo server ma vengono respinte come sospette. I tuoi clienti non ricevono le tue risposte e tu non lo sai finche qualcuno non ti chiama per chiedere "ma mi hai risposto?".
Struttura delle cartelle persa. Migrare le email non significa solo copiare i messaggi. Significa preservare la struttura delle cartelle, le etichette, le regole, i contatti, i calendari. Molti tool di migrazione copiano solo il contenuto della inbox. Tutto il resto sparisce.
Prima di tutto: il backup completo
Regola non negoziabile: prima di toccare qualsiasi cosa, fai un backup completo di tutte le caselle email. Non "delle caselle importanti". Di tutte.
Il backup deve includere:
- Tutti i messaggi di tutte le cartelle (inbox, inviati, bozze, cestino, cartelle personalizzate)
- Gli allegati
- I contatti
- I calendari
- Le regole e i filtri (dove possibile esportarli)
Come faccio il backup con i miei clienti:
- Connessione IMAP con un client desktop. Configuro Thunderbird o Outlook su un PC, collego tutte le caselle via IMAP, e aspetto che sincronizzi tutto. Poi esporto in formato MBOX (Thunderbird) o PST (Outlook). Questo mi da un archivio locale completo e leggibile.
- Export nativo del provider. Se il provider attuale offre un'opzione di export (Google Takeout per Google Workspace, export PST per Exchange/Microsoft 365), la uso come secondo backup. Mai fidarsi di un solo backup.
- Verifica del backup. Apro i file esportati e verifico che le email ci siano davvero. Ho visto backup MBOX da 0 KB che il sistema dichiarava "completati con successo". La verifica non e opzionale.
Tempo necessario per il backup: dipende dal volume. Per 10 caselle con una media di 5 GB ciascuna, il download IMAP richiede 4-8 ore con una buona connessione. Non e un'operazione da fare alle 17:55 del venerdi.
Scegliere il nuovo provider email
Non ripeto qui il confronto completo tra piattaforme -- lo trovi nel mio articolo Google Workspace vs Microsoft 365 per PMI. Ma ci sono criteri specifici che contano quando scegli un provider nel contesto di una migrazione:
- Supporto alla migrazione. Google Workspace ha un tool di migrazione integrato nella console admin. Microsoft 365 offre il Migration Manager. Se il provider che scegli non ha strumenti di migrazione nativi, dovrai usare tool di terze parti e la complessita aumenta.
- Compatibilita IMAP. Il protocollo IMAP e lo standard per la migrazione. Verifica che sia il vecchio che il nuovo provider supportino IMAP completo, non una versione castrata.
- Limiti di import. Alcuni provider hanno limiti sulla dimensione dei messaggi importabili o sulla velocita di import. Google Workspace, per esempio, limita l'upload via IMAP a circa 500 MB al giorno per casella -- non all'ora, al giorno. Su una casella da 10 GB, parliamo di 20 giorni solo di trasferimento. Per questo Google stessa sconsiglia IMAP per le migrazioni e raccomanda il Data Migration Service nativo della console admin, che non ha questo limite.
Preparare il DNS: la parte che tutti sottovalutano
La configurazione DNS e il punto dove le migrazioni fai-da-te falliscono piu spesso. E anche il punto dove i danni sono meno visibili e piu pericolosi -- perche non ti accorgi subito che qualcosa non funziona.
Ecco cosa devi fare, nell'ordine giusto:
- Abbassa il TTL dei record MX almeno 48 ore prima della migrazione. Il TTL (Time To Live) dice ai server DNS per quanto tempo tenere in cache i tuoi record. Se il TTL e 86400 (24 ore, il default di molti hosting), dopo il cambio dei record MX ci sara un giorno intero in cui alcuni server puntano ancora al vecchio provider. Abbassalo a 300 (5 minuti) almeno due giorni prima. Cosi quando fai il cambio reale, la propagazione sara quasi istantanea.
- Prepara i nuovi record MX, SPF, DKIM e DMARC. Scrivili prima in un file di testo. Verificali due volte. Non improvvisare nel pannello DNS alle 22 di sera.
- Non toccare gli altri record. A, CNAME, record per il sito web -- non li tocchi durante la migrazione email. Uno degli errori piu comuni e fare pulizia DNS durante la migrazione e tirare giu il sito insieme alla posta.
Un record SPF sbagliato dopo la migrazione puo significare settimane di email che finiscono nello spam dei tuoi clienti. E tu non lo sai finche il cliente non ti chiama e dice "non ricevo le tue email da dieci giorni". Dieci giorni di comunicazioni perse con i clienti. Fai il conto del danno.
Migrazione delle caselle: come si fa concretamente
Ci sono tre approcci alla migrazione vera e propria, e la scelta dipende dalla dimensione dell'azienda e dai provider coinvolti.
Approccio 1: Migrazione IMAP diretta (da qualsiasi provider a qualsiasi provider)
Funziona sempre, con qualsiasi combinazione di provider. Il principio e semplice: un tool si collega al vecchio server via IMAP, scarica tutto, e lo carica sul nuovo server via IMAP. E il metodo che uso piu spesso perche funziona universalmente.
Approccio 2: Tool di migrazione nativo del provider
Google Workspace offre il Data Migration Service nella console admin. Funziona bene per migrazioni da Exchange, Microsoft 365 o altri server IMAP verso Google. Il vantaggio: gestisci tutto dalla console senza installare nulla. Il limite: supporta solo la migrazione verso Google, non da Google verso altri.
Microsoft 365 ha il Migration Manager per migrazioni da Gmail, Exchange on-premise, e file share. Funziona in modo simile: tutto dalla console admin, ma solo verso Microsoft.
Approccio 3: Tool di terze parti per migrazioni grandi
Per migrazioni sopra le 50 caselle, i tool nativi possono essere lenti o limitati. In questi casi uso tool dedicati che gestiscono il processo in parallelo, con report dettagliati e retry automatico sugli errori.
Tool per la migrazione email: quali funzionano davvero
Questi sono i tool che uso nella pratica, non quelli che ho letto in un articolo.
| Tool | Tipo | Costo | Quando lo uso |
|---|---|---|---|
| imapsync | Codice su GitHub, linea di comando | Licenza da 72 EUR | Migrazioni piccole-medie (fino a 30 caselle). Affidabile, collaudato, funziona con qualsiasi server IMAP. Richiede competenze tecniche. |
| Google Workspace Migration | Integrato nella console Google Admin | Incluso nel piano | Migrazioni verso Google Workspace da qualsiasi server IMAP o Exchange. Semplice, ma lento su caselle grandi. |
| BitTitan MigrationWiz | SaaS, interfaccia web | 14 USD per casella | Migrazioni grandi (50+ caselle) o complesse (Exchange on-premise verso cloud). Gestisce calendari, contatti, permessi. Il migliore per migrazioni enterprise-grade verso Microsoft 365. |
| CloudM (ex Migrate) | SaaS | Da 7 USD per utente | Migrazioni tra piattaforme cloud (Google a Microsoft e viceversa). Buono per migrazioni bidirezionali. |
| MailStore | Software on-premise | Licenza a partire da 295 EUR / 259 USD | Non e un tool di migrazione ma di archiviazione. Lo uso per fare il backup certificato prima della migrazione e come archivio post-migrazione. |
Il mio consiglio: se hai meno di 30 caselle e un minimo di competenza tecnica, imapsync e la scelta migliore. Costa 72 EUR, e affidabile, e ti da controllo totale. Se hai piu di 50 caselle o devi migrare tra piattaforme cloud, BitTitan MigrationWiz vale ogni euro speso -- il tempo che risparmi supera il costo della licenza.
Tempi reali: quanto dura una migrazione email aziendale
Questi sono tempi reali, basati sulle migrazioni che ho fatto negli ultimi due anni. Non tempi teorici.
| Dimensione | Preparazione | Migrazione dati | Test e cutover | Totale |
|---|---|---|---|---|
| 10 caselle (PMI piccola) | 1-2 giorni | 4-8 ore | 1 giorno | 3-4 giorni lavorativi |
| 50 caselle (PMI media) | 3-5 giorni | 1-2 giorni | 2 giorni | 1-2 settimane |
| 100 caselle (PMI strutturata) | 1 settimana | 2-4 giorni | 3-5 giorni | 2-4 settimane |
Nota importante: la migrazione dati puo girare di notte e nel weekend. Non devi tenere i dipendenti fermi per tutto quel tempo. La preparazione e i test li fai prima del cutover, e il cutover lo pianifichi nel momento di minor traffico -- il venerdi sera o il sabato mattina.
Un caso concreto: tre mesi fa ho migrato 28 caselle da un hosting condiviso Aruba a Google Workspace per un'azienda di trasporti. Preparazione: 2 giorni (backup, configurazione Google Workspace, preparazione DNS). Migrazione dati con imapsync: partita il venerdi alle 18, finita il sabato alle 6. Cutover DNS sabato mattina alle 8. Test: sabato e domenica. Lunedi mattina i 28 dipendenti hanno acceso il PC e trovato tutte le loro email su Gmail. Zero messaggi persi. Zero downtime lavorativo.
Il cutover: quando si preme il pulsante
Il cutover e il momento in cui cambi i record MX e il traffico email inizia ad arrivare al nuovo server. E il punto di non ritorno -- o meglio, il punto dove il ritorno diventa molto costoso.
La mia checklist prima di premere il pulsante:
- Tutte le caselle sono state migrate e verificate. Non "quasi tutte". Tutte.
- Il backup del vecchio server e completo e verificato. Lo tengo per almeno 30 giorni dopo il cutover.
- I nuovi record MX, SPF, DKIM e DMARC sono pronti in un file di testo, copiabili.
- Il TTL dei record MX e stato abbassato 48 ore fa. Se non lo hai fatto, aspetta.
- Ogni utente ha testato il login sul nuovo sistema. Non basta che tu lo abbia testato. Ogni utente deve entrare nella sua casella nuova e confermare che vede le email migrate.
- Il vecchio server resta attivo in ricezione per 72 ore. Durante la propagazione DNS, alcuni server continueranno a mandare email al vecchio indirizzo. Se lo spegni subito, perdi quei messaggi. Lo tengo attivo in parallelo e controllo periodicamente se arriva qualcosa.
Dopo il cutover: monitoro per 72 ore. Controllo i log del vecchio server per intercettare email che arrivano ancora li e le inoltro manualmente. Verifico che le email in uscita dal nuovo server non finiscano in spam (test con mail-tester.com o mxtoolbox.com). Solo dopo 72 ore senza problemi considero la migrazione completata.
Gli errori che vedo ogni settimana
Dopo anni di migrazioni, questi sono gli errori che si ripetono. Li elenco perche se stai pianificando una migrazione, almeno questi puoi evitarli.
- "Faccio il backup dopo, prima migro." No. Il backup si fa prima. Sempre. Ho avuto un cliente che ha perso tre anni di email perche ha spento il vecchio server prima di verificare che la migrazione fosse completa. Tre anni di corrispondenza commerciale -- con tutti i problemi legali che ne conseguono.
- Dimenticare SPF e DKIM. Cambiano i record MX, le email iniziano ad arrivare sul nuovo server, tutto sembra funzionare. Ma il record SPF punta ancora al vecchio provider. Risultato: le email in uscita vengono rifiutate o marcate come spam. Lo scopri dopo tre giorni quando un cliente ti chiama.
- Non abbassare il TTL. Lasciano il TTL a 86400 e poi si chiedono perche dopo 24 ore alcune email arrivano ancora al vecchio server. Matematica elementare: se il TTL e 24 ore, ci vogliono 24 ore di propagazione. Se lo abbassi a 5 minuti, la propagazione e quasi istantanea.
- Migrare il venerdi pomeriggio senza piano. "Tanto nel weekend non lavora nessuno." Falso. I clienti mandano email anche nel weekend. E se qualcosa va storto il venerdi sera, il tecnico del provider non risponde fino a lunedi. Il venerdi sera va bene solo se hai un piano dettagliato e hai fatto tutto il lavoro preparatorio prima.
- Non comunicare ai dipendenti. I dipendenti accendono il PC lunedi e trovano una schermata diversa. Non sanno la password del nuovo sistema. Non trovano le cartelle. Chiamano tutti contemporaneamente. Caos. Un'email interna tre giorni prima della migrazione con istruzioni chiare risolve il 90% dei problemi.
- Spegnere il vecchio server troppo presto. Il vecchio server va tenuto attivo in ricezione per almeno 72 ore dopo il cutover. Meglio una settimana. Il costo di un mese in piu di hosting e trascurabile rispetto al rischio di perdere email durante la propagazione DNS.
Quando ha senso farsi aiutare
Sono onesto: una migrazione di 5 caselle da un hosting a Google Workspace la puo fare anche un titolare con buone competenze tecniche, seguendo questa guida passo passo. Ci vogliono mezza giornata di preparazione, una sera per la migrazione, un giorno di test.
Ma sopra le 10 caselle, o quando la migrazione coinvolge piattaforme diverse (Exchange on-premise verso cloud, per esempio), il rischio di fare danni supera il costo di un professionista. Non perche sia difficile in teoria -- perche nella pratica ci sono decine di variabili che non puoi prevedere se non le hai gia viste.
Il DNS che non si propaga perche il registrar ha una cache interna. Il tool di migrazione che si blocca a meta perche il vecchio server ha un timeout IMAP di 30 secondi. La casella del direttore che pesa 45 GB e fa saltare il limite di upload del nuovo provider. L'alias email che esisteva solo sul vecchio server e che nessuno si ricordava ma che riceveva il 30% degli ordini.
Queste sono le cose che rendono una migrazione email complicata. E sono le cose che un consulente IT che fa migrazioni ogni mese conosce e gestisce prima che diventino problemi.
Se stai pianificando una migrazione e vuoi capire cosa comporta nel tuo caso specifico, qui spiego come gestisco le migrazioni email per le PMI -- con tempi, costi e cosa includo nel servizio.