Pour une migration de projet, il est nécessaire d'évaluer comment la migration aura une incidence 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 qu'Identity and Access Management ou règles d'administration ne seront pas transférées avec le projet lors de 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 l'application de règles d'administration de non-respect des règles, en fonction des règles d'administration de la ressource d'organisation de destination.
Avant de migrer votre projet entre des ressources de l'organisation, vous devez envisager de créer un plan de migration pour déterminer l'état de préparation de votre ressource "Organisation" et des projets migrer. Dans ce plan de migration, faites l'inventaire de chacune des les services exécutés par votre projet, ainsi que tout autre service concernés par la migration, ou par la hiérarchie des ressources dans la destination 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 une bonne moyen de vérifier que les stratégies appropriées sont appliquées dès que la migration est terminé.
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 version preview sur les ressources, les dossiers ou les projets de l'organisation. Si vous avez activé une fonctionnalité alpha ou bêta pour le projet à migrer, cette doit 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 pourra plus modifier sa 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 indésirables lors de la migration d'un dans les ressources d'organisation source et de destination. Vous pouvez pour limiter ce risque en créant des dossiers spécifiques afin de ne conserver que les projets à exporter et l'importation, et s'assurer que les mêmes stratégies sont héritées par les dossiers dans les 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 d'organisation de destination à laquelle vous prévoyez
exporter des projets. Ensuite, définissez une règle d'administration sur ces dossiers, chacun avec
la contrainte constraints/resourcemanager.allowedExportDestinations définie sur
vers 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. Ensuite, définissez une règle d'administration sur ces dossiers,
chacune étant associée à l'ensemble de contraintes constraints/resourcemanager.allowedImportSources
à 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 gestion de l'authentification et des accès afin de migrer des projets entre des organisations, consultez Attribuer des rôles et des autorisations de gestion de l'authentification et des accès.