Migrare le email da Google Workspace senza perdite

Se migri le email da Google Workspace nel modo sbagliato, il lunedì mattina avrai consegna divisa, alias mancanti e utenti arrabbiati. È un lavoro di passaggio, non un'esportazione con trascinamento. Per il contesto d'acquisto generale, leggi email aziendale. Se il trasferimento è già in programma, questa procedura spiega come passare a un host IMAP come TrekMail senza interrompere la posta in arrivo.

La trappola è semplice: gli amministratori si concentrano sui vecchi messaggi e dimenticano il routing. Alla posta non importa che la migrazione sia completa al 92%. Appena cambia MX, i nuovi messaggi vanno da qualche parte. Se alias, gruppi, DNS e client non sono pronti nello stesso momento, si creano due realtà di posta in arrivo. Gli utenti continuano a inviare, i clienti a rispondere e metà della posta arriva nel posto sbagliato.

La soluzione è la sequenza. Prima l'inventario, poi la preparazione, un solo cambio DNS, la riconnessione pulita dei client e la verifica per conteggio. TrekMail si adatta con spazio condiviso, hosting multidominio a prezzo fisso, migrazione IMAP integrata e supporto IMAP/SMTP standard senza costi per utente.

Cosa significa migrare da Google Workspace?

Bisogna trasferire la posta archiviata via IMAP e poi spostare il routing dei nuovi messaggi da Google al nuovo provider. La copia è importante, ma il passaggio lo è di più. Se il routing cambia prima che identità, DNS e client siano pronti, i messaggi iniziano a finire nelle caselle sbagliate.

La distinzione conta perché Google Workspace nasconde vari tipi di identità dietro una sola interfaccia amministrativa. Un account di accesso non equivale a tutti gli indirizzi che ricevono posta per la persona. Alias condivisi, indirizzi di gruppo, inoltri e catch-all influenzano il passaggio.

Prima di toccare il DNS, prepara correttamente la destinazione. In TrekMail significa in genere aggiungere il dominio, confermare i record DNS, creare ogni casella e decidere quali indirizzi resteranno alias e quali diventeranno caselle reali. Questi documenti aiutano: aggiunta del dominio, record DNS obbligatori e spiegazione di come TrekMail gestisce le migrazioni Gmail.

Fase 1: inventario completo prima di copiare

La prima vera attività è scoprire ogni indirizzo capace di ricevere posta. Gli utenti principali sono evidenti. Alias, gruppi e vecchie regole di routing causano gli errori. Se li dimentichi, il cambio DNS li trasforma in rifiuti permanenti o vicoli ciechi.

Inizia con quattro elenchi:

1. Utenti principali e dimensioni delle caselle.
2. Tutti gli alias legati a ciascun utente.
3. Google Groups che ricevono ancora posta reale.
4. Inoltri, catch-all e indirizzi ritirati ancora presenti in fatture, moduli o firme.

Per questo una semplice esportazione amministrativa non basta. Una rappresentante può entrare come jane@company.com e ricevere ancora su sales@company.com, quotes@company.com e un vecchio dominio mai documentato. Dimenticarne uno fa sembrare rotto il passaggio anche con DNS corretto. Ogni indirizzo raggiungibile deve avere una destinazione.

Per estrarre i dati da Google, gli operatori usano spesso GAM o Admin SDK e costruiscono una mappa completa. Lo strumento conta meno del risultato: prima della migrazione ogni indirizzo instradabile deve avere una sede esplicita nel nuovo sistema.

gam print users aliases > aliases.csv
gam print groups members > group_members.csv

Mentre ordini gli indirizzi, decidi cosa diventerà ciascuna identità:

Per decidere rapidamente, leggi alias del dominio o casella. Molti errori iniziano qui.

Fase 2: preparare i dati perché Google limita IMAP

Per qualsiasi volume reale serve un passaggio preliminare. Google documenta limiti giornalieri di banda IMAP per download e upload per account. Le caselle grandi non finiscono in un fine settimana, per quanto ottimistico sia il piano.

Google pubblica questi limiti Gmail per Workspace: download IMAP di 2,500 MB al giorno e upload di 500 MB al giorno. Sono condizioni tecniche, non suggerimenti. Una casella da 50 GB può richiedere settimane per il recupero completo.

Il modello corretto è:

1. Preparare la posta vecchia mentre gli utenti lavorano ancora in Google.
2. Eseguire sincronizzazioni delta nei giorni precedenti.
3. Spostare la posta più recente dopo il cambio DNS o nella finestra finale.

Per gli utenti pesanti, dividi per intervalli di data quando lo strumento lo permette. Il flusso TrekMail supporta importazioni graduali e rende più pratico migrare a lotti invece di estrarre alla cieca l'intera cronologia.

Esempio: se l'amministrazione ha una casella da 36 GB ma necessita subito solo degli ultimi 90 giorni, importa prima le cartelle recenti, cambia il flusso e completa l'archivio dopo la stabilizzazione.

