5. Completare le attività preliminari al trasferimento

Passaggio 1: attività nell'ambiente di origine

1. Esegui l'upgrade delle licenze (se applicabile): le licenze non vengono spostate nell'ambito del processo di trasferimento. Se nell'ambiente di origine viene utilizzata una versione di Google Workspace diversa da quella in uso nell'ambiente di destinazione, devi eseguire l'upgrade della versione dell'ambiente di origine in modo che corrisponda a quella dell'ambiente di destinazione. Per saperne di più, esamina i dettagli relativi ai trasferimenti delle licenze in Attività nell'ambiente di destinazione.

   Note:

   • Puoi utilizzare le licenze di prova o alle quali si applica un periodo di tolleranza nell'ambiente di origine per ottenere licenze temporanee senza incorrere in costi. Tuttavia, tieni presente quanto segue:
     • Queste licenze bloccano il processo di scambio di qualsiasi altro dominio con il dominio principale. Modifica il dominio principale prima di eseguire il provisioning di licenze temporanee.
     • Se le licenze disponibili nell'ambiente di destinazione sono licenze complete, agli utenti vengono assegnate licenze complete in seguito al trasferimento.
   • Gli utenti dell'ambiente di origine a cui non sono assegnate licenze vengono comunque trasferiti.
2. Annulla gli abbonamenti a licenze non supportate: se annulli gli abbonamenti alle licenze, potrebbero esserci implicazioni. Particolare attenzione deve essere prestata a questo passaggio per gli ambienti di origine con Google Voice. Per informazioni dettagliate, vai a Licenze nell'ambiente di origine.
3. Aggiungi un dominio segnaposto a Google Workspace (se applicabile): aggiungi e verifica un nuovo nome di dominio secondario nell'ambiente di origine che andrà a sostituire il dominio principale esistente. In alternativa, puoi utilizzare un eventuale dominio secondario già esistente che non deve essere trasferito. Per maggiori dettagli, vedi Aggiungere un dominio degli alias utente o dominio secondario.
4. Crea un amministratore segnaposto e impostalo come amministratore principale dell'account: crea un account utente associato al dominio segnaposto. Se riutilizzi un vecchio account, verifica che non esistano altri domini di trasferimento quando gli alias vengono collegati all'account. Concedi a questo utente il ruolo di super amministratore e impostalo come amministratore principale dell'account. Per ulteriori informazioni, vai a Inviare notifiche relative alla fatturazione e all'account a un altro amministratore. Assicurati che la verifica in due passaggi di Google sia configurata e accedi almeno una volta per verificare l'accesso con l'account amministratore segnaposto.
5. Sostituisci il dominio principale con il dominio segnaposto: scambia i domini, promuovendo il dominio segnaposto a nuovo dominio principale.

   Prima di scambiare il dominio:

   Quando è tutto pronto per lo scambio, vai a Cambiare il dominio principale per Google Workspace.

   • Annulla tutti gli abbonamenti dei dispositivi, inclusi hardware Google Meet e Chrome Enterprise.
   • Prima del trasferimento potrebbe essere necessario rimuovere alcune licenze non supportate. Per informazioni dettagliate, vai a Licenze nell'ambiente di origine.
   • Se l'ambiente di origine usa delle licenze di prova, lo scambio verrà bloccato. Assicurati che lo scambio avvenga prima che venga eseguito il provisioning delle eventuali licenze temporanee.
   • Esistono dei problemi noti relativi alla modifica del dominio principale e all'uso dei domini secondari. Consulta Alternative al cambio del dominio principale.
   • Non rinominare gli utenti trasferiti, o i gruppi trasferiti, dopo aver modificato il nome del dominio principale. Utenti e gruppi devono rimanere nei propri domini trasferiti.
   • Se configuri il servizio SSO utilizzando un provider di identità di terze parti e utilizzi un emittente specifico per il dominio, l'asserzione SAML cambierà per riflettere il nuovo dominio principale. Controlla la configurazione del provider di identità per assicurarti che gli utenti possano eseguire l'autenticazione dopo lo scambio del dominio principale. Per maggiori dettagli, vedi Requisiti per l'asserzione SSO.
