O Exchange Server, o servidor de e-mail que fica dentro da empresa, chegou ao fim do suporte da Microsoft em 14 de outubro de 2025 — tanto na versão 2016 quanto na 2019. Segundo a própria Microsoft, isso quer dizer que o produto parou de receber suporte técnico para problema que aparecer, correção de erro que afeta a estabilidade do servidor, correção de falha de segurança e até atualização de fuso horário. O servidor continua ligado e funcionando normalmente. O que muda é que, se uma vulnerabilidade nova for descoberta amanhã, ninguém vai mais corrigi-la.
Cobertura brasileira publicada logo depois do prazo lembrou que empresas de setor regulado — financeiro, saúde, serviços essenciais — correm o risco de falhar auditoria de conformidade ao continuar operando um sistema sem suporte, além de ficar mais exposta a ataque. Servidor de e-mail sem atualização é porta aberta, e é exatamente o tipo de porta que quem ataca sabe procurar primeiro.
Para quem aprova o orçamento, a pergunta não é mais se a migração vai acontecer — é quando, e com que nível de sobressalto. Feita com método, a troca do servidor de e-mail pelo Microsoft 365 (o antigo Office 365) passa quase sem ninguém perceber. Feita com pressa, é exatamente onde mensagem de cliente se perde.
O risco de manter o e-mail como está
A situação mais comum é conhecida: alguém instalou aquele servidor de e-mail anos atrás, montou as regras e as caixas do jeito que a empresa precisava, e não trabalha mais ali. Quem ficou responsável por TI hoje sabe que o sistema funciona, mas evita mexer — porque não sabe explicar todas as engrenagens que dependem dele, e o medo de derrubar o e-mail da empresa pesa mais do que o incômodo de deixar quieto.
O problema é que "deixar quieto" tem um prazo de validade que já passou. A Microsoft lista quatro coisas que simplesmente pararam: suporte técnico para dúvida ou incidente, correção de erro que compromete a estabilidade, correção de falha de segurança e atualização de fuso horário. As três primeiras aparecem no pior momento possível — quando algo já quebrou ou quando um invasor já encontrou o caminho.
É o tipo de situação que provedores de serviços gerenciados como a Skills IT veem com frequência: o servidor não avisa que está desatualizado, ele simplesmente continua rodando até o dia em que para — ou até alguém de fora encontrar uma falha que ninguém mais vai corrigir. Nesse meio-tempo, cada mês que passa é mês sem correção, empilhado sobre o anterior.
A própria Microsoft recomenda começar a planejar a saída do Exchange Server o quanto antes, apontando a migração para o Microsoft 365 como o caminho mais direto — um único movimento para deixar de lidar com atualização de servidor, compra de equipamento e manutenção de sala técnica, e passar a estar sempre na versão mais atual do e-mail, sem precisar de outro projeto de upgrade daqui a alguns anos.
Por que o jeito comum não resolve
O jeito comum, quando a decisão finalmente é tomada, costuma ser um de dois extremos: continuar adiando até o servidor realmente falhar, ou tentar resolver tudo num fim de semana, sem inventário e sem teste, na esperança de que "só vai copiar as caixas para a nuvem".
Pesquisa da Osterman Research com profissionais de TI de médias e grandes empresas que estavam migrando seus sistemas de comunicação, publicada em 2020, achou que quase metade considera garantir que tudo continue funcionando durante a migração — sistemas ligados, acesso liberado, nada quebrado no meio do caminho — a parte mais difícil do processo. Logo atrás, 37% apontaram como difícil administrar a convivência entre o e-mail antigo e o novo enquanto os dois seguem no ar ao mesmo tempo.
Isso tem um motivo prático: enquanto a troca não é concluída, mensagem endereçada a quem já foi migrado continua chegando no servidor antigo até o apontamento de entrega da internet mudar para o novo endereço. Se ninguém acompanhar essa janela, mensagem se perde nela — não porque a migração falhou, mas porque ninguém verificou o que ainda estava chegando no lugar errado.
Um "jeito comum" adicional, ainda mais arriscado: tentar mover todas as caixas de uma vez, sem separar por grupos. A própria Microsoft recomenda o oposto até para empresas pequenas — mover as caixas aos poucos, verificando cada leva antes de seguir para a próxima, mesmo quando o limite técnico permitiria mover tudo junto.
O que precisa existir na prática
Uma migração de e-mail bem-feita se apoia em mecanismos concretos, não em torcer para dar certo.
Um inventário de caixas e do que depende de cada uma. Antes de mover qualquer coisa, alguém precisa listar quem usa cada endereço e quais sistemas de fora enviam para ele — cobrança, boleto, alerta de equipamento, portal de fornecedor. É o que costuma faltar quando a migração "descobre" um sistema quebrado só depois de pronta.
Migração em ondas, não tudo de uma vez. Grupos pequenos primeiro — um setor, uma filial —, com verificação antes de passar para o próximo grupo. Erro visto cedo, num punhado de caixas, é fácil de corrigir; o mesmo erro espalhado por toda a empresa não é.
Um período de convivência entre o servidor antigo e o novo. Enquanto a troca não termina, os dois sistemas seguem ligados e mensagem pode chegar em qualquer um dos dois. Alguém precisa acompanhar essa janela até o apontamento de entrega mudar de vez para o novo endereço.
Conferência antes de desligar o que ficou para trás. Cada caixa migrada é conferida — histórico, pasta, contato — antes de qualquer servidor antigo ser desligado. Desligar primeiro e conferir depois é como a mensagem perdida vira definitiva.
Um plano para o histórico e os anexos antigos. Nem tudo precisa ir para o novo sistema no primeiro dia; o que importa é decidir, e registrar a decisão, em vez de deixar mensagem antiga para trás por esquecimento.
É assim que a Skills IT trabalha: inventário antes de mexer em qualquer caixa, migração em ondas com conferência entre uma e outra, e o servidor antigo só sai do ar depois que o novo já provou que está recebendo tudo certo.
O que a empresa ganha depois
O ganho mais direto é deixar de manter um equipamento dentro de casa: sem compra de servidor novo daqui a alguns anos, sem sala fria para climatizar, sem alguém de plantão torcendo para o disco não falhar num fim de semana. A conta de manter aquele servidor — energia, hardware, tempo de quem cuida dele — some da planilha e vira uma mensalidade previsível, dentro do que já está definido em contrato.
Tem também o ganho de quem trabalha com aquele e-mail todo dia: caixa maior, sistema sempre na versão mais recente, integração nativa com agenda, arquivo e reunião — sem depender de outro projeto de atualização daqui a um tempo. E, para quem decide, a vantagem central é não precisar mais torcer: com o servidor de e-mail fora de casa e sempre atualizado, a pergunta deixa de ser "isso ainda aguenta?" e passa a ser sobre o que a empresa quer fazer com o tempo que sobrou.
Nenhum desses ganhos depende de pressa. Eles dependem de a migração ter sido feita com inventário, em ondas, com conferência — o oposto do fim de semana improvisado que costuma ser a origem da mensagem perdida.
Perguntas para decidir a migração
Antes de marcar uma data para começar, vale levar estas perguntas para a próxima conversa entre a direção e quem responde pela TI:
- Alguém sabe, hoje, quais sistemas de fora dependem de um endereço de e-mail específico? Cobrança, boleto, alerta de máquina, portal de cliente — se a resposta não existe no papel, a migração vai descobrir isso na marra, um sistema quebrado por vez.
- Existe um inventário das caixas ativas e das que só continuam ali por causa do histórico? Migrar sem saber o que cada caixa carrega é decidir no escuro o que fica e o que se perde.
- Quem vai conferir cada leva de caixas antes de seguir para a próxima? Sem esse passo, um erro pequeno no início vira um problema grande no fim.
- O que acontece com o histórico de e-mail quando o servidor antigo for desligado? A resposta precisa existir antes do desligamento, não depois.
- Quem é o responsável único por essa migração, dentro e fora da empresa? Uma migração sem dono definido é a receita mais comum para mensagem perdida.
