Un plan de migration de projet vous permet d'évaluer l'état de préparation de l'organisation et d'éviter les interruptions de service avant de déplacer un projet entre des ressources d'organisation. Un inventaire des services actifs et des dépendances vous aide également à anticiper l'impact de la hiérarchie des ressources de destination sur vos charges de travail.
Lors d'un déplacement, l'API Cloud Resource Manager traite le projet et ses services sous-jacents comme une seule unité, sans modification de la configuration interne. Toutefois, les stratégies d'autorisation, de refus et les règles d'administration héritées ne sont pas migrées avec le projet, tandis que les stratégies et les comptes de service directement associés sont conservés. Cette modification de la hiérarchie peut entraîner un comportement inattendu ou déclencher des non-respects des règles d'administration dans l'organisation de destination.
Présentation de l'inventaire
Utilisez l'inventaire des éléments cloud pour créer un aperçu des ressources utilisées, y compris les stratégies d'autorisation. 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.
Pour obtenir la liste de toutes les stratégies d'autorisation et de refus qui affectent l'accès à un projet, consultez Afficher toutes les stratégies d'autorisation et de refus qui s'appliquent à une ressource.
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. L'application de règles directement au projet est un bon moyen de vérifier que les règles appropriées sont appliquées dès que la migration est terminée.
Les stratégies d'autorisation, de refus et les règles d'administration sont héritées via la hiérarchie des ressources et peuvent empêcher le fonctionnement d'un service si elles ne sont pas correctement définies. Déterminez la règle effective au niveau de la destination du projet dans votre hiérarchie de ressources pour vous assurer qu'elle est conforme à vos objectifs de gouvernance.
Gérer des clés chiffrées
Vous devez vérifier si une clé de chiffrement gérée par le client ou un autre service Cloud Key Management Service est activé sur votre projet. 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 en preview sur les ressources d'organisation, les dossiers ou les projets. 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 n'est pas ajoutée à la liste d'autorisation de la ressource d'organisation de destination, vous ne pourrez pas modifier la configuration une fois la migration terminée.
Identifier le nouveau compte de facturation
Les comptes de facturation Cloud peuvent être utilisés dans toutes les ressources d'organisation. Le déplacement d'un projet d'une ressource d'organisation à une autre n'a aucune incidence sur la facturation. Les frais continuent d'être imputés à l'ancien compte de facturation. Toutefois, la migration de projets entre des ressources d'organisation implique souvent de migrer vers un nouveau compte de facturation.
Dans le cadre de votre plan de migration, déterminez si vous souhaitez conserver les comptes de facturation existants. Vous pouvez également associer des projets à un nouveau compte de facturation dans la ressource d'organisation de destination.
Pour savoir comment modifier ou migrer un compte de facturation, consultez Modifier le compte de facturation.
Plan de rollback
Si vous constatez que quelque chose ne fonctionne pas sur l'un des projets que vous avez migrés, vous pouvez le restaurer à son 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 la migration d'un projet, consultez Configurer des règles d'administration.
Dossiers d'importation et d'exportation dédiés
L'héritage des règles peut avoir des effets inattendus lorsque vous migrez un projet, à la fois dans les ressources de l'organisation source et dans celles de l'organisation de destination. Vous pouvez limiter ce risque en créant des dossiers spécifiques pour ne contenir que les projets à exporter et à importer, et en vous assurant que les mêmes règles sont héritées par les dossiers des deux ressources d'organisation. Vous pouvez également définir des autorisations sur ces dossiers, qui seront héritées par les projets déplacés vers 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 vers laquelle vous prévoyez d'exporter des projets. Ensuite, définissez 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 des 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 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 de règles d'administration#39;administration, consultez Configurer des règles d'administration.
Étapes suivantes
Pour attribuer des rôles et des autorisations Identity and Access Management pour la migration de projets entre organisations, consultez Attribuer des rôles et des autorisations Identity and Access Management.