Etapas da migração de email: calendário diário seguro

Etapas da migração de email: um calendário diário que reduz interrupções

Estas etapas não são uma simples cópia de ficheiros. Servem para gerir uma transição de estado entre duas bases de dados ativas enquanto os utilizadores alteram dados nas duas pontas. Se a camada de dados (IMAP) ficar dessincronizada da camada de encaminhamento (DNS), cria um encaminhamento dividido: parte da organização recebe correio no servidor antigo e outra parte no novo.

Este procedimento apresenta as etapas de cada dia, desde T-7 até T+1. Sem teoria, apenas a sequência de execução. Para aprofundar a arquitetura, consulte o guia completo de configuração de email.

As três camadas que está a gerir

Toda a migração de email envolve três camadas. Uma falha em qualquer uma pode causar uma interrupção.

1. Camada de dados: as mensagens antigas (IMAP)
2. Camada de encaminhamento: os registos DNS (MX) que determinam onde chega o correio novo
3. Camada de identidade: a configuração dos clientes (Outlook e aplicações móveis) utilizados para aceder ao correio

T-7 dias: levantamento e limpeza

Não pode migrar aquilo cuja existência desconhece. Uma lista de utilizadores não é um inventário. Estas primeiras etapas servem para criar uma visão completa.

Faça um inventário completo

• Registe todos os tipos de objeto: caixas de correio, aliases, listas de distribuição e pastas públicas
• Identifique as caixas gigantes: procure caixas com mais de 20 GB. A Google limita as transferências IMAP a cerca de 2,500 MB/dia. Uma caixa de 50 GB pode demorar semanas, não horas. O guia de migração de dados do Google Workspace documenta estes limites em pormenor.
• Limpe os dados inativos: os antigos colaboradores não precisam de caixas ativas. Exporte-os para arquivos locais.

Se estiver a migrar do Exchange, utilize o PowerShell para obter a contagem real de itens, pois o tamanho em GB não é fiável devido à compressão:

T-2 dias: sincronização de pré-carregamento

Não espere pela noite de sexta-feira. Transfira 90% dos dados históricos enquanto os utilizadores ainda trabalham. Este pré-carregamento reduz bastante o risco durante a transição.

Inicie a sincronização

Configure a ferramenta de migração, ou o imapsync, para transferir mensagens com mais de 30 dias. Monitorize os erros HTTP 429 (demasiados pedidos) ou Google 11001.

Limites que deve conhecer

Aviso para o Gmail: não migre diretamente a pasta «Todo o correio» além de cada etiqueta. O Gmail utiliza etiquetas em vez de cópias distintas, mas uma associação incorreta entre etiquetas e pastas pode criar duplicados no destino. Associe as etiquetas a pastas e exclua Gmail/All Mail deste percurso.

T-1 dia: redução do TTL (a regra dos 300 segundos)

Os registos DNS ficam muitas vezes em cache durante 24 horas (TTL 86,400). A redução do TTL é uma das etapas mais esquecidas e mais lamentadas. Se mudar os MX sem reduzir primeiro o TTL, alguns resolvedores podem continuar a encaminhar correio para o servidor antigo até a cache expirar.

1. Inicie sessão no seu fornecedor DNS (Cloudflare, Route53, etc.)
2. Localize os registos MX
3. Altere o TTL para 300 segundos (5 minutos)
4. Não elimine ainda os registos antigos; limite-se a atualizar o TTL

Confirme com o dig:

T-0 (sexta-feira à noite): a transição

Os utilizadores pararam de trabalhar. Execute a mudança. Estas são as etapas mais delicadas da migração.

Passo 1: congele a atividade

Peça aos utilizadores que deixem de enviar correio. Se possível, bloqueie as contas na origem para evitar mensagens órfãs.

Passo 2: sincronização diferencial

Volte a executar a ferramenta de migração. Esta passagem recolhe os últimos 30 dias e todos os itens novos. Como a maioria dos dados já foi transferida, deverá ser mais curta do que o pré-carregamento, mas a duração depende do volume e dos limites do fornecedor.