6. Stabilisci regole di conservazione di Google Vault: configura regole di conservazione personalizzata a tempo indeterminato.

   Crea una regola per le seguenti applicazioni:

   • Gmail: per Unità organizzativa, seleziona l'unità organizzativa principale.
   • Google Gruppi: per Gruppi, seleziona Tutti i gruppi.

   Crea due regole per le seguenti applicazioni:

   • Chat: seleziona Unità organizzativa l'unità organizzativa principale. Per la seconda regola, seleziona Tutti gli spazi di Chat.
   • Drive: seleziona Unità organizzativa l'unità organizzativa principale. Per la seconda regola, seleziona Tutti i Drive condivisi.
   • Meet: seleziona Unità organizzativa l'unità organizzativa principale e attiva Includi elementi dai Drive condivisi. Per la seconda regola, seleziona Tutti i Drive condivisi.
   • Sites: seleziona Unità organizzativa l'unità organizzativa principale e attiva Includi elementi dai Drive condivisi. Per la seconda regola, seleziona Tutti i Drive condivisi.

   Inoltre, le regole di conservazione personalizzate a tempo indeterminato vengono configurate nell'ambiente di destinazione prima del trasferimento. Per maggiori dettagli, vai a Conservazione a tempo indeterminato di Google Vault nell'ambiente di destinazione. Per ulteriori informazioni sul trasferimento da Vault, vedi Trasferire i dati di Vault con Domain Transfer.

7. Aggiorna il record SPF (Sender Policy Framework), se applicabile: se l'ambiente di destinazione utilizza un gateway in uscita diverso dall'ambiente di origine, l'origine deve aggiornare il record SPF in modo da includere il gateway in uscita.

   Nota:se utilizzi DomainKeys Identified Mail (DKIM), il trasferimento non dovrebbe avere alcun impatto sul criterio DMARC (Domain-based Message Authentication, Reporting, and Conformance). Il record SPF continuerà ad allinearsi dopo il trasferimento, anche se DKIM omettesse di farlo temporaneamente. Assicurati inoltre di completare l'attività DKIM post-trasferimento nell'ambiente di destinazione.

8. Risolvi i conflitti delle risorse del calendario: se esistono conflitti tra le risorse del calendario, risolvili prima di procedere:
   • ID edifici: un ID edificio nell'ambiente di origine non può essere uguale a un ID edificio nell'ambiente di destinazione. Per superare il blocco del trasferimento, hai due opzioni. Puoi eliminare l'edificio nell'ambiente di origine. In alternativa, puoi rendere identici i dettagli dei due edifici per unire gli edifici di origine e di destinazione. Per fare in modo che i due edifici siano identici, fai in modo che ID, nome, indirizzo, descrizione e piano siano gli stessi per entrambi gli edifici.
   • Nomi di edifici: se una risorsa edificio nell'ambiente di origine ha lo stesso nome di una risorsa edificio nell'ambiente di destinazione, dovrai modificare il nome di una delle due risorse per risolvere il conflitto. Al termine del processo di trasferimento, potrai unire le due risorse edificio.
   • ID risorsa: una risorsa nell'ambiente di origine con lo stesso ID risorsa della risorsa nella destinazione crea un conflitto che non può essere risolto dal processo di trasferimento e la risorsa non verrà trasferita. Elimina una delle risorse in conflitto e ricreala con un ID non in conflitto. Sono necessari 30 giorni per la cancellazione completa della risorsa eliminata dal sistema. Puoi attendere che la risorsa venga completamente eliminata oppure che il team di Domain Transfer possa inviare una richiesta di eliminazione manuale.
