Migrare da Google Workspace a Microsoft 365

Una migrazione può sembrare riuscita nel pannello di controllo e tuttavia fallire proprio dove gli utenti se ne accorgono: una casella delegata mancante, un Drive condiviso assegnato al team sbagliato, una sala che non si riesce a prenotare o collegamenti che non funzionano più. Per migrare da Google Workspace a Microsoft 365 in sicurezza, bisogna quindi trattare il progetto come una transizione aziendale, non come una semplice copia in blocco.

La destinazione non è una raccolta di applicazioni equivalenti. Gmail diventa Exchange Online e Outlook; i contenuti personali di Drive vengono normalmente trasferiti in OneDrive; i Drive condivisi richiedono un'architettura SharePoint o Teams. Le identità Google diventano identità Microsoft Entra ID e le abitudini relative a etichette, condivisione, riunioni e modifica nel browser devono adattarsi a un nuovo modello di lavoro.

Questa guida propone una sequenza per PMI e amministratori: inventario, abbonamenti, identità e coesistenza, migrazione di posta e file, progetto pilota, DNS, convalida e adozione. Gli strumenti Microsoft cambiano; all'avvio usate la panoramica Microsoft sulla migrazione come riferimento procedurale.

Indice

1. Perché le organizzazioni migrano e quando è meglio non farlo
2. Mappatura dei servizi Google e Microsoft
3. Fase 1: inventario e business case
4. Fase 2: licenze e architettura di destinazione
5. Fase 3: identità, domini e coesistenza
6. Fase 4: Gmail, calendari e contatti
7. Fase 5: Drive e Drive condivisi
8. Progetto pilota, passaggio, DNS e rollback
9. Convalida ed errori comuni
10. Adozione da parte degli utenti e gestione del cambiamento
11. Controllo di costi, rischi e tempistiche
12. Scegliere Microsoft 365 con Licendi
13. Domande frequenti

Perché le organizzazioni migrano e quando è meglio non farlo

Le organizzazioni cambiano raramente piattaforma perché una suite vince ogni confronto tra funzionalità. Migrano piuttosto perché Microsoft 365 si integra meglio con il loro ambiente. Gestione dei dispositivi Windows, applicazioni desktop di Office, Teams, SharePoint, Microsoft Entra ID e sicurezza Microsoft possono formare un insieme coerente. Una fusione può imporre un unico tenant; clienti o autorità possono chiedere controlli maggiori; la direzione finanziaria può voler ridurre gli strumenti duplicati. Alcuni utenti richiedono inoltre procedure avanzate in Excel, Word o PowerPoint difficili da riprodurre nel browser.

Queste motivazioni sono valide solo se la destinazione risolve un problema preciso. Un'azienda soddisfatta di Google Workspace, con poca esperienza Microsoft e fortemente dipendente dai metodi di lavoro Google, potrebbe affrontare molte interruzioni ottenendo pochi vantaggi. La stessa prudenza serve se il progetto si basa sul prezzo iniziale di un abbonamento senza considerare il lavoro di migrazione, il periodo di doppia operatività, la formazione, gli strumenti di terze parti, le correzioni e l'assistenza aggiuntiva.

Rinviate il progetto se l'inventario è incompleto, se applicazioni critiche dipendono da integrazioni Gmail o Drive non testate, se la responsabilità delle identità non è chiara o se manca uno sponsor dirigenziale che sostenga il cambiamento. Evitate anche un passaggio generale quando conservazione a fini legali, dati regolamentati, Drive condivisi complessi o instradamento critico richiedono una verifica graduale. La soluzione corretta può essere una migrazione a ondate, una coesistenza limitata oppure, per il momento, nessun cambiamento.

Mappatura dei servizi Google e Microsoft

Una corrispondenza uno a uno tra i nomi nasconde importanti decisioni architetturali. Un Drive condiviso non dovrebbe diventare automaticamente un enorme sito SharePoint e uno spazio Google Chat non corrisponde sempre a una struttura Teams. Usate la tabella come punto di partenza, poi progettate la destinazione in base a responsabilità e modalità di lavoro reali.

Fase 1: inventario e business case

