Com um plano de migração de projeto, é possível avaliar a prontidão da organização e evitar interrupções de serviço antes de mover um projeto entre recursos da organização. Um inventário de serviços e dependências ativos também ajuda a prever como a hierarquia de recursos de destino afeta suas cargas de trabalho.
Durante uma migração, a API Cloud Resource Manager trata o projeto e os serviços subjacentes como uma única unidade sem alterações de configuração interna. No entanto, as políticas herdadas de permissão, negação e da organização não são migradas com o projeto, enquanto as políticas e contas de serviço diretamente anexadas persistem. Essa mudança de hierarquia pode causar um comportamento inesperado ou acionar violações da política da organização na organização de destino.
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 são aplicadas a partir do momento em que a migração é concluída.
As políticas de permissão, negação e da organização são herdadas pela hierarquia de recursos e podem impedir o funcionamento de um serviço se não forem definidas corretamente. Determine a política em vigor no destino do projeto na hierarquia de recursos para garantir que ela esteja alinhada aos seus objetivos de governança.
Gerenciar chaves criptografadas
Verifique se o projeto tem uma chave de criptografia gerenciada pelo cliente ou outro Cloud Key Management Service 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 segregação de funções.
Recursos em fase de pré-lançamento
É possível ativar recursos em fase de pré-lançamento em recursos, pastas ou projetos da organização. Se você tiver ativado um recurso Alfa ou Beta no projeto a ser migrado, ele vai continuar funcionando após a migração. Se o recurso em fase de pré-lançamento for particular e não for adicionado à lista de permissões do recurso da organização de destino, não será possível fazer alterações na configuração após a conclusão da migração.
Identificar a nova conta de faturamento
As contas do Cloud Billing podem ser usadas em todos os recursos da organização. Mover um projeto de um recurso de organização para outro não afeta o faturamento. As cobranças continuam na conta de faturamento antiga. No entanto, a migração de projetos entre recursos de organização geralmente também inclui um requisito para migrar para uma nova conta de faturamento.
Como parte do seu plano de migração, determine se você quer manter as contas de faturamento atuais. Também é possível associar projetos a uma nova conta de faturamento no recurso da organização de destino.
Para saber como alterar ou migrar uma conta de faturamento, consulte Alterar a conta de faturamento.
Plano de reversão
Se você descobrir que algo não está funcionando em algum 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 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 armazenar apenas projetos de exportação e importação e 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 pelos projetos movidos para dentro delas, o que ajuda a acelerar o processo de migração de projetos.
Ao planejar uma migração, primeiro configure uma pasta de origem dedicada.
Para fazer isso, crie uma pasta para cada recurso de organização de destino para o 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 recurso de organização único 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 de organização de destino, uma para cada recurso de organização de onde você quer importar projetos. Para fazer isso, crie uma pasta para cada recurso da organização de origem de onde
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
para o recurso de organização único de onde 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 saber 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.