Como migrar e-mail sem perder dados nem interromper o serviço

Como migrar e-mail sem perder dados nem causar interrupções evitáveis

Migrar e-mail entre provedores não é apenas copiar arquivos. Você sincroniza uma base ativa enquanto chegam mensagens, usuários apagam itens e metadados mudam. Uma preparação ruim pode dividir o roteamento, omitir mensagens e causar problemas na segunda-feira.

Este guia apresenta um plano por fases para pequenas empresas, com preparação de DNS, estratégia IMAP, mudança e verificação. Nenhum processo garante ausência total de interrupção ou perda, mas estes controles reduzem o risco.

Por que muitas migrações falham

Três omissões causam boa parte dos incidentes. Entendê-las antes evita descobri-las em produção.

Cache de DNS: sem reduzir o TTL antes da mudança, alguns resolvedores podem enviar e-mail aos servidores antigo e novo por até 24 horas.
Limitação: provedores como o Google podem limitar downloads IMAP a cerca de 2,500 MB/dia conforme conta e política. A sincronização então desacelera ou para.
Ampliação do escopo: IMAP transfere apenas e-mail compatível. Calendários e contatos usam outros protocolos, como CalDAV e CardDAV.

Fase 1: auditoria técnica (7 dias antes)

Não é possível migrar o que você desconhece. Primeiro, crie um inventário técnico.

Mapeie identidades ocultas

Uma lista de usuários não basta. Registre todos os pontos de entrada:

• Aliases: john@ também recebe por sales@? Esquecer o alias no destino pode gerar rejeições.
• Listas de distribuição: team@ e info@ são caixas compartilhadas ou grupos de encaminhamento?
• Encaminhamentos: audite regras no servidor. Regras ocultas para Gmail pessoal falharão se não forem recriadas e autorizadas.

Identifique caixas muito grandes

Localize caixas acima de 10 GB. O IMAP faz muitas operações, e uma caixa de 50 GB pode demorar. O Microsoft 365 pode limitar o tráfego após cerca de 20 GB/dia conforme o serviço. Inicie uma pré-sincronização para esses usuários pelo menos 5 dias antes. O guia de migração do Google Workspace documenta condições atuais.

A realidade da migração apenas de e-mail

Ferramentas como imapsync e o motor do TrekMail usam o protocolo IMAP (RFC 3501). O IMAP transfere apenas e-mails compatíveis.

Calendários e contatos não fazem parte do IMAP. Eles usam formatos ou protocolos distintos, como Exchange e CalDAV. Peça aos usuários que exportem calendários (.ics) e contatos (.vcf ou .csv) antes de cancelar a assinatura antiga e teste a importação.

Fase 2: preparação da infraestrutura (48 horas antes)

Ainda não mova os dados. Prepare primeiro destino e roteamento.

A regra de 300 segundos para TTL de DNS

O TTL informa por quanto tempo um resolvedor pode armazenar um registro DNS. Com 86,400 segundos (24 horas), alguns continuarão usando o valor antigo até o cache expirar.

No provedor DNS, como Cloudflare, GoDaddy ou Route53, ajuste o TTL do MX para 300 segundos quando possível. Faça isso ao menos 24 horas antes e confirme o valor publicado.

Prepare o destino

Crie as caixas no novo provedor. No TrekMail, configure domínios e usuários no painel. No Nano, informe credenciais SMTP externas, como SES ou Mailgun, e teste o envio antes da mudança.

Confirme credenciais válidas das caixas de origem. Caso contrário, redefina-as ou use uma credencial administrativa compatível e autorizada.

Fase 3: estratégia de pré-sincronização

Evite mover tudo em uma única noite. Fazer a migração em etapas reduz volume e risco na mudança final.

Etapa 1: rodada histórica (3 dias antes)

Configure a ferramenta para copiar e-mails anteriores a 7 dias. Conforme o uso, isso pode mover cerca de 95% do volume enquanto todos trabalham. Se um anexo de 2 GB falhar, haverá tempo para investigar.