Partite dai fatti. Esportate utenti, gruppi, alias, account sospesi o archiviati, accessi condivisi o delegati, risorse, regole di instradamento, domini, dispositivi mobili, applicazioni OAuth e ruoli amministrativi. Per i file, rilevate Il mio Drive, Drive condivisi, proprietari, condivisioni esterne, tipi, numero e volume degli elementi, file molto grandi, percorsi profondi e contenuti senza proprietario. Aggiungete i requisiti di Google Vault e gli obblighi di conservazione a fini legali: uno strumento di migrazione non sostituisce l'analisi documentale.

Create un registro delle dipendenze. Quali applicazioni inviano messaggi tramite Gmail? Quali scanner, siti e sistemi aziendali usano SMTP? Quali processi dipendono da Apps Script, Google Moduli, macro di Fogli, scorciatoie di Drive o URL nel codice? Quali team condividono con clienti esterni? Classificateli: verde per i casi standard, giallo per i rischi di conversione o autorizzazione, rosso per dipendenze critiche o non supportate da gestire separatamente.

Trasformate l'inventario in un business case misurabile: consolidamento delle identità, applicazioni desktop gestite, migliore conformità dei dispositivi, riduzione degli strumenti duplicati o governance documentale standardizzata. Stabilite un riferimento per abbonamenti, assistenza, spazio di archiviazione, sicurezza ed esperienza utente. Includete il periodo temporaneo di doppia operatività e un margine per le correzioni. Non annunciate risparmi finché non conoscete l'architettura di destinazione e i profili di utilizzo.

Nominate responsabili per identità, posta, file, sicurezza, DNS, conformità, applicazioni, comunicazione e collaudo aziendale. Il responsabile del progetto coordina, ma non può assorbire ogni decisione. Stabilite subito i criteri per procedere o fermarsi, prima che la pressione delle scadenze trasformi prove insufficienti in un risultato considerato accettabile.

Fase 2: licenze e architettura di destinazione

Le licenze devono seguire le modalità d'uso, non le qualifiche professionali. Un operatore nel browser, un analista che necessita di Excel desktop e un amministratore di dati sensibili possono richiedere piani diversi. Per ogni profilo verificate posta, applicazioni Office, gestione dei dispositivi, protezione, conformità e diritti applicativi. Controllate anche prerequisiti e spazio disponibile: possedere un account non significa che ogni servizio o controllo sia incluso.

Business Basic può essere adatto agli utenti che lavorano soprattutto con servizi cloud e applicazioni web o mobili. Business Standard aggiunge le applicazioni desktop. Business Premium combina produttività e funzionalità aggiuntive per identità, gestione dei dispositivi e sicurezza. Consultate le risorse aggiornate dedicate a Business Premium invece di presumere che ogni controllo sia incluso o automatico. Nomi, diritti e disponibilità cambiano: verificate le condizioni commerciali prima dell'acquisto.

Progettate la destinazione prima di copiare: domini accettati, nomi principali, alias, destinatari Exchange, OneDrive, siti SharePoint, convenzioni Teams, proprietari dei gruppi, condivisione esterna, conservazione, riservatezza e ruoli. Separate i file di lavoro personali dai documenti appartenenti al team. Trasferire ogni Drive condiviso nel OneDrive di una persona può riuscire tecnicamente e creare subito un problema di proprietà.

Applicate il privilegio minimo: se possibile, separate gli operatori della migrazione dagli amministratori globali, proteggete gli account di emergenza e assegnate in anticipo le licenze al gruppo pilota per provare servizi e criteri. L'attuale procedura guidata di configurazione per Google Workspace può aiutare alcune piccole imprese idonee, ma deve servire l'architettura, non sostituirla.

Fase 3: identità, domini, sicurezza e coesistenza

La corrispondenza delle identità collega posta e file. Normalizzate indirizzi principali, alias, duplicati e indirizzi di gruppo. Decidete se il nome principale Microsoft Entra dovrà coincidere con l'indirizzo e-mail. Mantenete un file controllato che associ ogni utente e gruppo Google a un oggetto di destinazione, compresi gli ex dipendenti i cui dati sono ancora necessari. Provate caratteri speciali, account rinominati e domini multipli: indirizzi uguali non coprono ogni caso.

