Checklist de migração de e-mail para uma virada IMAP segura

Se você precisa de um checklist de migração de e-mail, provavelmente já conhece o risco. As migrações raramente falham apenas na cópia. Os problemas surgem nas bordas: aliases esquecidos, DNS desatualizado, perfis do Outlook em cache, peculiaridades dos marcadores do Gmail e aquela caixa de um usuário importante que demora três dias além do previsto.

Esse é o problema. Pior ainda é que muitos guias são genéricos demais para ajudar durante a virada. Se você está migrando uma equipe pequena, reorganizando uma hospedagem antiga ou tentando reduzir o custo do e-mail empresarial, comece pelos fundamentos de e-mail empresarial para pequenas empresas e depois volte para este roteiro operacional.

Este guia oferece um checklist de migração de e-mail para usar antes, durante e depois da virada. Foi pensado para fundadores, administradores de TI, agências e MSPs que migram para hospedagens IMAP como o TrekMail, cuja oferta descrita neste material inclui vários domínios, armazenamento compartilhado e migração IMAP integrada no servidor.

O que um checklist de migração de e-mail cobre

Um checklist de migração reúne controles para caixas, DNS, identidades e acesso dos clientes durante a virada. Serve para reduzir devoluções de mensagens, pastas ausentes, aplicativos móveis que deixam de funcionar e lacunas silenciosas nos dados, percebidas só depois que os usuários voltam a trabalhar.

Um bom checklist de migração de e-mail não se resume a “exportar, importar e trocar o MX”. Ele precisa cobrir todos os objetos que recebem mensagens, todas as dependências que podem impedir a entrega e todas as ações dos usuários que podem transformar uma migração concluída em uma crise de suporte.

1. Inventarie tudo o que pode receber e-mail

O primeiro item é o inventário. Se a lista de origem só inclui usuários com licença, ela está incompleta. Caixas compartilhadas, aliases, rotas catch-all, regras de encaminhamento, scanners, caixas do financeiro e listas de distribuição antigas podem continuar recebendo mensagens reais após a virada.

É aqui que a situação se complica. Alguém exporta os “usuários ativos”, cria as caixas de destino, muda o DNS e considera o trabalho encerrado. Depois, contatos comerciais enviados a sales@ são devolvidos, faturas para ap@ parecem desaparecer e a impressora começa a apresentar erros SMTP.

Use esta lista antes de mexer nos dados:

1. Caixas de usuários com licença
2. Caixas compartilhadas e contas funcionais como info@, billing@ e support@
3. Aliases vinculados a usuários ou caixas compartilhadas
4. Listas de distribuição e endereços de grupos
5. Regras de encaminhamento, comportamento catch-all e exceções de roteamento
6. Dispositivos e aplicativos que enviam pelo provedor antigo
7. Objetos legados do Exchange, incluindo referências X.500 ou LegacyExchangeDN

Decidir se um endereço deve continuar como alias ou virar uma caixa própria é mais importante do que parece. Consulte alias de e-mail no domínio ou caixa própria antes da migração, não depois que as mensagens começarem a voltar.

Regra operacional: se um endereço já recebeu pagamentos, contatos comerciais, chamados ou redefinições de acesso, trate-o como produção até demonstrar o contrário.

O modelo do TrekMail pode ajudar porque não cobra por usuário para cada caixa funcional. Na oferta registrada neste material, os planos pagos começam em $3.50/mês, o armazenamento é compartilhado e a migração pode ser feita para caixas IMAP reais, sem improvisar caixas críticas com encaminhamentos.

2. Confira o que a migração IMAP transfere ou não

Um checklist baseado em IMAP deve partir do princípio de que transfere dados de e-mail, mas não todo o ambiente. Mensagens e pastas geralmente são copiadas. Calendários, contatos, regras, assinaturas, permissões e alguns metadados proprietários geralmente não são.

É aqui que as expectativas se frustram. IMAP transfere e-mail, não recria toda a estrutura de colaboração. Se a origem é Google Workspace ou Exchange, os usuários podem esperar que calendários, permissões compartilhadas, categorias e histórico de preenchimento automático sejam preservados. Em geral, isso exige tratamento separado.

Antes do projeto, registre o que está no escopo:

