CloudM Migrate: como corrigir datas de email erradas

O problema de datas do CloudM Migrate que ninguem avisa

CloudM Migrate terminou o trabalho. O painel mostra 100 % concluido, todos os usuarios migrados, zero erros. O ticket do projeto e fechado e voce passa para o proximo cliente.

Uma semana depois, o diretor de TI liga. "Por que cada email na minha caixa mostra 2 de abril?"

Nao alguns emails. Todos. Cinco anos de correspondencia com clientes, documentos juridicos, registros de RH, pedidos de compra de 2020, todos mostrando a data em que CloudM executou a migracao. As mensagens estao la, o conteudo esta intacto, os anexos estao ok. Mas as datas estao erradas em cada uma.

Isso nao e um bug do CloudM. A documentacao de suporte do CloudM reconhece isso abertamente. O problema esta na intersecao entre como as ferramentas de migracao transferem mensagens e como os servidores de email de destino lidam com metadados de email recebido. Mas saber disso nao ajuda o cliente cuja caixa de entrada se tornou impossivel de classificar cronologicamente.

Como o CloudM realmente transfere as mensagens

CloudM Migrate se conecta as plataformas de origem e destino por meio de suas APIs. Para Google Workspace, isso significa uma conta de servico com delegacao em todo o dominio (configurada no Console de Administracao do Google em Seguranca > Controles de API). Para Microsoft 365, utiliza Exchange Web Services ou a API do Microsoft Graph, dependendo do caminho de migracao.

Quando o CloudM le uma mensagem da origem, obtem o conteudo completo RFC 2822, incluindo todos os cabecalhos originais e o corpo da mensagem. O cabecalho Date: original (aquele que o servidor de email do remetente carimbou quando o email foi enviado pela primeira vez) vem intacto. O mesmo vale para todos os cabecalhos Received: originais que tracam o caminho de entrega da mensagem.

O problema acontece no destino. Quando o CloudM grava essa mensagem na caixa de correio de destino, o servidor de destino a trata como uma nova entrega. Ele carimba um cabecalho Received: novo com a data e hora atuais, e define o INTERNALDATE (o timestamp que o IMAP usa para ordenacao) para o momento da insercao.

Eis como a cadeia de cabecalhos fica apos uma migracao CloudM para Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

O cabecalho de 2019 ainda esta la. O cabecalho Date: original ainda diz 23 de setembro de 2019. Mas o Outlook le o cabecalho Received: mais recente para determinar a ordem de exibicao, e esse diz 2 de abril de 2026.

A configuracao "Strip Received Headers" do CloudM

O CloudM oferece uma configuracao para resolver isso. Nas Configuracoes Avancadas da plataforma de destino, em Message Options, ha uma opcao "Strip Received Headers". Quando ativada, o CloudM remove os cabecalhos Received antes de inserir a mensagem e os substitui por um unico cabecalho que corresponde ao cabecalho Date: do email.

Parece que resolve tudo, ne? Na verdade, nao exatamente.

Primeiro, voce precisa saber dessa opcao antes de executar a migracao. A maioria dos administradores descobre o problema de datas depois que a migracao esta completa. A essa altura, as mensagens ja estao no destino com datas erradas. Reexecutar o CloudM com a configuracao ativada apenas cria duplicatas, nao corrige o que ja esta la.

Segundo, essa configuracao tem uma limitacao rigida quando Google Workspace e o destino. A propria documentacao do Google confirma: o Gmail sempre reescreve os cabecalhos Received: em mensagens inseridas via API, carimbando-os com o timestamp de insercao. Essa e uma restricao no nivel da plataforma que o CloudM nao consegue contornar. Mesmo com "Strip Received Headers" ativado, o Google Workspace adiciona seu proprio cabecalho Received: com a data da migracao.

Para destinos Microsoft 365, a configuracao funciona melhor em teoria, mas o pipeline de transporte do M365 tem seu proprio comportamento. O Exchange Online ainda pode definir o INTERNALDATE com base em seu proprio processamento de entrega, dependendo de como a mensagem entra no sistema.

