Para uma migração de projeto, é necessário avaliar como a migração afetará os serviços em execução dentro do projeto. A API Resource Manager trata o recurso do projeto e todos os serviços em execução como uma única unidade. Isso significa que nenhuma alteração de configuração será aplicada dentro do projeto.
Embora a migração não faça alterações de configuração diretas no projeto, a alteração na hierarquia de recursos provavelmente terá um impacto na função do projeto e nos serviços em execução. Políticas herdadas, como o Identity and Access Management ou as políticas da organização, não serão migradas com o projeto durante a migração. As políticas da organização e as contas de serviço anexadas diretamente ao recurso serão migradas. Isso pode causar um comportamento não intencional depois que a migração é concluída.
A migração do projeto também pode resultar em violações na política da organização, dependendo das políticas da organização do recurso da organização de destino.
Antes de migrar seu projeto entre recursos da organização, considere criar um plano de migração para determinar a prontidão do recurso da organização e dos projetos que você quer migrar. Nesse plano de migração, faça um inventário de cada um dos serviços que o projeto está executando e de todos os outros serviços que possam ser afetados pela migração ou pela hierarquia de recursos no destino do projeto.
Visão geral do inventário
Use o Inventário de recursos do Cloud para criar uma visão geral dos recursos em uso, incluindo as políticas de gerenciamento de identidade e acesso. Use-a para ajudar a descrever seu plano de migração.
Também é possível usar o Inventário de recursos do Cloud para transferir esses dados para o BigQuery. Isso permitirá que você consulte os dados usando SQL, que é mais fácil de ler em comparação com a interpretação de dados formatados em JSON. Para informações sobre como exportar esses dados, consulte Como exportar para o BigQuery.
Verificação da política
Quando você migrar seu projeto, ele não herdará mais as políticas do local atual na hierarquia de recursos e estará sujeito à avaliação de política vigente no destino. Verifique se as políticas em vigor no destino do projeto correspondem ao máximo possível das políticas que o projeto tinha no local de origem.
Todas as políticas aplicadas diretamente ao projeto ainda serão anexadas depois que a migração for concluída. Aplicar políticas diretamente no projeto é uma boa maneira de verificar se as políticas corretas são aplicadas a partir do momento em que a migração é concluída.
As políticas de gerenciamento de identidade e acesso e as políticas da organização são herdadas pela hierarquia de recursos e podem bloquear o funcionamento de um serviço se não forem definidas corretamente. Determine a política efetiva no destino do projeto na hierarquia de recursos para garantir que a política esteja alinhada aos seus objetivos de governança.
Gerenciar chaves criptografadas
Verifique se o projeto tem uma chave criptografada gerenciada pelo cliente ou outro
serviço de gerenciamento de chaves do Cloud ativado. As chaves criptográficas são de propriedade do projeto, e um
usuário com acesso owner a esse projeto, portanto, poderá gerenciar e
executar operações criptográficas em chaves no Cloud KMS nesse
projeto.
Para mais informações, consulte Separação de deveres.
Prévia dos recursos
É possível ativar recursos de pré-lançamento em recursos, pastas ou projetos da organização. Se você ativou um recurso Alfa ou Beta no projeto a ser migrado, ele deve continuar funcionando após a migração. Se o recurso em fase de pré-lançamento for particular e não permitido para o recurso da organização de destino, não será possível mudar a configuração após a conclusão da migração.
Plano de reversão
Se você descobrir que algo não está funcionando em nenhum dos projetos migrados, poderá restaurá-los para o local original. Para fazer isso, é preciso ter as permissões de IAM necessárias e definir as políticas da organização necessárias para executar a migração do projeto de maneira inversa.
Para uma lista de permissões necessárias, consulte Atribuir permissões. Para as políticas da organização que você precisa configurar para permitir uma migração de projeto, consulte Configurar políticas da organização.
Pastas de importação e exportação dedicadas
A herança de políticas pode causar efeitos não intencionais ao migrar um projeto, tanto nos recursos da organização de origem quanto nos de destino. É possível mitigar esse risco criando pastas específicas para manter apenas projetos para exportação e importação e garantindo que as mesmas políticas sejam herdadas pelas pastas nos dois recursos da organização. Também é possível definir permissões nessas pastas que serão herdadas para os projetos movidos dentro delas, ajudando a acelerar o processo de migração do projeto.
Ao planejar uma migração, primeiro configure uma pasta de origem dedicada.
Para fazer isso, crie uma pasta para cada recurso da organização de destino que vai receber
projetos de exportação. Em seguida, defina uma política da organização nessas pastas, cada uma com
a restrição constraints/resourcemanager.allowedExportDestinations definida como
o único recurso da organização para onde você quer exportar projetos.
Por exemplo, é possível configurar pastas Export to Marketing Org e Export to Sales Org, cada uma com as restrições de política da organização definidas.
Da mesma forma, configure pastas de importação dedicadas no recurso da organização de destino, uma para cada recurso da organização do qual você quer importar projetos. Para fazer isso, crie uma pasta para cada recurso da organização de origem do qual
você planeja importar projetos. Em seguida, defina uma política da organização nessas pastas,
cada uma com a restrição constraints/resourcemanager.allowedImportSources definida
como o único recurso da organização do qual você quer importar projetos.
Por exemplo, é possível configurar pastas Import from Marketing Org e Import from App Development Org, cada uma com as restrições de política da organização adequadas.
Em cada uma das pastas de importação e exportação, atribua o papel roles/resourcemanager.projectMover à pessoa que moverá os projetos. Esse papel será herdado por todos os projetos contidos nessas pastas, permitindo que o usuário execute as operações de movimentação em qualquer projeto que seja movido para essas pastas.
Depois de concluir a migração do projeto, remova essas pastas dedicadas.
Para mais informações sobre como definir políticas da organização, consulte Configurar políticas da organização.
A seguir
Para atribuir papéis e permissões do Identity and Access Management para migrar projetos entre organizações, consulte Atribuir papéis e permissões do Identity and Access Management.