A ferramenta de importação do TrekMail serve para importar e-mail via IMAP. Use-a para esse objetivo. Confira o fluxo na visão geral da migração IMAP e em iniciar uma importação no painel antes de prometer uma “migração completa do ambiente”.

3. Copie as caixas grandes antes ou o cronograma não será realista

Um checklist realista precisa considerar limitações de tráfego. A velocidade da sua conexão local não é o único limite. O provedor de origem, o de destino e os limites das sessões IMAP determinam a velocidade possível.

São restrições técnicas concretas. Mesmo com uma conexão rápida no escritório, uma caixa de 50 GB pode avançar lentamente porque a origem reduz a velocidade das solicitações, limita conexões ou suspende atividade IMAP intensa. O Google publica limites de largura de banda do Gmail e cotas de API; ambientes Microsoft também aplicam limitações próprias.

Por isso, não planeje transferir todas as caixas de uma vez num fim de semana. Divida a migração:

1. Copie as mensagens antigas com duas a três semanas de antecedência.
2. Mantenha as recentes na origem enquanto os usuários trabalham.
3. Execute uma sincronização incremental na janela final de virada.
4. Valide as contagens antes de alterar o MX.

Essa etapa torna a migração mais administrável e pode reduzir chamados, pois os usuários já encontram boa parte do histórico ao entrar no primeiro dia.

Se a origem é Gmail, lembre-se dos marcadores. Uma mensagem com vários marcadores pode aparecer como várias cópias em pastas num fluxo IMAP que não considere essa característica. Isso aumenta o tamanho das caixas e cria duplicatas. Um checklist de migração de e-mail deve revisar explicitamente esse mapeamento e, quando apropriado, excluir estruturas desnecessárias, como grandes agrupamentos de arquivo.

Se você prefere escolher primeiro a ferramenta, compare as opções com imapsync. Se prefere migração integrada ao painel da hospedagem, a importação no servidor do TrekMail evita fazer todo o trabalho passar pelo notebook de um administrador.

4. Reduza o TTL antes da virada, não durante

O checklist precisa prever os prazos do DNS. Reduzir o TTL só depois de trocar o MX não altera o prazo das respostas já armazenadas em cache. Planeje a redução pelo menos 24 a 48 horas antes e considere o TTL anterior, para dar tempo aos resolvedores externos de renovar as respostas antigas.

Esse é o caso clássico de destinos divergentes: parte da internet vê o MX novo e outra parte ainda entrega ao servidor antigo. O painel parece mostrar uma migração concluída, enquanto mensagens continuam chegando discretamente ao provedor anterior.

Use este cronograma:

Os registros exigidos pelo TrekMail estão em registros DNS obrigatórios. Se os dois provedores enviarem durante a transição, o SPF pode precisar autorizar ambos temporariamente. SPF é definido na RFC 7208 e DMARC na RFC 7489.

example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com include:spf.trekmail.net -all"

Essa combinação temporária no SPF é um item importante do checklist de migração de e-mail. Remova o include antigo depois das verificações, não cinco minutos após trocar o MX.

5. Valide pela quantidade de itens, não pelo tamanho da caixa

Um checklist adequado verifica primeiro a contagem de mensagens. O tamanho da caixa é impreciso: os provedores contabilizam o armazenamento de formas diferentes, anexos têm sobrecarga de codificação e os marcadores do Gmail podem representar a mesma mensagem em várias pastas.

É aqui que administradores podem se alarmar sem motivo. A origem mostra 10.2 GB e o destino, 9.8 GB. Isso não significa automaticamente perda de dados. A codificação MIME, os mecanismos de armazenamento e a deduplicação podem alterar o tamanho informado.

Valide nesta ordem:

1. Confira a quantidade total de itens.
2. Confira pastas importantes, como Caixa de entrada, Enviados, Rascunhos e Arquivo.
3. Confira por amostragem períodos e conversas com muitos anexos.
4. Só então compare o tamanho informado como um indicador aproximado.

Contagens compatíveis e amostras corretas são bons sinais, mas não substituem todas as verificações. Se houver diferença na quantidade de itens, pare e investigue antes de declarar sucesso.

Teste também o fluxo real. Envie de fora do domínio, de dentro dele e do dispositivo mais problemático da empresa. Outlook, Mail do iPhone e scanners antigos podem revelar problemas que o painel não mostra.