Microsoft offre Google Identity Sync ai tenant idonei. La documentazione descrive una sincronizzazione unidirezionale di utenti e gruppi Google verso Microsoft 365, soggetta a condizioni di dimensione e corrispondenza. Gli oggetti già esistenti non vengono semplicemente sovrascritti; gli utenti archiviati differiscono dagli account attivi o sospesi; membri esterni e autorizzazioni personalizzate possono richiedere un trattamento separato. Verificate idoneità e report prima di scegliere questo strumento al posto di uno script o di una soluzione di terze parti.

Aggiungete e verificate il dominio in Microsoft 365 senza spostare troppo presto il flusso di posta. Prima dei dati reali, configurate MFA, accesso condizionale se previsto dalla licenza, separazione dei ruoli, controllo, protezione di dispositivi o applicazioni, condivisione esterna e account di ripristino. Non applicate un criterio non testato a tutta l'azienda durante il passaggio. Usate gruppi pilota e verificate che un blocco amministrativo possa essere risolto senza indebolire i controlli.

La coesistenza richiede un flusso esplicito. Il percorso Exchange classico usa domini di instradamento per collegare gli utenti ancora in Google e quelli già migrati. I prerequisiti della migrazione Microsoft trattano utenti di posta, sottodomini di instradamento e inoltro. L'esperienza consolidata di Microsoft 365 e Simplified Gmail Migration possono automatizzare il processo in modo diverso; seguite un solo percorso nel vostro tenant invece di mescolare le istruzioni.

Mantenete un'unica fonte attendibile per gli account durante la coesistenza. Definite dove creare utenti, modificare password o federazione, disabilitare chi lascia l'azienda e gestire i gruppi. Bloccate le modifiche non essenziali ai nomi. Se le identità divergono durante la mappatura, gli errori sembreranno casuali anche se la causa è la governance.

Fase 4: migrare Gmail, calendari e contatti

Scegliete il metodo per la posta dopo aver completato l'inventario. La migrazione automatizzata in batch nell'Interfaccia di amministrazione di Exchange può trasferire e-mail, regole, calendari e contatti in ondate successive. L'Interfaccia di amministrazione di Microsoft 365 offre anche un'esperienza consolidata, mentre Simplified Gmail Migration usa un'app Google Marketplace per guidare alcune organizzazioni di piccole dimensioni. Disponibilità e requisiti di idoneità cambiano; nessun metodo è universale.

Nel percorso classico, soddisfate i prerequisiti relativi ad account di servizio, API, ruolo amministrativo, dominio di instradamento e destinatari. Create i batch da un elenco verificato, non da un foglio di calcolo improvvisato il giorno del passaggio. Precopiate la cronologia mentre gli utenti lavorano ancora in Google, esaminate gli errori, correggete le eccezioni e riprendete l'elaborazione quando possibile. Una sincronizzazione finale riduce lo scarto, ma non garantisce interruzioni pari a zero.

La panoramica della migrazione automatizzata in batch segnala alcuni limiti: non vengono migrati calendari condivisi, colori degli eventi, prenotazioni delle sale, impostazioni per ferie o risposte automatiche; esistono inoltre limitazioni per le etichette Gmail e alcuni campi o URL dei contatti. Viene indicato un massimo di tre indirizzi per contatto. Per impostazione predefinita, un messaggio è limitato a 35 MB, con possibilità di configurazione fino a 150 MB. Trasformate questi limiti in test e comunicazioni agli utenti, non in sorprese successive al passaggio.

Ricreate ciò che non viene migrato correttamente: cassette postali per sale o attrezzature, regole di prenotazione, calendari condivisi necessari e deleghe. Chiedete agli utenti di controllare le riunioni ricorrenti dopo il passaggio. Le etichette Gmail non corrispondono esattamente alle cartelle o alle categorie di Outlook, soprattutto quando un messaggio possiede più etichette. Provate un campione e spiegate il risultato prima che gli utenti lo interpretino come una perdita di dati.

Seguite la procedura aggiornata nell'Interfaccia di amministrazione di Exchange per il percorso scelto. Monitorate numero di elementi, elementi ignorati, cause degli errori e ultima sincronizzazione. Se Microsoft lo richiede, adattate i criteri di conservazione o archiviazione, perché potrebbero spostare elementi durante la verifica. Non eliminate le e-mail da Google appena il pannello diventa verde; conservate la fonte per il periodo di convalida e conservazione concordato.