Conta anche la guida attuale di Google sull'accesso. L'autenticazione di base è scomparsa nella maggior parte dei casi, mentre le password per le app restano l'eccezione principale nelle configurazioni compatibili. Per le fonti Gmail, TrekMail indica di usare una password per l'app al posto di quella normale quando la norma Google lo richiede. Vedi l'aiuto sulle password per le app Google.

Fase 3: cambiare DNS una volta e nell'ordine corretto

Il DNS determina dove arriva la nuova posta. Riduci il TTL in anticipo, pubblica i nuovi record di autenticazione e modifica MX solo dopo che caselle e alias esistono. Invertire l'ordine crea consegna divisa.

La sequenza pulita è volutamente semplice. Due giorni prima riduci il TTL di MX, SPF e DMARC a 300 secondi. Un giorno prima pubblica DKIM per il provider di destinazione. Al passaggio sostituisci l'MX di Google con quello di TrekMail. Poi verifica la propagazione da un resolver pubblico, non dalla cache del portatile.

; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -all

dig @1.1.1.1 example.com MX +short

Durante la sovrapposizione, mantieni Google e TrekMail in SPF se entrambi possono ancora inviare. È coerente con RFC 7208. Rispetta il limite di 10 ricerche DNS. Se il record è già sovraccarico di fornitori, semplificalo prima della migrazione.

Quando ripeti il processo su molti domini clienti, TrekMail ripaga l'investimento. Il vecchio metodo modifica DNS e caselle un dominio alla volta pagando per utente. Il nuovo usa una piattaforma a prezzo fisso con controllo multidominio, spazio condiviso, assistente DNS e migrazione integrata.

Fase 4: correggere i client, non solo la password

Dopo la migrazione, molti ticket sembrano errori di password ma non lo sono. I client configurati per Google conservano ipotesi OAuth, dati autodiscover in cache o profili del vecchio provider. Gli utenti hanno bisogno di una nuova configurazione IMAP per il nuovo host, non di continui tentativi di password.

Il problema colpisce soprattutto telefoni e Outlook. Sui dispositivi mobili gli utenti scelgono il logo Google per abitudine, ma dopo il passaggio è sbagliato. I vecchi profili Outlook possono continuare a tentare Google anche quando MX indica già un altro host.

Usa le impostazioni IMAP dirette di TrekMail:

Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox password

Su iPhone e Android rimuovi il vecchio account Google e aggiungi la casella come Altro o IMAP. In Outlook desktop crea un nuovo profilo anziché riparare il vecchio. Le guide TrekMail spiegano le impostazioni IMAP/SMTP, mentre imapsync completa un flusso manuale.

TrekMail è hosting IMAP basato sugli standard. Niente POP3 e nessuna imitazione di Exchange. Se dispositivo o utente insistono sulle procedure proprietarie Google o Microsoft, perderai tempo con il protocollo sbagliato.

Fase 5: verificare i conteggi e semplificare il ripristino

Verifica la salute delle caselle con conteggi per cartella e flusso reale, non con i gigabyte totali. La vista di Google comprende compressione e fattori non legati alla posta che non corrispondono a un obiettivo IMAP. Conta i messaggi, conferma entrata e uscita, poi chiudi il passaggio.

L'elenco minimo:

1. I conteggi delle cartelle sono abbastanza vicini in ogni casella critica.
2. I test in entrata arrivano solo a TrekMail dopo la propagazione MX.
3. La posta in uscita supera i controlli SPF, DKIM e DMARC.
4. Alias e indirizzi condivisi consegnano esattamente dove previsto.
5. Gli utenti accedono da desktop e mobile con le nuove impostazioni.

Piccole differenze possono essere normali. Messaggi corrotti, inviti difettosi ed elementi vuoti non sempre superano IMAP. Non è normale che la nuova posta continui ad arrivare a Google dopo la conclusione. In quel caso la migrazione non è finita.

Il ripristino deve essere diretto e veloce. Se la posta in arrivo non funziona in generale, riporta MX a Google mentre il TTL è basso. Poi esporta i messaggi arrivati al nuovo host nella finestra difettosa e reinseriscili se necessario. Un piano non eseguibile in cinque minuti non è un vero ripristino.

Vecchio metodo e nuovo metodo: perché scegliere TrekMail

Quando le migrazioni sono frequenti, il costo reale non è solo la licenza. È il lavoro ripetuto su domini, creazione di caselle, reimpostazione dei client e nuovi tentativi. TrekMail lo riduce con un modello multidominio a prezzo fisso per operatori, non con fogli per postazione.

TrekMail offre domini personalizzati, caselle IMAP, catch-all, inoltro, SMTP proprio o incluso secondo il piano e migrazione lato server. Nano è sempre gratuito e non richiede carta. I piani a pagamento includono una prova gratuita di 14 giorni che richiede una carta. Se oggi gestisci un marchio e il prossimo trimestre venti domini clienti, questo modello separa il margine dal caos.

Per i team con molte caselle, il vantaggio operativo ricorda l'hosting email multidominio: una dashboard, meno parti e nessuna trappola di costo per ogni nuova casella.

Per evitare che la migrazione diventi un'emergenza nel fine settimana, inizia dai prezzi TrekMail. Costruisci prima la destinazione, prepara la posta, cambia il DNS una volta e verifica come un operatore.