Ferramenta de migração: retome tarefas IMAP com segurança

Sua ferramenta de migração de e-mails é mais importante quando a tarefa falha às 2 da madrugada. Esse é o verdadeiro teste, não a demonstração perfeita nem a captura de tela comercial. Se você transfere mensagens do Gmail, Microsoft 365 ou de um servidor cPanel antigo, falhas são normais. A pergunta é simples: a ferramenta retoma o processo de forma limpa ou cria duplicatas, ignora pastas e deixa você explicando a confusão aos usuários? Se estiver planejando uma mudança mais ampla, comece pelo e-mail profissional para que a migração combine com o sistema que você realmente está construindo.

A resposta rápida é esta. Uma ferramenta segura precisa de quatro elementos: detecção de duplicatas, lógica de novas tentativas, mapeamento de pastas e logs por item. Se faltar um deles, uma interrupção no meio do processo vira um projeto de limpeza de caixas.

Você acorda, olha o painel e vê 68% concluído. Uma caixa aparece como falha. O usuário entra e metade dos e-mails enviados sumiu. Não é azar. É um problema da ferramenta.

É por isso que bons operadores se importam menos com a barra de progresso e mais com o acompanhamento do estado. Se a ferramenta não consegue comprovar o que copiou, o que ignorou e onde parou, você não tem uma migração. Tem uma aposta.

Para entender o protocolo, a visão geral da migração IMAP da TrekMail explica o que as importações IMAP transferem e o que deixam de fora. Se você usa a linha de comando diretamente, em vez de um fluxo hospedado, vale a pena ler também este guia sobre imapsync antes de mexer na produção.

O que uma ferramenta deve fazer quando a execução falha

Uma ferramenta de migração deve retomar o trabalho depois de quedas de rede, limites de tráfego ou mensagens defeituosas sem duplicar e-mails nem ignorar pastas. O requisito central é a idempotência: execute a mesma tarefa novamente e o destino continuará correto. Todo o restante é secundário.

Muitas ferramentas anunciam velocidade. Velocidade é conveniente. Retomar com segurança é o que evita problemas.

Quando uma tarefa falha, a ferramenta deve fazer tudo isto por padrão:

1. Reconectar sem começar do zero.
2. Ignorar mensagens que já existem no destino.
3. Registrar o item ou a pasta exatos que falharam.
4. Pausar e tentar novamente quando o servidor de origem pedir uma redução do ritmo.
5. Manter a estrutura das pastas intacta entre diferentes estilos de namespace IMAP.

Se o produto não realiza essas cinco tarefas, não confie a ele uma virada real.

As falhas que interrompem quase todas as migrações grandes

A maioria das falhas é um comportamento normal do IMAP sob carga. Os provedores limitam clientes, tokens expiram, servidores reiniciam conexões e mensagens malformadas derrubam analisadores. Uma boa ferramenta trata essas situações como condições operacionais esperadas, não como exceções raras.

Vamos aos detalhes.

Os limites de tráfego aparecem primeiro. Gmail, Microsoft 365 e servidores antigos de hospedagem compartilhada protegem seus recursos. Exija demais e eles reduzem a velocidade ou interrompem a conexão. Uma ferramenta fraca continua pressionando o servidor e agrava o bloqueio.

Os itens defeituosos vêm depois. Um único cabeçalho MIME malformado ou anexo grande demais pode derrubar repetidamente um importador frágil na mesma mensagem. Se a ferramenta não consegue isolar esse item e continuar, toda a execução fica parada.

A expiração da autenticação é outra causa comum. A Microsoft desativou a autenticação Básica em ambientes do Exchange Online, e os fluxos de autenticação modernos ainda exigem a renovação de tokens durante tarefas longas. Se o mecanismo de migração não cuida bem dessa renovação, a execução morre no meio.

A Microsoft documenta o encerramento da autenticação Básica no Exchange Online em sua orientação oficial sobre a desativação da autenticação Básica. No lado do IMAP, a RFC 3501 define UIDs de caixas e UIDVALIDITY na especificação básica do IMAP4rev1. As duas referências explicam por que antigas premissas falham em 2025-2026.

Retomar com segurança depende de idempotência, não de esperança

Idempotência significa que a ferramenta pode ser executada novamente na mesma caixa e ainda produzir uma única cópia correta de cada mensagem. Sem isso, toda nova tentativa pode gerar duplicatas, mensagens perdidas ou os dois problemas. Esse é o recurso de projeto mais importante em qualquer mecanismo de migração.

É aqui que ferramentas baratas desmoronam.

Uma ferramenta ingênua registra apenas o último UID visto e supõe que a caixa de origem nunca muda. Servidores reais não funcionam com tanta simplicidade. Caixas são compactadas, reparadas e restauradas. UIDVALIDITY muda. Quando isso acontece, a ferramenta deve trocar a retomada rápida baseada em UID por uma verificação de duplicatas mais lenta, como a comparação por Message-ID.

Essa é a diferença entre um atraso e um desastre.

imapsync \
  --host1 imap.oldhost.com --user1 alice@example.com --password1 'source-pass' \
  --host2 imap.trekmail.net --user2 alice@example.com --password2 'dest-pass' \
  --ssl1 --ssl2 \
  --syncinternaldates \
  --useheader 'Message-Id' \
  --skipsize \
  --skipcrossduplicates \
  --errorsmax 50

Esse tipo de abordagem segura para diferenças explica por que os operadores mantêm uma segunda execução no procedimento. A primeira transfere o volume principal. A segunda captura itens que chegaram depois e verifica se as duplicatas não estão se acumulando.

Se a origem for especificamente o Gmail, o guia de migração do Gmail da TrekMail trata das credenciais, inclusive da necessidade de uma senha de app quando o Google não aceita a senha comum da conta para acesso IMAP.

