5. Concluir tarefas de pré-transferência

Etapa 1: tarefas da origem

1. Fazer upgrade de licenças (se for o caso): as licenças não são migradas como parte da transferência. Se o ambiente de origem usar uma edição do Google Workspace diferente do ambiente de destino, será necessário fazer upgrade da origem para corresponder ao destino. Para mais informações, veja as transferências de licenças em Tarefas de destino.

   Observações:

   • Para evitar custos, é possível usar licenças por um período de carência ou de teste no ambiente de origem para a aquisição de licenças temporárias. No entanto, considere os seguintes pontos:
     • Essas licenças bloqueiam o processo de troca de qualquer outro domínio pelo domínio principal. Mude o domínio principal antes de provisionar licenças temporárias.
     • Se as licenças disponíveis no ambiente de destino forem licenças completas, os usuários vão receber licenças completas como resultado da transferência.
   • Os usuários no ambiente de origem sem licenças atribuídas são transferidos mesmo assim.
2. Cancelar as assinaturas de licença incompatíveis: o cancelamento das assinaturas de licença talvez tenha consequências. Em ambientes de origem com o Google Voice, é preciso prestar ainda mais atenção a esta etapa. Confira mais detalhes em Licenças no ambiente de origem.
3. Adicionar um domínio marcador ao Google Workspace (se aplicável): adicione e verifique um novo nome de domínio secundário no ambiente de origem para substituir o domínio principal. Se já houver um domínio secundário que não precise ser transferido, você poderá usá-lo. Confira mais detalhes em Adicionar um domínio de alias de usuário ou um domínio secundário.
4. Criar um administrador marcador e torná-lo o administrador principal da conta: crie uma conta de usuário associada ao domínio marcador. Caso você decida reutilizar uma conta antiga, confirme que nenhum outro domínio transferível existente como alias esteja vinculado à conta. Atribua a esse usuário a função de superadministrador e faça dele o administrador principal da conta. Saiba mais em Enviar notificações de faturamento e da conta para outro administrador. Confira se a verificação em duas etapas do Google está configurada e faça login pelo menos uma vez para verificar o acesso com a conta de administrador temporário.
5. Trocar o domínio principal pelo domínio marcador: faça a troca dos domínios, promovendo o domínio marcador a novo domínio principal.

   Antes de trocar seu domínio:

   Quando quiser fazer a troca, acesse Alterar seu domínio principal do Google Workspace.

   • Cancele todas as assinaturas de dispositivos, incluindo os dispositivos do Google Meet e o Chrome Enterprise.
   • Algumas licenças não compatíveis talvez precisem ser removidas antes da transferência. Confira mais detalhes em Licenças no ambiente de origem.
   • Se o ambiente de origem tiver licenças de teste, a troca será bloqueada. A troca precisa ocorrer antes do provisionamento de qualquer licença temporária.
   • A alteração do domínio principal e o uso de domínios secundários têm problemas conhecidos. Consulte Alternativas à alteração do domínio principal.
   • Não renomeie grupos nem usuários transferidos depois de alterar o nome de domínio principal. Os usuários e grupos devem ser mantidos nos respectivos domínios para transferência.
   • Se você configurar o SSO usando um provedor de identidade de terceiros e estiver usando um emissor específico do domínio, a declaração SAML mudará para refletir o novo domínio principal. Verifique a configuração do seu provedor de identidade para garantir que os usuários possam fazer a autenticação após a troca do domínio principal. Confira mais detalhes em Requisitos de declaração do SSO.