Quais migracoes CloudM quebram as datas (e quais nao)

Nem toda migracao CloudM produz datas erradas. O resultado depende da combinacao origem-destino e do caminho API especifico que o CloudM utiliza:

• Google Workspace para Microsoft 365: As datas quebram. O CloudM le via API do Gmail e escreve no Exchange. A camada de transporte do M365 carimba novos cabecalhos Received.
• Microsoft 365 para Google Workspace: As datas quebram. Mesmo com Strip Received Headers, a API do Google reescreve o cabecalho Received com a data de insercao. A documentacao de suporte do CloudM chama isso de "limitacao estrita da plataforma".
• Google Workspace para Google Workspace: As datas quebram. Trocas de dominio, consolidacoes de tenant, fusoes, o tenant Google de destino sempre carimba a data da migracao nas mensagens recebidas.
• Exchange on-premises para Microsoft 365: Geralmente quebra pela rota IMAP. Se o CloudM usa EWS em ambos os lados, a preservacao de datas e mais confiavel, mas nao garantida.
• Origem IMAP (generico) para qualquer destino: As datas quebram. Quando o CloudM se conecta a um servidor IMAP generico como origem, o destino ainda adiciona seus proprios cabecalhos de entrega.

A parte complicada? O painel de migracao do CloudM nao sinaliza nada disso. A barra de progresso preenche, a coluna de status diz "Completed", as contagens de itens conferem. Da perspectiva do CloudM, a migracao foi um sucesso. E tecnicamente foi. As mensagens foram transferidas. As datas simplesmente nao sobreviveram a viagem.

CloudM Managed vs. Self-Service: mesmo problema de datas

O CloudM oferece dois modelos de implantacao. A versao SaaS (CloudM Migrate hospedado) roda inteiramente na infraestrutura do CloudM. A versao auto-hospedada permite implantar servidores de migracao primarios e secundarios em sua propria rede, Google Cloud, Azure ou AWS.

Alguns MSPs assumem que a opcao auto-hospedada da mais controle sobre o tratamento de datas, ja que voce gerencia os servidores de migracao diretamente. Nao da. O problema de datas acontece no servidor de destino, nao nos nos de processamento do CloudM. Quer sua fazenda de migracao rode na nuvem do CloudM ou na sua propria VM do Azure, o servidor de email de destino ainda carimba a data da migracao em cada mensagem que recebe.

O CloudM tambem oferece "Serviced Migration" totalmente gerenciada, onde a equipe deles conduz o projeto do inicio ao fim. Mesmo resultado para as datas. A engenharia e identica, so mudam as maos no teclado. Alias, voce ja pagou por um servico premium e recebeu a mesma limitacao do plano gratuito? E exatamente essa a sensacao.

A complicacao dos cabecalhos Date invalidos

Ha outro comportamento especifico do CloudM que piora as coisas. Quando o CloudM encontra um email de origem com um cabecalho Date: que nao esta em conformidade com RFC 822 (fuso horario malformado, dia da semana ausente, formato nao padrao), ele modifica o cabecalho para garantir que a mensagem possa ser migrada.

Isso significa que alguns emails perdem ate mesmo sua referencia de data original. O cabecalho Date: modificado pode nao corresponder a data real de envio. A documentacao de suporte do CloudM menciona esse comportamento em "Possible Changes to Migrated Items", mas nao especifica qual sera a data modificada.

Para uma caixa de correio com 12.000 mensagens acumuladas ao longo de oito anos, pode haver centenas de emails com cabecalhos Date ligeiramente fora do padrao (especialmente mensagens de servidores de email antigos, sistemas automatizados ou remetentes internacionais com peculiaridades na formatacao de fuso horario). Apos a modificacao do CloudM somada a reescrita do cabecalho Received pelo servidor de destino, essas mensagens acabam com datas que nao tem qualquer semelhanca com a realidade.

