Migração tenant-to-tenant no Microsoft 365: guia para fusões e troca de domínio

Quando a migração tenant-to-tenant se torna necessária

O Microsoft 365 organiza cada empresa em um tenant, um ambiente isolado que reúne usuários, caixas de e-mail, arquivos do OneDrive, sites do SharePoint, equipes do Teams, políticas de segurança e domínios verificados. Enquanto a empresa mantém a mesma estrutura societária, esse isolamento é uma vantagem. Quando duas organizações se juntam, ou uma se divide, ele vira um obstáculo: os dados precisam sair de um tenant e entrar em outro, sem que o dia a dia dos colaboradores pare.

A migração tenant-to-tenant aparece em vários cenários corporativos. Os mais comuns são:

• Fusões e aquisições: a empresa compradora quer consolidar a adquirida em um único ambiente, com uma só política de segurança e um só catálogo de licenças.
• Cisões e venda de unidades de negócio: uma filial ou divisão passa a operar de forma independente e precisa levar seus dados para um tenant próprio.
• Reestruturação de marca: o grupo adota um novo nome e um novo domínio de e-mail e aproveita para corrigir um tenant criado sem planejamento anos atrás.
• Consolidação de ambientes: grupos econômicos com vários CNPJs, cada um com seu tenant, decidem unificar a gestão para reduzir custos e simplificar a administração.

Em todos esses casos, o desafio técnico é parecido: transferir caixas postais, arquivos, conversas e permissões preservando o histórico, mantendo o fluxo de e-mails e evitando que os usuários percam produtividade durante a transição. A diferença entre um projeto tranquilo e um fim de semana de crise está quase sempre no planejamento.

O que precisa ser planejado antes de mover qualquer dado

O erro mais comum em migrações entre tenants é tratar o projeto como uma simples cópia de dados. Na prática, ele envolve identidade, licenciamento, dispositivos, DNS, segurança e comunicação com os usuários. Antes de qualquer transferência, é preciso ter um inventário completo do ambiente de origem: quantos usuários, quantas caixas compartilhadas, qual o volume de dados em cada caixa e em cada OneDrive, quais grupos e listas de distribuição existem, quais equipes do Teams estão ativas e quais sites do SharePoint ainda são usados.

O inventário também deve cobrir o que não aparece à primeira vista: regras de fluxo de e-mail, conectores com sistemas de terceiros (ERP, CRM, impressoras multifuncionais que enviam digitalização por e-mail), aplicativos registrados no Entra ID, políticas de acesso condicional e retenções legais ativas. Esses itens não migram sozinhos e, se forem esquecidos, quebram processos de negócio logo após o corte.

Um bom plano de migração costuma seguir esta sequência:

1. Levantamento e mapeamento: correspondência entre cada usuário, grupo e recurso da origem e seu equivalente no destino.
2. Preparação do tenant de destino: licenças adquiridas, políticas de segurança configuradas, identidades criadas e, se houver ambiente híbrido, sincronização com o Active Directory local ajustada.
3. Piloto: migração de um grupo pequeno de usuários, de preferência da equipe de TI e de áreas com perfil variado, para validar o processo e medir o tempo real de transferência.
4. Migração em lotes: pré-sincronização dos dados com antecedência, deixando para o corte apenas a diferença.
5. Corte e pós-migração: troca de domínio, reconfiguração de dispositivos, suporte intensivo aos usuários e desativação controlada do ambiente antigo.

Em fusões e aquisições, a migração também envolve dados pessoais de colaboradores e clientes. O projeto deve considerar a LGPD: quem é o controlador dos dados após a operação, qual base legal sustenta a transferência e por quanto tempo o tenant de origem será mantido.

Migrando caixas de e-mail, OneDrive e Teams: ferramentas e limites

A Microsoft oferece recursos nativos de migração entre tenants. Para o Exchange Online, a migração de caixas cross-tenant move a caixa inteira (e-mails, calendário, contatos e arquivo morto) sem precisar recriar o perfil do zero, desde que os dois tenants estejam configurados com a relação de organização, o endpoint de migração e os objetos de usuário preparados no destino. Para o OneDrive, existe a movimentação cross-tenant de conteúdo do usuário, executada via PowerShell do SharePoint Online após estabelecer confiança entre os ambientes. Os dois recursos exigem a licença complementar Cross-Tenant User Data Migration, adquirida por usuário migrado.

O Microsoft Teams é o ponto em que os recursos nativos ficam mais limitados. Os arquivos das equipes ficam no SharePoint e podem ser transferidos, mas o histórico de conversas de canais e, principalmente, os chats privados não têm um caminho nativo completo. Nesses casos, entram ferramentas de terceiros especializadas em migração, que recriam equipes, canais, membros e mensagens no destino. A escolha da ferramenta depende do volume, do orçamento e do quanto o histórico de conversas importa para a operação.

