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

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 : dans certains cas, vous devez supprimer les licences non compatibles des utilisateurs transférés, tandis que les utilisateurs non transférés peuvent conserver leurs licences. Sinon, vous devez résilier ou supprimer complètement toutes les licences non prises en charge. Le dry run permet de valider les licences que vous devez résilier.

   Vous devez résilier Google Voice pour tous les utilisateurs. La résiliation des abonnements associés aux licences 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. Attribuez un nouveau domaine principal si vous souhaitez transférer le domaine principal actuel. Cette étape n'est requise que si vous souhaitez transférer votre domaine principal actuel. Changez de domaine, afin que le domaine de substitution devienne le nouveau domaine principal .Pour ce faire, vous pouvez choisir n'importe quel domaine non transférable.

   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 ni les groupes transférés 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.
4. 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.

5. Sauvegarder les artefacts Vault et supprimer les références aux entités de transfert : téléchargez et sauvegardez les configurations et les rapports Vault pour les entités de transfert, car il se peut qu'ils ne soient pas accessibles dans l'environnement source après le transfert. Ces informations incluent les litiges, les obligations de conservation, les recherches et les exportations.

   Après la sauvegarde, supprimez les références aux entités de transfert des artefacts Google Vault. Vault renvoie des erreurs et peut ne pas être accessible si des artefacts Vault contiennent des références aux entités de transfert.

   • La conservation et les préservations n'appliquent pas les obligations en échec sur les entités de transfert.
   • Supprimez toutes les références aux utilisateurs, aux groupes et aux Drive partagés de transfert dans les affaires, les listes partagées, les obligations de conservation et les règles de conservation. Vault ne vous permet pas d'appliquer une préservation à titre conservatoire dans un locataire qui fait référence à une entité dans un autre locataire.
   • Pour conserver les obligations de conservation des données utilisateur à transférer dans le locataire source, les administrateurs doivent créer un utilisateur non transférable et copier toutes les données Gmail et Drive des utilisateurs à transférer soumis à une obligation de conservation vers le nouvel utilisateur. Archivez ensuite les nouveaux utilisateurs non transférés et assurez-vous qu'ils appartiennent à un domaine non transféré. Créez plutôt des obligations de conservation Vault équivalentes pour le nouvel utilisateur non transféré et supprimez celles de l'utilisateur transféré d'origine.
   • Pour conserver les mesures de protection sur les données utilisateur transférées dans le locataire de destination, utilisez les sauvegardes pour ajouter des mesures de protection équivalentes dans le locataire de destination après le transfert.
   • Vous n'avez pas besoin de supprimer les références indirectes. Les références indirectes concernent une unité organisationnelle contenant un utilisateur de transfert.
   • Vous n'avez pas besoin de supprimer les références dans les recherches et les exportations terminées. Ces références sont téléchargées.
6. 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.

7. É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 Divestiture ne propose pas d'assistance pour Google Cloud lors des transferts de domaine.
8. 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.

9. 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 de l'opération n'est pas garanti. La démarche est donc recommandée, sans être obligatoire.

10. 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.

11. Mettre à jour l'appartenance aux groupes : supprimez tous les utilisateurs et groupes de transfert des groupes non transférés, et tous les utilisateurs et groupes non transférés des groupes de transfert. Par exemple, supprimez user@to-stay-insource.com et group@to-stay-insource.com de group@to-be-transfer.com.

    Remarque : Cette étape est facultative, car vous pouvez faire référence à des utilisateurs et groupes externes dans d'autres groupes. Tenez compte des implications de la gestion des groupes lorsqu'un autre locataire gère les groupes de membres et les utilisateurs.

12. Supprimer les utilisateurs et les groupes de transfert des audiences cibles : les audiences cibles ne sont pas transférées. L'administrateur de destination n'a donc aucun contrôle sur les audiences cibles de l'environnement source après le transfert.

    Remarque : Cette étape est facultative, car les audiences cibles autorisent les références aux utilisateurs et groupes externes. Les utilisateurs conservent l'accès aux documents qui ont été partagés avec des audiences cibles.

13. Mettez à jour les règles basées sur des groupes : vous devez supprimer du locataire source toutes les règles basées sur des groupes qui font référence à des groupes de transfert.

    Important : Si le locataire source contient des règles basées sur des groupes qui font référence à des groupes de transfert, la règle basée sur des groupes disparaît de la console d'administration et ne peut plus être modifiée. Elle reste en vigueur pour tous les utilisateurs non concernés par le transfert dans le groupe de transfert, mais vous ne pouvez pas la voir ni la modifier. C'est une autre raison de supprimer les groupes multilocaux à l'étape 12.

14. Définissez la gestion des appareils mobiles sur "De base" : désactivez la gestion des appareils mobiles pour les utilisateurs à transférer ou définissez-la sur "De base".

15. Annuaires personnalisés : un problème connu existe avec les annuaires personnalisés. Les répertoires personnalisés ne sont pas transférés. Vous devez supprimer tous les groupes de transfert avant le transfert.

    Important : Si vous ne supprimez pas les groupes de transfert, le répertoire ne pourra plus être modifié ni supprimé, et son comportement risque d'être incohérent.

16. Mettez à jour l'appartenance aux unités organisationnelles : assurez-vous qu'aucune unité organisationnelle de l'environnement source ne comporte à la fois des utilisateurs de transfert et des utilisateurs non transférés. Les utilisateurs transférés et non transférés doivent se trouver dans des unités distinctes et ne peuvent pas être mélangés dans une unité de l'environnement source.

17. Mettre à jour l'attribution automatique des licences : pour les unités organisationnelles contenant des utilisateurs à transférer, assurez-vous que la configuration de l'attribution automatique des licences est désactivée.

1. Créez un environnement de destination : Google Workspace Domain Transfer Divestiture ne crée pas automatiquement d'environnement de destination Google Workspace. Vous devez en créer un à l'avance. Assurez-vous de configurer la facturation et de valider un nom de domaine principal dans l'environnement de destination.

2. 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.

3. 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.

4. 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.

5. É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, car 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ôle 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.
   • Emplacements des données (pays/régions) : 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).
6. 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.
7. 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.
8. 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.

9. 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 de l'opération 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.

• 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é.

Google Workspace Domain Transfer Divestiture 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.