9. Valuta l'impatto sull'organizzazione Google Cloud associata (se applicabile): se viene utilizzato Google Cloud, comunica agli amministratori di quell'ambiente i potenziali effetti che il trasferimento del dominio Google Workspace potrebbe avere su Google Cloud. Se necessario, coinvolgi il tuo partner o i tuoi contatti Google Cloud per ricevere assistenza in merito alla valutazione degli effetti e alle eventuali misure correttive. Il team di Google Workspace Domain Transfer non fornisce assistenza per Google Cloud in relazione a un trasferimento di dominio.
10. Informa il tuo rivenditore Google Workspace (se applicabile): comunica al rivenditore la durata programmata del trasferimento del dominio e richiedi che l'account non venga modificato (ad esempio, aggiornando gli abbonamenti) durante il periodo di trasferimento.

11. Effettua la registrazione a eventuali programmi alpha o beta a cui sta partecipando l'ambiente di origine o di destinazione (se applicabile): le registrazioni ai programmi alpha e beta non vengono trasferite nell'ambiente di origine. Analogamente, l'ambiente di origine potrebbe dipendere dalle registrazioni nell'ambiente di destinazione. L'ambiente senza registrazioni deve richiedere la partecipazione ed essere accettato da quei programmi per continuare a utilizzarli.
    Ti consigliamo di iscriverti ai programmi alpha o beta prima di eseguire il trasferimento, in modo che gli utenti da trasferire abbiano a disposizione le stesse funzionalità durante tutto il processo. Tuttavia, la procedura di registrazione potrebbe richiedere tempo e non è garantito il buon esito. Di conseguenza, è consigliata ma non obbligatoria.

12. Per trasferire i dispositivi Chrome registrati zero-touch:
    1. Nell'ambiente di origine,revoca il token di pre-provisioning esistente ed esegui il deprovisioning di tutti i dispositivi. Ripristina i dati di fabbrica dei dispositivi.
    2. Nell'ambiente di destinazione, crea un nuovo token di pre-provisioning.
    3. Fornisci il nuovo token al tuo partner di pre-provisioning autorizzato. Il partner utilizza il token per eseguire il pre-provisioning dei dispositivi nell'ambiente di destinazione.

    I dispositivi si registrano una volta connessi a internet. Lo stato del dispositivo passa a Provisioning effettuato.

    Per ulteriori informazioni sui dispositivi zero-touch, visita la pagina Registrazione zero-touch.

Passaggio 2: attività nell'ambiente di destinazione

1. Le licenze non vengono spostate nell'ambito del processo di trasferimento, quindi è necessario eseguire il provisioning di un numero sufficiente di licenze Google Workspace di riserva per supportare tutti gli utenti trasferiti: nell'ambiente di destinazione, agli utenti trasferiti sarà assegnato lo stesso insieme di licenze di cui disponevano nell'ambiente di origine. Di conseguenza, è necessario che nell'ambiente di destinazione sia presente una quantità sufficiente di licenze di riserva dello stesso tipo al momento del trasferimento.

   Se l'ambiente di destinazione utilizza una versione di Google Workspace diversa da quella dell'ambiente di origine, assicurati che le licenze corrispondano eseguendo l'upgrade delle licenze nell'ambiente di origine o di destinazione.

   Note:

   • Google consiglia di eseguire l'upgrade delle licenze per evitare l'attivazione della procedura di cancellazione dei dati del servizio (SWP).
   • Esegui il provisioning di eventuali licenze mancanti in modo che esistano più abbonamenti nell'ambiente di destinazione. Se necessario, puoi eseguire l'upgrade o il downgrade di singole licenze utente dopo il trasferimento. Tieni presente che non tutti i tipi di licenza supportano il Partial Domain Licensing (concessione delle licenze di dominio parziale, PDL).
   • Assicurati di avere a disposizione un numero sufficiente di licenze di riserva nell'ambiente di destinazione. Considera se verranno aggiunti altri utenti (ad esempio nuovi assunti) in ciascun ambiente di origine tra l'inizio e la fine del processo di trasferimento. In caso di più trasferimenti, devi anche tenere conto del numero totale di utenti dell'ambiente di origine in tutti i trasferimenti.
   • Gli utenti dell'ambiente di origine a cui non sono assegnate licenze vengono comunque trasferiti. Controlla in che modo vengono assegnate automaticamente le licenze nell'ambiente di destinazione per assicurarti che questi utenti non le ricevano.
   • Il trasferimento del dominio non offre piani di fatturazione di Google Workspace speciali per includere l'acquisto di licenze di riserva durante il trasferimento. Se le licenze dell'ambiente di origine rientrano in un piano di fatturazione annuale, rimangono attive e vengono fatturate fino alla fine del contratto con piano annuale. Consulta il tuo rappresentante di vendita o account manager se hai altre domande sui piani di fatturazione di Google Workspace.