Alguns itens merecem atenção especial em qualquer abordagem:

• Permissões de compartilhamento: links compartilhados com pessoas de fora deixam de funcionar e precisam ser reemitidos.
• Reuniões recorrentes: links de reuniões do Teams criados no tenant antigo não funcionam no novo e precisam ser recriados pelo organizador.
• Caixas compartilhadas e de recursos: salas de reunião, equipamentos e caixas de departamento precisam ser migradas e ter as permissões reaplicadas.
• Respostas a e-mails antigos: para que as respostas a mensagens trocadas antes da migração cheguem à caixa certa, o endereço X500 legado deve ser preservado no destino.

Troca de domínio: o ponto mais delicado do projeto

Um mesmo domínio só pode estar verificado em um tenant por vez. Isso significa que, para levar o domínio empresa.com.br do tenant de origem para o de destino, ele precisa ser totalmente removido da origem antes de ser adicionado ao destino. Para que a remoção seja aceita, nenhum objeto pode continuar usando o domínio: nomes de usuário, endereços de e-mail secundários, grupos, contatos e aplicativos precisam ser renomeados para o domínio técnico onmicrosoft.com.

Entre a remoção na origem e a ativação no destino existe uma janela em que mensagens enviadas para o domínio podem ser rejeitadas ou ficar em fila. Por isso o corte costuma ser feito fora do horário comercial, geralmente em um fim de semana, com um roteiro detalhado e testado no piloto. Reduzir o TTL dos registros DNS com alguns dias de antecedência ajuda a propagação a acontecer em minutos, e não em horas.

Depois da troca, todos os registros de autenticação de e-mail precisam ser revisados. O MX e o Autodiscover passam a apontar para o novo tenant, o SPF deve refletir os novos remetentes autorizados, as chaves DKIM são geradas novamente no destino e a política DMARC deve ser acompanhada nos primeiros dias para detectar falhas de entrega. Um descuido nesse ponto faz com que os e-mails da empresa caiam no spam dos clientes justamente no momento em que a nova marca está sendo apresentada ao mercado.

Quando a fusão também envolve um novo domínio, vale manter o domínio antigo como endereço secundário por um bom período. Assim, clientes e fornecedores que ainda usam o endereço antigo continuam chegando à caixa certa enquanto a transição é comunicada.

Coexistência, corte e o dia seguinte

Em projetos maiores, é comum que os dois tenants convivam por semanas ou meses. Nesse período, recursos como a sincronização entre tenants do Entra ID e o compartilhamento de disponibilidade de agenda permitem que colaboradores das duas empresas se encontrem no catálogo de endereços, vejam a agenda uns dos outros e colaborem no Teams como se já estivessem no mesmo ambiente. Isso reduz a pressão sobre a data de corte e dá tempo para migrar em lotes, por departamento ou por localidade.

O dia seguinte ao corte é quando o usuário percebe a migração. O perfil do Outlook precisa ser reconfigurado, o cliente de sincronização do OneDrive deve ser conectado à nova conta, o Teams pede novo login e, em empresas que usam Intune, os dispositivos precisam ser registrados no novo tenant. Um guia simples, com capturas de tela, e uma equipe de suporte reforçada nas primeiras 48 horas fazem toda a diferença na percepção do projeto.

Por fim, o tenant de origem não deve ser desativado imediatamente. É recomendável mantê-lo em modo somente leitura por um período definido, garantir que backups e retenções legais foram transferidos ou preservados e só então cancelar as licenças antigas. Esse cuidado evita perdas irreversíveis caso algum dado tenha ficado para trás.

Como a Duk conduz migrações entre tenants

A Duk Informática & Cloud acompanha empresas em fusões, aquisições, cisões e trocas de marca há mais de 18 anos. Como Microsoft Gold Partner, conhecemos de perto os recursos nativos de migração do Microsoft 365, seus limites e as situações em que vale a pena complementar com ferramentas especializadas. Já atendemos mais de 550 empresas e sabemos que cada migração tem particularidades: volume de dados, integrações com sistemas internos, exigências jurídicas e o ritmo de cada negócio.

Nosso trabalho cobre o projeto de ponta a ponta: inventário do ambiente atual, desenho do tenant de destino, piloto, migração em lotes, troca de domínio com janela planejada, revisão de SPF, DKIM e DMARC, reconfiguração de dispositivos e suporte aos usuários no pós-corte. Também cuidamos da segurança do novo ambiente, com políticas de acesso, autenticação multifator e backup dos dados do Microsoft 365, para que a empresa saia da migração mais protegida do que entrou.

Se a sua empresa está passando por uma fusão, aquisição ou mudança de domínio, fale com a Duk antes de definir a data do corte. Um planejamento bem feito transforma uma migração arriscada em uma transição previsível, sem perda de e-mails, arquivos ou produtividade.