Pour une migration de projet, il est nécessaire d'évaluer l'impact de la migration 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 stratégies héritées, telles que les stratégies Identity and Access Management ou les règles d'administration, ne sont pas migrées avec le projet pendant la migration. Les règles d'administration et les comptes de service de l'organisation qui sont 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 infractions aux règles d'administration, en fonction des règles d'administration de la ressource de l'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 le niveau 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 et de tous les services susceptibles d'ê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 stratégies directement au projet est un bon moyen de vérifier que les stratégies appropriées sont appliquées à partir du moment où la migration est terminée.
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 preview
Vous pouvez activer les fonctionnalités bêta sur les ressources, les dossiers ou les projets de votre organisation. Si vous avez activé une fonctionnalité alpha ou bêta sur le projet à migrer, cette fonctionnalité doit continuer à fonctionner après la migration. Si la fonctionnalité Preview est privée et ne figure pas dans la liste d'autorisation pour la ressource de l'organisation de destination, vous ne pourrez pas modifier la configuration une fois la migration terminée.
Rollback du plan
Si vous constatez qu'un élément ne fonctionne sur aucun des 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 sur la migration d'un projet, à la fois dans les ressources de l'organisation source et de destination. Vous pouvez réduire ce risque en créant des dossiers spécifiques qui ne contiennent que les projets d'exportation et d'importation, et en veillant à ce que les mêmes stratégies soient héritées par les dossiers des deux ressources de l'organisation. Vous pouvez également définir des autorisations sur ces dossiers qui seront héritées par les projets déplacés dans ces dossiers, 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 de l'organisation de destination vers laquelle vous prévoyez d'exporter des projets. Définissez ensuite une règle d'administration sur 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 de l'organisation source à partir de laquelle vous prévoyez d'importer des projets. Définissez ensuite une règle d'administration sur ces dossiers, chacun avec la 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.
Étape suivante
Pour attribuer des rôles et des autorisations de Identity and Access Management afin de migrer des projets entre des organisations, consultez Attribuer des rôles Identity and Access Management et des accès.