5. Effectuer les tâches préalables au transfert

Étape 1 : Tâches liées à l'environnement source

1. Faire passer les licences à la version supérieure (le cas échéant) : les licences ne sont pas déplacées lors du processus de transfert. Si l'environnement source utilise une édition Google Workspace différente de celle de l'environnement de destination, vous devez faire passer la source à la version supérieure pour qu'elle corresponde à la destination. Pour en savoir plus, consultez la section sur les transferts de licences sous Tâches liées à l'environnement de destination.

   Remarques :

   • Pour éviter de payer, vous pouvez utiliser des licences d'essai ou de grâce dans l'environnement source. Notez toutefois les points suivants :
     • Ces licences bloquent le processus de remplacement de tout autre domaine par le domaine principal. Modifiez le domaine principal avant de provisionner des licences temporaires.
     • Si les licences disponibles dans l'environnement de destination sont des licences complètes, les utilisateurs se voient attribuer une licence complète suite au transfert.
   • Les utilisateurs de l'environnement source auxquels aucune licence n'est attribuée sont tout de même transférés.
2. Résiliez les abonnements associés aux licences non compatibles : cette résiliation peut engendrer certaines conséquences. Soyez particulièrement vigilant lors de cette étape si votre environnement utilise Google Voice. Pour en savoir plus, consultez Licences source.
3. Ajoutez un domaine réservé à Google Workspace (le cas échéant) : ajoutez et validez un nouveau nom de domaine secondaire dans l'environnement source, qui remplacera à terme le domaine principal existant. S'il existe un domaine secondaire et qu'il n'a pas besoin d'être transféré, vous pouvez l'utiliser à la place. Pour en savoir plus, consultez Ajouter un domaine avec alias d'utilisateur ou un domaine secondaire.
4. Créez un administrateur de substitution et définissez-le comme administrateur principal du compte : créez un compte utilisateur associé au domaine réservé. Si vous réutilisez un ancien compte, assurez-vous qu'aucun autre domaine transféré défini comme alias n'est associé au compte. Attribuez le rôle de super-administrateur à l'utilisateur, puis définissez-le comme administrateur principal du compte. Pour en savoir plus, consultez Envoyer les notifications d'un compte et de facturation à un autre administrateur. Assurez-vous que la validation en deux étapes de Google est configurée et connectez-vous au moins une fois pour valider l'accès avec le compte administrateur de substitution.
5. Définissez le domaine réservé comme domaine principal : changez de domaine, afin que le domaine réservé devienne le nouveau domaine principal.

   Avant de changer de domaine :

   Lorsque vous êtes prêt à procéder au remplacement, consultez Modifier votre domaine principal pour Google Workspace.

   • Résiliez tous les abonnements liés à des appareils, y compris du matériel Google Meet et Chrome Enterprise.
   • Il peut être nécessaire de supprimer certaines licences non compatibles avant le transfert. Pour en savoir plus, consultez Licences source.
   • Si l'environnement source comporte des licences en période d'essai, le changement est bloqué. Assurez-vous de procéder au changement avant le provisionnement des licences temporaires.
   • La modification du domaine principal et l'utilisation de domaines secondaires présentent des problèmes connus. Consultez Alternatives au changement de domaine principal.
   • Ne renommez pas les utilisateurs transférés ni les groupes après avoir modifié le nom du domaine principal. Les utilisateurs et les groupes doivent être conservés dans leur domaine transféré.
   • Si vous configurez l'authentification unique (SSO) via un fournisseur d'identité tiers et que vous utilisez un émetteur spécifique au domaine, l'assertion SAML change pour refléter le nouveau domaine principal. Vérifiez la configuration de votre fournisseur d'identité pour vous assurer que les utilisateurs peuvent s'authentifier après le changement du domaine principal. Pour en savoir plus, consultez Conditions requises concernant les assertions SSO.