6. Estabelecer regras de retenção do Google Vault: configure regras de retenção personalizadas indefinidas.

   Crie uma regra para os seguintes aplicativos:

   • Gmail: em unidade organizacional, selecione a unidade organizacional raiz.
   • Grupos do Google: em "Grupos", selecione "Todos os grupos".

   Crie duas regras para os seguintes aplicativos:

   • Chat: selecione Unidade organizacional a unidade organizacional raiz. Na segunda regra, selecione Todos os espaços do Chat.
   • Drive: selecione Unidade organizacional a unidade organizacional raiz. Na segunda regra, selecione Todos os drives compartilhados.
   • Meet: selecione Unidade organizacional a unidade organizacional raiz e ative a opção Incluir itens de drives compartilhados. Na segunda regra, selecione Todos os drives compartilhados.
   • Sites: selecione Unidade organizacional a unidade organizacional raiz e ative a opção Incluir itens de drives compartilhados. Na segunda regra, selecione Todos os drives compartilhados.

   Além disso, as regras de retenção personalizadas indefinidas são configuradas no ambiente de destino antes da transferência. Para mais detalhes, acesse Retenção do Google Vault indefinida no ambiente de destino. Saiba mais informações sobre a transferência no Vault em Transferir dados do Vault com o Domain Transfer.

7. Atualizar seu registro SPF (Sender Policy Framework) (se aplicável): se o ambiente de destino estiver usando um gateway de saída diferente do ambiente de origem, a origem precisará atualizar o registro SPF para incluir o gateway de saída.

   Observação:se você usa o DomainKeys Identified Mail (DKIM), a transferência não afeta sua política de Relatórios, conformidade e autenticação de mensagens com base no domínio (DMARC). O registro SPF vai continuar funcionando após a transferência, mesmo que o DKIM não funcione temporariamente. Além disso, conclua a tarefa de pós-transferência do DKIM no ambiente de destino.

8. Resolver conflitos entre recursos da agenda: se houver conflitos entre recursos da agenda, resolva-os antes de prosseguir.
   • IDs de edifícios: no ambiente de origem, não podem ser iguais aos IDs no ambiente de destino. Para ignorar o bloqueio de transferência, você tem duas opções. É possível excluir o edifício no ambiente de origem. Também é possível tornar os detalhes dos dois edifícios idênticos para mesclar o de origem e o de destino. Para tornar os dois idênticos, deixe o ID, o nome, todos os campos de endereço, a descrição e o andar exatamente iguais nos dois edifícios.
   • Nomes de edifícios: se um recurso de edifício no ambiente de origem tiver o mesmo nome que outro no ambiente de destino, altere o nome de um dos recursos para resolver o conflito. Depois que a transferência terminar, você vai poder mesclar os dois recursos de edifício.
   • IDs de recursos: um recurso no ambiente de origem que tem o mesmo ID que outro no destino cria um conflito que não pode ser resolvido pelo processo de transferência, e esse recurso não vai ser transferido. Exclua um deles e crie esse recurso novamente com um ID não conflitante. O prazo para que um recurso excluído seja completamente apagado do sistema é de 30 dias. Você pode aguardar até que o recurso seja completamente excluído ou a equipe do Domain Transfer pode enviar um pedido para a exclusão manual do recurso.
9. Avaliar o impacto na organização do Google Cloud associada (se aplicável): se o Google Cloud estiver sendo usado, informe os administradores desse ambiente sobre os possíveis impactos que a Transferência de domínio do Google Workspace pode ter no Google Cloud. Se necessário, contacte seu Google Cloud Partner ou seus contatos no Google Cloud para receber ajuda com a avaliação dos impactos e as ações para solução. A equipe do Google Workspace Domain Transfer não oferece ajuda para usar o Google Cloud durante a transferência de domínio.
10. Notifique seu revendedor do Google Workspace (se aplicável): informe o horário planejado para a transferência de domínio e peça para não alterar a conta (por exemplo, atualizando assinaturas) durante esse período.

11. Inscreva-se nos programas Alfa ou Beta de que os ambientes de origem e de destino participam (se aplicável): as inscrições em programas Alfa e Beta não são transferidas no ambiente de origem. Da mesma forma, o ambiente de origem pode depender de inscrições no ambiente de destino. O ambiente precisa se inscrever novamente e ser aceito nesses programas para continuar a usá-los.
    Recomendamos que você se inscreva em programas Alfa ou Beta antes de se transferir para que seus usuários tenham os mesmos recursos disponíveis durante todo o processo. No entanto, o processo de inscrição pode levar algum tempo e o sucesso não é garantido. Por isso, ela é recomendada, mas não obrigatória.