Fase 5: migrare Drive e i Drive condivisi

La migrazione dei file è un progetto di architettura dell'informazione tanto quanto un'operazione di copia. Il mio Drive viene normalmente trasferito in OneDrive; i Drive condivisi dei team in SharePoint, spesso tramite Teams. Prima di creare le attività, definite siti, proprietari, membri, condivisione esterna, riservatezza, conservazione e nomi. Suddividete un Drive condiviso troppo ampio quando reparti, livelli di riservatezza o cicli di vita rendono inadatta un'unica destinazione.

Il Gestore migrazione Microsoft per Google Workspace segue una sequenza chiara: connessione, scansione, aggiunta delle origini pronte, controllo delle destinazioni, mappatura delle identità, migrazione e monitoraggio. Usate il percorso completo quando la complessità lo richiede. Per alcuni tenant PMI può esistere un'esperienza semplificata, ma un'interfaccia semplice non decide dove debbano essere collocati i contenuti.

Eseguite la scansione prima della migrazione e leggete i report: file non supportati, restrizioni, percorsi troppo lunghi, nomi non validi, problemi di proprietà, elementi di grandi dimensioni e volumi che possono compromettere il calendario. Verificate le destinazioni invece di accettare automaticamente ogni corrispondenza. Mappate utenti e gruppi prima di aspettarvi che autorizzazioni e metadati vengano mantenuti. Il progetto pilota deve comprendere formati nativi Google, condivisione esterna, autorizzazioni ereditate, strutture di cartelle estese e contenuti di ex dipendenti.

La conversione cambia il file, non soltanto la sua posizione. Le indicazioni aggiornate di Microsoft sui file non supportati precisano che Documenti, Fogli e Presentazioni diventano DOCX, XLSX e PPTX tramite Google Export, mentre gli originali restano in Google. Disegni diventa PNG; Sites e Maps non vengono migrati; le scorciatoie vengono ignorate; i file orfani o non organizzati non vengono né analizzati né segnalati. Il trattamento di Moduli e altri elementi cambia nel tempo: verificate la documentazione all'avvio.

La conversione può modificare formule, script, impaginazione, commenti, oggetti incorporati e collegamenti. Fate convalidare una serie di documenti complessi dai rispettivi proprietari. Campionate anche le autorizzazioni: utenti interni, gruppi, ospiti, collegamenti anonimi e accessi personalizzati non vengono trasferiti tutti nello stesso modo. Registrate i file che richiedono esportazione manuale, riprogettazione, archiviazione o eliminazione. Gestore migrazione copia senza eliminare gli originali Google; la dismissione della fonte resta una decisione di governance separata.

Progetto pilota, passaggio, DNS e rollback

Un progetto pilota credibile rappresenta i casi difficili, non solo gli informatici più collaborativi. Includete reparti diversi, dirigenti o assistenti che usano deleghe, lavoratori da remoto, dispositivi mobili, proprietari di Drive condivisi, partner esterni, utenti che prenotano sale e almeno una cassetta postale molto grande o insolita. Stabilite soglie per flusso di posta, accesso, profili Outlook, accesso mobile, riunioni, autorizzazioni, conversione dei documenti e ticket di assistenza.

Eseguite il progetto pilota in condizioni vicine a quelle di produzione: abbonamenti, criteri, DNS e dispositivi previsti. Confrontate elementi di origine e destinazione, registrate esclusioni, collaudo degli utenti e tempo necessario per le correzioni. Se il 5% dei file richiede un trattamento manuale, aggiungete quel lavoro al calendario invece di dichiarare il successo solo perché il 95% è stato copiato.

Prima del passaggio, riducete il TTL DNS, se il provider e la procedura lo consentono, con sufficiente anticipo perché le vecchie cache scadano. Confermate l'accesso al provider DNS, registrate ogni record e preparate i valori indicati nell'Interfaccia di amministrazione di Microsoft 365. Verificate MX, Autodiscover, SPF, DKIM e DMARC. SPF deve rimanere un unico record valido che copra tutti i mittenti; un secondo record TXT SPF può rendere non valida la valutazione. Provate separatamente applicazioni aziendali e gateway di terze parti.

