Dans le cas d'une migration de projet, il est nécessaire d'évaluer son impact sur les services exécutés dans le projet. L'API Resource Manager traite la ressource de projet et tous les services exécutés en dessous comme une seule unité, ce qui signifie qu'aucune modification de configuration n'est appliquée dans le projet.
Même si la migration n'apporte pas de modifications directes à la configuration du projet, la modification de la hiérarchie des ressources est susceptible d'affecter la fonction du projet et ses services en cours d'exécution. Les règles héritées, telles que Identity and Access Management ou les règles d'administration, ne seront pas migrées avec le projet lors de la migration. Les règles d'administration et les comptes de service directement associés à la ressource seront migrés. Cela peut entraîner un comportement inattendu une fois la migration terminée.
La migration de votre projet peut également entraîner des cas de non-respect des règles d'administration, en fonction des règles d'administration d'administration de la ressource d'organisation de destination.
Avant de migrer votre projet entre des ressources d'organisation, vous devez envisager de créer un plan de migration pour déterminer l'état de préparation de votre ressource d'organisation et des projets que vous souhaitez migrer. Dans ce plan de migration, faites l'inventaire de chacun des services exécutés par votre projet, ainsi que de tous les autres services pouvant être affectés par la migration ou par la hiérarchie des ressources dans la destination de votre projet.
Présentation de l'inventaire
Utilisez l'inventaire des éléments cloud pour créer une vue d'ensemble des ressources utilisées, y compris des stratégies Identity and Access Management. Vous pouvez utiliser cette présentation pour vous aider à élaborer votre plan de migration.
Vous pouvez également utiliser l'inventaire des éléments cloud pour transférer ces données dans BigQuery. Vous pourrez ainsi interroger les données à l'aide de SQL, ce qui est plus facile à lire que l'interprétation des données au format JSON. Pour en savoir plus sur l'exportation de ces données, consultez la page Exporter vers BigQuery.
Validation des stratégies
Lorsque vous migrez votre projet, il n'hérite plus des stratégies de son emplacement actuel dans la hiérarchie des ressources et est soumis à l'évaluation effective des stratégies à sa destination. Nous vous recommandons de vous assurer que les stratégies en vigueur à la destination du projet correspondent autant que possible aux règles du projet dans son emplacement source.
Toutes les règles appliquées directement au projet seront toujours associées une fois la migration terminée. Appliquer des règles directement au projet est un bon moyen de vérifier que les règles appropriées sont appliquées dès la fin de la migration.
Les stratégies Identity and Access Management et les règles d'administration sont héritées via la hiérarchie des ressources et peuvent empêcher un service de fonctionner si elles ne sont pas correctement définies. Déterminez la stratégie en vigueur à la destination du projet dans votre hiérarchie de ressources pour vous assurer qu'elle est adaptée à vos objectifs de gouvernance.
Gérer des clés chiffrées
Vous devez vérifier si votre projet dispose d'une clé chiffrée gérée par le client ou d'un autre service Cloud Key Management Service activé. Les clés cryptographiques appartiennent au projet, et un utilisateur disposant de l'accès owner à ce projet pourra donc gérer et effectuer des opérations de chiffrement sur les clés Cloud KMS de ce projet.
Consultez la page Séparation des tâches pour en savoir plus.
Fonctionnalités en mode bêta
Vous pouvez activer les fonctionnalités en preview sur les ressources, les dossiers ou les projets de l'organisation. Si vous avez activé une fonctionnalité alpha ou bêta sur le projet à migrer, elle devrait continuer à fonctionner après la migration. Si la fonctionnalité en preview est privée et ne figure pas sur la liste d'autorisation pour la ressource d'organisation de destination, vous ne pourrez pas modifier la configuration une fois la migration terminée.
Rollback du plan
Si vous découvrez qu'un élément ne fonctionne pas sur les projets que vous avez migrés, vous pouvez les restaurer à leur emplacement d'origine. Pour ce faire, vous devez disposer des autorisations IAM nécessaires et définir les règles d'administration requises pour pouvoir exécuter la migration de projet en sens inverse.
Pour obtenir la liste des autorisations requises, consultez la section Attribuer des autorisations. Pour connaître les règles d'administration que vous devez configurer pour autoriser une migration de projet, consultez la page Configurer des règles d'administration.
Dossiers d'importation et d'exportation dédiés
L'héritage des stratégies peut avoir des effets inattendus lors de la migration d'un projet, à la fois dans les ressources de l'organisation source et de destination. Pour atténuer ce risque, créez des dossiers spécifiques pour ne conserver que les projets à exporter et à importer, et assurez-vous que les dossiers des deux ressources de l'organisation héritent des mêmes stratégies. Vous pouvez également définir des autorisations sur ces dossiers qui seront héritées pour les projets qu'ils contiennent, ce qui permet d'accélérer le processus de migration des projets.
Lorsque vous planifiez une migration, envisagez d'abord de configurer un dossier source dédié.
Pour ce faire, créez un dossier pour chaque ressource d'organisation de destination vers laquelle vous prévoyez d'exporter des projets. Ensuite, définissez une règle d'administration pour ces dossiers, chacun avec la contrainte constraints/resourcemanager.allowedExportDestinations définie sur la ressource d'organisation unique vers laquelle vous souhaitez exporter les projets.
Par exemple, vous pouvez configurer des dossiers Export to Marketing Org et Export to Sales Org, chacun avec des contraintes de règle d'administration appropriées.
De même, configurez des dossiers d'importation dédiés dans la ressource d'organisation de destination, un pour chaque ressource d'organisation à partir de laquelle vous souhaitez importer des projets. Pour ce faire, créez un dossier pour chaque ressource d'organisation source à partir de laquelle vous prévoyez d'importer des projets. Ensuite, définissez une règle d'administration pour ces dossiers, chacun avec une contrainte constraints/resourcemanager.allowedImportSources définie sur la ressource d'organisation unique à partir de laquelle vous souhaitez importer des projets.
Par exemple, vous pouvez configurer les dossiers Import from Marketing Org et Import from App Development Org, chacun avec des contraintes de règles d'administration appropriées.
Dans chacun des dossiers d'importation et d'exportation, attribuez le rôle roles/resourcemanager.projectMover à la personne qui déplacera les projets. Ce rôle sera hérité par tous les projets contenus dans ces dossiers, ce qui permet à l'utilisateur d'effectuer les opérations de déplacement sur n'importe quel projet déplacé dans ces dossiers.
Une fois la migration de votre projet terminée, vous devez supprimer ces dossiers dédiés.
Pour en savoir plus sur la définition des règles d'administration, consultez la section Configurer des règles d'administration.
Étapes suivantes
Pour savoir comment attribuer des rôles et des autorisations IAM (Identity and Access Management) pour la migration de projets d'une organisation à une autre, consultez Attribuer des rôles et des autorisations Identity and Access Management.