Migrar un Google Cloud proyecto es una operación de metadatos que cambia la ubicación del proyecto en la jerarquía de recursos. En esta página, se proporciona una descripción general de cómo funcionan las migraciones, qué se mantiene igual y qué cambia cuando un proyecto se mueve a una organización nueva.
Proyectos en la jerarquía de recursos
El recurso del proyecto es la entidad organizativa básica en un Google Cloud recurso de organización. Los proyectos se crean en recursos de organización y se pueden colocar en carpetas o en el recurso de organización en sí, lo que forma la jerarquía de recursos.
Es posible que debas migrar proyectos entre recursos de organización debido a adquisiciones, requisitos reglamentarios o la separación de unidades de negocios. Puedes usar la API de Resource Manager para migrar estos proyectos. La operación de migración muestra una cadena que representa el nombre de la operación. La API también te permite revertir una migración y volver a colocar el proyecto en su lugar original en la jerarquía si es necesario.
Situaciones de migración
La ubicación de tu proyecto determina cuál de las dos rutas debes tomar:
- Migra proyectos de una organización a otro recurso de organización.
- Migra un proyecto independiente (creado sin una organización) a la jerarquía de un recurso de organización.
Si necesitas volver a mover un proyecto a Sin organización después de que se asocia con un recurso de organización, debes comunicarte con Atención al Cliente de Cloud. No se admite la reversión de autoservicio de una organización a ninguna organización.
Además de la API, también puedes usar la Google Cloud consola para mover proyectos. Para ello, selecciona el proyecto y asígnale un nuevo destino superior.
Identifica el estado actual del proyecto
Antes de comenzar, debes determinar si tu proyecto está asociado con un recurso de organización. Esto determina si sigues la ruta De organización a organización o la ruta Sin organización.
Si no tienes el resourcemanager.organizations.get permiso en el
recurso de organización superior del proyecto, es probable que tus proyectos
no se reflejen como se espera en la organización real en la
Google Cloud consola. Esto puede hacer que parezca que el proyecto no está asociado con ningún recurso de organización.
Para determinar si el proyecto está asociado con un recurso de organización, ejecuta el siguiente comando:
gcloud
gcloud projects get-ancestors PROJECT_ID
Reemplaza PROJECT_ID por el ID del proyecto que deseas migrar.
Si el resultado incluye un tipo de recurso organization en la jerarquía, tu proyecto ya forma parte de una jerarquía de organización.
Si falta el tipo organization o está vacío, el proyecto es independiente y no tiene un recurso de organización.
Según el estado de tu proyecto, sigue la guía pertinente:
- Si deseas migrar proyectos que se crearon sin una organización asociada, consulta Migra proyectos que no están asociados con un recurso de organización.
- Si deseas migrar proyectos de una organización a otro recurso de organización, consulta Migra proyectos entre recursos de organización.
Cómo funciona la migración
La migración de un proyecto no es una transferencia de datos. Tus servicios, bases de datos y instancias de máquinas virtuales (VM) permanecen activos y no experimentan tiempo de inactividad. En cambio, la migración actualiza el recurso superior del proyecto. Debido a que Google Cloud sigue un modelo de herencia jerárquica, la postura de seguridad del proyecto cambia en el momento en que se adjunta a un nuevo elemento superior.
| Función | Estado | Impacto |
|---|---|---|
| ID y número del proyecto | Se mantiene igual | Las claves de API, los nombres de servicio y los IDs codificados no cambian. |
| Datos y recursos | Se mantiene igual | Las VMs, los buckets de Cloud Storage y las bases de datos permanecen en línea. |
| Roles de IAM directos | Se mantiene igual | Los roles otorgados directamente en el proyecto se mueven con él. |
| Roles de IAM heredados | Cambios | Se pierden los roles otorgados en la organización de origen o a nivel de la carpeta. |
| Políticas de la organización | Cambios | Las restricciones de origen se reemplazan por las restricciones de destino. |
| Cuotas | Cambios | Se pierden las cuotas heredadas a nivel de la organización; las cuotas a nivel de proyecto permanecen. |
| Cuenta de facturación | Se mantiene igual | El proyecto permanece vinculado a la cuenta de facturación original. |
Impacto en las cuotas
Si tienes cuotas definidas en un nivel de recurso determinado, se aplican los siguientes aspectos después de la migración:
- Las cuotas definidas a nivel de proyecto no cambian.
- Las cuotas definidas a nivel del recurso de organización no se transfieren. La organización pierde las cuotas heredadas o las anulaciones de cuotas.
Se pueden usar las siguientes páginas para determinar qué cuotas se aplican a un recurso de organización:
- Ver y administrar cuotas
- Enumera cuotas con gcloud
- Enumera cuotas con RPC
- Ejemplo de bucket de cuota
Ejemplo
$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"
...
- defaultLimit: '600'
dimensions:
region: us-central1
effectiveLimit: '650'
...
Consideraciones más importantes
Antes de comenzar una migración, revisa estas áreas de alto riesgo para evitar interrupciones en el servicio:
Límites de cuota: Si la organización de destino tiene límites de cuota más bajos que la fuente, es posible que tu proyecto supere su cuota cuando llegue.
Inventario de recursos: Las actualizaciones de la lista completa de recursos en Cloud Asset Inventory pueden tardar unos días en propagarse por completo después de la migración.
Costo y descuentos: Si la organización original tenía descuentos basados en SKU o en el Programa de Descuentos para Empresas (EDP), esos descuentos no se aplican en la organización nueva hasta que los negocies con tu representante de ventas de Google. Es posible que también debas volver a comprar los descuentos por compromiso de uso (CUD) y las compras de Google Cloud Marketplace.
Niveles de asistencia: Si no hay un contrato de asistencia activo o un nivel de asistencia inferior en la organización de destino, es posible que pierdas tu nivel de asistencia actual.
Roles personalizados: Si tu proyecto depende de roles de IAM personalizados definidos a nivel de la organización, esos roles no existirán en el destino. Vuelve a crearlos en la organización de destino antes de moverlos.
La hoja de ruta de la migración
Usa la siguiente hoja de ruta para navegar por el proceso de migración del proyecto:
- Preparación: Crea un plan de migración para coordinar los tiempos.
- Realización: Asigna roles de IAM, configura políticas de la organización y ejecuta la migración.
- Verificación: Completa las tareas posteriores a la migración, como auditar las políticas heredadas y actualizar la facturación.