Procure problemas de UIDVALIDITY: se o servidor de origem tiver reindexado as pastas, a ferramenta pode transferir duplicados. Execute sempre primeiro uma simulação. O RFC 3501 do IMAP explica em pormenor a semântica do UIDVALIDITY.

Passo 3: mude os registos MX

Atualize os registos MX para o novo fornecedor. Para utilizadores da TrekMail:

Com um TTL de 300 segundos, as caches que o respeitem podem atualizar-se em cerca de 5 minutos. Outros resolvedores podem demorar mais.

Passo 4: atualize o SPF e o DKIM

Publique e confirme a autorização dos novos IP no SPF antes de o novo fornecedor começar a enviar, mantendo as fontes antigas enquanto ainda estiverem ativas. Para saber mais sobre a autenticação de email no seu domínio, consulte o nosso guia específico.

T+1 (segunda-feira de manhã): verificação

As últimas etapas centram-se na validação. Não presuma que tudo correu bem; confirme o resultado.

Verificação da contagem de itens

Compare a contagem de itens da origem e do destino. Uma diferença inferior a 1% pode dever-se a itens MIME danificados e deve ser documentada. Segundo esta política operacional, uma diferença superior a 5% exige a investigação de um problema geral, como limites na profundidade das pastas ou filtros mal configurados.

Reconfiguração dos clientes

Consoante o cliente de email e a alteração do serviço, os utilizadores terão de reconfigurar a conta existente ou removê-la e adicionar a nova.

Calendários e contactos

A TrekMail oferece alojamento profissional de email para empresas, incluindo calendários no servidor através de CalDAV e contactos através de CardDAV. No entanto, a migração IMAP transfere apenas mensagens. Exporte os calendários (.ics) e os contactos (.vcf) do fornecedor antigo e depois importe-os para a TrekMail. Após configurar as contas, estes dados serão sincronizados nos dispositivos compatíveis.

Pontos de controlo para avançar ou parar

O plano de reversão

Se o sistema novo rejeitar correio ou faltarem dados essenciais:

1. Reponha os MX: volte a apontá-los para o fornecedor antigo. Com um TTL de 300s, algumas caches podem atualizar-se em 5 minutos, mas a recuperação completa pode demorar mais
2. Exporte o intervalo: mantenha o fornecedor novo acessível e repita a reconciliação; todo o correio que ali chegar até as caches DNS expirarem deve ser exportado em EML/MBOX e importado para o servidor antigo
3. Faça o diagnóstico: procure erros 550 5.7.1 (Relay Access Denied) ou bloqueios da firewall antes de tentar novamente

A TrekMail automatiza estas etapas de migração

Uma migração manual exige muito trabalho e envolve riscos. A TrekMail automatiza parte da infraestrutura para que se possa concentrar nos clientes.

Para pequenas empresas

Não pague por funções que não utiliza. A ferramenta de migração integrada da TrekMail gere a ligação IMAP, as novas tentativas e a lógica de limites para os dados suportados. Introduza as credenciais, acompanhe o processo e faça uma conferência final com a origem.

Para agências e MSP

Aprovisionamento em massa para mais de 100 domínios. Armazenamento partilhado entre todos os clientes em vez de limites por utilizador. SMTP gerido que reduz a necessidade de gerir o aquecimento do IP.

Todos os planos pagos incluem uma avaliação gratuita de 14 dias e exigem um cartão. O plano Nano não exige cartão.

Conclusão

Estas etapas seguem um calendário rigoroso porque cada fase depende da anterior. Se não reduzir o TTL, o encaminhamento pode permanecer dividido até 24 horas, conforme as caches expirem. Se ignorar o pré-carregamento, a janela de transição pode demorar muito mais do que o previsto.

Siga o calendário, compare a contagem de itens e mantenha um plano de reversão preparado. Esta é a fórmula completa.

Quer começar? Crie a sua conta TrekMail gratuita e utilize o motor de migração integrado para reduzir o trabalho manual.