6. Définissez des règles de conservation Google Vault : configurez des règles de conservation personnalisées illimitées.

   Créez une règle pour les applications suivantes :

   • Gmail : pour "Unité organisationnelle", sélectionnez l'unité organisationnelle racine.
   • Google Groupes : pour "Groupes", sélectionnez "Tous les groupes".

   Créez deux règles pour les applications suivantes :

   • Chat : sélectionnez Unité organisationnelle l'unité organisationnelle racine. Pour la deuxième règle, sélectionnez Tous les espaces Chat.
   • Drive : sélectionnez Unité organisationnelle l'unité organisationnelle racine. Pour la deuxième règle, sélectionnez Tous les Drive partagés.
   • Meet : sélectionnez Unité organisationnelle l'unité organisationnelle racine, puis activez l'option Inclure les éléments des Drive partagés. Pour la deuxième règle, sélectionnez Tous les Drive partagés.
   • Sites : sélectionnez Unité organisationnelle l'unité organisationnelle racine, puis activez l'option Inclure les éléments des Drive partagés. Pour la deuxième règle, sélectionnez Tous les Drive partagés.

   En outre, des règles de conservation personnalisées illimitées sont configurées dans l'environnement de destination avant le transfert. Pour en savoir plus, consultez Conservation Google Vault illimitée dans l'environnement de destination. Pour en savoir plus sur le transfert depuis Vault, consultez Transférer vos données Vault avec Domain Transfer.

7. Mettez à jour votre enregistrement SPF (Sender Policy Framework) (le cas échéant) : si l'environnement de destination utilise une passerelle sortante différente de l'environnement source, ce dernier doit mettre à jour son enregistrement SPF pour inclure la passerelle sortante.

   Remarque : Si vous utilisez DKIM (DomainKeys Identified Mail), le transfert ne devrait pas avoir d'incidence sur votre authentification DMARC (Domain-based Message Authentication, Reporting, and Conformance). L'enregistrement SPF continuera à s'aligner après le transfert, même si DKIM ne le fait pas temporairement. Assurez-vous également d'effectuer la tâche DKIM post-transfert dans l'environnement de destination.

8. Résolvez les conflits de ressources d'agenda : s'il existe des conflits de ressources d'agenda, résolvez-les avant de continuer :
   • ID de bâtiments : l'ID d'un bâtiment de l'environnement source ne peut pas être identique à l'ID d'un bâtiment de l'environnement de destination. Pour contourner le blocage des transferts, vous avez deux possibilités. Vous pouvez supprimer le bâtiment dans l'environnement source. Vous pouvez également rendre identiques les détails des deux bâtiments afin de fusionner les bâtiments source et de destination. Pour que les deux bâtiments soient identiques, faites en sorte que leur identifiant, leur nom, tous les champs d'adresse, leur description et leur étage soient parfaitement identiques pour les deux bâtiments.
   • Nom de bâtiments : si une ressource de bâtiment de l'environnement source porte le même nom qu'un bâtiment de l'environnement de destination, vous devez modifier le nom de l'une des ressources pour résoudre le conflit. Une fois le transfert terminé, vous pouvez fusionner les deux ressources de bâtiments.
   • ID de ressource : une ressource de l'environnement source ayant le même ID qu'une ressource de la destination crée un conflit qui ne peut pas être résolu avec le processus de transfert, et la ressource n'est pas transférée. Supprimez l'une des ressources en conflit et recréez-la avec un ID non conflictuel. Il faut compter 30 jours pour qu'une ressource supprimée soit complètement effacée du système. Vous pouvez attendre que la ressource soit complètement supprimée ou l'équipe Domain Transfer peut envoyer une demande de suppression manuelle.
9. Évaluez l'impact sur l'organisation Google Cloud associée (le cas échéant) : si Google Cloud est en cours d'utilisation, informez les administrateurs de l'environnement concerné de l'impact potentiel du transfert de domaine Google Workspace sur Google Cloud. Si vous avez besoin d'aide pour évaluer ces conséquences et connaître la procédure à suivre pour les corriger, contactez votre partenaire ou vos contacts Google Cloud. L'équipe Google Workspace Domain Transfer ne propose pas d'assistance pour Google Cloud lors des transferts de domaine.
10. Informez votre revendeur Google Workspace (le cas échéant) : indiquez-lui la date et l'heure du transfert de domaine, et demandez-lui de ne pas modifier le compte (modification des abonnements, par exemple) pendant cette période.

11. Inscrivez-vous aux programmes alpha ou bêta auxquels participe l'environnement source ou de destination (le cas échéant) : les inscriptions aux programmes alpha et bêta ne sont pas transférées dans l'environnement source. De la même manière, l'environnement source peut dépendre d'inscriptions dans l'environnement de destination. L'environnement non inscrit doit demander à participer à ces programmes et voir sa demande acceptée pour continuer à les utiliser.
    Nous vous recommandons de vous inscrire aux programmes alpha ou bêta avant le transfert afin que vos utilisateurs transférés bénéficient des mêmes fonctionnalités tout au long du processus. Toutefois, le processus d'inscription peut prendre un certain temps et le succès n'est pas garanti. La démarche est donc recommandée, sans être obligatoire.

