Para uma migração de projeto, é necessário avaliar como a migração vai afetar os serviços em execução no 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. As 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 da política da organização, dependendo das políticas da organização do recurso 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. Neste plano de migração, faça um inventário de cada um dos serviços que seu projeto está executando e de outros serviços que possam ser afetados pela migração ou pela hierarquia de recursos no destino do projeto: de dados.
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 ao projeto é uma boa maneira de verificar se as políticas corretas foram aplicadas desde a conclusão da migração.
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
Você pode ativar os 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 vai continuar funcionando após a migração. Se o recurso de visualização for particular e não estiver na lista de permissões do recurso da organização de destino, não será possível fazer alterações de 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, restaure-os 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 indesejados durante a migração de um projeto, tanto nos recursos da organização de origem quanto de destino. É possível reduzir esse risco criando pastas específicas para armazenar apenas projetos para exportação e importação, garantindo que as mesmas políticas sejam herdadas pelas pastas em ambos os 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 para a qual você planeja
exportar projetos. 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 o qual 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 de onde você quer importar projetos. Para fazer isso, crie uma pasta para cada recurso da organização de origem de que 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 de que 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.