2. Verifica che le licenze vengano applicate correttamente agli utenti trasferiti quando esistono più licenze: nell'ambiente di destinazione esistono alcune configurazioni che potrebbero influire sul modo in cui le licenze vengono assegnate agli utenti trasferiti.Questo può far sì che gli utenti trasferiti si ritrovino con una licenza diversa da quella prevista. Queste configurazioni includono le licenze automatiche e l'override delle licenze automatiche per organizzazioni specifiche.

   Per assicurarti che non vengano apportate modifiche impreviste alle licenze durante il trasferimento, devi applicare le seguenti azioni:

   • Non è necessario fare modifiche se nell'ambiente di destinazione la configurazione dell'assegnazione automatica delle licenze è "Disattivata per tutti" o se l'ambiente di destinazione ha un solo tipo di licenza.
   • Se nell'ambiente di destinazione la configurazione dell'assegnazione automatica delle licenze è "Attivata per tutti" (ad esempio, licenze Google Workspace), assicurati che l'override sia attivo per unità organizzative specifiche. Per l'unità organizzativa principale del trasferimento, assicurati che la configurazione dell'assegnazione automatica delle licenze sia disattivata, senza ulteriori override per le unità organizzative secondarie.

3. Crea l'unità organizzativa di trasferimento principale e, se necessario, ricrea la struttura di unità organizzative dell'ambiente di origine: crea un'unità organizzativa da utilizzare come unità organizzativa principale per tutti gli utenti trasferiti. Una volta creata, hai due opzioni:

   • Non fare nulla: il processo di trasferimento del dominio ricrea la struttura di unità organizzative dell'ambiente di origine sotto la nuova unità organizzativa principale del trasferimento. Per eseguire questa operazione, scegli No per l'opzione che consente di ricreare la struttura di unità organizzative in anticipo. Tutti gli utenti trasferiti ereditano i criteri che applichi a livello di unità organizzativa.
   • Ricrea manualmente la struttura di unità organizzative dell'ambiente di origine sotto l'unità organizzativa principale del trasferimento: il trasferimento del dominio assicura che l'intera struttura di unità organizzative dell'ambiente di origine venga replicata correttamente prima di procedere con il trasferimento. Per eseguire questa operazione, scegli Sì per l'opzione che consente di ricreare la struttura di unità organizzative in anticipo. Questa opzione è utile se vuoi impostare criteri separati per unità organizzative secondarie diverse.

     Nota: il trasferimento del dominio convalida solo la struttura di unità organizzative. È tua responsabilità verificare che vengano impostati i criteri appropriati per le unità organizzative.