12. Pour transférer des appareils Chrome enregistrés sans contact :
    1. Dans l'environnement source,révoquez le jeton de pré-provisionnement existant et déprovisionnez tous les appareils. Rétablissez les paramètres par défaut des appareils.
    2. Dans l'environnement de destination, créez un jeton de pré-provisionnement.
    3. Transmettez-le à votre partenaire de pré-provisionnement autorisé. Celui-ci utilise le jeton pour pré-provisionner les appareils dans l'environnement de destination.

    Les appareils s'enregistrent automatiquement une fois connectés à Internet. L'état de l'appareil passe à "Provisionné".

    Pour en savoir plus sur les appareils sans contact, consultez Enregistrement sans contact.

Étape 2 : Tâches liées à l'environnement de destination

1. Les licences ne sont pas déplacées dans le cadre du processus de transfert. Vous devez donc provisionner suffisamment de licences Google Workspace disponibles pour tous les utilisateurs transférés. Lorsque vous transférez des utilisateurs, ils se voient attribuer dans l'environnement de destination l'ensemble des licences qu'ils avaient dans l'environnement source. L'environnement de destination doit donc compter suffisamment de licences disponibles de même type au moment du transfert.

   Si l'environnement de destination utilise une édition Google Workspace différente de celle de l'environnement source, assurez-vous que les licences correspondent en mettant à niveau les licences dans l'environnement source ou de destination.

   Remarques :

   • Google recommande de faire passer les licences à la version supérieure pour éviter de déclencher le processus d'effacement du service (SWP).
   • Provisionnez toutes les licences manquantes afin que plusieurs abonnements figurent dans l'environnement de destination. Vous pouvez aussi faire passer les licences utilisateur individuelles à la version supérieure ou inférieure après le transfert. Notez que les types de licences ne sont pas tous compatibles avec l'attribution de licences de domaine partiel (PDL).
   • Assurez-vous que suffisamment de licences sont disponibles dans l'environnement de destination. Déterminez si d'autres utilisateurs sont ajoutés à chaque environnement source (en cas d'embauches, par exemple) entre le début et la fin du processus de transfert. S'il y a plusieurs transferts, vous devez également tenir compte du nombre total d'utilisateurs source pour tous les transferts.
   • Les utilisateurs de l'environnement source auxquels aucune licence n'est attribuée sont tout de même transférés. Surveillez l'attribution automatique des licences dans l'environnement de destination pour vous assurer que ces utilisateurs n'obtiennent pas de licence.
   • Le transfert de domaine ne propose pas de forfaits Google Workspace spécifiques permettant de faciliter l'achat de licences disponibles lors du transfert. Si les licences de l'environnement source présentent un forfait annuel, elles restent actives et sont facturées au terme de votre contrat annuel. Si vous avez d'autres questions concernant les forfaits Google Workspace, consultez votre conseiller commercial ou votre responsable de compte.

2. Assurez-vous que les licences sont bien appliquées aux utilisateurs transférés lorsque plusieurs licences sont présentes : certaines configurations de l'environnement de destination sont susceptibles d'avoir un impact sur l'attribution de licences aux utilisateurs.Les utilisateurs transférés peuvent ainsi se voir attribuer une licence qui ne leur correspond pas. Cela peut par exemple se produire en cas d'attribution de licences automatique ou lorsque l'attribution de licences automatique est ignorée pour des organisations spécifiques.

   Pour vous assurer qu'aucune modification imprévue n'est apportée à l'attribution de licences lors du transfert, vous devez remplir les conditions suivantes :

   • Si l'attribution de licences automatique de l'environnement de destination est définie sur "Désactivé pour tous" ou si l'environnement de destination comporte un seul type de licence, aucun changement n'est requis.
   • Si l'attribution automatique des licences de l'environnement de destination est définie sur "Activé pour tous" (licences Google Workspace, par exemple), assurez-vous de l'ignorer pour des unités organisationnelles spécifiques. Pour l'unité organisationnelle racine de transfert, assurez-vous que la configuration de l'attribution automatique des licences est désactivée, sans forçage supplémentaire pour les unités organisationnelles enfants.

3. Créez l'unité organisationnelle racine de transfert, et reproduisez éventuellement la structure de l'unité organisationnelle de l'environnement source : créez une unité organisationnelle servant de parent pour tous les utilisateurs transférés. Vous avez ensuite deux options :

   • Ne rien faire : le processus de transfert de domaine recrée la structure de l'unité organisationnelle de l'environnement source sous la nouvelle unité organisationnelle racine de transfert. Pour cela, définissez l'option de transfert "Recréer la structure de l'unité organisationnelle en amont" sur "Non". Tous les utilisateurs transférés héritent des règles que vous appliquez au niveau de l'unité organisationnelle.
   • Recréer manuellement la structure de l'unité organisationnelle de l'environnement source sous l'unité organisationnelle racine de transfert : le transfert de domaine s'assure que toute la structure de l'unité organisationnelle de l'environnement source est bien répliquée avant de procéder au transfert. Pour ce faire, définissez l'option de transfert "Recréer la structure de l'unité organisationnelle en amont" sur "Oui". Cette option peut s'avérer utile si vous souhaitez définir des règles distinctes sur les différentes unités organisationnelles enfants.

     Remarque : Le transfert de domaine ne valide que la structure de l'unité organisationnelle. Il est de votre responsabilité de vous assurer que les règles appropriées sont définies sur les unités organisationnelles.

4. Établissez les règles et paramètres adaptés aux besoins des environnements source et de destination : les règles et les paramètres de l'environnement source ne sont pas transférés vers l'environnement de destination. De plus, une fois le processus de transfert terminé, seuls les paramètres et les règles de l'environnement de destination s'appliquent aux utilisateurs transférés et à leurs données.

   Vous devez examiner les règles et les paramètres de l'environnement de destination et les comparer avec ceux de l'environnement source. Cette action inclut à la fois les paramètres généraux et ceux propres à l'unité organisationnelle racine de transfert pour qu'ils s'appliquent à tous les utilisateurs et entités transférés.

   Voici une liste non exhaustive des règles et paramètres à vérifier lors du processus de configuration. Réalisez aussi un audit complet des deux environnements pour vous assurer que toutes les sections pertinentes sont analysées :

   • Activation des services ("Activé"/"Désactivé") : vérifiez que les services que vous utilisez dans l'environnement source sont activés dans l'environnement de destination et que l'unité organisationnelle racine de transfert se comporte comme prévu. C'est particulièrement important lorsque vous utilisez Google Vault, puisque les règles Vault peuvent ne pas s'appliquer si le service est désactivé.
   • Gmail, paramètres avancés et enregistrements MX : examinez des paramètres comme le routage des e-mails, les règles de conformité, l'activation du protocole IMAP et la délégation. Pour en savoir plus, consultez Activer Gmail avec Google Workspace.
   • Gestion des mots de passe : examinez vos règles relatives aux mots de passe pour vous assurer qu'elles sont conformes aux procédures de votre organisation. Une fois les utilisateurs transférés déplacés vers l'environnement de destination, ils héritent des règles de gestion des mots de passe dans l'environnement de destination.
   • Validation en deux étapes : permet d'autoriser ou d'appliquer de force la validation en deux étapes, ainsi que de définir si les utilisateurs peuvent l'ajouter à leur compte. Si des utilisateurs pour lesquels la validation en deux étapes est activée sont transférés dans un environnement de destination ou une unité organisationnelle où cette fonction est désactivée, les administrateurs de destination ne pourront pas les gérer. Il est plutôt recommandé pour les administrateurs de déplacer ces utilisateurs vers une autre unité organisationnelle dans laquelle la validation en deux étapes est activée afin d'effectuer des modifications, ou de désactiver cette fonction des comptes avant le transfert.
   • Paramètres de partage : contrôlent si les utilisateurs peuvent partager du contenu en dehors de l'organisation. Si l'environnement source bloque le partage alors que l'environnement de destination ne le fait pas, le contenu transféré peut être accessible en dehors de votre organisation. Si l'environnement source propose un partage ouvert par défaut alors que l'environnement de destination ne le propose pas, le contenu transféré peut être inaccessible aux utilisateurs de votre organisation. En savoir plus sur les options de partage de Google Drive et de Google Agenda
   • Règles de protection contre la perte de données : surveillent les utilisateurs et les empêchent de partager des informations sensibles en dehors de votre organisation. Quand la protection contre la perte de données empêche les utilisateurs de partager des informations dans l'environnement source et quand le contenu est transféré dans un environnement de destination sans configuration de protection contre la perte de données, les utilisateurs de l'environnement de destination peuvent partager des informations en dehors de votre organisation. En savoir plus sur les règles de protection contre la perte de données Gmail et les règles de protection contre la perte de données Drive
   • Historique des discussions : contrôle si l'historique des discussions est enregistré ou en mode privé, et si les utilisateurs peuvent définir l'application sur toutes les discussions ou l'appliquer par défaut. Si l'environnement source permet d'activer l'historique des discussions alors que l'environnement de destination impose sa désactivation, l'historique des discussions est perdu. Même si Google Chat est indiqué comme non compatible avec le transfert, les messages privés (MP) seront transférés.
   • Pays/Régions des données : contrôle les emplacements géographiques spécifiques dans lesquels stocker vos données migrées. Pour les utilisateurs transférés devant rester dans un emplacement géographique spécifique, cette règle doit être définie correctement dans l'environnement de destination pour vous assurer que leurs données ne quittent pas la région ou le pays requis de manière inattendue. Pour en savoir plus, consultez Régions de données : choisir l'emplacement géographique de vos données.
   • Applications moins sécurisées (nécessitant un mot de passe) : si les applications moins sécurisées sont activées dans l'environnement source et désactivées dans l'environnement de destination, le délai de connexion avec l'application à l'aide d'applications moins sécurisées est dépassé et la connexion est interrompue. Les délais avant expiration varient selon les applications, mais sont généralement de 60 minutes. Les demandes d'accès ultérieures effectuées par les applications non sécurisées sont bloquées. Pour en savoir plus, consultez Contrôler l'accès aux applications moins sécurisées.
   • Champs d'application OAuth, authentification unique (SSO) pour SAML, applications approuvées et extensions Chrome : les commandes OAuth déterminent le niveau d'accès aux API autorisé pour les utilisateurs et les applications tierces. L'authentification unique pour SAML, qu'elle soit fournie par Google Workspace ou implémentée comme application personnalisée, permet aux utilisateurs d'accéder à d'autres applications ou services à l'aide de leurs identifiants Google Workspace. Les applications approuvées déterminent les applications que les utilisateurs peuvent installer depuis Google Workspace Marketplace ou le Chrome Web Store, ainsi que les applications autorisées à contourner les restrictions OAuth. Découvrez comment contrôler les applications tierces et internes, l'authentification unique SAML, les applications Google Workspace Marketplace et les applications et extensions Chrome.
   • Délégation au niveau du domaine : permet aux applications d'accéder aux données Google Workspace des utilisateurs. Pour vous assurer que les clients et les habilitations fonctionnent correctement, configurez la délégation au niveau du domaine dans l'environnement de destination avant le transfert.

   Important : Si vous ne pouvez pas établir correctement les règles et paramètres, vous risquez :

   • l'exposition accidentelle de vos données en dehors de votre organisation (l'environnement de destination a des paramètres plus ouverts que l'environnement source, par exemple) ;
   • de voir l'accès aux données auparavant accessibles restreint (l'environnement de destination a des paramètres plus restrictifs que l'environnement source, par exemple).
5. Acceptez les contrats régissant les données transférées : consultez l'Avenant relatif au traitement des données (DPA), le modèle de clause contractuelle et l'Amendement à l'accord de partenariat relatif à la loi HIPAA dans l'environnement de destination. Pour en savoir plus, consultez Respect de la confidentialité et conservation des données dans Google Workspace et Cloud Identity.
6. Activez Vault s'il est utilisé dans l'environnement source : si l'environnement de destination n'utilise pas Vault alors que l'environnement source le fait, l'environnement de destination doit l'activer.
7. Informez votre revendeur Google Workspace (le cas échéant) : indiquez-lui la date et l'heure du transfert de domaine, et demandez-lui de ne pas modifier le compte (modification des abonnements, par exemple) pendant cette période.

8. Inscrivez-vous aux programmes alpha ou bêta auxquels participe l'environnement source ou de destination (le cas échéant) : les inscriptions aux programmes alpha et bêta ne sont pas transférées dans l'environnement source. De la même manière, l'environnement source peut dépendre d'inscriptions dans l'environnement de destination. L'environnement non inscrit doit demander à participer à ces programmes et voir sa demande acceptée pour continuer à les utiliser.
   Nous vous recommandons de vous inscrire aux programmes alpha ou bêta avant le transfert afin que vos utilisateurs transférés bénéficient des mêmes fonctionnalités tout au long du processus. Toutefois, le processus d'inscription peut prendre un certain temps et le succès n'est pas garanti. La démarche est donc recommandée, sans être obligatoire.

Important :

• Faire revenir les licences à une version inférieure peut entraîner une perte de services et de fonctionnalités Google Workspace. Examinez attentivement les différences entre les éditions Google Workspace ainsi que l'impact du passage à une version supérieure comme inférieure avant d'apporter des modifications. En savoir plus sur les éditions Google Workspace
• Faire revenir les licences à une version inférieure risque de déclencher le SWP, ce qui entraîne un retard du transfert pouvant aller jusqu'à 90 jours.

Étape 3 : Autres tâches et éléments à prendre en compte

• Gestion du changement : ni l'équipe Google Workspace chargée du transfert de domaine ni le processus de transfert en lui-même ne fournissent automatiquement aux utilisateurs des informations sur l'exécution du transfert lors du processus. Il est vivement recommandé pour les responsables des environnements source et de destination d'informer en amont les utilisateurs au sujet du processus de transfert et de son éventuel impact.

  Toutes les actions d'administration dans les environnements source et de destination sont bloquées lors du transfert, que ce soit par l'intermédiaire de l'API ou de la console d'administration Google. Il est vivement recommandé pour les responsables des environnements source et de destination d'informer tous les super-administrateurs de domaine et administrateurs délégués du début et de la fin du transfert.

• Dépendances externes : si vous utilisez Google Cloud Directory Sync (GCDS), GAM (un outil de ligne de commande tiers permettant aux administrateurs Google Workspace de gérer les paramètres des domaines et des utilisateurs) ou un fournisseur d'authentification unique (SSO) tiers, assurez-vous d'analyser l'effet du transfert. Examinez aussi l'impact sur votre système de la coexistence des environnements source et de destination dans un même environnement, ainsi que le moment où votre transfert doit être exécuté.

Conservation Google Vault illimitée dans l'environnement de destination

Google Workspace Domain Transfer configure des règles de conservation personnalisées illimitées dans l'environnement de destination. Aucune action n'est requise pour les administrateurs de l'environnement de destination.

L'archive Vault pour les utilisateurs transférés est déplacée, contrairement aux règles de conservation Vault de l'environnement source. Pour assurer la protection de toutes les données Vault pendant et après le transfert, le processus de transfert crée les règles de conservation Vault suivantes dans l'environnement de destination avant d'exécuter la moindre action de transfert :

• Gmail : règle de conservation personnalisée illimitée (appliquée au niveau de l'unité organisationnelle racine de transfert)
• Google Agenda : règle de conservation personnalisée illimitée (appliquée au niveau de l'unité organisationnelle racine de transfert)
• Google Chat : règle de conservation personnalisée illimitée (appliquée au niveau des messages privés échangés avec les utilisateurs transférés dans l'unité organisationnelle racine de transfert, mais pas au niveau des espaces).
• Google Drive : règle de conservation personnalisée illimitée, à l'exclusion des Drive partagés (règle appliquée au niveau de l'unité organisationnelle racine de transfert)
• Google Groupes : règle de conservation personnalisée illimitée (appliquée au niveau de l'unité organisationnelle racine) Les données de tous les groupes de l'environnement de destination sont conservées, y compris s'ils ne sont pas inclus dans le processus de transfert.
• Google Meet : nécessite deux règles de conservation personnalisées illimitées.
  1. Les Drive partagés ne sont pas compris (règle appliquée au niveau de l'unité organisationnelle racine de transfert)
  2. Tous les Drive partagés sont compris (règle appliquée au niveau de l'unité organisationnelle racine).

     Les données de tous les Drive partagés de l'environnement de destination sont conservées, y compris s'ils ne sont pas inclus dans le processus de transfert.

• Google Sites : nécessite deux règles de conservation personnalisées illimitées.
  1. Les Drive partagés ne sont pas compris (règle appliquée au niveau de l'unité organisationnelle racine de transfert)
  2. Tous les Drive partagés sont compris (règle appliquée au niveau de l'unité organisationnelle racine).

     Les données de tous les Drive partagés de l'environnement de destination sont conservées, y compris s'ils ne sont pas inclus dans le processus de transfert.

• Drive partagés : règle de conservation personnalisée illimitée (appliquée au niveau de l'unité organisationnelle racine) Les données de tous les Drive partagés de l'environnement de destination sont conservées, y compris s'ils ne sont pas inclus dans le processus de transfert.

Important : Les règles de conservation Vault de l'environnement de destination ne sont ni retirées ni modifiées lors du transfert, car cela risquerait d'engendrer une perte de données irréversible.