Se ti serve una checklist per la migrazione email, parti da questa regola: la posta non si migra trascinando cartelle. È un sistema attivo, con stati dei messaggi che cambiano, alias, inoltri, limitazioni, client malfunzionanti e utenti che continuano a inviare mentre lavori. Ecco perché i passaggi approssimativi falliscono. Se stai ancora decidendo dove ospitare la posta dopo il trasferimento, leggi prima la guida all'email aziendale per piccole imprese. Se sai già di dover migrare, usa questo runbook e rendi il passaggio noioso.
Il problema è semplice. Molti team copiano la posta, cambiano il record MX e sperano. Il lunedì emergono gli elementi mancanti: l'archivio del fondatore, l'inoltro delle fatture, la casella condivisa che in realtà era un account usato da cinque persone. Questa checklist risolve il problema imponendo analisi, sincronizzazione preliminare, verifica, nuovi tentativi e ripristino in un unico documento operativo.
| Approccio | Vecchio metodo | Nuovo metodo |
|---|---|---|
| Pianificazione | Copiare tutto in un fine settimana | Verificare, preparare, trasferire, controllare e bloccare la sorgente |
| Metrica di successo | La dimensione della casella sembra simile | Conteggi, log degli errori e invii di prova coincidono |
| Gestione degli errori | Riprovare finché qualcuno si lamenta | Attesa, responsabile e causa di ripristino definiti per ogni errore |
| Attività successive | Lasciare attiva la vecchia posta per giorni | Bloccare gli accessi obsoleti e ricreare rapidamente i client guasti |
Checklist prima di copiare anche un solo messaggio
Una checklist per la migrazione parte dalla visibilità. Prima di spostare un byte, serve un inventario programmatico di caselle, alias, regole di inoltro, dimensioni e limiti sul lato sorgente. Se l'analisi è debole, ogni passaggio successivo diventa più lento, rischioso e costoso.
Non fidarti delle esportazioni delle risorse umane o del foglio che il cliente ha inviato il mese scorso. Estrai i dati dalla piattaforma sorgente e crea un inventario che risponda a cinque domande:
- Quali caselle esistono e quali ricevono ancora posta?
- Quali alias e account di ruolo rimandano a queste caselle?
- Quali utenti hanno consumi di spazio anomali?
- Quali regole di inoltro della posta in arrivo, del trasporto o della casella sono attive?
- Quali account sono indirizzi operativi condivisi e non caselle personali?
L'ultimo punto conta più di quanto si ammetta. invoices@, support@ e hello@ sembrano spesso caselle normali fino al giorno del passaggio. Poi nessuno sa chi ne sia responsabile, quale dispositivo sia ancora connesso o dove finiscano le risposte.
Esegui anche un controllo sui dati problematici. Cerca MIME malformato, allegati troppo grandi e alberi di cartelle assurdi. IMAP può trasferire molto, ma non trasforma dati sorgente danneggiati in dati di destinazione integri. Ricorda anche ciò che IMAP trasferisce male o non trasferisce. Il flusso di TrekMail riguarda solo la posta, quindi calendari e contatti richiedono un piano separato. La panoramica della migrazione IMAP di TrekMail chiarisce questo confine.
Esempio: una casella contiene 14,200 elementi nella sorgente, ma due messaggi sono danneggiati e un allegato da 80 MB supera la policy di destinazione. Se il runbook dice “la dimensione sembra corretta”, non te ne accorgi. Se richiede conteggi e verifica del log degli elementi non riusciti, trovi il problema prima degli utenti.
Checklist per progettare il passaggio
La checklist deve scegliere l'architettura di migrazione prima che qualcuno pianifichi il passaggio nel fine settimana. Le caselle piccole possono tollerare un trasferimento in un'unica operazione. Le aziende reali di solito no. Precarica la posta storica, lascia le modifiche recenti al delta finale e cambia il DNS solo quando le caselle più lente sono quasi complete.
Esistono tre schemi comuni:
| Schema | Ideale per | Rischio principale |
|---|---|---|
| Passaggio unico | Team minuscoli con caselle leggere | Nessun margine se limitazioni o dati corrotti emergono durante il passaggio |
| Precaricamento più delta | La maggior parte delle migrazioni di PMI e MSP | Richiede log rigorosi e un secondo passaggio |
| Ibrido | Grandi ambienti Exchange | Complessità inutile per la maggior parte dei piccoli team |
Per la maggior parte dei lettori, precaricamento più delta è la scelta giusta. Una pianificazione pratica è questa:
- T meno 14 giorni: migrare prima la posta vecchia e individuare le caselle lente.
- T meno 7 giorni: confermare alias, regole di inoltro e associazione delle caselle di destinazione.
- T meno 2 giorni: abbassare il TTL DNS, provare l'autenticazione e controllare i log degli errori.
- T zero: cambiare MX, aggiornare SPF e DKIM, eseguire il delta e poi sistemare i client.
- T più 1 giorno: verificare i conteggi, provare posta in entrata e in uscita e disattivare il vecchio accesso.
Se sbagli il DNS, il flusso della posta si interrompe. Abbassa il TTL con almeno 48 ore di anticipo, quindi confronta i record di destinazione con i record DNS obbligatori di TrekMail.
example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
# DKIM value is generated per domain in the TrekMail dashboard.
Nelle prime 24 fino a 48 ore dopo il cambio MX, una policy DMARC temporanea p=none può ridurre i rifiuti causati dalla propria configurazione mentre le cache si assestano. Quando il trasferimento è stabile, torna a una policy più severa. Questo consiglio conta ancora di più se invii volumi significativi a Gmail. Le linee guida di Google per i mittenti ora impongono SPF, DKIM, allineamento, TLS e DMARC ai mittenti di massa.
Checklist per precaricamento e sincronizzazione delta
La parte centrale di una migrazione riguarda la fisica, non l'ottimismo. IMAP copia i messaggi cartella per cartella e i grandi provider impongono limiti di banda e frequenza. Devi spostare presto la posta vecchia, controllare i nuovi tentativi e rendere il delta finale abbastanza piccolo da terminare nella finestra prevista.
Qui molte migrazioni esplodono. IMAP si basa sugli identificatori dei messaggi e sullo stato delle caselle. Il comportamento degli UID e di UIDVALIDITY nella RFC 3501 spiega perché cartelle reindicizzate o danneggiate possano causare risincronizzazioni problematiche. Se lo strumento supporta l'esclusione dei duplicati o il confronto per contenuto, usalo. La procedura guidata di TrekMail include l'opzione per ignorare i duplicati, e i passaggi sono descritti in Avviare una migrazione dal pannello.
Agli operatori che provano strumenti da riga di comando prima di intervenire in produzione conviene tenere aperta la guida complementare a imapsync.
imapsync \
--host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--syncinternaldates \
--exclude 'Calendar|Contacts' \
--skipsize
Calcola la banda prima di promettere la fine in un weekend. Google pubblica i limiti IMAP di Gmail, compreso un massimo giornaliero di download di 2,500 MB per account. Microsoft funziona diversamente, ma non è più generosa. Secondo Microsoft, le prestazioni variano e risentono delle limitazioni del servizio. Ecco perché una sola casella enorme può distruggere il programma se viene scoperta tardi.
Mantieni realistico anche il destino. TrekMail usa solo IMAP e non è una suite per ufficio completa. Durante una migrazione questo è un vantaggio, perché l'ambito resta chiaro: spostare la posta, verificarla e poi gestire separatamente calendari e contatti senza mescolare aree di errore.
Checklist di verifica dopo il cambio DNS
Una checklist solida tratta la verifica come una fase separata, non come un'occhiata alla dimensione della casella. Le dimensioni ingannano. Le codifiche cambiano, gli allegati sono gestiti diversamente da ogni piattaforma e il calcolo dello spazio lato server non è uniforme. Conteggi, verifiche a campione, invii di prova e analisi degli errori mostrano se la posta ha davvero superato il trasferimento.
Usa una semplice matrice per ogni classe di casella: dirigenti, account condivisi, utenti ordinari e utenti con caselle sovradimensionate.
| Verifica | Che cosa confrontare | Condizione di riuscita |
|---|---|---|
| Conteggio elementi | Totali delle cartelle sorgente e destinazione | Corrispondenza esatta o differenze spiegate nei log |
| Flusso della posta | Entrata esterna, uscita esterna e posta interna | Tutti e tre funzionano e arrivano nella casella prevista |
| Alias | Prove di risposta e ricezione per ogni alias | Nessun rimbalzo e consegna alla casella corretta |
| Inoltro | Inoltri critici noti | Regole ricreate e documentate |
| Accesso client | Outlook, Apple Mail e client mobili | Nuovo profilo o nuova aggiunta funziona senza autenticazione sorgente obsoleta |
La checklist deve includere anche un passaggio per gli accessi obsoleti. Al termine del delta, impedisci agli utenti di accedere alla vecchia piattaforma. Altrimenti un telefono dimenticato o un profilo Outlook può ancora inviare o ricevere dalla sorgente, lasciando lì i messaggi.
Le impostazioni dei client TrekMail sono semplici: host IMAP imap.trekmail.net, porta 993 e indirizzo email completo come nome utente. POP3 non è supportato. I valori esatti sono nella guida alle impostazioni IMAP e SMTP. Se Outlook continua ad aggrapparsi al vecchio server, smetti di applicare correzioni e crea un nuovo profilo.
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
Checklist per tentativi, log e ripristino
L'ultimo terzo della checklist stabilisce che cosa fare quando il piano entra in crisi. Servono regole per i tentativi, campi dei log, responsabili delle escalation e una soglia di ripristino prima di avviare la prima casella. Inventarli sotto pressione porta a decisioni sbagliate.
Il log deve registrare casella, cartella, data e ora, server sorgente, server di destinazione, elementi tentati, elementi copiati, byte copiati, numero di tentativi, stato finale ed errore comprensibile. Poi classifica rapidamente i problemi:
| Errore | Significato | Azione dell'operatore |
|---|---|---|
| Errore di autenticazione | Password errata, password dell'app mancante o accesso sorgente bloccato | Correggere le credenziali, riprovare su una casella e riprendere il lotto |
| Connessione rifiutata | Porta errata, SSL incompatibile, firewall o problema dell'host sorgente | Verificare host e porta 993 e provare manualmente prima di ripetere |
| Limitazione o attesa tipo 429 | Il provider limita la frequenza delle richieste | Ridurre la simultaneità, attendere da 5 a 10 minuti e riprendere lentamente |
| Valanga di duplicati | Cartella reindicizzata o stato di migrazione divergente | Fermare il lotto, attivare l'esclusione dei duplicati e ripetere solo le cartelle interessate |
| Posta recente mancante | Delta incompleto o vecchi client ancora attivi sulla sorgente | Eseguire di nuovo il delta finale e disattivare subito l'accesso alla sorgente |
Ripristinare non significa “rimettere tutto com'era perché un utente si è lamentato”. Una checklist seria definisce prima i fattori scatenanti. Sono validi un guasto diffuso della posta in entrata dopo il cambio MX, grandi differenze inspiegate nei conteggi delle caselle critiche o un errore di autenticazione a destinazione che blocca l'intera organizzazione. Non lo sono un singolo telefono obsoleto o un utente che non ha mai aggiornato la password.
Se il ripristino è necessario, mantienilo limitato. Ripristina prima il flusso della posta, comunica un solo aggiornamento e conserva tutti i log. Non riavviare tre strumenti contemporaneamente creando un disordine maggiore del problema iniziale.
Perché questa checklist funziona meglio su TrekMail
La checklist diventa più semplice quando la piattaforma di destinazione è costruita per la posta, non per vendere pacchetti per utente. Il vecchio metodo consiste nel pagare per ogni persona una suite usata poco e trattare la migrazione come attività secondaria. Il nuovo metodo usa una piattaforma incentrata sulla posta, con spazio prevedibile, DNS chiaro e un percorso IMAP adatto al lavoro.
TrekMail segue bene questo modello. Supporta domini personalizzati, caselle IMAP, catch-all, inoltro, migrazione lato server, procedura per SPF, DKIM e DMARC, SMTP proprio o incluso e API. I piani a pagamento partono da $3.50 al mese con Starter e includono lo strumento di migrazione. Per provare le funzioni a pagamento è disponibile una prova gratuita di 14 giorni che richiede una carta. Per iniziare senza carta, il piano Nano è sempre gratuito.
Il vantaggio operativo è lo spazio condiviso e la gestione di più domini a prezzo fisso. Una casella enorme non impone una tassa per utente all'intera azienda. Conta per agenzie, MSP e chi gestisce account di ruolo su molti domini. Se è il tuo ambiente, leggi poi la guida di TrekMail all'hosting email per più domini. Per costi e scelta del piano, consulta i prezzi TrekMail.
Anche l'esecuzione è più pulita. Aggiungi il dominio, crei la casella di destinazione, avvii la migrazione IMAP lato server, convalidi il DNS e sposti i client. Nessuna deviazione POP3 e nessun connettore proprietario misterioso. Solo IMAP e SMTP standard con impostazioni esplicite.
Conclusione: mantieni noiosa la checklist di migrazione
La migliore checklist è quella che nessuno ricorda un mese dopo. Censisci la sorgente, precarica la posta vecchia, cambia il DNS con criterio, esegui il delta, verifica i conteggi, elimina gli accessi obsoleti e limita il ripristino. Così la migrazione smette di essere una scommessa e diventa ordinaria amministrazione, come dovrebbe essere la posta in produzione.