12. Para transferir dispositivos de registro sem toque do Chrome:
    1. No ambiente de origem,revogue o token de pré-provisionamento atual e desprovisione todos os dispositivos. Redefina os dispositivos para o padrão de fábrica.
    2. No ambiente de destino, crie um novo token de pré-provisionamento.
    3. Informe o novo token ao parceiro de pré-provisionamento autorizado. Seu parceiro usa o token para pré-provisionar os dispositivos no ambiente de destino.

    Os dispositivos são registrados quando se conectam à Internet. O estado do dispositivo muda para "Provisionado".

    Para mais informações sobre dispositivos sem toque, acesse Registro sem toque.

Etapa 2: tarefas do destino

1. Como as licenças não são migradas durante a transferência, você precisa provisionar licenças extras do Google Workspace para atender a todos os usuários. Quando você transfere os usuários, eles recebem o mesmo conjunto de licenças no ambiente de destino que tinham no ambiente de origem. Sendo assim, é preciso que existam licenças extras suficientes do mesmo tipo no ambiente de destino no momento da transferência.

   Se o ambiente de destino usar uma edição do Google Workspace diferente do ambiente de origem, faça upgrade das licenças no ambiente de origem ou de destino para garantir que elas sejam correspondentes.

   Observações:

   • O Google recomenda fazer upgrade das licenças para evitar o acionamento do processo de exclusão permanente do serviço (SWP).
   • Provisione as licenças ausentes para que várias assinaturas existam no ambiente de destino. Você pode fazer upgrade ou downgrade das licenças de usuários específicos após a transferência. Nem todos os tipos de licença são compatíveis com o licenciamento de domínio parcial (PDL).
   • Verifique se você tem licenças extras suficientes no ambiente de destino. Considere a necessidade de adicionar usuários (por exemplo, novas contratações) a cada ambiente de origem entre o início e o fim da transferência. Se houver várias transferências, você também precisará considerar o número total de usuários da origem em todas as transferências.
   • Os usuários no ambiente de origem sem licenças atribuídas são transferidos mesmo assim. Monitore a forma como as licenças são atribuídas automaticamente no ambiente de destino para garantir que esses usuários não recebam licenças.
   • A transferência de domínio não oferece planos de faturamento especiais do Google Workspace para permitir a compra de licenças extras durante a transferência. Se as licenças do ambiente de origem estiverem vinculadas a um plano de faturamento anual, elas vão permanecer ativas e serão faturadas até o fim do contrato do plano. Consulte seu representante de vendas ou gerente de contas se tiver mais dúvidas sobre os planos de faturamento do Google Workspace.

2. Garantir que as licenças sejam aplicadas corretamente aos usuários transferidos quando existem várias licenças: algumas configurações no ambiente de destino podem afetar a forma como são atribuídas licenças aos usuários transferidos.Isso pode fazer com que os usuários acabem com uma licença diferente da esperada. Essas configurações incluem o licenciamento automático e a substituição do licenciamento automático para organizações específicas.

   Para que não ocorram mudanças inesperadas no licenciamento durante a transferência, siga estas etapas:

   • Se a configuração de licenciamento automático do ambiente de destino for "Desativado para todos" ou o ambiente de destino só tiver um tipo de licença, nenhuma alteração será necessária.
   • Se a configuração de licenciamento automático do ambiente de destino for "Ativado para todos" (por exemplo, licenças do Google Workspace), confirme se a substituição está ativada para unidades organizacionais específicas. Na unidade organizacional raiz para transferência, verifique se a configuração de licenciamento automático está desativada, sem mais substituições para as unidades organizacionais filhas.