Por que correcoes manuais nao escalam apos o CloudM

Seria possivel corrigir isso por conta propria? Tecnicamente, o cabecalho Date: original ainda esta presente na maioria das mensagens (exceto aquelas que o CloudM modificou para conformidade RFC). Alguns administradores tentaram escrever scripts para corrigir datas apos uma migracao CloudM.

Eis a realidade dessa abordagem. Estamos falando de conectar a potencialmente milhares de caixas de correio, cada uma com milhares de mensagens. Para cada email, e preciso parsear a cadeia completa de cabecalhos, identificar quais cabecalhos Received: o CloudM ou o servidor de destino adicionou, lidar com os casos extremos (mensagens assinadas com S/MIME onde a modificacao de cabecalhos quebra a assinatura, conteudo criptografado com PGP, estruturas MIME multipart com limites aninhados, cabecalhos nao-ASCII codificados com RFC 2047 de remetentes japoneses ou coreanos), e fazer tudo isso sem perder um unico anexo ou quebrar o encadeamento de emails.

Um script que funciona com 50 emails de teste de uma caixa limpa nao sobrevivera ao contato com um ambiente de producao de 40.000 mensagens ao longo de uma decada. O que acontece quando voce encontra um email de 47 MB com seis anexos aninhados? E os limites de taxa das APIs (250 unidades de cota por usuario por segundo no Google, limitacao da Microsoft em cerca de 10.000 requisicoes por 10 minutos)? Qual e o plano de rollback quando algo da errado na mensagem numero 8.347?

E a pergunta real que a maioria dos administradores nao faz ate que seja tarde demais: como verificar que cada mensagem corrigida esta realmente intacta?

Corrigindo datas de migracao CloudM com Redate.io

Redate.io se conecta diretamente as caixas de correio afetadas (Google Workspace, Microsoft 365 ou IMAP) e escaneia em busca de emails que carregam a assinatura de data de migracao do CloudM. O escaneamento e gratuito e leva alguns minutos por caixa, mostrando a contagem exata de mensagens afetadas antes de qualquer compromisso.

A correcao utiliza um motor proprietario de analise de cadeias de cabecalhos que identifica padroes de migracao especificos do CloudM ao longo da cadeia Received. Redate.io realiza correcao direcionada de metadados sem alterar o conteudo da mensagem, preservando anexos, encadeamento, labels, pastas e assinaturas digitais. Cada mensagem corrigida passa por verificacao individual, checando a integridade da mensagem contra o original antes de o processo avancar.

Os emails originais sao mantidos em uma pasta de backup visivel Redate.io - Originals por 30 dias. Se algo precisar ser revertido, os originais estao ali mesmo na caixa de correio, nao enterrados em algum arquivo externo.

Para MSPs que usaram o CloudM em ambientes de clientes, Redate.io lida com correcoes de multiplas caixas em escala, com a mesma verificacao por mensagem quer voce esteja corrigindo 1 caixa ou 500. O problema de datas que o CloudM deixou para tras nao precisa se tornar uma caracteristica permanente do ambiente de email do seu cliente.

Guias de correcao por plataforma para migracoes CloudM

O processo de correcao se adapta a plataforma de destino. Redate.io lida com as especificidades de cada plataforma automaticamente, mas para detalhes sobre sua configuracao:

• Corrigir datas de migracao CloudM no Gmail
• Corrigir datas de migracao CloudM no Outlook
• Corrigir datas de migracao CloudM no Google Workspace
• Corrigir datas de migracao CloudM no Microsoft 365

Para uma explicacao aprofundada de por que isso acontece com todas as ferramentas de migracao (nao apenas CloudM), confira por que os emails mostram datas erradas apos a migracao.

Migrou com CloudM e preso com datas erradas em cada email? Execute um escaneamento gratuito para ver exatamente quantas mensagens estao afetadas e quanto custa corrigi-las.