Migrazione
Una migrazione senza interruzioni significa che ogni messaggio inviato al suo dominio arriva in una casella, e che ogni dipendente può scrivere ai propri interlocutori il giorno del passaggio. Non significa che lo storico, i dispositivi mobili e le abitudini cambino senza alcun intervento.
Due piattaforme convivono in parallelo.
La falla tipica nasce da un MX spostato mentre una copia è incompleta, oppure da una fotocopiatrice, un sito o un CRM che invia ancora con le vecchie credenziali.
Il MX è un record DNS: indica ai server mittenti dove consegnare la posta del suo dominio. Cambiare servizio di email significa innanzitutto cambiare questo indirizzo di consegna. Il resto (account, storico, dispositivi) si prepara attorno.
Il protocollo SMTP tollera bene gli incidenti brevi. Un server mittente che riceve un errore temporaneo tiene il messaggio in coda e riprova più tardi. Un server momentaneamente irraggiungibile non fa quindi perdere posta. Un errore definitivo (casella sconosciuta, messaggio rifiutato) restituisce invece il messaggio al mittente, e quel messaggio non arriverà mai da solo. Il rischio principale di un passaggio non è il guasto, ma la nuova piattaforma che rifiuta un destinatario perché un alias o una lista non è stato ricreato.
Il TTL (durata di vita) stabilisce per quanto tempo un resolver DNS può conservare una risposta in memoria. Durante questo intervallo, una parte dei mittenti consegna ancora alla vecchia piattaforma. È normale, ed è per questo che la vecchia deve restare in grado di ricevere durante la transizione.
Due settimane prima. Inventario delle caselle, degli alias, delle liste, delle caselle condivise e di tutte le applicazioni che inviano email. Riduzione del TTL DNS del MX a un valore breve (spesso 300 secondi), affinché il giorno X la modifica si propaghi rapidamente. Creazione degli account di destinazione. Prima copia dello storico.
Il TTL si riduce in anticipo perché un resolver che ha letto il vecchio valore lo conserva fino alla scadenza: il TTL breve ha effetto solo una volta esaurita la vecchia cache. La prima copia, dal canto suo, è la più lunga; avviarla presto lascia il tempo di individuare le caselle problematiche.
Alcuni giorni prima. Controllo di un campione: numero di messaggi, cartelle o etichette, appuntamenti, contatti. Correzione del metodo se il campione non supera il controllo. Preparazione delle istruzioni per i dispositivi mobili e per Outlook. Test di invio dalla destinazione verso Gmail e Outlook.com, con SPF, DKIM e DMARC già validi sulla nuova piattaforma. Questi record possono essere pubblicati prima del MX.
In pratica: un solo record SPF che autorizza entrambe le piattaforme durante la transizione (due record SPF distinti fanno fallire la verifica), una chiave DKIM della nuova piattaforma pubblicata con un proprio selettore, accanto alla vecchia, e una policy DMARC ricontrollata. DMARC richiede che il messaggio sia autenticato tramite SPF o DKIM a nome del dominio del mittente; se la sua policy è rigorosa e la destinazione non è ancora autorizzata, i suoi interlocutori rifiutano i suoi messaggi.
Il giorno prima. Seconda passata: copiare soltanto ciò che è arrivato dopo la prima copia. Congelare le modifiche ad alias e liste.
Il giorno X. Passaggio del MX. Verifica esterna immediata: un’email inviata da una casella personale esterna deve arrivare sulla nuova piattaforma entro il TTL. Monitoraggio della coda. Riconfigurazione delle applicazioni che inviano posta. Hotline interna identificata, con l’autorità di ripristinare il vecchio MX se un flusso critico fallisce.
Modifichi contemporaneamente il record autodiscover, se esiste: è quello che Outlook interroga per trovare il proprio server. Rimuova anche i MX secondari che indicherebbero ancora la vecchia piattaforma: un mittente che non riesce a raggiungere il MX principale prova i successivi.
I giorni successivi. La vecchia piattaforma in sola lettura. Segnalazione delle discrepanze (una cartella mancante, una casella condivisa). Terza passata mirata, se necessario. Poi chiusura dell’invio sulla vecchia, affinché un dipendente non risponda più da due posti diversi.
Quest’ultimo punto ha una ragione tecnica. La vecchia piattaforma si considera ancora responsabile del suo dominio: un messaggio inviato da essa a un collega vi viene consegnato localmente, senza consultare il MX. Il collega non lo vedrà mai nella sua nuova casella.
| Rischio | Cosa succede | Contromisura |
|---|---|---|
| MX spostato troppo presto | La posta nuova arriva, lo storico manca | Effettuare il passaggio dopo il controllo del campione e la seconda passata |
| Alias o lista dimenticati | La destinazione rifiuta definitivamente quei messaggi | Inventario, congelamento degli alias il giorno prima, test degli indirizzi collettivi |
| SPF, DKIM o DMARC incompleti | I suoi messaggi vengono rifiutati o classificati come indesiderati dagli interlocutori | Pubblicare prima del giorno X, verificare su un messaggio reale |
| Applicazione che invia con il vecchio account | Fatture, avvisi o scansioni non partono più | Elenco delle applicazioni, nuovo server SMTP configurato il giorno X |
| Invio rimasto aperto sulla vecchia piattaforma | Alcuni messaggi interni restano nel vecchio sistema | Chiudere l’invio non appena il campione è convalidato |
| Ritorno indietro non preparato | Il MX torna indietro, ma i messaggi ricevuti nel frattempo restano sulla destinazione | Piano scritto, con il recupero di quei messaggi |
Prendiamo, a titolo illustrativo, uno studio professionale di 40 persone. Sceglie di effettuare il passaggio un giovedì a fine giornata anziché un venerdì: il giorno dopo il team è presente per gestire le discrepanze, e la hotline interna ha davanti a sé una giornata lavorativa. La fotocopiatrice della reception, che effettua scansioni verso l’email, viene riconfigurata la sera stessa. Se due caselle condivise segnalano una cartella mancante, una passata mirata le completa. In questo scenario nessun messaggio va perso, ma diversi dipendenti devono riconfigurare l’account sul telefono: è la parte visibile che occorre annunciare.
Cambiano server in Outlook o sul dispositivo mobile. Il primo caricamento di una casella voluminosa richiede tempo. I messaggi già presenti nella cache del telefono possono comparire in doppio se il profilo non viene ricreato correttamente. Preveda la procedura «eliminare l’account e ricrearlo» anziché modifiche improvvisate del server.
La ragione è la stessa per Outlook: il profilo conserva una cache locale legata al vecchio server. Un nuovo profilo parte da uno stato pulito; un vecchio profilo modificato mescola i due mondi. Sui dispositivi mobili, il protocollo utilizzato (Exchange ActiveSync o IMAP a seconda della destinazione) a volte cambia con la piattaforma, il che è un motivo in più per ricreare l’account.
Le regole lato server, le firme centralizzate e i diritti di delega vanno reimpostati. Lo comunichi. Non è un’interruzione della posta. È lavoro di amministrazione.
Questo inoltro richiede un’impostazione esplicita: la vecchia piattaforma, che crede ancora di ospitare le caselle, deve essere configurata per inoltrare verso la nuova invece di consegnare localmente. In mancanza di ciò, una passata di recupero mirata svolge lo stesso lavoro.
Le particolarità di ciascun punto di partenza sono descritte in migrare da Microsoft 365 e migrare da Google Workspace.
Il tempo necessario per verificare che nessun flusso utilizzi ancora la vecchia, e che le discrepanze segnalate siano state risolte. Dipende dal numero di caselle, dalle applicazioni che inviano posta e dal ritmo di riconfigurazione delle postazioni. Chiudere troppo presto impedisce di correggere; chiudere troppo tardi lascia i dipendenti a lavorare in due sistemi.
No, se è preparato. Durante il TTL, una parte dei mittenti consegna ancora alla vecchia piattaforma, l’altra alla nuova. Entrambe ricevono, e la passata successiva riunisce le due. La posta si perde solo se viene rifiutata, da qui l’importanza degli alias e delle liste.
In generale no: gli indirizzi non cambiano. Avvisi invece i partner che filtrano rigorosamente i suoi messaggi o che le hanno assegnato una regola particolare, e quelli che scambiano con lei posta cifrata, se le chiavi cambiano.
Sì, ripristinando il vecchio MX, a condizione che la vecchia piattaforma sia ancora attiva. I messaggi ricevuti nel frattempo dalla nuova devono allora essere ricopiati o restare consultabili. Il piano di ritorno indietro stabilisce chi decide, in quanto tempo, e come vengono recuperati quei messaggi.
Chieda all’operatore che cosa garantisce: l’arrivo dei messaggi, il recupero dello storico, o entrambi. Sono impegni diversi. Chieda anche il piano di ritorno indietro, scritto, con la persona che ha l’autorità di attivarlo.
Una garanzia sull’arrivo dei messaggi riguarda il giorno X e i giorni successivi. Una garanzia sullo storico riguarda la copia e il suo controllo. Un fornitore può rispettare l’una senza l’altra; il preventivo deve indicare quale prende in carico e come si verifica.
Presso Klytic, i consigli e i suggerimenti per preparare la migrazione dell’email sono gratuiti, e nessuna email va persa. La migrazione eseguita da Klytic è stabilita su preventivo. Gli abbonamenti sono nella pagina Prezzi e sono fatturati a parte. Il dettaglio delle voci di costo è in quanto costa una migrazione Microsoft 365, e l’elenco dei controlli nella checklist. Per confrontare le destinazioni, vedere scegliere un’email aziendale europea.
Questa pagina descrive un metodo. Lo svolgimento reale dipende dai suoi flussi, dai suoi volumi e dalla piattaforma che lascia.
Consultate a ottobre 2026.
Consigli gratuiti, nessuna email persa. La migrazione eseguita da Klytic è su preventivo, dopo un inventario.
Offerta di benvenuto
Offerta di prova senza impegno. Un consulente la ricontatterà per comprendere le sue esigenze e preparare il suo spazio Klytic.