Definite la sequenza dell'evento: bloccate le modifiche evitabili, completate i passaggi finali o differenziali supportati, verificate i batch, modificate il flusso di posta, provate ricezione e invio, convalidate i record di sicurezza del dominio e poi aprite l'accesso in base alle ondate. Microsoft colloca la connessione del dominio dopo la migrazione di e-mail e calendari: cambiare il record MX è una transizione di servizio, non una semplice attività preparatoria.

Scrivete il piano di rollback prima di autorizzare l'avvio. Definite chi può fermare un'ondata, l'ultimo punto decisionale sicuro, come ripristinare MX o l'instradamento, come gestire i nuovi messaggi in Microsoft 365 e l'eventuale modifica di file in entrambi i sistemi. Il ripristino DNS non è istantaneo e non unisce i dati creati sui due lati. Spesso è meglio sospendere l'ondata successiva e correggere il problema anziché riportare indietro utenti già operativi.

Create un canale di comando con responsabili tecnici e aziendali. Registrate le modifiche e preparate assistenza, annunci ed escalation ai fornitori. Non programmate la prima grande ondata prima delle paghe, della chiusura trimestrale, di un lancio pubblico o di una festività, salvo esplicita accettazione del rischio.

Lista di controllo per la convalida ed errori comuni

Lo stato “completato” non equivale all'accettazione aziendale. Le indicazioni Microsoft sui file osservano che le attività possono risultare pronte o completate anche quando elementi non supportati sono falliti singolarmente. Convalidate ogni carico di lavoro, utente ed eccezione.

• Identità: gli utenti riescono ad accedere, MFA funziona, le licenze sono assegnate, gli alias vengono risolti, i gruppi hanno i proprietari corretti e gli account disabilitati restano tali.
• Posta: la consegna in ingresso, in uscita e interna funziona; l'esito per cartelle storiche o etichette è compreso; deleghe, alias, regole ed eccezioni per i messaggi di grandi dimensioni sono stati controllati.
• Calendario: vengono provati riunioni ricorrenti, fusi orari, comportamento dell'organizzatore, sale, calendari condivisi e sincronizzazione mobile.
• File: numero e dimensioni degli elementi vengono riconciliati considerando le differenze note di conversione; proprietari, autorizzazioni, accesso esterno e documenti campione sono approvati.
• Client: Outlook, Teams, OneDrive e l'attivazione di Office funzionano su dispositivi Windows, macOS e mobili rappresentativi.
• Sicurezza: gli eventi di controllo vengono registrati, l'accesso condizionale si comporta come previsto, i controlli di condivisione si applicano, la conservazione è verificata e l'accesso di emergenza resta disponibile.
• Operazioni: le procedure per assunzioni, cambi di ruolo, uscite, ripristino, assistenza ed escalation funzionano nella nuova piattaforma.

Gli errori comuni sono generalmente prevedibili: identità senza corrispondenza causano la perdita di autorizzazioni; OneDrive o siti non predisposti bloccano le destinazioni; alias obsoleti creano conflitti di posta; autorizzazioni OAuth o API scadono; percorsi o file non sono supportati; gli ospiti esterni non vengono mappati; i criteri di conservazione spostano elementi durante la verifica. Un altro errore frequente è confrontare i conteggi grezzi dei file senza considerare la conversione dei formati nativi Google o le scorciatoie ignorate. Classificate ogni discrepanza come prevista, risolta, accettata da un responsabile o ancora bloccante.

Conservate le prove. Esportate report di migrazione, elenchi degli errori, file di mappatura, record DNS, approvazioni del collaudo e decisioni di correzione. Campionate gli utenti ad alto rischio invece di controllare soltanto le medie. Mantenete l'accesso alla fonte in sola lettura o in forma controllata per il periodo di convalida approvato, nel rispetto dei requisiti legali e di sicurezza. Rimuovete poi app di migrazione, account di servizio, privilegi temporanei, regole di inoltro e domini di instradamento obsoleti quando non servono più.

Adozione da parte degli utenti e gestione del cambiamento