4. Definisci le impostazioni e i criteri in modo che riflettano i requisiti degli ambienti di origine e di destinazione: i criteri e le impostazioni dell'ambiente di origine non vengono trasferiti nell'ambiente di destinazione. Inoltre, terminato il processo di trasferimento, solo i criteri e le impostazioni presenti nell'ambiente di destinazione vengono applicati agli utenti trasferiti e ai loro dati.

   Esamina i criteri e le impostazioni nell'ambiente di destinazione e confrontali con l'ambiente di origine. Questa azione riguarda sia le impostazioni generali sia quelle specifiche per l'unità organizzativa principale del trasferimento, al fine di assicurarsi che coprano tutte le entità e tutti gli utenti trasferiti.

   Di seguito è riportato un elenco non esaustivo di criteri e impostazioni che devi verificare nell'ambito del processo di configurazione. Inoltre, esegui un controllo completo di entrambi gli ambienti per assicurarti che vengano analizzate tutte le sezioni pertinenti:

   • Attivazione dei servizi (on/off): verifica che i servizi che utilizzi nell'ambiente di origine siano attivati nell'ambiente di destinazione e che l'unità organizzativa principale del trasferimento si comporti come previsto. Questa verifica è particolarmente importante se utilizzi Google Vault, perché le regole di Vault potrebbero non essere applicate se il servizio non è attivo.
   • Gmail, impostazioni avanzate e record MX: esamina impostazioni come routing della posta, regole di conformità, abilitazione IMAP e delega. Per maggiori dettagli, vedi Attivare Gmail con Google Workspace.
   • Gestione delle password: rivedi i criteri relativi alle password per assicurarti che siano allineati alle procedure della tua organizzazione. Gli utenti trasferiti nell'ambiente di destinazione ereditano i criteri di gestione delle password dell'ambiente di destinazione.
   • Verifica in due passaggi: controlla se gli utenti sono autorizzati ad aggiungere una configurazione della verifica in due passaggi al proprio account e se la verifica è consentita o viene imposta. Se gli utenti con la verifica in due passaggi attivata vengono trasferiti in un ambiente di destinazione o un'unità organizzativa in cui la verifica in due passaggi è disattivata, gli amministratori della destinazione non saranno in grado di gestirli. Gli amministratori possono spostare questi utenti in un'altra unità organizzativa in cui è attivata la verifica in due passaggi per apportare delle modifiche oppure possono rimuovere la verifica in due passaggi dagli account prima del trasferimento.
   • Impostazioni di condivisione: consentono di specificare se gli utenti possono condividere i propri contenuti all'esterno dell'organizzazione. Se l'ambiente di origine blocca la condivisione e l'ambiente di destinazione no, i contenuti trasferiti potrebbero essere accessibili all'esterno dell'organizzazione. Se nell'ambiente di origine la condivisione è aperta per impostazione predefinita e nell'ambiente di destinazione non lo è, i contenuti trasferiti potrebbero essere inaccessibili per gli utenti della tua organizzazione. Scopri di più sulle opzioni di condivisione per Google Drive e Google Calendar.
   • Regole di Prevenzione della perdita di dati (DLP): la funzionalità DLP monitora e impedisce agli utenti di condividere informazioni sensibili all'esterno dell'organizzazione. Quando DLP impedisce agli utenti di condividere informazioni nell'ambiente di origine e i contenuti vengono trasferiti in un ambiente di destinazione in cui DLP non è configurata, gli utenti dell'ambiente di destinazione possono condividere le informazioni all'esterno dell'organizzazione. Scopri di più sulle regole DLP per Gmail e le regole DLP per Drive.
   • Cronologia chat: consente di stabilire se la cronologia viene salvata o meno nel registro e se gli utenti possono impostare l'applicazione forzata per tutte le chat o come valore predefinito. Se l'ambiente di origine consente l'attivazione della cronologia chat, ma l'ambiente di destinazione ne forza la disattivazione, la cronologia chat va perduta. Anche se Google Chat è indicato come non supportato per il trasferimento, i messaggi diretti verranno trasferiti.
   • Paesi/regioni dei dati: puoi decidere in quale località geografica specifica vuoi archiviare i dati migrati. Per gli utenti trasferiti che devono rimanere in una località geografica specifica, questo criterio deve essere impostato correttamente nell'ambiente di destinazione per assicurarsi che i dati non escano inaspettatamente dal paese o dalla regione in cui devono trovarsi. Per informazioni dettagliate, vedi Regioni di dati: scegliere una posizione geografica per i propri dati.
   • App meno sicure (note anche come app che usano una password): se le app meno sicure sono attive nell'ambiente di origine e disattivate nell'ambiente di destinazione, la connessione con l'applicazione che le utilizza scade e si chiude. I periodi di timeout variano a seconda dell'applicazione, ma in genere la scadenza è entro 60 minuti. Le future richieste di accesso effettuate dall'applicazione non sicura verranno bloccate. Per maggiori dettagli, vedi Controllare l'accesso alle app meno sicure.
   • Ambiti OAuth, Single Sign-On (SSO) via SAML, app attendibili ed estensioni di Chrome: i controlli OAuth determinano il livello di accesso tramite API consentito agli utenti e alle applicazioni di terze parti. Il Single Sign-On via SAML, sia fornito da Google Workspace sia implementato come applicazione personalizzata, consente agli utenti di sfruttare le proprie credenziali di Google Workspace per accedere ad altre applicazioni o altri servizi. Le app attendibili determinano le applicazioni che gli utenti possono installare da Google Workspace Marketplace o da Chrome Web Store e a quali app è consentito bypassare le limitazioni di OAuth. Scopri di più su come controllare le app interne e di terze parti, il Single Sign-On via SAML, le app di Google Workspace Marketplace e le app e le estensioni di Chrome.
   • Delega a livello di dominio: consente alle app di accedere ai dati di Google Workspace degli utenti. Per assicurarti che i client e gli ambiti funzionino correttamente, configura la delega a livello di dominio nell'ambiente di destinazione prima del trasferimento.

   Importante: la mancata corretta definizione dei criteri e delle impostazioni può avere le conseguenze seguenti.

   • Esposizione involontaria dei dati all'esterno dell'organizzazione (ad esempio, l'ambiente di destinazione ha impostazioni più aperte rispetto all'ambiente di origine).
   • Accesso limitato a dati che prima erano accessibili (ad esempio, l'ambiente di destinazione ha impostazioni più restrittive rispetto all'ambiente di origine).
