Un plan de migración de proyectos te permite evaluar la preparación de la organización y evitar interrupciones del servicio antes de mover un proyecto entre recursos de organización. Un inventario de servicios y dependencias activos también te ayuda a anticipar cómo la jerarquía de recursos de destino afecta tus cargas de trabajo.
Durante un traslado, la API de Cloud Resource Manager trata el proyecto y sus servicios subyacentes como una sola unidad sin cambios de configuración interna. Sin embargo, las políticas de permisos, de denegación y de la organización heredadas no se migran con el proyecto, mientras que las políticas y las cuentas de servicio conectadas directamente persisten. Este cambio de jerarquía puede causar un comportamiento inesperado o activar incumplimientos de política de la organización en la organización de destino.
Descripción general de Inventory
Usa Cloud Asset Inventory para crear una descripción general de los recursos en uso, incluidas las políticas de permisos. Puedes usar esta descripción general para ayudarte a esbozar tu plan de migración.
También puedes usar Cloud Asset Inventory para transferir estos datos a BigQuery. Esto te permitirá consultar los datos con SQL, que es más fácil de leer en comparación con la interpretación de datos con formato JSON. Para obtener información sobre cómo exportar estos datos, consulta Exporta a BigQuery.
Para obtener una lista de todas las políticas de permiso y denegación que afectan el acceso a un proyecto, consulta Visualiza todas las políticas de permiso y denegación que se aplican a un recurso.
Verificación de políticas
Cuando migres tu proyecto, ya no heredará las políticas de su lugar actual en la jerarquía de recursos y estará sujeto a la evaluación de la política vigente en su destino. Te recomendamos que te asegures de que las políticas vigentes en el destino del proyecto coincidan lo más posible con las políticas que tenía el proyecto en su ubicación de origen.
Cualquier política que se aplique directamente al proyecto seguirá adjunta después de que se complete la migración. Aplicar políticas directamente al proyecto es una buena manera de verificar que se apliquen las políticas correctas desde el momento en que se completa la migración.
Las políticas de permiso, denegación y de la organización se heredan a través de la jerarquía de recursos y pueden impedir que un servicio funcione si no se configuran correctamente. Determina la política vigente en el destino del proyecto en tu jerarquía de recursos para asegurarte de que la política se alinee con tus objetivos de administración.
Administra claves encriptadas
Debes verificar si tu proyecto tiene una clave de encriptación administrada por el cliente o algún otro
Cloud Key Management Service habilitado. Las claves criptográficas son propiedad del proyecto y, por lo tanto, un
usuario con acceso de owner a ese proyecto podrá administrar y
realizar operaciones criptográficas en las claves de Cloud KMS de ese
proyecto.
Consulta Separación de obligaciones para obtener más información.
Funciones de versión preliminar
Puedes habilitar las funciones de versión preliminar en los recursos, las carpetas o los proyectos de la organización. Si habilitaste una función alfa o beta en el proyecto que se migrará, esta función debería seguir funcionando después de la migración. Si la función de versión preliminar es privada y no se agrega a la lista de entidades permitidas para el recurso de la organización de destino, no podrás realizar ningún cambio de configuración después de que se complete la migración.
Identifica la nueva cuenta de facturación
Las cuentas de Facturación de Cloud se pueden usar en todos los recursos de la organización. Mover un proyecto de un recurso de organización a otro no afecta la facturación. Los cargos se siguen aplicando a la cuenta de facturación anterior. Sin embargo, la migración de proyectos entre recursos de organización suele incluir también el requisito de migrar a una cuenta de facturación nueva.
Como parte de tu plan de migración, determina si deseas conservar las cuentas de facturación existentes. También puedes asociar proyectos con una cuenta de facturación nueva en el recurso de organización de destino.
Para obtener información sobre cómo cambiar o migrar una cuenta de facturación, consulta Cambia la cuenta de facturación.
Plan de reversión
Si descubres que algo no funciona en alguno de los proyectos que migraste, puedes restablecerlos a su ubicación original. Para ello, debes tener los permisos de IAM necesarios y establecer las políticas de la organización requeridas para poder ejecutar la migración del proyecto en orden inverso.
Para obtener una lista de los permisos necesarios, consulta Asigna permisos. Para conocer las políticas de la organización que debes configurar para permitir la migración de un proyecto, consulta Configura las políticas de la organización.
Carpetas dedicadas para importación y exportación
La herencia de políticas puede causar efectos no deseados cuando migras un proyecto, tanto en los recursos de la organización de origen como en los de destino. Puedes mitigar este riesgo creando carpetas específicas que solo contengan proyectos para exportar e importar, y asegurándote de que las mismas políticas se hereden en las carpetas de ambos recursos de organización. También puedes establecer permisos en estas carpetas que se heredarán a los proyectos que se muevan dentro de ellas, lo que ayuda a acelerar el proceso de migración de proyectos.
Cuando planifiques una migración, considera configurar primero una carpeta de origen dedicada.
Para ello, crea una carpeta para cada recurso de organización de destino al que planeas
exportar proyectos. Luego, establece una política de la organización en estas carpetas, cada una con
la restricción constraints/resourcemanager.allowedExportDestinations establecida en
el recurso de organización único al que deseas exportar proyectos.
Por ejemplo, puedes configurar las carpetas Export to Marketing Org y
Export to Sales Org, cada una con las restricciones de la política de la organización
adecuadas.
Del mismo modo, configura carpetas de importación dedicadas en el recurso de organización de destino, una para cada recurso de organización desde el que quieras importar proyectos. Para ello, crea una carpeta para cada recurso de organización de origen desde el que
planeas importar proyectos. Luego, establece una política de la organización en estas carpetas,
cada una con la restricción constraints/resourcemanager.allowedImportSources establecida
en el único recurso de organización desde el que deseas importar proyectos.
Por ejemplo, puedes configurar las carpetas Import from Marketing Org y
Import from App Development Org, cada una con las restricciones de la política de la organización
adecuadas.
En cada una de las carpetas de importación y exportación, asigna el rol roles/resourcemanager.projectMover a la persona que moverá
los proyectos. Este rol lo heredarán
todos los proyectos que se encuentren dentro de estas carpetas, lo que le dará al
usuario la capacidad de realizar las operaciones de traslado en cualquier proyecto que se mueva
a esas carpetas.
Después de completar la migración del proyecto, debes quitar estas carpetas dedicadas.
Para obtener información sobre cómo configurar las políticas de la organización, consulta Configura las políticas de la organización.
¿Qué sigue?
Para asignar roles y permisos de Identity and Access Management para migrar proyectos entre organizaciones, consulta Asigna roles y permisos de Identity and Access Management.