Gli utenti non hanno bisogno di una visita guidata di ogni funzionalità di Microsoft 365. Devono capire come cambia il loro lavoro quotidiano. Fornite indicazioni brevi e basate sui ruoli: cartelle e categorie di Outlook rispetto alle etichette Gmail; condivisione OneDrive rispetto a Drive; canali Teams rispetto alle chat improvvisate; proprietà dei team in SharePoint; creazione di riunioni; prenotazione delle sale; file offline e modalità di richiesta degli accessi. Mostrate le differenze che possono causare errori, non solo le somiglianze che fanno sembrare semplice la formazione.

Coinvolgete referenti del gruppo pilota, date ai responsabili una lista per il passaggio e pubblicate un percorso di assistenza. Inviate credenziali e istruzioni tramite un canale disponibile anche in caso di problemi alla posta. Offrite supporto nelle prime ondate e raggruppate le domande per tema. Una confusione ricorrente è un riscontro sulla progettazione: può indicare nomi poco chiari, autorizzazioni mancanti, una struttura dei siti troppo complessa o un criterio non documentato.

Misurate l'adozione dopo il lancio. Esaminate accessi, utilizzo attivo, volume delle richieste di assistenza, richieste di condivisione irrisolte, crescita dello spazio occupato e lavoro duplicato in Google. Non cancellate la fonte solo perché la scadenza della migrazione è trascorsa. Dismettetela quando convalida dei dati, conservazione, accettazione aziendale e obblighi contrattuali di preavviso sono soddisfatti.

Controllo di costi, rischi e tempistiche realistiche

Nessuna guida responsabile può promettere durata o prezzo fissi. Un'azienda di cinquanta persone con Gmail standard e Drive ordinati può risultare più semplice di uno studio di venti persone con terabyte di contenuti multimediali, ampia condivisione esterna e automazioni Apps Script. Le tempistiche dipendono da volume dei dati, numero degli elementi, limitazione delle API, dimensioni delle cassette postali, contenuti non supportati, qualità delle identità, numero dei domini, coesistenza, conservazioni legali, preparazione degli endpoint, calendario aziendale e rapidità delle decisioni dei responsabili.

Controllate i costi con ondate e punti decisionali. Quando è commercialmente opportuno, assegnate prima le licenze agli utenti pilota; evitate di acquistare software di migrazione prima di avere verificato che uno strumento nativo non soddisfi il requisito; prevedete un budget per il doppio abbonamento. Date priorità alle correzioni in base all'impatto aziendale anziché inseguire differenze di conteggio innocue. Mantenete un registro dei rischi con probabilità, impatto, responsabile, mitigazione e fattore di attivazione. Riservate un margine per documenti complessi, autorizzazioni condivise e integrazioni applicative.

Un calendario utile è espresso in fasi, non in promesse: inventario; architettura e approvvigionamento; preparazione del tenant e delle identità; progetto pilota; correzioni; precopia graduale; ondate di passaggio; convalida e dismissione della fonte. Ogni fase si conclude sulla base di prove. Se l'inventario amplia l'ambito, aggiornate apertamente il calendario. Ridurre i test non elimina il rischio: lo trasferisce semplicemente ai dipendenti e al servizio di assistenza.

Scegliere il piano Microsoft 365 adatto alla migrazione

Il marketplace di Licendi include piani Microsoft 365 e altre opzioni di licenza software. Selezionate gli abbonamenti in base a utenti, applicazioni, controlli di sicurezza e requisiti di conformità dell'architettura di destinazione. Non presumete che ogni abbonamento sia una licenza perpetua usata e trasferibile: i servizi Microsoft 365 sono generalmente abbonamenti continuativi, mentre altri software offerti nel marketplace possono seguire modelli di licenza e condizioni di trasferimento differenti.

Conclusione

Il successo di una migrazione da Google Workspace non si misura dalla velocità con cui i dati lasciano Google. Si misura dalla capacità delle persone di comunicare, trovare informazioni, conservare i documenti necessari e lavorare in sicurezza in Microsoft 365 dopo la dismissione della fonte. Inventario e mappatura delle identità evitano la maggior parte delle sorprese prevenibili. Il progetto pilota fa emergere le altre quando il rollback è ancora praticabile.