5. Accettare contratti che regolano i dati trasferiti: esamina l'Emendamento sul trattamento dei dati (ETD), la clausola contrattuale standard e l'Emendamento al Contratto di società in affari HIPAA (BAA) nell'ambiente di destinazione. Per maggiori dettagli, vedi Conformità e registrazioni relative alla privacy per Google Workspace e Cloud Identity.
6. Attivare Vault se è utilizzato nell'ambiente di origine: se l'ambiente di destinazione non utilizza Vault, ma l'ambiente di origine sì, l'ambiente di destinazione deve attivare Vault.
7. Informa il tuo rivenditore Google Workspace (se applicabile): comunica al rivenditore la durata programmata del trasferimento del dominio e richiedi che l'account non venga modificato (ad esempio, aggiornando gli abbonamenti) durante il periodo di trasferimento.

8. Effettua la registrazione a eventuali programmi alpha o beta a cui sta partecipando l'ambiente di origine o di destinazione (se applicabile): le registrazioni ai programmi alpha e beta non vengono trasferite nell'ambiente di origine. Analogamente, l'ambiente di origine potrebbe dipendere dalle registrazioni nell'ambiente di destinazione. L'ambiente senza registrazioni deve richiedere la partecipazione ed essere accettato da quei programmi per continuare a utilizzarli.
   Ti consigliamo di iscriverti ai programmi alpha o beta prima di eseguire il trasferimento, in modo che gli utenti da trasferire abbiano a disposizione le stesse funzionalità durante tutto il processo. Tuttavia, la procedura di registrazione potrebbe richiedere tempo e non è garantito il buon esito. Di conseguenza, è consigliata ma non obbligatoria.

Importante:

• Eseguire il downgrade delle licenze potrebbe causare la perdita di servizi e funzionalità di Google Workspace. Controlla attentamente le differenze tra le versioni di Google Workspace e l'impatto dell'upgrade e del downgrade prima di apportare modifiche. Scopri di più sulle versioni di Google Workspace.
• Il downgrade delle licenze potrebbe attivare il processo SWP, il che può causare un ritardo del trasferimento fino a 90 giorni.

Passaggio 3: altre attività e considerazioni