3. Criar a unidade organizacional raiz para transferência e, se necessário, recriar a estrutura da unidade organizacional do ambiente de origem: crie uma unidade organizacional mãe para todos os usuários para transferência. Depois de criar, você terá duas opções:

   • Nenhuma alteração: o processo de transferência de domínio recria a estrutura da unidade organizacional do ambiente de origem na nova unidade organizacional raiz transferida. Para seguir esta etapa, defina a opção de transferência "Recriar a estrutura de unidades organizacionais antecipadamente" como "Não". Todos os usuários transferidos herdam as políticas aplicadas por você no nível da unidade organizacional.
   • Recriar manualmente a estrutura de unidades organizacionais do ambiente de origem na unidade organizacional raiz transferida: a transferência de domínio garante que toda a estrutura de unidades organizacionais do ambiente de origem seja replicada corretamente antes de continuar com a transferência. Para seguir esta etapa, defina a opção "Recriar a estrutura de unidades organizacionais antecipadamente" como "Sim". Isso é útil quando você quer definir políticas distintas nas diferentes unidades organizacionais filhas.

     Observação: a transferência de domínio só valida a estrutura da unidade organizacional. É sua responsabilidade garantir que as políticas adequadas estejam definidas nas unidades.

4. Estabelecer as políticas e configurações adequadas de acordo com os requisitos dos ambientes de origem e de destino: as políticas e configurações do ambiente de origem não são transferidas para o ambiente de destino. Além disso, após o processo de transferência, só as políticas e configurações do ambiente de destino são aplicadas aos usuários transferidos e aos dados deles.

   Revise as políticas e configurações no ambiente de destino e compare-as com o ambiente de origem. Isso inclui configurações gerais e específicas da unidade organizacional raiz para transferência para garantir que elas cubram todos os usuários e entidades para transferência recebidas.

   Confira a seguir uma lista incompleta das políticas e configurações que você deve verificar durante o processo de configuração. Faça também uma auditoria completa dos dois ambientes para analisar todas as seções relevantes:

   • Ativação/desativação de serviços: verifique se os serviços que você usa no ambiente de origem estão ativados no ambiente de destino e se a unidade organizacional raiz transferida funciona como esperado. Isso é importante ao usar o Google Vault porque as regras do Vault talvez não sejam aplicadas caso o serviço esteja desativado.
   • Gmail, configurações avançadas e registros MX: revise as configurações de roteamento de e-mail, regras de compliance, ativação do IMAP e delegação. Confira mais detalhes em Ativar o Gmail com o Google Workspace.
   • Gerenciamento de senhas: consulte as políticas de senha para confirmar se elas estão alinhadas aos procedimentos da organização. Depois que os usuários para transferência são movidos para o ambiente de destino, eles herdam as políticas de gerenciamento de senha desse ambiente.
   • Verificação em duas etapas: determina se os usuários podem adicionar uma configuração de verificação em duas etapas às próprias contas, seja ela permitida ou obrigatória. Quando usuários com a verificação em duas etapas ativada são transferidos para um ambiente de destino ou uma unidade organizacional em que ela está desativada, os administradores do destino não podem gerenciar essas contas. Os administradores podem mover os usuários para uma unidade organizacional com a verificação em duas etapas ativada para fazer alterações ou remover essa verificação antes da transferência.
   • Configurações de compartilhamento: determina se os usuários podem compartilhar o próprio conteúdo fora da organização. Se o compartilhamento for bloqueado no ambiente de origem, mas não no ambiente de destino, o conteúdo transferido talvez seja acessível fora da organização. Caso o ambiente de origem tenha compartilhamento aberto por padrão e o ambiente de destino não tenha, o conteúdo transferido talvez não seja acessível para os usuários da organização. Saiba mais sobre as opções de compartilhamento do Google Drive e do Google Agenda.
   • Regras da Prevenção contra perda de dados (DLP): monitora e impede que os usuários compartilhem informações confidenciais fora da organização. Quando a DLP impede que os usuários compartilhem informações no ambiente de origem e o conteúdo é transferido para um ambiente de destino sem a configuração da DLP, os usuários do ambiente de destino podem compartilhar informações fora da organização. Saiba mais sobre as regras da DLP do Gmail e as regras da DLP do Drive.
   • Histórico de chat: determina se a gravação está ou não ativada para o histórico de chat e se os usuários podem defini-la como padrão ou definir a aplicação em todos os chats. Se o ambiente de origem permitir a ativação do histórico de chat, mas o ambiente de destino forçar a desativação, ocorrerá a perda do histórico de chat. Embora o Google Chat esteja listado como incompatível para a transferência, as mensagens diretas serão transferidas.
   • Países/regiões de dados: controla em quais localizações geográficas específicas os dados migrados serão armazenados. Essa configuração precisa ser definida corretamente no ambiente de destino para os usuários transferidos que devem permanecer em uma localização geográfica específica. Isso evita que os dados deles saiam inesperadamente desse país/região de dados. Confira mais detalhes em Regiões de dados: escolher uma localização geográfica para seus dados.
   • Apps menos seguros (também conhecidos como senhas de apps): quando os apps menos seguros estão ativados no ambiente de origem e desativados no ambiente de destino, a conexão com o app que usa apps menos seguros expira e é encerrada. O tempo limite varia de acordo com o app, mas normalmente a expiração ocorre em 60 minutos. As solicitações de acesso feitas pelo app não seguro passam a ser bloqueadas. Para mais detalhes, acesse Controlar o acesso a apps menos seguros.
   • Escopos OAuth, Logon único (SSO) para SAML, apps confiáveis e extensões do Chrome: os controles do OAuth determinam o nível de acesso à API concedido a usuários e apps de terceiros. O SSO para SAML, seja fornecido pelo Google Workspace ou implementado como um aplicativo personalizado, permite que os usuários acessem outros aplicativos ou serviços com as credenciais do Google Workspace. Os apps confiáveis são aqueles que os usuários podem instalar no Google Workspace Marketplace ou na Chrome Web Store e que ignoram as restrições do OAuth. Saiba mais sobre como controlar apps internos e de terceiros, SSO para SAML, apps do Google Workspace Marketplace e apps e extensões do Chrome.
   • Delegação em todo o domínio: permite que os apps acessem os dados do Google Workspace dos usuários. Para garantir que os clientes e escopos estejam funcionando corretamente, configure a delegação em todo o domínio no ambiente de destino antes da transferência.

   Importante: veja a seguir as possíveis consequências caso as políticas e configurações não sejam estabelecidas corretamente.

   • Exposição involuntária dos dados fora da organização (por exemplo, se o ambiente de destino tiver configurações mais abertas que o ambiente de origem)
   • Acesso restrito a dados antes acessíveis (por exemplo, se o ambiente de destino tiver configurações mais restritivas que o ambiente de origem)