Usate gli strumenti Microsoft aggiornati per i carichi di lavoro che supportano davvero, documentate ogni limitazione nota e lasciate che i responsabili aziendali approvino documenti convertiti e autorizzazioni. Con passaggi graduali, modifiche DNS controllate, convalida misurata e formazione mirata, il trasferimento può diventare prevedibile senza fingere che sarà perfetto o invisibile.

Domande frequenti

Microsoft può migrare Gmail, calendari e contatti?

Sì. Le esperienze Microsoft disponibili per la migrazione da Google Workspace possono trasferire i dati Gmail e i contenuti supportati di calendari e contatti in Exchange Online. I dati selezionabili e la configurazione dipendono dal metodo disponibile nel tenant. Calendari condivisi, prenotazioni delle sale, colori degli eventi, etichette Gmail e alcuni campi dei contatti presentano limiti nel percorso classico automatizzato in batch: provate quindi il metodo scelto e comunicatene l'ambito aggiornato.

Google Drive viene migrato direttamente in OneDrive?

I contenuti personali di Il mio Drive vengono normalmente associati a OneDrive, mentre i Drive condivisi dovrebbero essere indirizzati a siti SharePoint o connessi a Teams sottoposti a governance. Gestore migrazione copia contenuti, metadati e autorizzazioni supportati in base alla configurazione. Architettura della destinazione, mappatura delle identità e correzione degli elementi non supportati richiedono comunque decisioni amministrative.

I Documenti Google vengono convertiti in file Microsoft Office?

Sì. Gestore migrazione usa l'API Google Export per convertire Documenti, Fogli e Presentazioni Google in DOCX, XLSX e PPTX. La conversione può modificare formule, script, impaginazione, commenti, contenuti incorporati o collegamenti; i proprietari devono quindi convalidare i file complessi. Gli originali Google restano nella fonte finché l'organizzazione non decide di rimuoverli.

Tutte le autorizzazioni e i collegamenti di condivisione continueranno a funzionare?

Non è possibile garantirlo. La mappatura delle identità può conservare le autorizzazioni supportate, ma accessi personalizzati, utenti esterni, collegamenti anonimi, scorciatoie, proprietà e criteri della destinazione possono cambiare il risultato. Provate modelli di condivisione rappresentativi, pubblicate nuovi collegamenti quando necessario e mantenete un registro delle eccezioni da correggere.

Quanto tempo di inattività richiede una migrazione?

Non esiste un valore universale. La preparazione anticipata dei dati e la coesistenza graduale possono ridurre le interruzioni, ma la sincronizzazione finale, la propagazione DNS, la riconfigurazione dei client e i problemi di assistenza comportano comunque dei rischi. Pianificate una finestra di servizio controllata ed evitate di promettere tempi di inattività pari a zero.

Google Workspace e Microsoft 365 possono coesistere durante la migrazione?

Sì. I metodi supportati per una migrazione graduale della posta possono usare domini di instradamento e destinatari predisposti affinché utenti migrati e non migrati si scambino messaggi. La coesistenza aggiunge però complessità: proprietà delle identità, inoltro, modifiche ai gruppi, comportamento del calendario e limiti dell'assistenza devono essere documentati e provati.

Quando si può cancellare l'abbonamento Google Workspace?

Cancellatelo soltanto dopo la convalida di posta e file, la revisione legale e della conservazione, l'accettazione dei responsabili aziendali, la scadenza del periodo di rollback e la rimozione o esportazione di tutto ciò che non verrà migrato. Verificate prima la gestione del dominio e dell'hosting DNS. Gli strumenti di migrazione copiano i dati supportati, ma non prendono per l'organizzazione le decisioni sulla dismissione della fonte.

Qual è il piano Microsoft 365 migliore dopo Google Workspace?

Il piano migliore dipende da ogni profilo utente. Business Basic può essere adatto a chi lavora soprattutto nel cloud, Business Standard aggiunge applicazioni desktop per la produttività e Business Premium offre ulteriori funzionalità per identità, gestione dei dispositivi e sicurezza. Verificate diritti aggiornati, esigenze di conformità, limiti di utenti e prerequisiti della migrazione anziché scegliere automaticamente un solo piano per tutti.