• Gestione dei cambiamenti: né il team di trasferimento del dominio Google Workspace né il processo di trasferimento forniscono automaticamente agli utenti informazioni sull'esecuzione del trasferimento quando questo è in corso. Consigliamo vivamente ai rappresentanti dell'ambiente di origine e di quello di destinazione di informare in anticipo gli utenti del processo di trasferimento e dei suoi potenziali effetti.

  Durante il trasferimento, sia nell'ambiente di origine che in quello di destinazione vengono bloccate tutte le azioni di tipo amministrativo, incluso l'accesso alle API e alla Console di amministrazione Google. Consigliamo vivamente ai rappresentanti dell'ambiente di origine e di quello di destinazione di informare tutti i super amministratori e gli utenti con delega di amministratore del dominio prima del trasferimento e una volta che questo sia stato completato.

• Dipendenze esterne: se utilizzi Google Cloud Directory Sync (GCDS), GAM (uno strumento a riga di comando di terze parti utilizzato dagli amministratori di Google Workspace per gestire le impostazioni del dominio e degli utenti) o un fornitore di Single Sign-On (SSO) di terze parti, assicurati di analizzare l'effetto del trasferimento. Esamina inoltre il modo in cui la coesistenza degli ambienti di origine e di destinazione in un unico ambiente influisce sul sistema e sulla tempistica dell'esecuzione del trasferimento.

Conservazione a tempo indeterminato di Google Vault nell'ambiente di destinazione

Google Workspace Domain Transfer& configura regole di conservazione personalizzate a tempo indeterminato nell'ambiente di destinazione. Non è necessario alcun intervento da parte degli amministratori dell'ambiente di destinazione.

L'archivio di Vault per gli utenti trasferiti viene spostato, ma le regole di conservazione di Vault dell'ambiente di origine non vengono trasferite. Per assicurarsi che i dati di Vault non corrano rischi durante il trasferimento, il processo di trasferimento crea le seguenti regole di conservazione di Vault nell'ambiente di destinazione prima di eseguire qualsiasi azione:

• Gmail: regola di conservazione personalizzata a tempo indeterminato (ambito: unità organizzativa principale del trasferimento).
• Google Calendar: regola di conservazione personalizzata a tempo indeterminato (ambito: unità organizzativa principale del trasferimento).
• Google Chat: regola di conservazione personalizzata a tempo indeterminato (ambito: messaggi diretti con utenti trasferiti nell'unità organizzativa principale del trasferimento, ma non spazi).
• Google Drive: regola di conservazione personalizzata a tempo indeterminato, che non include i Drive condivisi (ambito: unità organizzativa principale del trasferimento).
• Google Gruppi: regola di conservazione personalizzata a tempo indeterminato (ambito: unità organizzativa principale). Conserva i dati per tutti i gruppi nell'ambiente di destinazione, compresi quelli non inclusi nel processo di trasferimento.
• Google Meet: richiede due regole di conservazione personalizzate a tempo indeterminato:
  1. Non include i Drive condivisi (ambito: unità organizzativa principale del trasferimento).
  2. Include tutti i Drive condivisi (ambito: unità organizzativa principale).

     Conserva i dati per tutti i Drive condivisi nell'ambiente di destinazione, compresi quelli non inclusi nel processo di trasferimento.

• Google Sites: richiede due regole di conservazione personalizzate a tempo indeterminato.
  1. Non include i Drive condivisi (ambito: unità organizzativa principale del trasferimento).
  2. Include tutti i Drive condivisi (ambito: unità organizzativa principale).

     Conserva i dati per tutti i Drive condivisi nell'ambiente di destinazione, compresi quelli non inclusi nel processo di trasferimento.

• Drive condivisi: regola personalizzata di conservazione a tempo indeterminato per tutti i Drive condivisi (ambito: unità organizzativa principale). Conserva i dati per tutti i Drive condivisi nell'ambiente di destinazione, compresi quelli non inclusi nel processo di trasferimento.

Importante: le regole di conservazione di Vault nell'ambiente di destinazione non vengono rimosse né modificate durante il processo di trasferimento perché ciò potrebbe causare la perdita irreversibile dei dati.