Toda migração de e-mail que dá errado dá errado pelo mesmo motivo, e não é técnico.
A parte técnica é bem resolvida. A Microsoft tem ferramenta pronta, o processo é documentado, e copiar caixas de correio de um servidor para outro é coisa de décadas atrás. O que derruba projeto é descobrir, na segunda-feira de manhã, que o sistema de emissão de notas fiscais mandava e-mail por um SMTP que ninguém documentou — e que a nota não sai desde sexta.
Este artigo é sobre essa parte.
Antes de tudo: o inventário
Noventa por cento do sucesso está aqui, e é a etapa que todo mundo quer pular porque “é só o e-mail”.
Levante, por escrito:
As caixas de verdade. Quantas contas existem, quanto cada uma ocupa, e quais são pessoas de verdade. Em toda empresa existem contas de gente que saiu há três anos que ninguém desativou, e contas genéricas (contato@, financeiro@) que podem virar caixas compartilhadas — que não consomem licença e portanto reduzem o custo final.
Os aliases. Endereços alternativos que entregam na mesma caixa. O comercial que recebe em vendas@ e comercial@ vai perceber na hora se um dos dois sumir.
As listas de distribuição. todos@, diretoria@, obra-2@. Elas não vêm junto com as caixas; precisam ser recriadas.
As regras e os redirecionamentos. Especialmente o redirecionamento externo — o sócio que manda cópia de tudo para o Gmail pessoal. Isso muda a configuração de segurança que você vai querer aplicar depois.
Quem mais manda e-mail usando o seu domínio. E aqui mora a armadilha:
- o ERP mandando boleto e nota fiscal;
- o sistema de RH mandando holerite;
- a plataforma de e-mail marketing;
- o formulário do site;
- a impressora multifuncional que digitaliza e envia por e-mail;
- o sistema de monitoramento que manda alerta.
Essa lista é quase sempre maior do que a empresa imagina, e cada item esquecido é uma interrupção silenciosa na segunda-feira. Ninguém reclama que “a impressora parou de escanear” até precisar escanear.
Como está o DNS hoje. Onde o domínio está registrado, quem tem acesso ao painel, e o que já existe de SPF, DKIM e DMARC. Se ninguém na empresa sabe o login do registrador, descubra isso antes de marcar data. Já vimos projeto parar duas semanas esperando a recuperação de um acesso de domínio.
Escolhendo o tipo de migração
A Microsoft oferece caminhos diferentes, e a escolha depende de onde você está saindo e de quanto pode parar. A documentação de migração de caixas de correio detalha cada um; o resumo prático:
Corte (cutover). Tudo de uma vez, num fim de semana. Simples, barato, e a melhor opção para a maioria das pequenas empresas. O limite prático é o volume: se há 200 GB de caixas e a internet sobe a 10 Mbps, a conta não fecha num fim de semana — e isso precisa ser calculado antes, não descoberto no sábado.
Em estágios. Por grupos, ao longo de semanas. Reduz o risco, mas cria o período em que metade da empresa está num sistema e metade no outro — com o calendário compartilhado funcionando pela metade. Pede atenção à convivência.
Híbrida. Os dois ambientes coexistem de verdade, com fluxo integrado. É a opção certa para empresas grandes ou com exigência regulatória. Para uma empresa de 30 pessoas, é um canhão com custo de canhão.
IMAP. Quando você sai de um provedor genérico que só oferece IMAP. Funciona, mas traz só o e-mail — contatos, calendário e regras ficam para trás e precisam de um plano próprio.
Para a maioria das empresas pequenas e médias saindo de um provedor de hospedagem comum, o corte num fim de semana é a resposta certa — e a mais barata.
A semana da migração, dia a dia
Duas semanas antes
Baixe o TTL dos registros DNS, principalmente o MX, para 300 segundos. O TTL diz aos servidores do mundo por quanto tempo guardar a resposta antiga. Se ele está em 24 horas e você vira a chave no sábado, parte da internet continuará entregando no servidor velho até domingo.
Esse é o ajuste mais barato e mais esquecido da migração inteira. Feito com antecedência, a virada leva minutos. Esquecido, você passa o fim de semana explicando por que alguns e-mails ainda não chegaram.
Uma semana antes
Crie os usuários, as caixas compartilhadas, os grupos e os aliases. Não aponte o MX ainda. O ambiente fica pronto e vazio, esperando.
Aproveite para configurar SPF, DKIM e DMARC corretamente — e aqui vai um aviso: se você copiar o SPF antigo e só acrescentar a Microsoft, pode acabar com dois registros SPF no domínio. Dois SPF é o mesmo que nenhum: a validação falha e seus e-mails começam a cair em spam. Tem que haver um único registro, contendo todas as origens legítimas.
Avise as pessoas. Uma mensagem curta: o que muda, quando, e o que elas precisam fazer (normalmente nada além de entrar com a senha nova).
Sexta-feira
Rode a primeira sincronização com o MX ainda apontando para o servidor antigo. O volume grande sobe enquanto todo mundo trabalha normalmente, sem pressão.
Sábado
Sincronização final — só o delta, o que mudou desde sexta. Então vire o MX. Com o TTL baixo, a propagação é rápida.
Teste, de verdade:
- enviar e receber de fora;
- responder a uma mensagem antiga;
- o celular de três pessoas diferentes;
- a impressora escaneando;
- o ERP emitindo um documento;
- o formulário do site;
- o calendário compartilhado e as salas de reunião.
Segunda-feira
Alguém da equipe disponível e presente, não “a postos no celular”. As dúvidas são pequenas — senha de celular, assinatura que sumiu, um contato que não veio — mas chegam todas no mesmo intervalo de duas horas. Resolvidas na hora, a migração é lembrada como tranquila. Deixadas para a tarde, viram a história de que “a migração foi um caos”.
Nas semanas seguintes
Não desligue o servidor antigo. Deixe-o de pé, recebendo, por pelo menos 30 dias. É a sua rede de segurança — e custa quase nada mantê-lo mais um mês.
Depois de confirmado tudo: ative o MFA, faça backup do novo ambiente (a Microsoft não faz isso por você) e aperte o DMARC de p=none para p=quarantine.
Os cinco erros que mais vemos
- Não baixar o TTL. Transforma uma virada de minutos num fim de semana de explicações.
- Esquecer quem envia pelo domínio. A impressora, o ERP, o sistema de nota. Sempre há um.
- Dois registros SPF. Autenticação quebrada, e-mails legítimos em spam, e uma causa difícil de achar depois.
- Desligar o servidor antigo rápido demais. Economiza uma mensalidade e cria um risco desproporcional.
- Migrar sem backup do destino. Você saiu de um servidor que tinha fita e chegou a um ambiente sem nenhuma cópia. Tecnicamente migrou; na prática, regrediu.
Quanto tempo leva
Para uma empresa de 10 a 50 pessoas saindo de um provedor comum, o cronograma realista é:
- Semana 1 — inventário, decisões e ajuste de TTL;
- Semana 2 — criação do ambiente, DNS de autenticação, comunicado;
- Fim de semana — sincronização e virada;
- Semana 3 — acompanhamento, ajustes finos, segurança;
- Dia 30 — desligamento do ambiente antigo.
Três semanas de calendário, com algumas horas por dia. Quem promete “migramos no sábado” normalmente está olhando só para a cópia das caixas — e é justamente o resto que decide se a segunda-feira vai ser tranquila.
Se você está com uma migração marcada, o inventário é o melhor lugar para investir tempo. Se quiser uma segunda opinião sobre a sua lista antes da data, é uma conversa curta e costuma valer.