5. Concluir tarefas de pré-transferência

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: em alguns casos, é necessário remover as licenças incompatíveis dos usuários para transferência, enquanto os usuários não transferidos podem manter as licenças. Caso contrário, cancele ou remova todas as licenças sem suporte. A simulação valida quais licenças precisam ser canceladas.

   Você precisa cancelar o Google Voice para todos os usuários. O cancelamento das assinaturas de licença talvez tenha consequências. Em ambientes de origem com o Google Voice, é preciso prestar atenção a esta etapa. Confira mais detalhes em Licenças no ambiente de origem.

3. Atribua um novo domínio principal se quiser transferir o atual: essa etapa só é necessária se você quiser transferir seu domínio principal atual. Faça uma troca de domínio, promovendo qualquer outro domínio como o novo domínio principal .Qualquer domínio que não seja para transferência pode ser promovido como principal para essa finalidade.

   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 o hardware 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 tem problemas conhecidos. Consulte Alternativas à alteração do domínio principal.
   • Não renomeie grupos nem usuários transferidos depois de mudar 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.
4. 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 sobre a transferência no Vault em Transferir dados do Vault com o Domain Transfer.

5. Faça backup dos artefatos do Vault e remova as referências às entidades de transferência: faça o download e o backup das configurações e dos relatórios do Vault para as entidades de transferência, porque eles podem ficar inacessíveis no ambiente de origem após a transferência. Essas informações incluem casos, guardas de documentos, pesquisas e exportações.

   Depois do backup, remova as referências às entidades de transferência dos artefatos do Google Vault. O Vault retorna erros e pode não estar acessível se algum artefato do Vault contiver referências às entidades de transferência.

   • As retenções e preservações não aplicam as retenções com falha nas entidades de transferência.
   • Remova todas as referências a usuários, grupos e drives compartilhados de transferência de casos, listas compartilhadas, guarda de documentos e regras de retenção. O Vault não permite que você tenha uma guarda de documentos em um locatário que faça referência a uma entidade no outro locatário.
   • Para preservar as retenções nos dados do usuário de transferência no locatário de origem, os administradores precisam criar um novo usuário de não transferência e copiar todos os dados do Gmail e do Drive dos usuários de transferência em retenção para o novo usuário. Em seguida, arquive os novos usuários não transferidos e verifique se eles pertencem a um domínio não transferido. Em vez disso, crie retenções equivalentes do Vault no novo usuário não transferido e remova as retenções do usuário transferido original.
   • Para preservar as retenções nos dados do usuário de transferência no locatário de destino, use os backups para adicionar retenções equivalentes no locatário de destino após a transferência.
   • Não é necessário remover referências indiretas. As referências indiretas se relacionam a uma unidade organizacional que contém um usuário de transferência.
   • Não é necessário remover referências em pesquisas e exportações concluídas. Essas referências são baixadas.
6. 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 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.

7. 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 alienação da 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 de desinvestimento de transferência de domínio do Google Workspace não oferece ajuda para usar o Google Cloud durante a transferência de domínio.
8. 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.

9. 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.

10. 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.

11. Atualizar a associação a grupos: remova todos os usuários e grupos de transferência dos grupos que não são de transferência e vice-versa. Por exemplo, remova user@to-stay-insource.com e group@to-stay-insource.com de group@to-be-transfer.com.

    Observação:esta etapa é opcional, já que é possível referenciar usuários e grupos externos em outros grupos. Considere as implicações de gerenciar grupos enquanto outro locatário gerencia grupos de membros e usuários

12. Remover usuários e grupos de transferência dos públicos-alvo: os públicos-alvo não são transferidos. Portanto, o administrador de destino não tem controle sobre os públicos-alvo do ambiente de origem após a transferência.

    Observação:essa etapa é opcional, já que os públicos-alvo permitem referências a usuários e grupos externos. Os usuários mantêm o acesso aos documentos compartilhados com públicos-alvo.

13. Atualizar políticas baseadas em grupo: remova todas as políticas baseadas em grupo que fazem referência a grupos de transferência do locatário de origem.

    Importante:se o locatário de origem tiver políticas baseadas em grupo que referenciam grupos de transferência, a política baseada em grupo vai desaparecer do Admin Console e não poderá ser editada. Ele ainda está em vigor para todos os usuários que não são de transferência no grupo de transferência, mas não é possível ver nem editar. Esse é outro motivo para remover grupos entre locatários na etapa 12.

14. Defina o gerenciamento de dispositivos móveis como "Básico": desative o gerenciamento de dispositivos móveis para usuários de transferência ou defina como "Básico".

15. Diretórios personalizados: há um problema conhecido com diretórios personalizados. Os diretórios personalizados não são transferidos, e você precisa remover todos os grupos de transferência antes da transferência.

    Importante:se você não remover os grupos de transferência, o diretório não poderá ser editado nem excluído, e o comportamento dele poderá ser inconsistente.

16. Atualizar a associação à unidade organizacional: verifique se nenhuma unidade organizacional no ambiente de origem tem usuários para transferência e usuários que não serão transferidos. Os usuários para transferência e os usuários não transferidos precisam estar em unidades separadas e não podem ser misturados em uma unidade no ambiente de origem.

17. Atualize o licenciamento automático: para unidades organizacionais que contêm usuários de transferência, verifique se a configuração de licenciamento automático está desativada.

1. Crie um ambiente de destino: o Google Workspace Domain Transfer Divestiture não cria automaticamente um ambiente de destino do Google Workspace. Você precisa criar um com antecedência. Configure o faturamento e verifique um nome de domínio principal no ambiente de destino.

2. 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.

3. 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.

4. 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 organizacionais.

5. 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 os apps internos e de terceiros, o SSO para SAML, os apps do Google Workspace Marketplace e os 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)
6. 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.
7. 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.
8. 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.

9. 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.

• 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.

A transferência de domínio do Google Workspace e a desinvestimento configuram 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.