Migração Google Workspace para Google Workspace: datas quebradas

O cenário que ninguém suspeita

Você acabou de finalizar a migração de um tenant Google Workspace para outro. Aquisição de empresa, mudança de domínio, fusão de duas entidades que coexistiam em contas G Suite separadas há anos. A operação foi bem, as caixas estão no lugar, os usuários estão se conectando. Segunda-feira de manhã, primeiro ticket: "Todos os meus emails têm a mesma data." Depois um segundo. Depois dez.

Instintivamente, você pensa: deve ser um problema IMAP, alguma ferramenta mal configurada, algo exótico. Não uma migração Google para Google. Mas é exatamente aí que o problema acontece.

Esse cenário é provavelmente o menos documentado do setor. A maioria dos admins de TI que se deparam com ele perde horas procurando uma explicação no cliente de email, no Outlook, nas configurações de conta, antes de perceber que o problema está nos cabeçalhos dos próprios emails.

Por que uma migração Google para Google quebra as datas

Para entender o que acontece, é preciso voltar à mecânica dos cabeçalhos de email. Cada mensagem RFC 2822 contém um campo Date: original, inserido pelo cliente ou servidor remetente no momento do envio. É a data "real" do email, aquela que corresponde a quando a mensagem foi escrita e enviada.

Mas existe outro mecanismo: o INTERNALDATE do IMAP. É um metadado armazenado no servidor que indica quando a mensagem foi depositada na caixa. E é aí que as coisas ficam interessantes.

Quando uma ferramenta de migração transfere um email de um tenant Google Workspace para outro, ela passa pelo protocolo IMAP (mesmo que os dois servidores sejam do Google). A mensagem é lida na origem e reinserida no destino. No momento dessa reinserção, o servidor de destino adiciona automaticamente um cabeçalho Received: com o timestamp da operação, ou seja, a data da migração.

Acontece que clientes de email como o Outlook usam o primeiro Received: da cadeia para exibir a data de uma mensagem, e não necessariamente o campo Date: original. Resultado: todos os emails exibem a data do dia da migração.

Quais ferramentas causam o problema

Praticamente todas as ferramentas usadas em migrações entre tenants Google Workspace são afetadas. Sem exceção notável:

• GSMMO (Google Workspace Migration for Microsoft Outlook): desenvolvido originalmente para migrar a partir do Exchange, mas usado em alguns fluxos de GWS para GWS. Veja como o GSMMO afeta as datas no Workspace.
• CloudM Migrate: muito usado por MSPs em migrações inter-Google, adiciona sistematicamente um Received: de migração. Consulte a análise detalhada do CloudM.
• BitTitan MigrationWiz: o mesmo comportamento, documentado no artigo sobre o BitTitan.
• imapsync: a ferramenta open source que permite scripts de migrações IMAP, inclusive entre dois tenants Google.
• Exportações/importações manuais via Takeout + reimportação IMAP: menos comuns, mas produzem exatamente o mesmo efeito.

O motivo é simples: todas essas ferramentas funcionam como clientes IMAP padrão. Elas não têm acesso a uma via "nativa" do Google que preservaria os metadados. Mesmo que os dois tenants sejam do Google, a transferência passa pela camada IMAP, e essa camada não sabe que está falando consigo mesma.

A mecânica dos cabeçalhos Received em detalhes

(Se você já tentou ler os cabeçalhos brutos de um email pelo Gmail ou pelo Outlook, sabe que não é exatamente uma leitura prazerosa. Mas é lá que toda a verdade está escondida.)

Um email que trafegou normalmente contém uma cadeia de cabeçalhos Received: em ordem inversa ao percurso: o último servidor que tocou a mensagem fica no topo. Após uma migração, o cabeçalho de migração acaba bem no topo da pilha.

Veja como fica em uma mensagem migrada via CloudM de um tenant GWS para outro:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <usuario@novo-dominio.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

O campo Date: diz 2019. O primeiro Received: diz outubro de 2024. O Outlook lê o primeiro Received:. O usuário vê outubro de 2024 em um email de 2019.

O campo Date: original está intacto. Não foi alterado. Essa é a boa notícia: a informação está lá, só esperando ser usada corretamente.

Outlook e Gmail não se comportam da mesma forma

Essa é uma distinção importante. Os usuários que acessam seus emails pela interface web do Gmail frequentemente veem as datas corretas, porque o Gmail prioriza o campo Date: RFC 2822 para exibir as mensagens. O problema é menos visível pelo navegador.

Já os usuários que configuram sua caixa do Google Workspace no Outlook via IMAP (ou via sincronização Exchange ActiveSync) sofrem diretamente com a data errada, porque o Outlook confia no INTERNALDATE do IMAP, que por sua vez reflete a data do primeiro Received: adicionado durante a migração.

Na verdade, para ser preciso: o comportamento do Outlook varia conforme a versão e o modo de conexão. O Outlook 2019 e o Microsoft 365 (versões recentes) usam o INTERNALDATE quando se conectam via IMAP. Versões mais antigas podem se comportar de forma ligeiramente diferente. Mas em todos os casos observados em produção, a migração GWS para GWS via IMAP produz datas incorretas no Outlook.