O mapeamento de pastas esconde a perda silenciosa de dados

O mapeamento informa à ferramenta como os nomes das pastas de origem devem aparecer no destino. Sem ele, os e-mails podem ser importados corretamente, mas chegar ao lugar errado. É uma falha silenciosa porque os dados existem, embora o usuário ache que sumiram.

Isso acontece o tempo todo.

Um servidor usa pontos. Outro usa barras. Um chama os e-mails enviados de Sent Messages. Outro espera Sent Items. Uma ferramenta fraca copia os nomes literalmente e declara a tarefa concluída. O usuário entra e encontra um amontoado de pastas no nível raiz.

Estes são os mapeamentos mais importantes:

^Sent Messages$  -> Sent Items
^Deleted Messages$ -> Trash
^Draft Messages$ -> Drafts
INBOX\.(.+) -> INBOX/$1

A última linha é a armadilha do namespace. Ela converte árvores de pastas separadas por pontos, comuns em configurações Dovecot ou cPanel, em árvores separadas por barras, geralmente esperadas por clientes IMAP e plataformas hospedadas.

O mapeamento também importa ao ampliar a configuração de caixas em vários domínios. É o mesmo problema operacional do provisionamento: consistência evita limpeza. Por isso, criar contas de e-mail em massa e a hospedagem de e-mail para vários domínios se tornam relevantes quando você transfere mais do que alguns usuários.

Os logs determinam se você consegue corrigir os últimos 2%

Uma ferramenta útil precisa gerar logs por item, e não apenas uma marca verde ou um X vermelho. Você precisa saber qual mensagem falhou, em que pasta ela estava e por quê. Sem isso, não dá para decidir se deve repetir, ignorar ou escalar o problema.

“Concluído com erros” não informa nada de útil. Você precisa de uma lista.

Os logs devem incluir, no mínimo, assunto, pasta de origem, data da mensagem, tamanho do item e motivo da falha. Melhor ainda se houver exportação em CSV. Assim, você pode filtrar por tipo de erro e tratar cada classe de problema da forma correta.

Este é o fluxo operacional que realmente funciona:

1. Execute a primeira etapa da migração.
2. Exporte ou analise os logs de itens ignorados.
3. Agrupe as falhas por causa: autenticação, tempo limite, tamanho excessivo, item malformado ou cota do destino.
4. Execute a tarefa novamente com a exclusão de duplicatas ativada.
5. Trate manualmente apenas as verdadeiras exceções.

Esse fluxo é monótono. Ótimo. É disso que você precisa durante uma migração.

Antes da virada final, verifique o domínio de destino e a configuração das caixas. O guia da TrekMail para adicionar um domínio explica a parte de DNS para que você não transfira o correio corretamente e depois interrompa a entrega na etapa do MX.

Método antigo e novo: scripts, SaaS por usuário e TrekMail

O método antigo reúne uma pilha de scripts, tarifas de migração por usuário e supervisão manual. O novo integra a ferramenta à plataforma de e-mail, define o preço no nível do plano e já inclui novas tentativas e verificação de duplicatas no fluxo.

Método antigo: executar o imapsync por conta própria, gerenciar senhas de app, ajustar novas tentativas, mapear pastas manualmente, analisar logs à mão e depois pagar outro provedor por cada caixa transferida.

Método novo: usar a migração IMAP do servidor da TrekMail dentro da mesma plataforma que hospedará as caixas de destino. Você informa os dados IMAP antigos, escolhe a caixa da TrekMail e inicia a importação no painel. A documentação apresenta a exclusão de duplicatas como uma opção padrão, e o status da tarefa aparece como na fila, em processamento, concluído ou com falha.

Isso importa porque a migração não deveria virar uma fonte separada de receita. Ela deveria fazer parte da integração.

A TrekMail foi criada em torno da hospedagem de e-mail para vários domínios com preço fixo. Os planos começam em $3.50 por mês. O produto inclui domínios personalizados, caixas IMAP, endereços catch-all, SMTP próprio ou incluído conforme o plano, encaminhamento de caixas, uma ferramenta de migração e acesso por API nos níveis superiores. Há um plano Nano de $0, e os planos pagos podem ser testados gratuitamente por 14 dias. O plano gratuito não exige cartão. A avaliação exige.

Para equipes pequenas, isso permite transferir mensagens sem comprar primeiro um complemento de migração por usuário. Para agências, permite encaixar o processo no mesmo modelo de controle já necessário para propriedade das caixas, integração de clientes e margem recorrente.

Se a economia importa tanto quanto as ferramentas, compare os planos diretamente em preços da TrekMail.

Como escolher uma ferramenta de migração sem arrependimento

Escolha uma ferramenta com base na recuperação de falhas, no tratamento de duplicatas, no mapeamento de pastas e nos logs. Ignore painéis meramente estéticos. Se ela não resiste a limites de tráfego, mensagens problemáticas e novas tentativas, custará mais tempo do que economiza.

Use este checklist antes de decidir:

1. A ferramenta consegue ignorar duplicatas ao executar novamente?
2. Consegue continuar depois da falha de uma única mensagem?
3. Consegue mapear nomes de pastas e delimitadores de namespace?
4. Consegue mostrar erros por item em vez de apenas um resumo?
5. Consegue lidar com autenticação moderna e sessões prolongadas?
6. Consegue migrar via IMAP sem impor um modelo separado de cobrança por usuário após a transferência?

Se alguma resposta for negativa, continue procurando.

A melhor ferramenta não é a que tem a interface mais bonita. É a que pressupõe que haverá falhas e foi criada para se recuperar sem danificar a caixa. Esse é o padrão. Tudo o que estiver abaixo dele é uma interrupção prestes a acontecer.