6. Planeje nova autenticação e recriação de perfis

Um checklist está incompleto se termina no estado do servidor. Os usuários ainda precisam entrar novamente em celulares, computadores, tablets e aplicativos antigos. Em muitos casos, após proteger dados locais, remover a conta e adicioná-la novamente é mais rápido do que tentar reparar a configuração.

Essa é a fase de maior demanda de suporte. A caixa e o DNS estão corretos, mas o Outlook insiste na última configuração conhecida ou um celular conserva um token antigo do Google ou da Microsoft e não conecta ao novo servidor IMAP.

Prepare a orientação do primeiro dia: preserve dados locais necessários, remova a conta antiga, adicione a nova e use os parâmetros exatos de IMAP e SMTP. O TrekMail os publica em configurações IMAP e SMTP para todos os clientes. Os valores padrão descritos são:

IMAP host: imap.trekmail.net
IMAP port: 993
SMTP host: smtp.trekmail.net
SMTP port: 465
Username: full email address
Password: mailbox password

Outro ponto: no cenário deste material, o TrekMail usa IMAP, sem POP3. Em 2026, a manutenção de um estado compartilhado tende a ser mais útil do que o modelo antigo de baixar e excluir mensagens.

Se você administra muitos domínios ou ambientes de clientes, essa etapa de suporte cresce rapidamente. A organização operacional importa tanto quanto a ferramenta. Nesse aspecto, hospedagem de e-mail com vários domínios exige um planejamento mais amplo.

7. Decida se todo o histórico precisa ser transferido

Às vezes, o melhor checklist recomenda “não migrar tudo”. Se os usuários quase não consultam uma década de mensagens, exportar um arquivo e começar com uma caixa mais enxuta pode reduzir riscos, encurtar a virada e limitar o impacto de problemas.

Muita gente ignora essa decisão por ser difícil negociá-la internamente. Mas transferir 15 anos de recibos, newsletters e conversas de projetos encerrados consome tempo e aumenta o risco. Se o arquivo é pouco usado, retire-o do caminho crítico, respeitando as obrigações de retenção.

A comparação entre os modelos é simples:

Modelo tradicional: continuar pagando por usuário porque uma caixa tem 40 GB de histórico que ninguém consulta.

Nova abordagem: arquivar o que não é operacional, migrar o que os usuários precisam e usar armazenamento compartilhado para que uma caixa grande não exija, por si só, uma mudança de licenças para toda a equipe.

Esse modelo pode ser útil para reorganizar muitas caixas no TrekMail. Segundo a oferta registrada neste material, há início gratuito, planos pagos a partir de $3.50/mês e teste gratuito de 14 dias nos planos pagos, com cartão de crédito obrigatório. O Nano não exige cartão e permanece gratuito, conforme as condições vigentes.

Checklist de migração de e-mail: roteiro final

Esta versão resumida pode ser colada num chamado de mudança. Ela reúne controles mínimos para reduzir os modos de falha mais comuns numa virada IMAP real.

1. Inventarie cada caixa, alias, caixa compartilhada, grupo, rota e aplicativo de envio.
2. Confirme o que o IMAP transfere e o que exige exportação separada.
3. Copie as mensagens antigas antes da virada.
4. Reduza o TTL do MX com 24 a 48 horas de antecedência.
5. Prepare a autorização temporária de ambos no SPF se os sistemas antigo e novo enviarem durante a transição.
6. Execute a sincronização incremental final antes de trocar o MX, monitore mensagens tardias no servidor antigo e repita a sincronização quando necessário.
7. Valide por contagem de itens, conferência de pastas e testes reais de envio/recebimento.
8. Recrie perfis quando necessário, preservando dados locais. Não gaste horas “reparando” configurações em cache inválidas.
9. Arquive o histórico sem uso, conforme a retenção necessária, em vez de transferir tudo por padrão.
10. Mantenha acesso ao sistema antigo para reversão até concluir a validação.

Esse é o objetivo de um checklist de migração de e-mail: não elegância nem teoria, mas menos surpresas.

Se você procura um destino para migrações IMAP, compare os planos nos preços do TrekMail. Conforme o plano, a oferta descrita inclui domínios próprios, caixas IMAP, catch-all, SMTP próprio ou gerenciado, encaminhamento e migração integrada, sem cobrança por usuário.