Com isso, nas organizações que migraram para um novo tenant e mantêm usuários híbridos (alguns no Gmail web, outros no Outlook), os tickets chegam de forma incoerente. As equipes de TI passam tempo tentando entender por que "alguns são afetados e outros não", quando a resposta é simplesmente: é o cliente de email que faz a diferença.

Aquisições, fusões, mudanças de domínio: os casos mais frequentes

Esse tipo de migração não é raro. Estes são os cenários que geram mais tickets:

Aquisição de empresa

Uma empresa adquirida tinha seu próprio tenant Google Workspace (domínio @empresaantiga.com). Após a aquisição, tudo precisa migrar para o tenant da controladora (@grupo.com). As 250 caixas, os arquivos, os 8 anos de histórico de email. BitTitan ou CloudM é contratado para a operação. Resultado: 2,4 milhões de emails com a data do final de semana da migração.

Mudança de domínio

Uma empresa reposicionada passa de @nomeantigo.com.br para @novonome.com.br. Mesmo tenant Google, mas criação de um novo tenant para começar do zero (escolha comum para evitar resíduos de configuração). Migração das caixas via imapsync ou GSMMO. As datas quebram exatamente da mesma forma.

Consolidação de filiais

Um grupo com 4 filiais, cada uma em seu próprio tenant G Suite histórico, decide centralizar tudo em um tenant único. Quatro migrações em paralelo, quatro lotes de emails com datas corrompidas para tratar.

Nesses três cenários, o problema é idêntico e a solução é a mesma. O checklist de migração de email permite antecipar esse tipo de problema antes de iniciar a migração.

Por que um script caseiro não é a resposta

Entender o problema é uma coisa. Decidir "vou escrever um script Python que limpa os cabeçalhos" e aplicá-lo em 30.000 emails de produção é outra completamente diferente.

Os casos extremos são inúmeros. Um script que funciona em 50 emails de teste em um ambiente limpo vai inevitavelmente se deparar, em uma caixa de produção real, com:

• Mensagens com assinaturas S/MIME ou conteúdo PGP criptografado, onde qualquer modificação na estrutura da mensagem invalida a assinatura criptográfica.
• Emails com estruturas MIME aninhadas complexas (multipart/alternative dentro de um multipart/mixed com anexos de dezenas de megabytes).
• Cabeçalhos codificados em RFC 2047 (caracteres não-ASCII), que parsers mal configurados consomem silenciosamente.
• Erros 429 Too Many Requests da API do Google às 2h da manhã, no meio de um lote de correção, deixando o processo em estado indeterminado.
• Emails nos quais a cadeia de Received: é ambígua: várias ferramentas de migração sucessivas adicionaram cada uma o seu cabeçalho, e não é trivial determinar qual remover.

E a pergunta mais importante: como verificar, email por email, que cada mensagem corrigida está intacta e que nada foi perdido ou corrompido? Um script caseiro geralmente não faz essa verificação. O Redate.io faz automaticamente, com preservação dos originais em uma pasta de backup visível por 30 dias.

O que o Redate.io faz nesse tipo de migração

O Redate.io se conecta ao tenant Google Workspace de destino (via delegação de domínio, sem intervenção manual caixa por caixa) e escaneia os emails para identificar aqueles cujos metadados de data são inconsistentes com o conteúdo da mensagem. Essa fase de scan é gratuita e oferece uma visão exata da dimensão do problema antes de qualquer correção.

O motor de correção proprietário analisa em seguida a cadeia de cabeçalhos de cada mensagem, aplica correspondência de padrões sobre as assinaturas conhecidas das ferramentas de migração (BitTitan, CloudM, imapsync, GSMMO, e outras menos comuns), e efetua uma correção direcionada dos metadados sem alterar o conteúdo da mensagem. Cada email corrigido é verificado individualmente. Os originais são preservados.

Para migrações entre tenants Google Workspace especificamente, o pipeline trata os casos em que várias passagens de migração ocorreram (por exemplo, uma caixa migrada pela primeira vez em 2021 e depois novamente em 2024), com múltiplas camadas de cabeçalhos parasitas para desembaraçar.

Os guias de correção específicos para CloudM para Google Workspace e BitTitan para Google Workspace detalham as etapas de conexão para esse tipo de configuração.

Detectar o problema antes que os usuários reclamem

O melhor momento para detectar datas corrompidas é logo após a migração, antes do go-live. Uma verificação rápida em algumas caixas piloto via um cliente IMAP como o Thunderbird permite comparar a exibição das datas com o que se esperaria. Se todos os emails importados parecem ter a mesma data recente, é o sinal característico do problema.

Mas na prática, a descoberta costuma acontecer semanas depois da migração, quando um usuário procura um contrato antigo e percebe que a caixa do Gmail está perfeitamente organizada... por data de migração. Milhares de emails empilhados no mesmo timestamp. A busca por data não funciona mais. Os fios de conversa estão fora de ordem. O histórico parece ter desaparecido.

Para os MSPs que gerenciam regularmente migrações entre tenants Google Workspace, incluir um scan do Redate.io na checklist pós-migração (antes da validação pelo cliente) evita esse tipo de surpresa.

Você acabou de migrar entre dois tenants Google Workspace e as datas dos seus emails estão incorretas? Inicie um scan gratuito no Redate.io para medir o impacto antes de qualquer correção.