5. Aceitar os contratos que regem os dados transferidos: leia com atenção a Emenda sobre tratamento de dados (DPA), a cláusula contratual modelo e a Emenda para parceiros comerciais (BAA) da HIPAA no ambiente de destino. Para mais detalhes, acesse Compliance com privacidade e registros no Google Workspace e no Cloud Identity.
6. Ativar o Vault caso ele seja usado no ambiente de origem: quando o ambiente de destino não usa o Vault, mas o ambiente de origem usa, é preciso ativar o serviço no ambiente de destino.
7. Notifique seu revendedor do Google Workspace (se aplicável): informe o horário planejado para a transferência de domínio e peça para não alterar a conta (por exemplo, atualizando assinaturas) durante esse período.

8. Inscreva-se nos programas Alfa ou Beta de que os ambientes de origem e de destino participam (se aplicável): as inscrições em programas Alfa e Beta não são transferidas no ambiente de origem. Da mesma forma, o ambiente de origem pode depender de inscrições no ambiente de destino. O ambiente precisa se inscrever novamente e ser aceito nesses programas para continuar a usá-los.
   Recomendamos que você se inscreva em programas Alfa ou Beta antes de se transferir para que seus usuários tenham os mesmos recursos disponíveis durante todo o processo. No entanto, o processo de inscrição pode levar algum tempo e o sucesso não é garantido. Por isso, ela é recomendada, mas não obrigatória.