Monitore erros HTTP 429 ou "User is throttled". Se aparecerem, reduza a concorrência, por exemplo para 5 usuários em vez de 50, e siga a orientação do provedor.

Etapa 2: pausa operacional (momento da mudança, sexta-feira à noite)

Avise os usuários e peça que não enviem mensagens durante a janela. Se possível, deixe a origem somente para leitura sem bloquear recebimentos. Trocar senhas pode criar outros riscos; documente e teste o procedimento.

Etapa 3: sincronização incremental

Execute novamente a ferramenta para copiar os últimos 7 dias e reconciliar itens alterados. Se quase 95% dos dados já estiverem no destino, esta rodada costuma ser menor, mas depende de volume, limites e diferenças entre servidores.

Fase 4: mudança de serviço

Altere os registros MX

Troque os MX pelos valores do novo provedor. Para o TrekMail, são indicados:

Com TTL de 300 segundos, muitos resolvedores mudam rapidamente, mas caches externos podem prolongar a transição. Mantenha e monitore os dois sistemas.

Autenticação SPF e DKIM

A mudança exige atualizar e validar os registros de autenticação. A ausência deles pode prejudicar a entrega e favorecer o spam, embora não determine sozinha o resultado.

• SPF: atualize o TXT sem criar vários registros SPF. Exemplo: v=spf1 include:spf.trekmail.net -all
• DKIM: gere chaves no painel novo, adicione registros CNAME ou TXT ao DNS e confirme a assinatura.

Veja como configurar e-mail no domínio.

Confira os serviços antigos

Se você sair do Google Workspace mas mantiver Drive ou Docs, o Gmail pode continuar capturando e-mail interno conforme a configuração. Desative o Gmail nos usuários afetados ou configure entrega dividida e teste rotas internas e externas.

Fase 5: verificação

Não dependa apenas da impressão dos usuários. Use métricas e amostras.

Contagem de itens, não tamanho

Não compare apenas GB, pois compressão e representação variam. Compare a quantidade de itens por pasta:

Uma diferença abaixo de 1% não deve ser aceita automaticamente: pode vir de itens corrompidos, duplicados ou incompatíveis. Acima de 5% exige investigação urgente. Documente exceções.

Hierarquia de pastas

Procure pastas achatadas. Uma árvore como Clients/2024/Project A/Invoices/Paid pode ser truncada. Confira também namespaces como INBOX.Sent e Sent.

Solução de falhas comuns

Motor de migração integrado do TrekMail

Se coordenar IMAP, limites e propagação DNS for trabalhoso, o motor do TrekMail automatiza parte do processo. O administrador ainda cuida de DNS, permissões, dados fora do escopo e verificação final.

Para pequenas empresas (1 a 50 usuários)

O TrekMail inclui um motor de migração. Conecte um provedor compatível, como Gmail, Outlook ou cPanel, selecione caixas e execute. A infraestrutura gerencia novas tentativas, limites e duplicatas conforme suas capacidades. Confira relatórios e reconcilie com a origem; o fluxo compatível não exige linha de comando.

Para agências (100+ domínios)

Gerenciar migrações de vários clientes consome tempo. O TrekMail oferece operações em massa, armazenamento compartilhado entre domínios e preço fixo nos limites do plano.

Os planos pagos descritos incluem teste de 14 dias com cartão. O Nano é anunciado sem cartão. Confirme preços, elegibilidade e condições atuais.

Conclusão: como migrar corretamente

A migração fica controlável quando o processo é respeitado. Pré-carregue dados, reduza o TTL para 300 segundos, execute sincronização incremental e confira contagens, amostras e exceções. O objetivo também é adotar uma infraestrutura que atenda às necessidades de e-mail empresarial com custos previsíveis.

Para testar o motor integrado, crie uma conta gratuita no TrekMail, confirme a compatibilidade da origem e comece por uma caixa não crítica.