Importante:

• O downgrade de licenças pode causar a perda de serviços e da funcionalidade do Google Workspace. Leia com atenção as diferenças entre as edições do Google Workspace e o impacto do upgrade e do downgrade antes de fazer qualquer alteração. Saiba mais sobre as edições do Google Workspace.
• O downgrade das licenças pode acionar o SWP, que atrasará a transferência em até 90 dias.

Etapa 3: outras tarefas e considerações

• Gestão da mudança: a equipe do Google Workspace Domain Transfer e o processo de transferência não enviam automaticamente aos usuários informações sobre a execução da transferência. É altamente recomendável que os representantes dos ambientes de origem e de destino informem os usuários com antecedência sobre o processo de transferência e o impacto que ele pode ter.

  Todas as ações dos administradores são bloqueadas nos ambientes de origem e de destino durante a transferência, inclusive o acesso a APIs e ao Google Admin Console. É altamente recomendável que os representantes dos ambientes de origem e de destino notifiquem todos os superadministradores e administradores delegados antes e logo depois da transferência.

• Dependências externas: se você usa o Google Cloud Directory Sync (GCDS), o GAM (uma ferramenta de linha de comando de terceiros para que os administradores do Google Workspace gerenciem as configurações do domínio e dos usuários) ou um provedor de Logon único (SSO) externo, analise o efeito da transferência. Examine também como a coexistência dos ambientes de origem e de destino em um mesmo ambiente afeta seu sistema e a data de execução da transferência.

Retenção do Google Vault indefinida no ambiente de destino

A Transferência de domínio do Google Workspace& configura regras de retenção personalizadas indefinidas no ambiente de destino. Nenhuma ação dos administradores do ambiente de destino é necessária.

O arquivo do Vault para usuários transferidos é migrado, mas as regras de retenção do ambiente de origem não. Para evitar a perda de dados do Vault durante e após a transferência, o processo cria automaticamente as seguintes regras de retenção do Vault no ambiente de destino antes de executar qualquer ação de transferência:

• Gmail: regra de retenção personalizada indefinida (escopo: unidade organizacional raiz transferida).
• Google Agenda: regra de retenção personalizada indefinida (escopo: unidade organizacional raiz para transferência).
• Google Chat: regra de retenção personalizada indefinida (escopo: mensagens diretas com usuários para transferência na unidade organizacional raiz para transferência, mas não nos espaços)
• Google Drive: regra de retenção personalizada indefinida, sem incluir drives compartilhados (escopo: unidade organizacional raiz transferida).
• Grupos do Google: regra de retenção personalizada indefinida (escopo: unidade organizacional raiz). Retém os dados de todos os grupos no ambiente de destino, até os que não foram incluídos no processo de transferência.
• Google Meet: requer duas regras de retenção personalizadas indefinidas:
  1. Sem incluir drives compartilhados (escopo: unidade organizacional raiz transferida)
  2. Para todos os drives compartilhados (escopo: unidade organizacional raiz)

     Retém os dados de todos os drives compartilhados no ambiente de destino, até os que não foram incluídos no processo de transferência.

• Google Sites: requer duas regras de retenção personalizadas indefinidas.
  1. Sem incluir drives compartilhados (escopo: unidade organizacional raiz transferida)
  2. Para todos os drives compartilhados (escopo: unidade organizacional raiz)

     Retém os dados de todos os drives compartilhados no ambiente de destino, até os que não foram incluídos no processo de transferência.

• Drives compartilhados: regra de retenção personalizada indefinida para todos os drives compartilhados (escopo: unidade organizacional raiz). Retém os dados de todos os drives compartilhados no ambiente de destino, até os que não foram incluídos no processo de transferência.

Importante: as regras de retenção do Vault no ambiente de destino não são removidas nem modificadas durante o processo de transferência, já que isso poderia causar a perda irreversível de dados.